Free tool — no account, no card
Is your domain silently landing in spam?
One check covers everything receivers look at: SPF, DKIM, DMARC, MX and 39 blacklists. You get a score, the problems, and the exact fix for each.
What gets checked
Five checks, one score.
Why mail goes to spam
Nobody sends you a bounce that says "your DKIM key is gone".
Deliverability fails quietly. Gmail keeps accepting your mail — it just files it under Spam, and the only signal you get is that people stop replying.
Receivers ask three questions of every message: did an authorised server send it (SPF), is the signature intact (DKIM), and does the domain tell us what to do when the answer is no (DMARC)? A fourth question sits underneath all of them: is this sender on a list of known spammers?
Any one of these can break without you touching a thing. An IT provider adds a mail tool to your SPF record and pushes it past the 10-lookup limit. A key rotates and the old selector stops resolving. A shared IP at your host gets listed on Spamhaus because of somebody else. This check answers all four questions at once and tells you which one is currently costing you.
How the pieces fit
SPF and DKIM produce a verdict. DMARC decides what it's worth.
The three records people talk about as one thing are three separate jobs. They only protect you when they chain together correctly — and the chain has a specific weak link most setups get wrong.
SPF checks the connecting server. When a server opens a connection to Gmail, SPF asks a single question: is this IP on the domain's published list of permitted senders? Pass or fail, that verdict is about the envelope sender — the address in the connection, not the one your recipient reads.
DKIM checks the message. Your sending platform signs each message with a private key; the matching public key sits in your DNS under a selector. The receiver recomputes the signature and confirms nothing was altered in transit. DKIM survives forwarding, which SPF often does not — the two overlap on purpose.
DMARC ties both to the domain your reader sees. This is the part that bites. SPF and DKIM can each pass on a domain the recipient never sees — a newsletter tool's own domain, a reply address, a bounce path. DMARC demands alignment: the domain that passed SPF or signed with DKIM must match the visible From:. Only then does it apply your policy — none, quarantine, or reject. A message can pass SPF and DKIM outright and still fail DMARC because neither one aligned. That single fact is behind most "but my SPF is green" surprises.
A healthy setup, and where it fails
Each layer has exactly one thing that usually breaks it.
End to end, a domain in good standing looks the same everywhere. So do the failures. Here is what right looks like — and the single point of failure that takes each layer down.
What a clean domain publishes
SPF v=spf1 include:_spf.google.com include:sendgrid.net ~all DKIM google._domainkey → 2048-bit public key, resolves DMARC v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s MX mail routes to your provider, servers answer PTR each sending IP resolves back to a name that matches
SPF breaks on the lookup count. Every
include: costs a DNS lookup, and each include carries
its own. Google spends three before you add anything. Past ten, SPF returns permerror and receivers
treat you as if you published nothing.
DKIM breaks on rotation. A platform issues a new key and retires the old selector; if the new public key was never added to DNS, signatures start failing the day the switch happens. Nothing bounces.
DMARC breaks on alignment, or on never leaving
p=none — a record that reports and protects nothing.
MX breaks on a dangling record pointing at a host
that no longer answers. PTR — reverse DNS — breaks
when a sending IP has no name, or a name that does not match; Microsoft 365 in particular is blunt
about rejecting mail from IPs with no valid PTR. Blacklists
need nothing of yours to go wrong: a neighbour on a shared IP is enough.
Why a green check goes red
Passing today is not the same as passing next month.
A one-off check is a photograph of your DNS at one moment. The things that break deliverability move after you take the photo — and none of them tell you they moved.
In 2024 Google and Yahoo made SPF, DKIM and a DMARC record hard requirements for anyone sending in bulk to their users. Microsoft has since followed. The bar that was optional advice is now the gate — and it moves. A setup that cleared it last year can quietly fall behind a tightened rule this year without a single record changing.
More often it is your own side that shifts. A vendor updates the includes behind their SPF macro and
your record silently crosses ten lookups. A platform rotates a DKIM key on a schedule you never saw. An
IT contractor adds a tool and drops the all mechanism. A
shared IP picks up a Spamhaus listing overnight because of another tenant. Each of these turns a passing
domain into a failing one between one send and the next, and the first symptom is always the same — mail
that used to land starts landing in Spam.
Know what a DNS check can and cannot see. Reading your
records tells you the rules you have published: whether SPF is valid, whether a DKIM key resolves at a
known selector, whether DMARC enforces anything, whether an IP is listed. It cannot see a live message
being authenticated, and it cannot see which of your senders actually align — that lives in the
DMARC aggregate reports receivers send back, which only arrive if you have an rua=
address and something ingesting them. A one-off check catches a broken record. Continuous monitoring
catches the record that breaks after you looked, and the reports that show who is really sending as you.
Check once to fix what is wrong now. Monitor to know the day it changes.
Common questions
Before you hit Check.
How it works
Real DNS queries, not a cached database.
We query your records live, the way Gmail or Outlook would at the moment of delivery. What you see is what receivers see.
- 1 You enter a domain. No verification needed — the records we read are public DNS, the same ones every mail server reads.
- 2 We run ~90 live queries. DNS records, selector probes, and one lookup per blacklist — about 40 seconds in total.
- 3 Every finding is scored and explained. Problems that cost you deliverability today, watches that will — each with numbered steps to fix it.
- 4 The report gets its own link. It stays at that URL: send it to your host, your IT provider or your client instead of a screenshot. Public DNS only — we store the answers, never your mail.
The other free checks