Can someone send email as your domain?
Enter a domain. This checks SPF, DKIM and DMARC the way a receiving mail server would, and shows you the actual records. No signup, no email required.
Every test, explained
Four record types decide whether your email is trusted. Here is what each one does, and what this tool looks at.
MX — where your mail arrives
MX records name the servers that accept mail for your domain. This tool reads them first, for context. Because a domain that receives no mail is a different problem from a domain that receives mail badly.
It checks that the records exist, that each hostname actually resolves, and that none of them contain an IP address instead of a name. It also spots a null MX, which is the correct way to say "this domain accepts no mail."
Worth knowing: MX records have nothing to do with sending. So a domain with perfect MX records can still be forged by anyone.
SPF — who is allowed to send
SPF lists the servers permitted to send email for your domain. Receivers look it up, compare it to the connecting server, and decide.
The tool checks the obvious things: whether a record exists, whether there is exactly one, and whether the syntax parses. Then it checks the part most tools skip. SPF is limited to ten DNS lookups, and every include: you add spends some of them. Go over ten and receivers return a permanent error. At that point SPF does nothing at all — but your DNS panel still shows a long, careful, entirely correct-looking record.
So the tool follows every include and redirect, and counts what a receiver would actually spend. It also checks how the record ends, because -all, ~all, ?all and +all mean four very different things.
DKIM — the signature on the message
DKIM signs each message with a private key. The matching public key sits in your DNS. Receivers fetch it and verify that the message was not altered in transit.
There is a catch. DNS offers no way to list which selectors a domain uses. So this tool probes the common ones, plus any that your MX records imply — a domain on Google Workspace gets google checked, one on Microsoft 365 gets selector1 and selector2.
If nothing is found, that is reported as inconclusive. Not as a failure. To check properly, open a message you have sent, find the DKIM-Signature header, read the s= value, and enter it in the selector box.
Where a key is found, the tool checks the key length, whether it has been revoked, and whether test mode is still switched on.
DMARC — what receivers do when the first two fail
DMARC is the instruction. SPF and DKIM produce a result; DMARC tells receivers what to do with it, and where to send the reports.
This is the record that matters most, and it is the one most often missing. The tool checks whether it exists, whether there is exactly one, and whether the policy is set to monitor or to enforce. Then it checks the reporting address, including a step most checkers ignore: if your reports go to a different domain, that domain has to publish a record authorising it. Without that, compliant receivers send nothing. Your DMARC record looks complete, and the reports never arrive.
Subdomains are handled properly too. A subdomain with no policy of its own inherits the organisational domain's record, so the tool falls back the way a receiver would.
What usually goes wrong, and how it gets fixed
Most domains fail on the same handful of things. Here they are, with the fix.
No DMARC record
Without DMARC, nobody is told what to do with mail that fails your checks. And nobody tells you it happened.
Start in monitor mode. Add a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comThen read the reports for two to four weeks before tightening anything.
DMARC stuck on monitor mode
p=none is the correct first step. It is not a destination. Left in place, it reports on forgery and then delivers it anyway.
Once the reports show your legitimate senders passing, move to p=quarantine. Later, move to p=reject. Do not skip straight to reject on a domain you have not measured.
SPF needs more than ten DNS lookups
This one is invisible. The record looks fine and does nothing.
Remove includes for services you no longer use. Then replace any provider include that resolves to a small, stable set of addresses with ip4: entries instead. Those cost zero lookups. Failing that, SPF flattening services exist, but they add a dependency that breaks when your provider changes IPs.
Remember that a third party can push you over the limit by editing their own record. So it is worth re-checking after any provider change.
Two SPF records
Usually this happens when a new provider is added without merging into the existing record. Receivers that find two return a permanent error and ignore SPF entirely.
Merge them into one record. Keep every include: from both, and keep one all at the end.
The record ends in ?all or +all
?all expresses no opinion, so unauthorised senders are treated exactly as if you had published nothing. +all is worse: it tells receivers that every server on the internet is authorised. That is almost always a typo, or a debugging change nobody reverted.
Use -all if you are confident your record is complete. Use ~all if DMARC is already enforcing.
No DKIM key found
First, confirm the selector. Send yourself a message, open the raw headers, and read s= from the DKIM-Signature line.
If there genuinely is no signing, enable DKIM in your mail provider's admin console. Most generate the key and give you the DNS record to publish. The step people forget is switching signing on after publishing the record.
Reports go to a domain that has not authorised them
If your rua address is on another domain — a DMARC reporting service, or a different company domain — that domain must publish an authorisation record. Otherwise receivers discard the request.
The record goes on the receiving domain:
yourdomain.com._report._dmarc.reportingdomain.com TXT "v=DMARC1"Subdomains held to a weaker policy
A record with p=reject; sp=none protects the domain and leaves every subdomain open. Attackers know to forge from names that were never used for mail.
Remove the sp tag. Subdomains then inherit the stronger policy automatically.
Found something broken?
Send me the result. I'll tell you what it takes to fix it, and whether it's worth paying anyone to do — including me.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.
Questions
Does this send any email?
Why does it say no DKIM key was found?
s= value in the DKIM-Signature header, and enter it in the selector box.I just fixed a record. Why does the result look the same?
Will moving DMARC to reject break my legitimate mail?
p=none with reporting first, confirm every legitimate sender passes, and only then tighten.My domain does not send email. Do I still need this?
v=spf1 -all and p=reject, which takes minutes and closes the door completely.What is the right order to fix these in?
p=none with reporting switched on. Never start at reject.