SPF: declaring who may send mail for a domain

SPF (Sender Policy Framework) lets the owner of a domain publish, in a DNS record, the list of IP addresses and servers allowed to send messages on behalf of that domain. The receiving server compares the IP address of the server talking to it against that list and derives a result (pass, fail, softfail, neutral and so on). SPF is specified in RFC 7208.

What SPF actually checks#

SPF does not look at the address shown in the message's From: header. It applies to two identities of the SMTP session:

• the envelope address, known as MAIL FROM or Return-Path, which is where non-delivery notifications are sent back;
• the name announced in the sending server's HELO / EHLO command, used in particular when MAIL FROM is empty (bounce messages).

The distinction matters: a message can pass SPF with a MAIL FROM on a provider's technical domain while displaying a From: on your own domain. It is DMARC that later requires alignment between the two.

Record syntax#

The record is a TXT published at the apex of the domain (or subdomain) used in MAIL FROM. It must start with v=spf1 and is read left to right: the first mechanism matching the connecting IP address decides the result.

example.com.  IN TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 mx include:_spf.example.net -all"

The most common mechanisms:

• ip4: and ip6:: an address or a network prefix. This is the cheapest mechanism, as it costs no DNS query.
• a and mx: the addresses behind the A/AAAA or MX records of the domain (or of a named domain, such as mx:mail.example.org).
• include:: evaluates the SPF record of another domain, typically a sending provider. An include is not a textual inclusion but a recursive evaluation.
• exists:: tests whether a DNS name exists, mainly used with macros.
• all: matches everything, placed at the end of the record.

Each mechanism may carry a qualifier: + (pass, the default), - (fail), ~ (softfail), ? (neutral). Ending with -all means any server not listed must fail; ~all is a softer form, historically used during transition periods. The redirect= modifier replaces the whole evaluation with that of another domain.

The ten-lookup limit#

RFC 7208 sets a hard limit: evaluating a record must not trigger more than ten DNS queries across the include, a, mx, ptr and exists mechanisms and the redirect modifier. Beyond that, the result is permerror, which amounts to no authentication at all. Two additional queries returning nothing (void lookups) are also enough to cause an error.

This is the most frequent cause of failure. Every provider added through include brings its own nested include statements, and a domain using an office suite, a marketing tool, a CRM and a support platform quickly exceeds the limit without noticing. The remedies are to replace include statements with stable ip4: / ip6: prefixes, to remove providers that no longer send, and to dedicate subdomains to specific mail streams (see subdomains and wildcards).

Deploying SPF#

1. Inventory every system that sends mail with the domain in MAIL FROM: internal servers, marketing providers, transactional tools, business applications, printers and appliances that send alerts.
2. For each source, note either the IP prefixes or the include documented by the provider.
3. Publish a single TXT record starting with v=spf1, ending with ~all while validating, then with -all.
4. Check the lookup count and the size of the DNS answer: a single TXT string is limited to 255 characters, so a longer record must be split into several strings within the same record.
5. Publish v=spf1 -all on domains and subdomains that never send mail.
6. Watch DMARC reports to catch forgotten sources before tightening the policy.

Common mistakes#

• Several SPF records on the same name: the RFC requires exactly one record starting with v=spf1, otherwise permerror.
• +all or ?all at the end: the record forbids nothing and offers no protection.
• The ptr mechanism: discouraged by the RFC, slow and unreliable.
• A record of DNS type SPF (type 99): obsolete, only TXT is evaluated.
• Forgetting HELO: the name announced by your outbound servers also needs an SPF record, otherwise bounces and notifications fail.
• Confusing SPF with DMARC: a valid SPF on the provider's domain does not protect the visible From:. Without aligned DKIM or a MAIL FROM on your domain, DMARC will fail.
• Never revisiting the record: providers change addresses, include targets evolve, and an unmaintained record ends up exceeding the limit or authorising ranges that no longer belong to you.

What SenderRadar shows#

In a domain's map, SenderRadar displays the published SPF record, its breakdown mechanism by mechanism, the number of DNS queries consumed against the limit of ten, the terminating policy (-all, ~all, other) and any syntax anomalies detected. SenderRadar relies on its own analysis base to place these elements against common practice among comparable domains.

References#

• RFC 7208 – Sender Policy Framework (SPF)
• RFC 7489 – DMARC, for alignment between MAIL FROM and From:
• RFC 5321 – SMTP, for the MAIL FROM and HELO identities