SPF, DKIM and DMARC checker
Look up the three DNS records that decide whether Gmail and Outlook trust mail from a domain.
This tool only reads public DNS or runs in your browser. It does not spend verification credits.
What this checker looks up
Three DNS records decide whether Gmail, Outlook, and everyone else *trust mail claiming to be from a domain*:
- [SPF](/resources/glossary/spf) — which servers may send.
- [DKIM](/resources/glossary/dkim) — a signature that the message was not altered and came from a key the domain published.
- [DMARC](/resources/glossary/dmarc) — what to do when SPF or DKIM fail, and where to send reports.
Paste a sending domain. We read live DNS. No account, no credits, uncapped. This is the same family of lookups as the MX tool, pointed at authentication instead of routing.
If the words are unfamiliar, read SPF, DKIM, and DMARC, explained without the jargon first, then come back and paste your domain.
Why list quality is not enough
A verified recipient list still lands in spam if the *sending* domain is unauthenticated. Providers treat missing SPF/DKIM/DMARC as a property of suspicious mail. You can do everything right on the To: line and still lose on the From: domain.
Conversely, perfect SPF on a domain that hard-bounces 20% of a cold list will still get you throttled. Authentication and verification are different jobs. This tool is the first one.
How to read each section
SPF
You want exactly one SPF TXT record on the apex, starting with v=spf1, listing the providers you actually send through, ending in ~all (soft fail) or -all (hard fail). Two SPF records is a common break: both get ignored or evaluated unpredictably.
An empty lookup means you have not published SPF. Mail from Google Workspace or Microsoft 365 may still go out — those hosts try — but receiving servers have nothing to check.
DKIM
DKIM is a TXT record on a *selector* hostname, often google._domainkey or selector1._domainkey. This checker looks up common selectors. If you use a custom selector your ESP chose, you may need to confirm in that ESP's dashboard even if this page shows a miss.
No DKIM means the message cannot prove it was unchanged in transit.
DMARC
A TXT record on _dmarc.yourdomain.com starting with v=DMARC1. p=none is monitor-only — the right place to start. p=quarantine and p=reject are tightening steps *after* the reports look clean. Publishing p=reject on day one of a new sending domain is how you discard your own mail.
A sensible order of operations
- Check this page on the domain you will put in From:.
- If SPF is missing, use the SPF generator and the provider setup pages.
- Turn on DKIM in Google Admin, Microsoft 365, or your ESP, then re-check.
- Publish DMARC at
p=nonewith arua=mailbox you actually read. The DMARC generator will draft it. - Only then start warmup.
Authentication before volume. Volume before clever copy.
What this tool cannot see
- Whether your DKIM *private* key is correctly installed on the sending host. We only see the public DNS side.
- Alignment issues (SPF pass on a bounce domain that is not the From: domain). Full alignment debugging is a header-level job; this page is DNS.
- Inbox vs spam for a specific message. That is reputation plus content plus complaints.
Related
- SPF record generator
- DMARC record generator
- Provider walkthroughs: SPF for Google Workspace, Microsoft 365
Related
- SPF record generator
Build a v=spf1 TXT record from the providers you actually send through.
- DMARC record generator
Build a _dmarc TXT record. Start at p=none, then tighten once the reports look clean.
- SPF, DKIM, and DMARC, explained without the jargon
What these three DNS records actually do, in plain language.
- Free work email finder
Find a work email from a name and company domain. Checked against the mail server, not guessed from a database.