An SPF record lists who may send mail for a domain. Most of that list is written as references to other domains, and each reference costs the receiving server a DNS lookup. RFC 7208 caps those lookups at ten. An eleventh makes the whole record return a permanent error, and SPF then fails for every message, including the ones from servers listed first.
Nothing warns you when it happens. The record still looks valid, DNS still serves it, and the cause is usually a change somebody else made: a mail provider that added an include inside its own record.
What counts toward the ten
| Term | Counts? | Notes |
|---|---|---|
| include: | Yes | One for the include, plus every counting term inside the record it points to. |
| a | Yes | One. |
| mx | Yes | One. The servers it returns are then resolved, up to a limit of ten names. |
| exists: | Yes | One. |
| redirect= | Yes | One, plus everything in the record it points to. |
| ptr | Yes | One. RFC 7208 says not to use it at all. |
| ip4: and ip6: | No | Addresses are written in the record. Nothing is looked up. |
| all | No |
Counting a real record
Follow every include to the end. The count is the total for the whole tree, not the number of terms you can see.
example.com v=spf1 mx include:_spf.mailhost.example include:mail.crm.example
include:send.news.example include:helpdesk.example -all
mx 1
include:_spf.mailhost.example 1 + 3 inside = 4
include:mail.crm.example 1 + 2 inside = 3
include:send.news.example 1 + 1 inside = 2
include:helpdesk.example 1
total 11: permanent errorFour ways to get under the limit
- Remove what is no longer used. Old marketing tools, a previous mail provider and trial services are the usual finds. This alone fixes most records.
- Replace a and mx with addresses. If your own servers have fixed addresses, ip4: and ip6: say the same thing with no lookup.
- Move a sender to a subdomain. Send newsletters from news.example.com with its own SPF record. Each domain has its own budget of ten, and a reputation problem with bulk mail stays away from the main domain.
- Check whether the include is needed. SPF is checked against the bounce address. A service that sends with its own bounce domain is never checked against your record, so its include does nothing. Such a service authenticates for DMARC through DKIM signing with your domain.
About flattening
Flattening means replacing each include with the addresses it currently resolves to. It removes the lookups, and it works until the provider changes its addresses, which large providers do without notice. Mail from the new addresses then fails SPF with no error anywhere.
Flatten only with a tool that re-checks the provider's record and updates yours automatically, and treat that tool as a dependency your mail now relies on. A record flattened by hand once is a fault waiting for a date.
After the change
- Confirm there is exactly one TXT record beginning v=spf1. Two is also a permanent error.
- Count the lookups again on the published record.
- Send a message from each system to an outside mailbox and read the spf= result in the header.
- Watch DMARC aggregate reports for a week for any sender that now fails.
- Write down which service each include is for. The next person to edit the record will need it.