SPF: authorise sending servers through DNS and investigate errors

This chapter helps you understand an existing record, assess additional sending services and investigate errors such as multiple SPF records or too many DNS lookups.

What SPF checks and where its limits lie

SPF stands for Sender Policy Framework. A receiving mail server can use it to check whether its SMTP peer's IP address is authorised for the SMTP sender domain in use. The relevant identities are MAIL FROM and HELO or EHLO. The visible From: in the message header is a different identity. SPF alone therefore does not confirm the address your mail client displays as the sender.

For an empty SMTP reverse path, such as MAIL FROM:<>, SPF uses an identity derived from the HELO domain. A domain check without the SMTP connection does not know this particular context. The distinction is described in RFC 7208, sections 2.3–2.5.

A DNS check can show the published SPF record, identifiable references and certain configuration errors. Without the sending IP address and SMTP sender, it does not establish that a particular message passes SPF. A missing record must also be distinguished from a temporarily failed DNS query.

SPF does not encrypt a message, inspect its content or confirm a person's identity. DMARC adds the connection between successful authentication and the visible sender domain. DKIM offers a second possible path through a signature.

How an SPF check works

The recipient determines the connecting IP address and SMTP identity, then queries the corresponding SPF record. After checking syntax, it evaluates mechanisms from left to right. The first matching mechanism determines the result. An error can also end evaluation earlier. If no mechanism matches, an existing redirect decides the outcome; without that reference, the default result is Neutral.

Without SPF, this domain has no published SPF authorisation. Recipients can still accept messages and examine them using DKIM, DMARC or other methods. SPF can express which servers are authorised and which are not. This makes sending routes traceable; it guarantees neither a harmless message nor its acceptance.

These results and their limits are defined in RFC 7208, section 2.6. A Pass does not promise inbox placement. A Fail alone is likewise not a universal instruction to reject the message.

Read an SPF record: mechanisms, include and redirect

An SPF record starts with v=spf1, followed by mechanisms and, where applicable, modifiers. The syntax of the entire record is checked before evaluation begins. An error in a later part does not become valid because an earlier mechanism might match.

The IP networks shown and domains containing example are documentation examples. Even a real provider name in the table is not a recommendation to add its include to your domain without checking. Use only the values specified by the responsible sending service for your route.

include adds an evaluation path

With include, such as include:sender.example, a Pass from the target policy makes this mechanism match. With the usual positive qualifier, the calling record also returns Pass. If the target returns Fail, Softfail or Neutral, include does not match and evaluation continues in the calling record. An error in the target may end evaluation, however. A target without an SPF record produces PermError when the include is reached.

So include does not copy a line of text into your record. The recipient evaluates another policy, and its DNS-triggering terms count towards the shared limit. The exact mapping of results is in RFC 7208, section 5.2.

redirect delegates the remaining evaluation

A valid SPF record may consist solely of the version and redirect:

v=spf1 redirect=policy.example

If the reference is reached, SPF adopts the target policy's result. If no SPF record exists there, the result is PermError; a temporary DNS error must be treated as such. A local include is not a prerequisite for this delegation.

redirect is a modifier and need not appear at the end of the text. It may occur only once. If the record contains an all mechanism, redirect is ignored regardless of its position. An earlier match can also prevent an otherwise present reference from being evaluated at all. RFC 7208, sections 5.1 and 6.1

What -all, ~all, ?all and +all mean

The qualifier before a mechanism determines the SPF result when it matches. If omitted, + applies. Because all always matches, it is usually used as the final mechanism.

all is not syntactically required. But without a matching mechanism or redirect, the result is Neutral. Whether -all suits your complete sender list or you initially use ~all must reflect the actual configuration; neither form guarantees acceptance or rejection by the recipient.

Too many DNS lookups: what the limit actually counts

The often cited limit of ten concerns DNS-triggering SPF terms, not ten visible include words or ten DNS packets. It counts evaluated include, a, mx, ptr, exists and redirect terms, including nested evaluation. ip4, ip6 and all do not count. The version string v=spf1 does not use one of these places either. DNSSEC and DANE queries are outside this SPF term budget.

