SPF Records Explained: Syntax, Alignment and Lookup Limits

Sender Policy Framework (SPF) lets a domain publish which systems are authorised to send mail using that domain in the SMTP envelope. A receiving system compares the connecting IP address with the applicable SPF policy.

SPF is useful, but its scope is often misunderstood. It normally authenticates the envelope sender or HELO identity, not the visible From address by itself. DMARC adds an alignment test between an authenticated SPF domain and the visible From domain.

The shape of an SPF record

SPF policy is published as a DNS TXT record at the domain being evaluated. A simple record can look like this:

example.co.za. IN TXT "v=spf1 ip4:192.0.2.0/24 include:provider.invalid -all"

The example addresses and provider name are reserved for documentation. A real record must use only networks and provider references authorised for that domain.

The terms are processed from left to right. Evaluation stops when a mechanism matches. The record begins with v=spf1 and generally ends with an all mechanism that states the result for anything not matched earlier.

Common mechanisms

ip4 and ip6

These authorise a specific address or network.

ip4:192.0.2.20
ip6:2001:db8::/48

They are direct and do not require another DNS lookup during SPF evaluation, but they must be maintained when sending infrastructure changes.

include

An include evaluates another domain’s SPF policy as part of the current record.

include:provider.invalid

Use the exact value supplied by an authorised provider. The include and its recursive dependencies can consume the SPF DNS-query budget.

a and mx

The a mechanism tests addresses returned for a name. The mx mechanism tests addresses associated with the domain’s MX hosts. Both can trigger DNS queries.

Do not add them merely because a domain has web or mail records. They should appear only when those resolved systems are genuinely authorised to send with the evaluated identity.

exists

This mechanism performs a DNS test using a domain specification and can support provider-specific logic. It is usually supplied and managed as part of a documented service configuration.

redirect

The redirect modifier points evaluation to another domain’s SPF record when no earlier mechanism produced a result. Its behaviour differs from include; do not substitute one for the other without understanding the provider design.

all

all always matches. It is normally last because later mechanisms cannot be reached once it matches.

Qualifiers and results

A mechanism can have a qualifier:

The final qualifier should reflect an intentional, domain-specific policy. Changing ~all to -all is not a generic clean-up step; first confirm the domain’s authorised sending use and expected receiver behaviour.

The 10-querying-term limit

RFC 7208 limits an SPF evaluation to 10 terms that cause DNS queries. The limit includes recursive dependencies reached through includes and redirects.

If the evaluation exceeds the limit, the receiver can return an SPF permanent error. A record with only a few visible includes can still exceed the limit after those provider policies expand.

Review the complete dependency tree. If it is too large, remove obsolete authorisations and consider provider-supported redesign before deciding whether SPF flattening is appropriate.

SPF and DMARC alignment

For SPF to contribute a DMARC pass:

1. SPF must pass for the relevant SMTP identity; and
2. that authenticated domain must align with the visible From domain under the published DMARC alignment mode.

Example:

Visible From: billing@example.co.za
Envelope sender: bounce@mailer.provider.invalid

SPF might pass for mailer.provider.invalid, but it is not aligned with example.co.za. The provider may offer a custom return-path domain that can create alignment, or the message may pass DMARC through aligned DKIM instead.

Why forwarding affects SPF

A forwarder relays a message from a different connecting IP address. That IP may not be authorised by the original envelope-sender domain, so SPF can fail at the final receiver even when it passed at the first hop.

Some forwarding systems use Sender Rewriting Scheme or other handling, but behaviour varies. DKIM can survive forwarding when signed content is not changed, which is one reason DMARC accepts aligned DKIM or aligned SPF rather than requiring both.

Common SPF mistakes

Multiple SPF records

A domain must not publish more than one SPF record. Two separate v=spf1 TXT values do not combine into a larger policy; they produce an invalid result.

Copying a provider’s IP addresses without maintenance

An observed or copied address list can become stale. Prefer the provider’s documented authorisation pattern unless a managed, reviewed alternative is deliberately chosen.

Authorising more than necessary

Broad network ranges, obsolete includes, and unrelated a or mx mechanisms increase exposure and complexity. Every term should have a named service owner and current reason.

Assuming the root domain covers every identity

SPF is evaluated for a specific domain identity. A subdomain, custom return path, or provider-controlled domain may use a different record.

Treating SPF pass as message trust

SPF pass means the connecting IP was authorised for the evaluated domain. It does not assess message content, account compromise, intent, or visible-brand alignment unless DMARC’s separate test is considered.

A safe review sequence

1. Query public DNS and confirm there is exactly one SPF record.
2. Map each mechanism to a current, approved sender.
3. Resolve recursive dependencies and check the querying-term limit.
4. Send controlled samples and inspect Authentication-Results and return-path headers.
5. Check DMARC alignment, not SPF pass alone.
6. Remove stale authorisations through approved change control.
7. Validate public DNS and new samples after the change.
8. Revisit the record when services or infrastructure change.

Frequently asked questions

Does SPF prevent spoofing?

SPF gives receivers an authentication result for a defined SMTP identity. It does not, by itself, protect the visible From domain or stop lookalike domains and compromised accounts.

Should every SPF record end in -all?

Not as a blind rule. The final policy should be chosen after the authorised sending surface is understood and tested. DMARC reporting and aligned DKIM remain relevant.

Can a domain publish SPF as a DNS SPF record type?

SPF policy is published in a TXT record. The historic SPF-specific DNS resource record type is not the current publication method.

Does SPF control inbound mail?

SPF is evaluated by receiving systems against the sender identity. A domain’s own SPF record does not configure its inbound spam or malware filtering.

Next step

Check the domain’s public record with the Vigil DMARC checker, then verify the result against an authorised sender inventory before publishing changes.