Look Up a Domain's SPF Record — and What It Leaves Uncovered
Check whether a domain publishes an SPF record, see which mail provider sits behind it, and find out what SPF does and does not protect against. Free, no signup.
Enter a domain to look up its SPF record
Checking syntax, MX, SMTP, trust, gateway, and domain profile…
Enter a domain above and click Check to see results.
SPF — Sender Policy Framework — is a TXT record on your domain listing the servers permitted to send mail as it. A receiving server reads the record, compares it to the host that actually delivered the message, and gets a pass or a fail.
A record looks like v=spf1 include:_spf.google.com include:sendgrid.net ~all: a version tag, a set of mechanisms naming the permitted senders, and a catch-all rule at the end saying how to treat everything else.
The important limitation is what SPF checks. It validates the envelope sender — the MAIL FROM address exchanged during the SMTP conversation — not the From: header a recipient actually sees. Those two can differ, and in a well-built phishing message they do. That gap is precisely what DMARC exists to close.
The mechanism at the end of the record decides what happens to a sender that is not on the list. It is the part most often left on its permissive default.
| Mechanism | Name | What it asks receivers to do |
|---|---|---|
| -all | Fail (hard) | Reject mail from any host not listed. The strict setting, and the one to aim for once the record is complete. |
| ~all | SoftFail | Accept it, but mark it suspicious. In practice most receivers deliver it. The usual default, and where most records stay. |
| ?all | Neutral | Express no opinion. Functionally equivalent to publishing no policy at all. |
| +all | Pass everything | Authorise the entire internet to send as this domain. Almost always a mistake. |
SPF permits a maximum of ten DNS lookups when evaluating a record. Every include:, a, mx, ptr, exists and redirect mechanism counts — and each include: can pull in a record that spends several more.
Exceed ten and evaluation returns permerror. Under DMARC, a permerror is not a pass. The record is still there, still looks reasonable in a text editor, and has stopped working.
This is what makes SPF breakage hard to notice: it arrives by accumulation. Nobody breaks the record — a team adds a helpdesk tool, then an invoicing provider, then a marketing platform, and the eleventh lookup lands on a Tuesday months after anyone last looked at DNS. The usual fixes are flattening includes into IP ranges, dropping providers that no longer send, and never using ptr.
SPF also breaks on forwarding, by design. When a message is forwarded, the forwarding host becomes the sending host and is not on your list, so SPF fails legitimately. DKIM survives forwarding where SPF does not, which is one reason DMARC accepts either.
Most SPF guidance assumes you are auditing your own domain. Looking one up on a domain you do not control answers a different question: how seriously does whoever runs this domain take its mail?
A domain with SPF and an enforcing DMARC policy is being administered by someone. A domain with neither, no website and a registration date three weeks ago is a different proposition — and if it is turning up in your signup form, worth treating accordingly. Those signals are exactly what MailRook's signup protection scores in real time.
SPF on its own is a weak signal, though — plenty of throwaway providers publish a perfectly valid record. Read it alongside the mail server and MX records, whether the domain is disposable, and whether it is a catch-all domain. To check a specific mailbox rather than the domain, use the free email checker.
Enter the domain above. The checker reads the domain's TXT records and reports whether an SPF record is published, along with the mail provider behind the domain. You can query it directly with dig TXT example.com.
No. Two v=spf1 records on the same domain is a permerror, and evaluation fails. Multiple senders belong in one record as multiple include: mechanisms.
No. SPF validates the envelope sender, not the visible From: address, so display-name spoofing passes straight through. Pair it with DKIM and an enforcing DMARC policy.
They are different answers. If MailRook has not yet inspected a domain's DNS, reporting "no SPF record" would assert something about that domain we have not verified. Run the lookup and it fills in.
Yes, with no signup. An account raises the daily limit and unlocks bulk checks and API access.
One domain at a time is the free tier. The API returns SPF, DMARC policy, MX, catch-all and a domain trust score for every address you send it — at signup, or across an existing list.
What you unlock