Email authentication
Check your domain's email authentication
Most checkers tell you a record exists.
This one tells you whether it works.
No signup. Nothing stored. Four seconds.
Enter a domain to see what receiving mail servers see when they decide whether to trust your email.
Why your email goes to spam
Receiving mail servers do not read your subject line to decide whether to trust you. They read your DNS. Three records tell them whether an email claiming to come from your domain actually came from you. If those records are missing, contradictory, or quietly broken, your mail is treated as suspicious — no matter how well you wrote it.
MX — where your mail arrives
The MX record points to the server that accepts mail for your domain. It has to point to a hostname, never an IP address, and never to a CNAME. If it's missing, your domain cannot receive email. If it's proxied behind a CDN, delivery breaks in ways that are difficult to diagnose.
Those mail servers also carry your sending reputation. You can check whether they're on a public blocklist — a listing is one of the few things that blocks delivery outright.
SPF — who is allowed to send
An SPF record lists the servers permitted to send mail on your behalf. Two things go wrong with it, and both are invisible from the outside.
The first is the lookup limit. Every include: in your record triggers a DNS lookup, and each of those can trigger more. The specification allows ten. Past ten, receiving servers stop evaluating and return a permanent error — which means your SPF record is ignored entirely. The record still looks correct in your DNS panel. It simply does nothing. This is the single most common cause of deliverability failure I see, and almost no free checker counts the lookups.
Want to see the chain itself? Walk your own record's include tree and find exactly which nested include pushes it over the limit.
The second is the ending. A record ending in -all tells receivers to reject unauthorized mail. ~all tells them to accept it and flag it. ?all tells them to make no judgment at all. Most domains sit on ~all for years because someone was cautious once and never came back.
DKIM — proof the message wasn't altered
DKIM signs each outgoing message with a private key. The matching public key lives in your DNS. Receivers use it to confirm the message really came from you and wasn't modified in transit. Keys are published under a selector — a label your provider chooses — which means DKIM can only be checked from outside if you know the selector. This is why a checker that reports "DKIM: not found" is overstating what it knows.
If you know your selector, you can look the key up directly — it will tell you whether the key is strong, weak, revoked, or simply not published.
DMARC — what happens when a message fails
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both. It has three policy levels. p=none means monitor and do nothing. p=quarantine means send failures to spam. p=reject means refuse them outright.
Most domains that have DMARC are sitting on p=none, which is why "you have a DMARC record" is not the same as "your domain is protected." A p=none policy does not stop anyone from sending mail as you. It only lets you watch it happen — and only if you've configured a reporting address, which many haven't.
Since February 2024, Google and Yahoo have required a DMARC record from anyone sending more than 5,000 messages a day. The requirement is a record, not a policy. Meeting the requirement and being protected are two different things.
Questions
- Is this free?
- Yes. No signup, no email address, no limit worth mentioning.
- Do you store the domains people check?
- No. The query runs, the result is returned, nothing is written down.
- Why does it say my SPF record is broken when my DNS panel says it's fine?
- Your DNS panel checks syntax. It doesn't count DNS lookups. A record can be perfectly valid and still exceed the ten-lookup limit, at which point receiving servers ignore it. That's the most common version of "everything looks right but mail still fails."
- I have a DMARC record. Why isn't that enough?
- Check the policy. If it says p=none, it monitors but blocks nothing — anyone can still send mail as your domain and it will be delivered.
- You couldn't find my DKIM key. Is DKIM broken?
- Not necessarily. DKIM keys are published under a selector chosen by your provider, and I test the common ones. If yours uses a custom selector, I won't find it from outside. It means unconfirmed, not missing.
- Can I just fix this myself?
- Often, yes. The records are public and the specifications are open. What takes time is working out which of your systems send mail, in what order they need to be merged, and how to move to enforcement without silently dropping legitimate messages. If you want to do it yourself, the notes on this site cover most of it.