SPF Record Checker

About Email Authentication Checker

Three things here are invisible from a casual look at DNS, and each of them silently undoes the record above it.

An MTA-STS TXT record only announces that a policy exists — it is the policy *file*, fetched over HTTPS from mta-sts.<domain>, that says whether the policy is enforced. A domain in mode: testing has switched nothing on: failures are reported and the mail still goes in the clear. From DNS alone that is indistinguishable from real enforcement, so the file is fetched and the mode reported.

DMARC reports going to another domain need that domain's permission. RFC 7489 requires the destination to publish <your-domain>._report._dmarc.<their-domain>, and a conforming receiver sends nothing without it. The DMARC record looks perfect, the reports never arrive, and nothing anywhere says why — so each external destination is checked. A report processor that publishes a wildcard is consenting to everybody, which is both common and correct.

BIMI is downstream of everything else. A BIMI record on a domain whose DMARC is still p=none displays no logo anywhere, because every mailbox provider requires enforcement first — and most require a Verified Mark Certificate on top of that.

SPF, DKIM, DMARC, MX and MTA-STS for one domain, read together — because the answer is the combination and almost never any one of them.

The three are routinely confused for one another. SPF says which servers may send for the domain, and it is checked against the envelope sender — the bounce address — not against the address a person sees. DKIM signs the message, so a valid signature proves it left the signing domain unaltered; it says nothing about who the From line claims to be either. DMARC is the one that ties them to the visible address: it requires that a passing SPF or DKIM be *aligned* with the From domain, and it tells receivers what to do when neither is.

That is why a domain can have a perfect SPF record, valid DKIM signatures, and no protection at all. Without DMARC, both of the other two are guarding things nobody is checking the name of — and putting your domain in the From line costs an attacker nothing.

DKIM is the awkward one to check, because a selector is chosen by whoever set the mail up and is published nowhere. The only way to find one without a signed message in hand is to try the names the big providers use, which is what this does — so an empty DKIM result means those names are not in use, not that the domain has none.

Where it helps

• Asks for MTA-STS's actual policy file, not just the TXT record that announces one — which is the only way to tell an enforced policy from a testing one that changes nothing.
• Checks whether each external DMARC report destination has published its consent, which is why a correct-looking rua can receive nothing at all.
• Reads BIMI and says plainly that it does nothing until DMARC reaches quarantine or reject.
• Reads all three records together, which is the only way the answer means anything.
• Says what each one does *not* protect, because that is where the false confidence comes from.
• Guesses about twenty DKIM selectors, and is clear that an empty result is not proof of absence.
• Follows DMARC up to the organisational domain the way receivers do, so a covered subdomain is not reported as unprotected.
• Checks MTA-STS as well, which is the only thing that makes a missing TLS a failure rather than a silent downgrade.

Limits

• It reads what is published; it cannot tell you whether your mail actually passes. Only the receiving server knows that, and its answer is in the message headers.
• A DKIM selector that is not on the guess list comes back empty. Look in the s= tag of any DKIM-Signature you have, then use the DKIM Lookup tool.
• SPF include: chains are counted but not followed, so the lookup count is what the record itself costs rather than the full evaluated total.
• Nothing here judges your sending reputation — a perfectly configured domain can still be blocklisted, which is a different tool.
• The organisational domain is approximated as the last two labels, which is right for .com and wrong for .co.uk.

Frequently asked questions

SPF and DKIM pass. Why is mail still being spoofed?

Because neither of them looks at the address your recipients see. SPF checks the bounce address and DKIM checks whoever signed — an attacker can pass both with their own domain while putting yours in the From line. DMARC is the only one of the three that requires the visible address to match, which is why a domain without it is unprotected however good the other two are.

Why did DKIM come back empty?

Almost certainly because the selector is not one of the names tried. A selector is invented by whoever configured the mail and is published nowhere in DNS, so there is no way to enumerate them — the only reliable source is the s= tag in a DKIM-Signature header on a message the domain actually sent.

What should my DMARC policy be?

Start at p=none with a rua address. That changes nothing about delivery and starts the aggregate reports, which are the only way to find out who sends as you before you tighten anything. Move to quarantine once the reports are clean, then to reject. Going straight to reject without reading reports is how an organisation discovers its invoicing system was sending from a subdomain.

Is more than one SPF record a problem?

Yes, and a silent one. RFC 7208 says a receiver finding two must treat it as a permanent error, which most treat as though there were no SPF at all — so a domain that added a second record to "also allow" a provider has usually turned SPF off entirely.

Related tools

• Email Header Analyzer — The delivery path, the authentication results, and what a forgery looks like
• DMARC Lookup — A domain's DMARC policy, and what it actually asks receivers to do
• DKIM Lookup — A domain's DKIM keys, for a selector or by trying the common ones, and whether each is worth anything
• DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
• IP Lookup — Resolve addresses and reverse DNS for a host or IP
• Port Checker — Test whether TCP ports accept connections

More Network & DNS tools

• DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
• IP Lookup — Resolve addresses and reverse DNS for a host or IP
• Port Checker — Test whether TCP ports accept connections
• Nmap Port Scanner — Scan a host's common TCP ports, Nmap style, and see what each open service says it is
• Ping (TCP) — Measure connection latency with repeated TCP probes
• What Is My IP — Your public address, and what a browser reveals about you
• WHOIS — Registry records for a domain, an IP address or an AS number
• DNS Propagation Checker — The same name asked of resolvers worldwide, and of the zone's own servers
• Email Authentication Checker — SPF, DKIM, DMARC and MX for a domain, read together
• Email Header Analyzer — The delivery path, the authentication results, and what a forgery looks like
• DKIM Lookup — A domain's DKIM keys, for a selector or by trying the common ones, and whether each is worth anything
• DMARC Lookup — A domain's DMARC policy, and what it actually asks receivers to do
• Reverse DNS Lookup — The PTR record for an address, and whether it confirms itself
• IP Blacklist Checker — Whether an address is on the blocklists that actually stop mail
• Reverse IP Lookup — What an address says about itself: its name, its certificate, its network
• Traceroute — Every hop between this server and a host, with the time each one took
• Broadband Speed Test — Download, upload, latency and jitter, measured from this tab
• HTTP Headers — Grade a site's security headers from A+ to F, see every response header, and get the fix for your server
• Redirect Checker — Follow a URL's redirects hop by hop, and flag loops, downgrades and temporary redirects doing a permanent job
• IP Address Converter — Write an IPv4 or IPv6 address as an integer, hex, binary, expanded or mapped form, and see what kind it is
• MAC Address Lookup — Find the manufacturer behind a MAC address, and see what kind of address it is
• MAC to IP Converter — Build the IPv6 address a MAC forms with SLAAC, recover the MAC from one, or find a MAC's IP in an ARP table
• IP to MAC Lookup — Find the MAC address behind an IP: computed for multicast and EUI-64 addresses, or read from an ARP table
• DNSSEC Checker — Whether a domain's DNSSEC validates, and if not, whether it is the DS, a key, an algorithm or an expired signature