Understanding SPF mechanisms: a, mx, ip4, and include

SPF defines 8 mechanisms in RFC 7208 §5: all, include, a, mx, ptr, ip4, ip6, and exists. The four you will use 95% of the time are ip4 (authorize a specific IPv4 address or CIDR range), a (authorize the domain’s A/AAAA records), mx (authorize the domain’s MX records), and include (delegate evaluation to another domain’s SPF record).

“SPF syntax is deceptively simple,” says Adam Lundrigan, CTO of DuoCircle. “v=spf1 followed by mechanisms and a qualifier looks straightforward, but the evaluation semantics are surprisingly complex — mechanism ordering matters, the first match wins, and the difference between ~all and -all has real delivery consequences. We see records every week where a misplaced mechanism silently overrides the intended policy.”

Each mechanism has a specific DNS-lookup cost that counts against the RFC 7208 10-lookup limit:

• ip4 / ip6 — 0 lookups (literal IP, no DNS needed)
• a — 1 lookup
• mx — 1 lookup plus 1 per MX host returned (can silently blow the budget on domains with many MXs)
• include — 1 lookup plus whatever the included SPF record consumes recursively
• exists — 1 lookup
• ptr — 1+ lookups (and RFC 7208 §5.5 explicitly recommends AGAINST using it)

This guide walks through each of the four commonly-used mechanisms with exact syntax, the corner cases (multi-IP A records, MX hosts with many A records, recursive includes), and how to choose between a/mx/ip4/include when you have multiple options for the same set of sending IPs.

‘a’ mechanism

The ‘a’ mechanism in SPF tells receiving mail servers that if a particular domain’s A or AAAA record points to the IP address sending the email, then consider it legit.

So basically, if an email is coming from an IP that’s listed in the domain’s A (ip4) or AAAA (ip6) records, and you’ve included the ‘a’ mechanism, then SPF passes.

For example; v=spf1 a -all

When should you use the ‘a’ mechanism?

Use it when:

• Your email server shares the same IP address as your domain (e.g., website and mail server hosted on the same server).

• You’re running a small, simple setup, and your sending IP is directly tied to your domain’s A/AAAA record.

• You’re sure that the domain’s A record will always reflect your mail server’s IP (this is key).

When should you avoid the ‘a’ mechanism?

Refrain from using the ‘a’ mechanism when:

• You don’t know or control what the A record points to (e.g., you’re using third-party hosting or CDNs).

• Your website and mail server are hosted separately on different IP addresses.

• You want your SPF record to be explicit and maintainable, using ‘ip4’ or ‘include’ for clarity.

Additionally, if your domain’s A record ever changes (such as during a server migration), you may inadvertently break SPF for your outbound emails without realizing it.

‘mx’ mechanism

In SPF, the ‘mx’ mechanism tells the receiving servers that it allows any server listed in the sending domain’s MX record to send emails on behalf of the domain owner. It basically resolves the domain’s MX record to get the hostnames. Then it resolves the hostnames to IP addresses. If the IP address of the sender of your email matches one of the listed IP addresses, the SPF check passes.

When should you use the ‘mx’ mechanism?

Use the ‘mx’ mechanism if your email is being sent through the same mail servers that receive emails for your domain, i.e., your inbound and outbound mail servers are the same.

Common cases:

• You’re using your web host or domain provider’s email service (like GoDaddy or Bluehost email).

• You have an on-premise mail server (like Microsoft Exchange) that handles both incoming and outgoing mail.

• Your company uses a setup where the same provider handles both inbound and outbound mail flow.

When should you avoid the ‘mx’ mechanism?

It’s not ideal to use the ‘mx’ mechanism if your outgoing emails don’t go through your MX servers. Here are the cases where this commonly happens:

• You use a third-party email-sending service (like Mailchimp, Google Workspace, Zoho, Salesforce, etc.).

• Your domain receives emails through one server (MX) but sends through another (SMTP relay or API-based sender).

• You’re not sure what your MX records actually point to.

Please note that if you use the ‘mx’ mechanism, your MX records should be well updated. Also, keep checking the IPs they resolve to, as some services frequently rotate them or utilize CDNs or load balancers. Therefore, there is a chance of a broken MX record.

‘ip4’ mechanism

The ‘ip4’ mechanism is used to explicitly authorize an IPv4 address (or range) to send emails on behalf of your domain.

Example:

v=spf1 ip4:192.0.2.0/24 -all

This tells mail servers, ‘Hey, if an email comes from any IP in the 192.0.2.0/24 range, it’s legit for this domain.’

When should you use the ‘ip4’ mechanism?

The ‘ip4’ mechanism is best used when:

• You manage your own mail server and know its IP.

• You’re using a service (such as a web host or CRM tool) that provides you with a fixed sending IP.

• You want to manually allowlist known, static IPs instead of using the include mechanism.

• You have to custom-authorize a third-party sender that’s not covered by a known SPF ‘include.’

As a bonus benefit, it also helps avoid extra DNS lookups.

When should you avoid the ‘ip4’ mechanism?

It’s better to be cautious:

• If the IP address is dynamic or changes frequently, because SPF won’t auto-update, you could break email delivery.

• When you’re using large third-party platforms like Google Workspace or Mailchimp, they already provide ‘include’ records.

Also, note that adding multiple ‘ip4’ entries in a single record can make your SPF record too lengthy and harder to manage.

‘include’ mechanism

The ‘include’ mechanism lets you authorize other domains to send email on your behalf. 

When should you use the ‘include’ mechanism?

Use it when a third-party service sends email using your domain. This includes:

• Email marketing platforms (Mailchimp, SendGrid, Klaviyo, etc.)

• Transactional email services (Amazon SES, Postmark, etc.)

• CRM tools or helpdesks (HubSpot, Intercom, Freshdesk)

• Security services (like Proofpoint or Mimecast, if they handle outbound mail)

When should you avoid the ‘include’ mechanism?

You don’t have to avoid using the ‘include’ mechanism; however, consider these points so that you don’t overuse it-

• Each ‘include’ adds to your 10 DNS lookup limit.

• Nested ‘include’ statements from other domains can silently blow past the limit.

• Never include domains you don’t fully control or trust.

If you have used too many ‘include’ statements and your SPF record has already exceeded the DNS lookup limit, then use our automatic SPF flattening tool. It will replace them with the IP addresses, which minimizes the need for lookups. Reach out to us to know more about the tool or to get help with other SPF-related issues.