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

Looking into an SPF record and figuring out what these alien terms are: a, mx, ip4, and include? Guess what, you are not alone. Anyone with no-so-adept technical expertise feels the same at first glance.

SPF is undoubtedly one of the powerful tools for combating phishing and spoofing attempts made in your name. However, creating and managing an SPF record requires knowledge of mechanisms, qualifiers, and modifiers. This is because if you don’t use them correctly, your SPF record won’t just be messy, but it can also break your email delivery altogether. 

In this blog, we’ll break down the four most commonly used SPF mechanisms and explain when to use and avoid them to prevent misconfigurations. 

‘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.