SPF record checker

Each include:, a, mx, ptr, exists: and redirect= term costs one lookup, and every included domain's record is walked the same way, so the count is the total a receiver would perform. ip4:, ip6: and all cost nothing. The checker reads TXT records through the system resolver; it does not evaluate a particular sender IP.

SPF, Sender Policy Framework, specified in RFC 7208, is one DNS TXT record listing the hosts allowed to send mail using your domain. A receiving mail server takes the domain out of the SMTP envelope sender (the MAIL FROM address, where bounces go, not the From: header a person reads), looks up that domain's SPF record, and evaluates it against the IP address that opened the connection. The outcome is one of seven results: pass, fail, softfail, neutral, none, permerror, temperror; it feeds the receiver's filtering and, where the domain publishes DMARC, its alignment decision.

The record goes at the domain being checked, as an ordinary TXT record whose value begins v=spf1. Two consequences catch people out. There is no inheritance: if mail.acme.com appears in an envelope sender, it needs its own record: acme.com's does not cover it. And the dedicated SPF resource-record type that early drafts defined is obsolete; §3.1 requires publication as TXT, so a domain that published only the SPF-type record has published nothing receivers will read.

Names like _spf.example.com are not an exception to that. They are simply the hostnames vendors publish their own records on so that you can point an include: at them; your record still lives at your domain.

TXT records also carry domain-ownership proofs; the glossary entry on TXT record verification explains how those work and why a SaaS product should require one.

After the v=spf1 version tag, a record is a space-separated list of terms. Each term is either a mechanism, which can match the connecting IP, or a modifier, written name=value, which changes how the evaluation runs. Mechanisms are tried strictly left to right and the first one that matches ends the evaluation; its qualifier becomes the result. Nothing after that point is read, which is why a term placed after all is dead weight.

The two modifiers are position-independent, take no qualifier, and may appear at most once each:

A qualifier is the single character in front of a mechanism that decides what a match means (§4.6.2). Omitting it means +:

So v=spf1 include:_spf.example.net ip4:203.0.113.0/24 ~all reads: mail from a host the record at _spf.example.net authorises passes; mail from anything in 203.0.113.0/24 passes; everything else softfails.

§4.6.4 caps the terms that require a DNS query at 10 for the whole evaluation: include, a, mx, ptr, exists and the redirect modifier. The count is recursive, and that is the part that surprises people: an include: whose target record itself contains three includes costs four, not one. Because each vendor's record is maintained by that vendor, your total can cross the limit on a day you changed nothing. We measured what each common vendor's include costs: from one lookup to seven.

Receivers return permerror for any sender whose check runs past the 10th lookup; which senders that hits depends on their order in the record. The same section caps "void" lookups, the ones answering with no data, at two.

There are four honest ways down, in the order worth trying:

• Delete what no longer sends. Records accumulate ex-vendors; each one is a free lookup back.
• Give a vendor its own subdomain. Send its mail as notifications.acme.com with its own SPF record. Each domain gets its own budget of 10, and this is the only fix that scales.
• Replace an include with the ranges it resolves to. ip4:/ip6: terms cost nothing, but you have now pinned a vendor's infrastructure by hand, and mail breaks silently when they renumber. Only do this for a vendor that publishes stable ranges, and diary a re-check.
• Drop ptr, and drop mx if your mail is inbound-only. Both are commonly present out of habit rather than need.

Automated "SPF flattening" services do the third option for you on a schedule. That removes the maintenance burden but adds a dependency whose failure mode is your mail quietly failing authentication, so treat it as infrastructure, not a fix-and-forget.

-all tells receivers that a host you did not list is not authorised, full stop; they may reject the message. ~all says the same thing but asks them to accept and mark instead. The usual advice (publish ~all while you are still discovering which systems send as your domain, then move to -all) is about your confidence in the list, not about strictness for its own sake.

If you publish DMARC, the choice matters less than it looks: DMARC only counts an SPF pass toward alignment, so softfail and fail are the same non-pass to it and your DMARC policy decides the outcome. Where the difference still bites is the receivers that act on SPF alone. ?all and a record with no all at all are weaker still: both leave unmatched senders neutral, which is the position a domain with no SPF record is already in.

Whatever you choose, publish it exactly once. §3.2 forbids two v=spf1 records at the same name and §4.5 makes the check permerror when a receiver finds them; they do not merge the records or pick the stricter one, they abandon the check. It happens most often when a second provider's setup wizard adds its own TXT record rather than editing the one already there. Merging is just putting both include: terms in one record. Note that this is a different thing from length: DNS transmits a long TXT value as several chunks that are concatenated back together, so one record over 255 characters is legal, while two records never are.

Every finding the tool prints is one of the codes below, with a severity attached. They are the checker's complete vocabulary: if a record produces no finding beyond info, there was nothing here to report.

SPF answers one narrow question (may this IP send for this envelope domain) and it has one well-known blind spot: forwarding. A forwarder re-sends your message from its own address, which your record does not list, so the check fails through no fault of the configuration.

DKIM covers that gap from the other direction. The sending system signs the message with a private key and publishes the public half at <selector>._domainkey.example.com; the signature travels with the mail and still verifies after a hop. DMARC, published at _dmarc.example.com, is the layer that makes either signal mean something to a recipient: it requires the visible From: domain to align with the domain that passed SPF or DKIM, states what receivers should do when neither aligns, and asks for aggregate reports so you can see who is sending as you before you enforce. Three records, three names, one purpose.

If your product sends mail on behalf of customers, each customer has to add your include: to a TXT record inside their own DNS, the same class of change, and the same stalled-onboarding problem, as pointing a hostname at your platform. DoDomain mints and verifies those records as part of a connect session; the multi-record and email guide covers what each connect path can do with an SPF, DKIM or DMARC record, including the one-include-per-session limit of the Domain Connect template. For the hostname half, the apex-domain guide is the one to read before promising a customer their bare domain will work.

Two checks here pair with this one: the DNS propagation checker reads a single record from the zone's authoritative nameservers and three public resolvers, which is how you tell "the TXT record is wrong" from "the TXT record is right and not yet cached", and the DNS provider detector says which host actually serves the zone you need to edit.

No card, no sales call: create an app, mint a session, and watch the first domain verify.

• DNS provider detector

  Which DNS host serves a domain, and whether one-click setup is available there.

• DNS propagation checker

  One record, read from the authoritative nameservers and three public resolvers.