English Nederlands Español Italiano 日本語 Français
Log in

SPF|A and MX Records

SPF records used to include “a” and “mx” mechanisms almost by default: early SPF generator tools made them mandatory, whether a domain actually needed them or not. That advice hasn’t aged well: today, including them is one of the more common ways an SPF record ends up silently broken. (New to SPF? Start with SPF | Guidelines for the fundamentals.)

DNS round-robin breaks A/MX-based SPF

Many mail servers sit behind load balancers that return a different set of IP addresses on every query (a pattern called round-robin, or “ flapping”). If your SPF record includes an “a” or “mx” mechanism that resolves to one of these, the IP a message actually came from may not match whatever your SPF check happened to resolve, causing authentication to fail intermittently and unpredictably.

Why it matters

The mx mechanism authorises whatever IP addresses your domain’s currently point to, but exist to handle incoming mail, not to describe who’s allowed to send. Your actual outbound mail provider (Microsoft 365, Google Workspace, and similar) already gives you a dedicated include mechanism listing every IP that’s genuinely allowed to send on your behalf; that’s the mechanism your SPF record should use instead. The a mechanism has the same problem in reverse: it authorises your domain’s website IP, and most websites don’t send mail directly at all anymore: they hand that off to a separate email service provider.

How it works

Beyond simply being the wrong tool for the job, a and mx both resolve at evaluation time: every time a receiving server checks your SPF record, it re-resolves whatever hostname those mechanisms point to. If that hostname sits behind a load balancer using round-robin, the set of IPs it resolves to can change from one query to the next. A message that was sent from an IP address that was valid a moment ago can fail SPF simply because the next lookup returned a different set of addresses.

A worked example of DNS flapping

Here’s what that round-robin behaviour actually looks like in practice, using a real-world MX hostname queried twice in quick succession:

Query 1:
mta5.am0.yahoodns.net.  60  IN  A  67.195.228.110
mta5.am0.yahoodns.net.  60  IN  A  98.136.96.74
mta5.am0.yahoodns.net.  60  IN  A  67.195.204.74
mta5.am0.yahoodns.net.  60  IN  A  67.195.228.106

Query 2:
mta5.am0.yahoodns.net.  11  IN  A  67.195.228.94
mta5.am0.yahoodns.net.  11  IN  A  67.195.228.111
mta5.am0.yahoodns.net.  11  IN  A  67.195.204.73
mta5.am0.yahoodns.net.  11  IN  A  98.136.96.74

Two queries, seconds apart, and almost none of the IP addresses match. If this hostname were referenced by an a or mx mechanism in an SPF record, which of these addresses gets authorised depends entirely on the moment a receiving server happens to look it up. That’s exactly the kind of intermittent, hard-to-diagnose authentication failure this causes in practice.

I need more information

What to use instead

  • Use the include mechanism your mail provider gives you (for example include:spf.protection.outlook.com for Microsoft 365) rather than mx.
  • If you need to authorise specific, stable IP addresses directly, use ip4 or ip6 instead of a.
  • Both a and mx also count towards the -lookup limit; see SPF | Guidelines for the full limit and which other mechanisms count toward it.

None of this means a and mx are forbidden outright: they’re valid SPF mechanisms, and there are narrower, deliberate cases where they’re genuinely the right tool (for instance, authorising a mail server hostname’s own identity, which does need a matching “A” record). The recommendation is specifically about using them as a default, unexamined choice for authorising your general sending infrastructure.

Good to know

Manager’s Sender Manager checks for hostnames that exhibit flapping and will warn you before you add one to an SPF record, specifically to catch this failure mode before it reaches production.

References & further reading