SPF glossary
What does the mx mechanism do in an SPF record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The mx mechanism authorizes the hosts listed in a domain's MX records — the servers that receive its mail. It costs one DNS lookup plus an address lookup per MX host, and it's frequently cargo-culted: inbound MX servers usually aren't the outbound senders, so mx often authorizes nothing useful while burning budget.
mx at a glance | |
|---|---|
| Tag | mx (mechanism) |
| Valid values | mx · mx:<domain> · mx/<cidr> |
| Default | Bare mx defaults to the current domain's MX hosts. |
| Where it goes | Between v=spf1 and the final all, like any mechanism. |
How mx works
The mx mechanism looks up the domain's MX records — the hosts nominated to receive its mail — and matches if the sending IP belongs to one of them. Bare mx means the current domain; mx:otherdomain.com and a CIDR form like mx/24 exist too.
It's expensive. The mx term itself costs one of the 10 lookup-triggering terms, and resolving each MX host to addresses costs further lookups — RFC 7208 caps those at 10 per mx term. A domain with several MX hosts pays a lot of DNS for one mechanism.
It's also the most cargo-culted term in SPF. With Google Workspace or Microsoft 365, receiving and sending run on separate infrastructure, and the provider's include already authorizes the actual senders — so mx authorizes nothing useful and just burns budget. The legitimate case is a self-hosted server that genuinely both receives and sends mail on the same host.
Correct record vs common mistake
Correct
v=spf1 mx -allLegitimate on a self-hosted mail server that really does send from the same host it receives on.
Common mistake
v=spf1 mx include:spf.protection.outlook.com -allMicrosoft 365's include already authorizes the real outbound senders. The mx term duplicates nothing useful — inbound MX hosts don't send your mail — and burns lookups.
Generate your SPF record
Build a correct SPF record for your domain — add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider's docs, e.g. spf.example-esp.com — commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include — check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 DNS lookupsPublish as a TXT record at the domain root. One SPF record per domain — if one exists, merge into it instead of adding another.
yourdomain.com (or @)
v=spf1 ~all
Record type: TXT · ip4/ip6 mechanisms don't count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn't stop spoofing — pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting mx
| Issue | Likely cause | Fix |
|---|---|---|
| 'Too many DNS lookups' with mx in the record | mx plus its per-host address lookups eat the budget fast | Remove mx unless the MX hosts genuinely send outbound mail; rely on the provider include or ip4 |
| SPF passing for a server that shouldn't send | mx authorizes every MX host — including a backup MX you don't operate | Drop mx and authorize only the actual outbound senders explicitly |
| SPF behavior changed after a mail-provider migration | The MX records changed, silently changing what mx authorizes | Prefer explicit include/ip4 terms you change deliberately — not as a side effect of an MX cutover |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
A templated mx replicated across 50–200 client records burns one or more lookups per tenant for zero coverage — budget you'll want back the day a client onboards one more SaaS tool and tips over the 10-lookup wall. It can also quietly authorize a backup-MX host a client doesn't control. At fleet scale, mx is usually dead weight with a side of risk.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
Whether a client's MX hosts ever send outbound mail isn't a matter of opinion — it's in the report data. Palisade reads each domain's DMARC reports, so you can see exactly which sources send and prune cargo-culted `mx` terms with evidence, keeping every tenant's record lean on the way to `p=reject`.
Free 15-day trial · No credit card · Your own domain free forever (NFR)