If an eleventh such term is needed, SPF evaluation must return PermError. If a mechanism matches earlier, the remaining path is not followed. The actual load therefore depends on the IP address and identity examined. A static overview of all branches is useful, but is not complete evidence for every possible message.

Additional limits also apply:

• MX resolution: Further limits apply to the addresses looked up. Exceeding the MX address limit described in RFC 7208 produces PermError.
• PTR and %{p}: The addresses to be validated are limited here too. Further results beyond the limit are ignored; this does not imply the same blanket error rule as for MX. The standard advises against ptr in new SPF records.
• Empty answers: For void lookups — DNS queries with no matching answer or with NXDOMAIN — the standard recommends a limit of two. It may be configurable; exceeding the applied limit produces PermError.

The distinct rules are in RFC 7208, section 4.6.4. Do not collapse them into a single general “DNS limit” during diagnosis.

Three ways to investigate an overly complex record

Review the sender list. Match each authorised service to a sending route actually used. Remove entries only after establishing their use. A forgotten newsletter service and an unused old authorisation are different cases.

Separate sending routes onto subdomains. A dedicated sending subdomain can separate policies if the service actually uses that domain in MAIL FROM. Merely publishing another SPF record under a new name does not change the sending route. Afterwards, check the necessary DMARC alignment with the visible From: domain.

Use flattening only with ongoing maintenance. Replacing provider references with IP networks can reduce DNS-triggering terms. A list copied once may become outdated or incompletely represent a dynamic policy. Anyone using this method takes responsibility for maintaining the authorised addresses. Macros also require the specific evaluation context; a domain check cannot conclusively check every possible expansion. They do not bypass the limit. If sender data needed for expansion is missing, that part of the evaluation cannot be assessed conclusively. This establishes neither a DNS outage nor a complete SPF pass.

Check an existing SPF record

1. Identify the sending route: Which application sends, which IP address connects to the recipient, and which domain appears in SMTP MAIL FROM? Do not confuse this with the visible sender address.
2. Look up the DNS record: Query TXT for this domain. The following command is a read example, not a measurement performed here:

dig TXT example.com

3. Count matching records: There must be only one SPF record for this query. Other TXT records may coexist. Related character strings within one TXT record are joined without additional spaces.
4. Examine syntax and references: Check qualifiers, provider values, include targets and redirect. Distinguish a missing record from DNS errors and investigate the lookup path relevant to your sending route.
5. Assess the message separately: An actual SPF result needs connection data or a finding from a trusted receiving system. An arbitrary Authentication-Results header with uncertain provenance is not reliable evidence. The section on header findings explains this diagnostic approach.

The Email Security Check can inspect publicly accessible configuration features of your domain. A finding may suffice for initial clarification. When a delegation is resolved, distinguish the original record from the effective target policy. The domain check does not replace evidence that each of your sending services correctly authenticates a particular message.

Document SPF: technical measures and legal context

Record which sending services you authorise, who maintains their DNS entries and what needs checking when changes are made. SPF can then form part of traceable technical protection. A published record does not establish the complete effectiveness of your safeguards or compliance with a law.

The following references concern this guide's existing German and EU context; they do not establish general requirements for other countries:

• Germany: section 30 BSIG requires appropriate and proportionate risk management measures from entities in scope. It does not establish a blanket SPF obligation for every domain.
• European Union: Article 32 GDPR concerns a level of protection appropriate to the risk when processing personal data. SPF does not encrypt content or prevent misuse of an already compromised authorised account.
• Technical profiles and contracts: Requirements such as BSI TR-03182 on email authentication need separate consideration. A particular SPF result or -all does not prove conformity. Additional contractual requirements must also be distinguished from SPF protocol syntax.

To assess possible attacks, see the sections on email spoofing and phishing. SPF offers limited protection against domain misuse; it is not general protection against every forged or harmful email.

A guide for your sending service

Choose the available guide for the service that actually sends for your domain. The chapters explain different configuration paths; their existence does not confirm your domain's configuration.