Free SPF, DKIM and DMARC Checker

Why all three records matter

Sender authentication is the mechanism that lets a receiving mail server decide whether a message claiming to come from your domain actually did. Without it, anyone can put your domain in the From header, and receivers have no way to tell the difference between your invoices and someone else's phishing. The three records work as a set, and a gap in any one of them weakens the others.

SPF publishes the list of servers permitted to send for your domain. It is checked against the envelope sender, which means it survives neither forwarding nor mailing lists particularly well — that is the gap DKIM fills. DKIM signs each message with a private key held on your mail server and publishes the matching public key in DNS, so a receiver can verify the message is intact and authentically yours regardless of the path it took. DMARC sits on top and does two things SPF and DKIM cannot do alone: it tells receivers what to do when both checks fail, and it asks them to send you aggregate reports so you can see who is sending as your domain.

Reading your SPF record

An SPF record is a single TXT record on your domain starting with v=spf1, followed by mechanisms listing permitted senders and ending in an all qualifier that says what to do with everything else. The qualifier is the part most worth checking. A record ending in +all authorises the entire internet to send as your domain, which is worse than having no record at all — this checker flags it as critical. ?all is neutral and gives receivers no useful signal. ~all is softfail, the sensible default while you are still discovering which services send on your behalf. -all is hardfail, the end state you want once your list of senders is complete.

One constraint catches people out: you may publish only one SPF record per domain. Two records is a permanent error and receivers will treat SPF as failing entirely, not as passing on whichever record happens to match. Because this is invisible unless you look at every TXT record on the domain, this tool lists all of them.

Finding your DKIM selector

DKIM keys live at selector._domainkey.yourdomain.com, and DNS provides no way to list the selectors that exist. That means no checker can find yours automatically — you have to supply it. The reliable way to find it is to open a message you have sent, view its raw headers, and read the s= tag from the DKIM-Signature header. Failing that, common values are default, mail, google for Google Workspace, selector1 and selector2 for Microsoft 365, and k1 for several ESPs.

Moving DMARC from monitoring to enforcement

Almost every domain that has a DMARC record has it set to p=none, and most never move past it. That is a shame, because p=none provides no protection — it only produces reports. The reports are the point, though: they show you every source sending as your domain, including the marketing platform someone signed up for two years ago and the invoicing system nobody remembers configuring. Once those are all covered by SPF or DKIM, move to p=quarantine, watch for a few weeks, then p=reject.

If this check shows records missing entirely, the DNS record generator will produce a correct starting set for your sending host. If you are chasing a delivery problem rather than a configuration one, check whether your sending IP is listed with the blacklist checker, and confirm the server itself is answering with the SMTP server test.

Automating this across many domains

Checking one domain by hand is fine. Doing it for fifty sending domains after every infrastructure change is not. PMTAcore includes DNS automation that creates and verifies SPF, DKIM, DMARC, MX and PTR records directly through Cloudflare, GoDaddy and Namecheap, detects conflicting records before they cause a failure, and does it as part of the same run that installs PowerMTA. See the pricing page or start on the free trial.