SPF, DKIM, DMARC, MX, PTR, MTA-STS, and TLS-RPT are checked as public signals. Real pass/fail still depends on actual messages and receivers.
Email Deliverability Doctor
Check the public DNS and optional sender-IP signals that commonly affect email authentication: MX, SPF, DMARC, DKIM selector records, MTA-STS, TLS-RPT, PTR, and selected blacklist context.
This tool does not send test email, log into mailboxes, inspect content, or promise inbox placement. It shows what is visible and what to fix next.
Direct answer
Email Deliverability Doctor: answer first
Email Deliverability Doctor reviews public email-domain signals including MX, SPF, DMARC, DKIM selectors, MTA-STS, TLS-RPT, sender route, and blacklist context. It estimates readiness and does not guarantee inbox placement.
Before interpreting resultsEmail report limits
The result is an Email Trust Estimate, not a deliverability score, spam score, reputation guarantee, or provider compliance certification.
Diagnosis first
Email Trust Estimate
Safe report available after scan.
Preparing your report...
Email trust audit
Authentication, Policy and Sender Route
MX, SPF, DMARC, DKIM selectors, MTA-STS, TLS-RPT, PTR/FCrDNS, and selected blacklist context.
Run a scan to build the email trust audit.
The audit will summarize readiness categories and practical DNS/mail-provider fixes.
Top issues
What needs attention
Maximum five issues are shown here.
Next steps
Recommended Fixes
Prioritized for DNS and mail-provider work.
Technical details
Checks
Collapsed by default.
Share safely
Copy Actions
Use Safe Copy before sharing results.
Safe Copy keeps the domain-level result, removes raw sensitive fields, masks IP values, and confirms that email local-parts are not stored or copied.
Limits
What this tool does not do
Clear limits keep the result useful.
No test email
The scanner does not send mail, open relays, log into accounts, or inspect message bodies.
No DMARC alignment claim
Alignment can only be judged from real message headers and Authentication-Results.
No DKIM missing claim without selector
DKIM selectors are provider-specific, so the scan checks only selectors you provide.
No universal reputation guarantee
Selected blacklist signals are limited and cannot replace provider postmaster tools.
Monitoring beta (optional)
Email authentication change review is available for beta review
Monitoring will compare MX, SPF, DKIM selector checks, DMARC policy, MTA-STS, TLS-RPT, PTR/FCrDNS, and selected blacklist signals. Beta review is optional; public signup, dashboards, billing, and automatic alerts are not live.
- DMARC policy weakened
- SPF invalid or risky
- MX/PTR provider changes
- Blacklist signal appeared or resolved
Focused tools
Related Tools
Use these when one signal needs deeper detail.
Email Domain Checklist
Email authentication review without inbox-placement claims
Use the free email scan to review public authentication signals. Beta monitoring can compare approved mail-domain changes, but it does not send email or promise placement.
One-time scans are free. Monitoring beta is optional, requires approved public targets, and does not mean public signup, automatic alerts, billing, or dashboards are live. See How We Make Money and the Affiliate Disclosure.
B2B diagnostic report model
Email domain diagnostics
Email checks connect MX, SPF, DMARC, optional DKIM selector records, PTR/rDNS, sender-IP context, blacklist context, and email-header evidence.
Client-safe report
Share findings without leaking raw technical material
Use Safe Copy or this page's summary when sending results to a client, vendor, developer, or support team. Raw headers, credentials, tokens, cookies, private addresses, email local-parts, and oversized payloads should stay out of client-facing copy.
Check my email domain
What this checks
Public mail-domain records and pasted email-header signals such as MX, SPF, DMARC, DKIM selector context, and sender-route clues.
Limits
What this cannot check
It cannot guarantee inbox placement, inspect private mailboxes, or certify sender reputation everywhere.
Read results
How to use the output
Treat results as review signals for this browser/session or public target. Re-test after one change, then use Safe Copy or notes that avoid raw identifiers.
SEO and AI citation summary
Email Deliverability Doctor: what this tool does
Runs an email authentication exposure estimate across MX, SPF, DMARC, optional DKIM selectors, MTA-STS, TLS-RPT, PTR, and selected sender-IP signals without sending email.
How to use
- Enter one public domain, email domain, optional selector, or pasted header depending on the tool.
- Review authentication, policy strength, routing, and monitoring signals together.
- Apply one DNS or mail-provider change, then retest after propagation.
What the result means
Treat MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, PTR, and header findings as email trust signals. They do not guarantee inbox placement or prove sender identity alone.
Limitations
- This tool reports observable signals only; it is not a guarantee or certification.
- Uses /api/email-exposure backed by constrained DNS-over-HTTPS checks for MX, TXT, PTR, optional selector records, and selected public sender-IP signals. Email local-parts are not stored or returned.
- Results can change after VPN reconnects, DNS propagation, browser updates, cache changes, or provider configuration changes.
FAQ
Does this prove email deliverability?
No. It checks public authentication and optional sender-IP signals, but it does not send test email or guarantee inbox placement.
Can it check DKIM without a selector?
No. DKIM selectors are provider-specific, so the tool checks only selectors you provide.
What does Email Deliverability Doctor do?
Email Deliverability Doctor runs an email authentication exposure estimate across MX, SPF, DMARC, optional DKIM selectors, MTA-STS, TLS-RPT, PTR, and selected sender-IP signals without sending email. Results are review signals with stated limits.
How should I use Email Deliverability Doctor results?
Use the result to decide what to review next, make one change at a time, and retest in the same browser, network, domain, or provider context when possible.