Is your sending domain set up to be trusted?
Type a domain and read its SPF, DKIM, DMARC, MX, BIMI, MTA-STS and TLS-RPT records live from DNS — in plain English, with the exact record to publish where one is missing.
Free · no signup · 30 checks per hour · nothing stored
Authentication is the entry requirement, not the decision
Getting these records right does not guarantee the inbox. Getting them wrong guarantees you will not be considered for it.
Since February 2024, Gmail and Yahoo have required bulk senders to authenticate their mail, and Microsoft followed for Outlook.com in 2025. Pass and your email is judged on its merits: reputation, complaint rate, whether people open and reply. Fail and a large share of your list never gets the chance to ignore you.
It is also the part nobody notices has broken. A retired provider leaves an include: eating one of your ten SPF lookups, a rotated DKIM key leaves the old selector revoked, a new tool starts sending as your domain. Run this twice a year on everything you send from.
What each record does
Seven records, three of which are mandatory in practice and four of which are refinements.
SPF
A TXT record listing which servers may send as your domain. We follow every include: and redirect= recursively, count them against RFC 7208’s ten-lookup limit, and flag a second SPF record, the deprecated ptr mechanism, and includes pointing at a domain with no SPF of its own.
DKIM
A public key at <selector>._domainkey.<domain> that verifies the signature on your mail. Selectors are chosen by your provider and cannot be enumerated, so we probe common ones and say plainly that a miss is not proof of absence — enter yours to check it properly. We also flag revoked keys (an empty p=), test mode (t=y) and keys under 1024 bits.
DMARC
The policy that ties SPF and DKIM together and tells receivers what to do when they fail. We read the policy, subdomain policy, percentage, alignment modes and reporting addresses — flagging p=none as monitoring only, sp=none as a subdomain hole, pct below 100, and a missing rua= (enforcing a policy with no reports is enforcing it blind).
MX
Where mail to your domain is delivered. A From address with no MX record cannot receive replies or bounces, and some receivers read that as a spam signal. RFC 7505 null MX (".") is reported as what it is: a deliberate declaration that the domain accepts no mail.
BIMI
Optional. Shows your logo beside the message in participating clients, and needs DMARC at quarantine or reject plus a paid Verified Mark Certificate — so its absence is a low-priority note, not a failure.
MTA-STS and TLS-RPT
Optional, and about mail sent TO you. MTA-STS tells senders to require valid TLS so a connection cannot be downgraded to plaintext; TLS-RPT reports when it could not. Both come with the record to publish.
Getting to enforced DMARC without breaking your mail
The order matters. Skipping to p=reject before your reports are clean is how legitimate mail gets destroyed.
- 1
Authenticate every sender
List every service that sends as your domain — ESP, CRM, helpdesk, invoicing — in one SPF record, and set up DKIM signing with each. Watch the ten-lookup limit: going over is a permanent error that fails SPF for everything.
- 2
Publish p=none and read the reports
A DMARC record at p=none with a rua= address changes nothing about delivery and starts the aggregate reports flowing. Give it a few weeks: they surface sending sources you had forgotten, and your own mail that is failing alignment.
- 3
Move to quarantine, then reject
Once your legitimate mail passes consistently, step to p=quarantine so forged mail goes to spam, then p=reject so receivers refuse it. Keep sp= in step with p= or subdomains stay an open door, and keep pct at 100.
Findings with the record attached
Most checkers tell you something is missing and leave you to derive the syntax from a standards document. Where the fix is genuinely one DNS record, this one hands you the record — the host, the value, and the placeholders you have to fill in named explicitly. Where it is not one record, it says so.
- The exact TXT host and value for a missing SPF, DMARC, MTA-STS or TLS-RPT record
- Findings ordered failures first, then warnings, then passes — worst news at the top
- Every finding explains the consequence, not just the rule
What we deliberately do not check
There is no blocklist panel on this page, and that is not an omission. Blocklists are not checked here because a DNSBL answer is only truthful from the resolver that will actually deliver your mail: Spamhaus and the other major lists refuse queries from public resolvers and cloud IP ranges, and a refusal is indistinguishable from “not listed”. So the check reports the gap as its own finding and points you at a real answer — each list directly, or your ESP, which queries from the IPs that matter.
- No invented blocklist status, and an explicit finding explaining why
- DNS is read at check time over DNS-over-HTTPS — no cached results presented as live
- When the lookup budget is exhausted on a very long SPF chain, the result says so
More free email tools
Every one of these runs in your browser, needs no account, and has no usage limit.
Email authentication, answered
- Is this deliverability check free?
- Yes, completely, with no account. The lookup is rate-limited to 30 checks per hour per IP address to keep it available, and nothing about your domain is stored.
- Why does my email go to spam even though SPF and DKIM pass?
- Because authentication is the entry requirement, not the decision. Once you pass it, placement is decided by reputation and engagement: your domain’s and IP’s sending history, your complaint rate (Gmail asks bulk senders to stay under 0.3% spam reports), your bounce rate, and whether recipients open, click and reply. Authentication gets you considered. Engagement gets you delivered.
- What exactly do Gmail and Yahoo require from bulk senders?
- Since February 2024, anyone sending more than about 5,000 messages a day to Gmail or Yahoo users has to authenticate with SPF and DKIM, publish a DMARC record, keep the From domain aligned with the authenticated domain, offer one-click unsubscribe, and stay under a 0.3% spam-complaint rate. Microsoft introduced the same requirements for Outlook.com in 2025. None of it is new advice — the standards are between ten and twenty years old — but it is the point at which the industry stopped treating them as optional.
- Do I really need DMARC?
- Yes, if you send any volume. Since February 2024 both Gmail and Yahoo require a DMARC record from bulk senders, and without one nobody can tell receivers what to do with mail that forges your domain — or send you reports about who is trying. Start at p=none with a rua= address, read the aggregate reports for a few weeks until your legitimate mail is passing, then move to p=quarantine and finally p=reject.
- Why do you say a missing DKIM key might not be missing?
- Because DKIM keys live at a selector name your provider chooses, and there is no way to enumerate them from DNS. We probe the selectors that providers commonly use, but a sender using something unusual will show as "not found" when the key is fine. That is why the finding is a warning that names the selectors we tried and asks for yours, rather than a confident failure.
- Why don’t you check blocklists?
- Because we cannot do it truthfully from here, and a wrong answer on this is worse than no answer. A DNSBL result is only meaningful when it comes from the resolver that will actually deliver your mail, and the major lists refuse queries from public resolvers and cloud IP ranges — where a refusal looks exactly like "not listed". Every tool that shows you a green blocklist panel from a browser is showing you something it cannot verify. Check your own status directly with each list, or with your ESP, which queries from the IPs that matter.
- I just published a record and it still shows as missing.
- DNS answers are cached for the length of their TTL, so a change can take anywhere from a few minutes to a day to be visible everywhere. This check reads live from a public resolver, which usually sees updates within minutes, but if you had a previous record with a long TTL you may need to wait it out.
- Does this tell me if a specific message will be delivered?
- No, and nothing that reads DNS can. This tells you whether your domain is set up so that receivers are able to trust your mail. For a specific message, send yourself a real test and read the authentication results in the headers — and use the free preview and spam-check tools for the content side.
Domain sorted. Now get the email itself right.
Preview it in every client, check its accessibility and its spam signals, then share one link for approval.
14-day all-access trial · no credit card required · reviewers never need an account