SPF Mechanisms: include, ip4, mx, a, all Explained

An SPF record is a list of mechanisms — instructions that tell receiving mail servers which IP addresses are authorized to send email for your domain. Each mechanism checks the sender's IP in a different way, and the first match determines the result. Once you've built your record, you can verify it with SPF Record Check.

This is the complete reference. Every mechanism, every qualifier, every modifier.

Quick Reference

The include Mechanism

include is the most common mechanism. It tells the receiving server to also check the SPF record of another domain. If the sender's IP passes the included domain's SPF record, it passes yours too.

v=spf1 include:_spf.google.com -all

This says: "Check Google's SPF record. If the sender's IP is authorized by Google, it's authorized by me."

Key details:

• Each include costs at least 1 DNS lookup, plus any lookups within the included record
• If the included domain's SPF record doesn't exist, the result is permerror
• include is not the same as copying the other record's contents — only a pass result from the included record counts as a match. A fail from the included record doesn't produce a fail in yours; evaluation just continues to the next mechanism

Common Include Values

Here are the include values for popular email services:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• SendGrid: include:sendgrid.net
• Mailchimp: include:servers.mcsv.net
• Amazon SES: include:amazonses.com
• Mailgun: include:mailgun.org
• Postmark: include:spf.mtasv.net
• Zendesk: include:mail.zendesk.com
• Freshdesk: include:email.freshdesk.com
• HubSpot: include:spf.hubspot.com (check current docs)

The ip4 Mechanism

ip4 matches against a specific IPv4 address or CIDR range. No DNS lookup required.

v=spf1 ip4:203.0.113.50 -all

You can also specify a range:

v=spf1 ip4:203.0.113.0/24 -all

This authorizes all 256 addresses from 203.0.113.0 to 203.0.113.255.

When to use it:

• Your own mail server has a static IP
• A sending service gives you dedicated IPs instead of an include value
• You want to authorize a specific server without a DNS lookup

The ip6 Mechanism

Identical to ip4 but for IPv6 addresses. No DNS lookup required.

v=spf1 ip6:2001:db8::1 -all

With a prefix length:

v=spf1 ip6:2001:db8::/32 -all

If your servers send email over IPv6, you need ip6 mechanisms alongside your ip4 ones. Many organizations forget this and wonder why SPF fails intermittently — it's because some connections use IPv6.

The a Mechanism

The a mechanism checks whether the sender's IP matches the A record (or AAAA record) of a domain.

v=spf1 a -all

Without a domain argument, a checks the current domain's A record. You can also specify a different domain:

v=spf1 a:mail.example.com -all

Or add a CIDR prefix:

v=spf1 a:mail.example.com/24 -all

When to use it: When the server at your domain's A record also sends email. Common for small sites where the web server and mail server are the same machine.

Cost: 1 DNS lookup.

The mx Mechanism

The mx mechanism checks whether the sender's IP matches any of the domain's MX record hosts (after resolving the MX hostnames to IPs).

v=spf1 mx -all

This says: "If the sender's IP is one of my mail exchange servers, it's authorized."

You can specify a different domain or add a CIDR prefix:

v=spf1 mx:example.com/24 -all

When to use it: When your inbound mail servers also handle outbound sending. This is common with self-hosted mail setups.

Cost: 1 DNS lookup for MX records, plus additional lookups to resolve each MX hostname. The MX mechanism also has its own limit — no more than 10 MX records can be resolved.

The exists Mechanism

The exists mechanism checks whether a given domain has an A record (resolves to any IP — the actual IP doesn't matter).

v=spf1 exists:%{i}.spf.example.com -all

The %{i} is a macro that expands to the sender's IP address. So if the sender's IP is 203.0.113.50, the server checks whether 203.0.113.50.spf.example.com has an A record.

When to use it: Advanced setups where you want per-IP authorization via DNS wildcards or dynamic records. This is rare in typical configurations.

Cost: 1 DNS lookup.

The ptr Mechanism (Deprecated)

The ptr mechanism does a reverse DNS lookup on the sender's IP and checks whether the resulting hostname belongs to the specified domain.

v=spf1 ptr:example.com -all

The all Mechanism

The all mechanism matches everything. It's always placed last in the record as the catch-all for any IP that didn't match a previous mechanism.

The qualifier before all determines what happens to unmatched IPs:

-all (Hard Fail)

Recommended for domains where you've identified all sending sources. Tells receiving servers to reject email from unauthorized IPs.

~all (Soft Fail)

A softer stance. Use this when you're still figuring out all your sending sources. Receiving servers will typically flag the message but not reject it outright. Many organizations start with ~all and switch to -all once they're confident.

+all (Pass All)

This authorizes every IP address on the internet to send email as your domain. Never, ever use this. It's worse than having no SPF record because it explicitly says "anyone can send as me."

Qualifiers

Every mechanism can be preceded by a qualifier that determines the result when the mechanism matches:

• + (Pass) — Default if no qualifier is specified. The IP is authorized.
• - (Fail) — The IP is explicitly not authorized.
• ~ (Softfail) — The IP is probably not authorized.
• ? (Neutral) — No assertion is made about the IP.

You usually only see qualifiers on the all mechanism, but they can be applied to any mechanism:

v=spf1 +include:_spf.google.com -ip4:192.168.1.1 ~all

In practice, the + qualifier is almost never written explicitly because it's the default.

Modifiers

Modifiers are not mechanisms — they don't match IPs. They change how the SPF record is processed.

redirect=

The redirect modifier replaces the current SPF evaluation with the SPF record of another domain. Unlike include, a redirect completely hands off evaluation.

v=spf1 redirect=_spf.example.com

Key differences from include:

• redirect is only processed if no mechanisms match
• redirect replaces the entire evaluation — the result of the redirected record becomes the final result
• You cannot use redirect and all in the same record (the all would always match before redirect is reached)
• Costs 1 DNS lookup

exp=

The exp modifier specifies a domain whose TXT record contains an explanation string. This explanation is included in bounce messages when SPF fails.

v=spf1 -all exp=explain.example.com

Where explain.example.com has a TXT record like:

"See https://example.com/spf for our email authentication policy"

This is rarely used in practice, but it can help recipients understand why their email was rejected.

Evaluation Order and Matching

Mechanisms are evaluated left to right. Here's how the full process works:

Putting It Together

Here's a real-world SPF record that uses multiple mechanism types:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.50 include:_spf.google.com include:sendgrid.net mx ~all

Reading left to right:

1. Is the IP in the 203.0.113.0/24 range? Pass.
2. Is the IP 198.51.100.50? Pass.
3. Is the IP authorized by Google? Pass.
4. Is the IP authorized by SendGrid? Pass.
5. Is the IP one of our MX servers? Pass.
6. Nothing matched. Softfail.

This record uses 3 DNS lookups (include x2 + mx x1), plus any nested lookups inside Google's and SendGrid's records. After setting up SPF, the next step is DKIM for message signing, followed by a DMARC policy to tie them together.

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.