Email Deliverability Checker — SPF, DKIM, DMARC and MX
See your domain's mail authentication exactly as a receiving server sees it, and get a score for what is missing.
Free and instant — results appear in seconds. No sign-up, no limits, and nothing you type is stored.
When legitimate mail lands in spam, the cause is authentication far more often than content. A receiving server checks three things before it looks at your subject line: does an SPF record authorise the server that sent this, does a DKIM signature verify, and does a DMARC policy say what to do if either fails.
What makes this hard to notice is that broken authentication produces no error. Your mail client says sent. The queue drains. Nothing bounces. Somewhere on the other side a filter quietly scores the message down, and you find out weeks later when a client mentions they never got the invoice.
This tool reads all four record types for your domain and grades what it finds. Add your DKIM selector if you know it — mail providers each use their own, so a blind check can only try the common ones.
A domain with the usual gap
Here is a real-shaped result for a business that set up SPF years ago and never went further:
Grade: C (55 / 100)MX PASS 2 mail servers found
SPF PASS v=spf1 include:_spf.google.com include:sendgrid.net ~all
DKIM PASS google selector responded
DMARC WARN v=DMARC1; p=none;
```
SPF, DKIM and MX are all fine. The problem is the DMARC line, and it is worth understanding why it costs so much.
p=none tells receiving servers: check the authentication, then deliver the message regardless of the outcome. It is monitor-only. It was designed as a first step — you publish it, collect reports for a few weeks, confirm your legitimate senders all pass, then tighten.
Most domains never take the second step. They publish p=none and stop, which leaves the domain forwarding no instruction at all. Anyone can spoof it and receiving servers have been told explicitly not to act.
There is a second problem here that the grade does not fully capture: no rua= address. Without it, no aggregate reports are sent anywhere, so nobody can see who is sending as this domain. Adding one is free and is the entire point of running p=none in the first place.
The fix sequence:
v=DMARC1; p=none; rua=mailto:dmarc@example.com;
↓ after 2-4 weeks of clean reports
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com;
↓ raise pct gradually to 100
v=DMARC1; p=reject; rua=mailto:dmarc@example.com;Moving straight to p=reject without the reporting phase is how people accidentally block their own invoicing system.
What each record actually does
MX names the servers that receive mail for your domain. It has no direct bearing on whether your outbound mail is trusted, but a domain with no MX at all is treated as suspicious by some filters, since a domain that cannot receive replies looks disposable.
SPF is a TXT record listing which servers are permitted to send mail using your domain in the envelope sender. The receiving server compares the connecting IP against that list.
DKIM attaches a cryptographic signature to each outgoing message. The public key lives in DNS at selector._domainkey.yourdomain. If the signature verifies, the message was not altered in transit and genuinely came from a system holding your private key.
DMARC ties the two together. It tells receivers what to do when SPF and DKIM fail, and — crucially — where to send reports about it.
The SPF ten-lookup limit
SPF permits a maximum of ten DNS lookups while evaluating a record. Each include:, a, mx, ptr, exists and redirect counts, and includes are recursive — one include: pointing at a provider who themselves use three includes consumes four of your ten.
Exceed the limit and the record returns permerror, which most receivers treat as a failure. You do not get a partial pass.
This breaks silently over time. Each new service you connect adds an include, and the tenth one takes the whole record down. If the checker warns about lookup count, flatten the record or drop services you no longer use.
Choosing an "all" mechanism
The final token in an SPF record sets the default for senders not otherwise listed:
-all(hard fail) — reject anything unlisted. Correct once you are confident the list is complete.~all(soft fail) — treat as suspicious but accept. The sensible default while you are still discovering senders.?all(neutral) — no opinion. Nearly useless.+all— anyone may send as you. Actively harmful; it grants the world permission to spoof your domain.
Omitting all entirely leaves the record with no defined default, which is nearly as unhelpful as ?all.
Why DKIM cannot always be found automatically
DKIM keys are published under a selector name chosen by whoever set up the mail service. Google Workspace commonly uses google, Microsoft 365 uses selector1 and selector2, and self-hosted setups use whatever the administrator picked.
There is no way to enumerate selectors from DNS — you can only test names you already suspect. This tool tries the common ones, but a negative result on a blind check does not prove DKIM is missing. Find the selector in your mail provider's DNS instructions and enter it directly.
Things this tool cannot tell you
Authentication is necessary but not sufficient. A perfectly configured domain still lands in spam if:
- The sending IP has a poor reputation, often inherited on shared hosting.
- Recipients mark the mail as spam, which outweighs almost everything else.
- You send to stale lists with high bounce rates.
- The domain is newly registered with no sending history.
- Message content trips content filters independently.
Fix authentication first because it is deterministic and fully in your control. Reputation takes consistent sending over weeks.
Frequently asked questions
What is the difference between SPF, DKIM and DMARC?
SPF lists which servers may send mail for your domain. DKIM cryptographically signs each message so tampering is detectable and the sender is verifiable. DMARC tells receiving servers what to do when SPF or DKIM fails, and where to send reports. You need all three; each covers a gap the others leave.
Why can the tool not find my DKIM record?
DKIM keys live at a selector name that whoever configured your mail service chose, and there is no way to list selectors from DNS. The checker tries common names such as default, google, selector1 and k1. If yours differs, enter it in the selector field — your mail provider's setup instructions will name it.
Can I have two SPF records?
No. A domain must publish exactly one SPF TXT record. Two causes a permanent error and the check fails entirely rather than merging them. If you use several mail services, combine them into one record using multiple include: mechanisms.
What DMARC policy should I use?
Start at p=none with a rua= reporting address and leave it for two to four weeks while you read the reports. Once every legitimate sender is passing, move to p=quarantine, optionally with pct= set low and raised gradually. Reach p=reject only when the reports are clean. Jumping straight to reject blocks your own mail.
I fixed my records but mail still goes to spam. Why?
Authentication is one input among several. Sending IP reputation, recipient complaint rates, list hygiene, domain age and message content all matter independently. Authentication is worth fixing first because it is deterministic and entirely under your control, but reputation is built through consistent sending over weeks.
Does this tool send a test email?
No. It only reads public DNS records — the same records any receiving mail server queries. Nothing is sent to or from your domain, and no mailbox is contacted.
Do I need SPF if I use Google Workspace or Microsoft 365?
Yes. The provider supplies the include: value, but publishing the record in your DNS is your responsibility, and it is not created automatically when you sign up. The same applies to DKIM, which usually needs enabling in the admin console as well as adding to DNS.
Reviews
No reviews yet. If this tool solved something for you, yours would be the first — and it helps other people decide whether it is worth their time.