Email authentication test — your domain's SPF, DKIM and DMARC

Find out whether your domain can be spoofed. We read the public DNS records a receiving mail server would check: SPF, DKIM, DMARC and MX, plus MTA-STS, TLS-RPT, CAA and BIMI. Free, no sign-up, and it works for any domain — including one you do not own.

What the email test covers

SPF — who may send as you — We read your SPF record and its closing qualifier. -all (hard fail) is the destination, ~all is acceptable while you are still rolling out, and +all defeats the whole point by authorising the entire internet. We also flag multiple SPF records, a common mistake that invalidates all of them at once.

DKIM — the cryptographic signature — We look for a published DKIM public key on the selectors used by mainstream mail providers. DKIM signs the message itself, so a recipient can confirm the content was not altered or forged in transit.

DMARC — what to do with a forgery — We read the _dmarc record and its policy. p=none only reports, p=quarantine sends suspect mail to the spam folder, and p=reject tells receivers to refuse it outright. Without DMARC, SPF and DKIM have no way to work together and nothing tells the receiving server how to act.

MX and the supporting layer — MX records (whether the domain receives mail at all), MTA-STS and TLS-RPT (enforced transport encryption and reports when it fails), CAA (which certificate authorities may issue for the domain) and BIMI (your logo beside the message in the inbox).

We read public DNS only, so we see exactly what a receiving mail server sees — but we cannot tell you whether a particular message was delivered, and we do not inspect your sending IP's reputation. DKIM is probed on common selectors: a key published under an unusual selector is invisible from the outside, so the report says "not found on common selectors" rather than "no DKIM". The full signal list and weightings are in the methodology.

Why this matters even if you "don't send newsletters"

A domain without DMARC is free raw material for phishing. An attacker does not need to break into your server — they send a message with invoices@yourcompany.com in the From field from any machine on the internet, and the recipient sees your name. Your customer pays for it, your brand pays for it, and you are the last to find out.

The second reason is mundane. Since 2024 Google and Yahoo require SPF, DKIM and DMARC from bulk senders, and other providers treat their absence as a risk signal. A properly authenticated domain simply lands in the inbox more often than in the spam folder.

Even a domain that sends no mail at all should say so, with an empty SPF and a reject policy. Otherwise it stays an open invitation to impersonation.

How to set this up correctly, in order

1. Publish SPF listing your real senders One TXT record at the domain root naming every service that actually sends your mail: your mailbox provider, marketing platform, CRM, shop server. Close it with -all once you are confident the list is complete.

v=spf1 include:_spf.google.com include:sendgrid.net -all

2. Turn on DKIM with your mail provider Your provider generates the key pair and gives you a record to publish. Once it is live, send a test message and confirm dkim=pass appears in the headers.

selector._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=MIIBIjANBg...

3. Start DMARC in monitoring mode Begin with p=none and a reporting address. For a few weeks you will receive summaries of who sends mail in your name — the only reliable way to avoid cutting off your own invoicing system.

_dmarc.yourdomain.com  TXT  v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

4. Tighten the policy only after reading the reports When the reports show nothing but known senders and all of them pass SPF or DKIM, move to p=quarantine, then after another quiet period to p=reject. The order matters more than the speed.

_dmarc.yourdomain.com  TXT  v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

5. No mail on this domain? Close it explicitly If the domain never sends messages, say so. Two records settle the matter and protect the brand with no ongoing maintenance.

yourdomain.com        TXT  v=spf1 -all
_dmarc.yourdomain.com TXT  v=DMARC1; p=reject;

The mistakes we see most often

Two SPF records. The standard permits exactly one. When a new tool gets its own record instead of being added to the existing one, receiving servers return permerror and SPF stops working entirely. Merge everything into a single record with multiple include: terms.

Blowing the ten-lookup limit. Every include:, a, mx and redirect costs a DNS lookup, and SPF fails after ten. Long provider chains exhaust that budget faster than you would expect.

Switching DMARC to p=reject on day one. Without a monitoring period you will reject your own accounting notifications or contact-form mail. Start at p=none.

+all in SPF. It turns up in examples copied off the web. Such a record authorises every server on the planet, which is worse than having no record at all, because it looks like protection.

Frequently asked questions

What is the difference between SPF, DKIM and DMARC? SPF lists the servers allowed to send mail using your domain. DKIM adds a cryptographic signature proving the content was not altered. DMARC ties the two together, tells the receiving server what to do with a message that fails, and specifies where to send reports. Only all three together form a working defence.

Does missing DMARC mean my email goes to spam? Not necessarily, but the risk goes up. Google and Yahoo have required authentication from bulk senders since 2024, and smaller providers treat its absence as one risk signal among several. Deliverability also depends on IP reputation, sending history and content, none of which an external DNS test can measure.

Why didn't the test find my DKIM even though I have it? DKIM is published under a selector — an arbitrary name chosen by your mail provider. There is no way to enumerate every selector on a domain from the outside, so we probe the ones mainstream providers use. A key under an unusual selector stays invisible, which is why the report says "not found on common selectors" rather than "no DKIM".

My domain doesn't send email. Do I still need to configure anything? Yes, and it is the simplest case. Publish SPF as v=spf1 -all and DMARC with p=reject. That declares no server is authorised to send on the domain's behalf, so impersonation attempts are refused by recipients. It needs no further maintenance.

Is the test free, and do I need an account? The test is free and requires no login or email address. Email authentication is one of the eight pillars in a full SEOMaster audit, alongside SEO, performance, security, accessibility, trust, hosting and AI readiness.

Check a domain's hosting and DNS · Security headers test · How we scan