SPF mx Mechanism: When and Why to Use It

The SPF mx mechanism is one of the most misunderstood pieces of SPF syntax. It's useful in some configurations and a deliverability liability in others. This guide covers what mx does, when to use it, when to avoid it, and how it counts against the SPF 10-lookup limit.

If you're configuring SPF for a typical ESP-based sender (Google Workspace, SendGrid, Klaviyo), you almost certainly don't want mx. Use the provider's include.

What the mx mechanism does

The mx mechanism in SPF authorizes any IP listed in your domain's MX (Mail Exchanger) records to send mail for your domain. SPF evaluation looks up your MX records, then resolves each MX target's A record, then checks if the sending IP matches any of those.

; MX records
acme.com.  MX  10  mail.acme.com.
acme.com.  MX  20  mail2.acme.com.

; A records for MX targets
mail.acme.com.   A  192.0.2.1
mail2.acme.com.  A  192.0.2.2

; SPF record using mx
acme.com.  TXT  "v=spf1 mx ~all"

In this example, any mail from 192.0.2.1 or 192.0.2.2 passes SPF for acme.com.

When to use mx

The mx mechanism makes sense when:

1. Self-hosted mail server where the same machine handles inbound (MX) and outbound (SMTP submission and outbound transfer).
2. Small office setup with one Postfix server doing both jobs.
3. Mail-in-a-Box, Mailcow, or similar all-in-one stacks that ship with this assumption.
4. Migrating between hosts and you want SPF to authorize whichever IP your MX resolves to.

For Mailcow setup specifics, see Mailcow setup guide. For Postfix, see Postfix Dovecot setup.

When to avoid mx

Skip mx when:

1. You use Google Workspace. Outbound goes through Google's relays, not your MX. Use include:_spf.google.com.
2. You use Microsoft 365. Same — outbound goes through Microsoft. Use include:spf.protection.outlook.com.
3. You use any cloud ESP for outbound. Use their include.
4. You have third-party MX (a security gateway, anti-spam service) that doesn't handle outbound. Authorizing them wastes lookups and authorizes IPs that shouldn't be sending as you.
5. You're trying to stay under 10 lookups and don't strictly need mx.

Common mistake: a domain on Google Workspace with v=spf1 mx include:_spf.google.com ~all. The mx here resolves to Google's MX IPs (used for inbound only) but those don't send outbound for the domain. It's wasted lookups.

DNS lookup math

The mx mechanism consumes:

• 1 lookup for the MX query
• 1 lookup for each MX host's A record (up to 10)
• Plus any AAAA lookups if the records have IPv6

A domain with 2 MX records consumes 3 lookups via mx. With 5 MX records, 6 lookups.

Combined with other mechanisms, you eat through your 10-lookup budget fast:

v=spf1 mx include:_spf.google.com include:sendgrid.net ~all
;       3  +  4                  +  2                  = 9

For the full lookup-limit discussion, see SPF multiple providers.

Practitioner note: I had a client whose SPF was at permerror because they had mx plus three ESP includes plus a flattening-service include. Removing mx (which wasn't authorizing anything legitimate anyway — their outbound was all ESP) immediately resolved it.

mx variants

Two qualifiers commonly seen with mx:

• mx — authorize IPs from this domain's MX records
• mx:otherdomain.com — authorize IPs from another domain's MX records

The second form is rare and usually wrong. If you need to authorize someone else's mail server, use include: or a: instead.

Alternatives to mx

If you don't want to use mx, the alternatives:

Pattern	When to use
include:provider.com	Cloud ESP or third-party provider
a:mail.acme.com	Specific named host
ip4:192.0.2.0/24	Fixed IP range (no lookup)
ip6:2001:db8::/32	Fixed IPv6 range (no lookup)

For high-volume senders trying to minimize lookups, ip4: directly avoids any lookup cost but requires manual updates when IPs change.

A realistic SPF for self-hosted mail

A small business running Mailcow on a single VPS:

acme.com.  TXT  "v=spf1 mx ~all"

Simple, single lookup chain (1 for MX + 1 for A = 2 lookups total assuming 1 MX record), authorizes the actual sending server.

If they later add SendGrid for marketing:

acme.com.  TXT  "v=spf1 mx include:sendgrid.net ~all"

Total lookups: 2 (mx chain) + 2 (sendgrid) = 4. Plenty of headroom.

A realistic SPF for ESP-only sender

A SaaS startup on Google Workspace + SendGrid:

acme.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

No mx. Their MX records point to Google for inbound, but outbound is also Google for staff mail (covered by _spf.google.com) and SendGrid for app mail. The mx mechanism would be redundant and wasteful.

Practitioner note: A useful audit question for any SPF record: for each mechanism, what is it actually authorizing and is that thing actually sending mail as you? If mx is in your record but you're 100% on cloud providers, remove it. Every unused mechanism is wasted lookups and increased blast radius.

Debugging mx-related SPF issues

When SPF returns permerror and mx is involved:

# Check what mx resolves to
dig MX yourdomain.com
dig A mx-target.yourdomain.com

# Count effective lookups
# Use mxtoolbox.com SPF Survey

# Test SPF for a specific IP
# Use kitterman.com SPF validator

If mx is resolving to unexpected hosts (e.g., a third-party security gateway you forgot about), that's authorizing IPs you don't want authorized.

If you need help auditing SPF records, deciding whether to use mx, or untangling SPF that's at permerror, book a consultation. I do SPF audits and rewrites for senders combining self-hosted mail with cloud providers.

Sources

• RFC 7208 — SPF — IETF
• MXToolbox SPF mechanism reference — MXToolbox
• Google Workspace SPF documentation — Google
• Microsoft 365 SPF setup — Microsoft
• Postfix SPF configuration — Postfix

---

v1.0 · May 2026