MX Records and SPF

MX records tell the world where to deliver mail for your domain. The SPF mx mechanism says outbound senders on those same hosts may also send as you. In classic on-premise setups, that coupling made sense.

Modern cloud email often breaks the assumption that MX hosts send employee mail. Microsoft 365 and Google Workspace use includes precisely because their outbound IPs are not simple A records of your MX names.

Knowing when mx is appropriate prevents both lookup waste and false confidence that your MX configuration alone authorizes SaaS senders.

The mx mechanism triggers an MX lookup on the domain being evaluated, then resolves each MX hostname to A or AAAA records. Those IPs are compared to the connecting client. An mx:subdomain.example.com variant scopes lookups to another domain's MX set.

Each step consumes DNS lookups, so mx is more expensive than static ip4 entries. For Google Workspace, include:_spf.google.com is the supported pattern rather than mx alone.

Some legacy documentation still recommends mx for simple self-hosted Postfix or Exchange edge servers. Validate with actual SMTP egress IPs after any MX migration because receiving and sending paths may diverge in split architectures.

Incorrect mx reliance leaves cloud outbound mail unauthorized while DNS appears superficially correct to non-specialists. Migration projects to hosted mailbox providers often stall on this misunderstanding.

Unnecessary mx mechanisms add lookup overhead that can push crowded records into PermError, affecting all mail streams on the domain.

- Using mx alone for Microsoft 365 or Google Workspace instead of provider includes
- Assuming MX points to the same IPs used by marketing ESPs
- Forgetting that mx lookups count toward the ten-lookup SPF limit