DKIM
Not FoundDKIM evidence was not found in the pasted headers.
Make Sense of Your DNS
Domain Email Auth Checker
Check visible email authentication signals: MX, SPF, DKIM, DMARC, and what still needs a real sent email header.
This checker summarizes public DNS evidence. It does not inspect email headers, send email, access mailboxes, store submitted domains, or connect to any provider account.
Run a Check
Check a domain
Use one domain or subdomain, such as example.com. Submitted domains are used only for this lookup response. This review applies only to the exact domain or subdomain entered. Some organizations use separate subdomains for marketing or transactional sending.
Advanced DKIM selector
The checker also tries common selectors such as selector1, selector2, google, k1, s1, default, mail, mandrill, kl, and sendgrid.
Ready to check public DNS evidence.
Advanced: Analyze email headers
Paste full message headers from a received email to compare public DNS evidence with what actually happened when the message was delivered.
Headers are parsed in your browser only. They are not submitted, stored, or logged.
You can paste the full message source. The checker will read the header section before the email body.
Header analysis runs locally in this browser.
Real message authentication
Paste full email headers to summarize authentication results from one received message.
Header analysis works without a DNS lookup.
No authentication results were found in the pasted headers.
SPF
Not FoundSPF evidence was not found in the pasted headers.
DMARC
Not FoundDMARC evidence was not found in the pasted headers.
Message details
ReadyDomain-level message details will appear here.
Unsubscribe signals
ReadyList-Unsubscribe evidence will appear here when present.
How to read this result
Analyze a received message header to summarize what the mailbox reported for this message.
This reflects one received message. It does not prove every message from this domain authenticates the same way.
Email authentication summary
The summary explains visible DNS evidence in plain language, with limits where only a real sent email header can prove behavior.
Ready
Good Foundation
Enter a domain to review public DNS evidence for MX, SPF, DKIM, and DMARC.
Public DNS Evidence
0
/ 100
High DNS Confidence
The score is based only on public DNS evidence returned by the checker.
- Why
- Run a lookup to see which public DNS records are visible.
- Limitation
- Headers are still required to confirm actual sending behavior.
Authentication records
MX
ReadyRun a lookup to review inbound mail routing evidence.
What this tells us
MX records show where a domain receives mail. They do not prove which service sends mail for the domain.
SPF
ReadyRun a lookup to review SPF-style TXT evidence.
What this tells us
SPF can authorize sending services for a domain. Multiple SPF records at the same name can cause authentication problems.
DKIM
ReadyRun a lookup to review selector-specific DKIM evidence.
What this tells us
DKIM uses selector-specific DNS records. Finding a selector is useful, but only message headers can confirm a sent email was actually signed.
DMARC
ReadyRun a lookup to review DMARC policy evidence.
What this tells us
DMARC tells receiving systems how to handle mail that fails alignment checks. Policy should be tightened only after legitimate sending is understood.
DMARC policy language
p=none
Monitoring Mode
Mail is not asked to be quarantined or rejected by policy. Best while validating legitimate mail and reviewing DMARC reports.
p=quarantine
Partial Enforcement
Receiving systems may place failing mail in spam or quarantine. Best after most legitimate mail is authenticating correctly.
p=reject
Full Enforcement
Receiving systems are asked to reject mail that fails DMARC checks. Best after all legitimate sending sources are understood and passing authentication.
Strict policy is not automatically better. It can cause delivery issues if SPF or DKIM alignment is incomplete for legitimate mail.
Provider evidence
Provider interpretation is not included in this version.
Provider names should only appear when DNS evidence is explicit and provider-specific. Weak hints should stay out of this section.
DNS records can show authorized providers, but a real sent email header is needed to confirm which platform sent a specific message.
Things to Review
Review first
Header confirmation
Send a real test email and inspect the authentication headers before treating DNS records as proof of outgoing signing.
Review next
DMARC monitoring
Review aggregate reports before considering quarantine or reject.
Good to Know callouts
Could Not Be Confirmed is not a failure
DNS lookups can miss selector-specific DKIM records or private sending paths. The safest language is narrow and evidence-based.
One SPF record per name
Multiple SPF records at the same name can create authentication problems. A real checker should flag that as Needs Review.
DMARC policy should be staged
Monitoring first, then stricter policy only after legitimate sending sources and alignment are understood.
Expert Perspective
Run a lookup to see a practical, evidence-based perspective on what the DNS records can and cannot confirm.
What DNS can and cannot prove
DNS can show
Public records, authorized sending hints, DMARC policy, inbound mail routing, and provider-specific evidence when it is explicit.
DNS cannot prove
Which platform sent a specific message, whether a live message was signed, whether alignment passed, or whether inbox placement will be good. Real message headers and provider dashboards can confirm behavior this DNS review cannot.
This checker summarizes public DNS-style findings. It does not inspect email headers, send email, access mailboxes, verify inbox placement, or confirm which platform sent a specific message. This review applies only to the exact domain or subdomain entered.