Free Email Deliverability Checker
Enter a domain and see its mail servers and its email-authentication setup, SPF, DKIM and DMARC, graded the way our monitoring engine grades them.
Reading the zone...
Could not check
This domain publishes no DNS records at all, so it has no mail setup to read.
No MX records, this domain is not set up to receive email.
No issues found in the records we could read.
What is an Email Deliverability Checker?
An email deliverability checker reads the DNS records that decide whether a domain's email reaches the inbox: the MX records that route incoming mail, and the three authentication records, SPF, DKIM and DMARC, that let receiving servers verify a message really came from you.
Get them wrong and your mail lands in spam or is rejected outright, while anyone can spoof your domain. This tool reads all four through the same DNS engine our monitoring uses, grades the setup, and points out exactly what is missing or misconfigured, including the subtle failures like two conflicting records where there should be one.
- Enter the domain you send email from.
- We read its MX, SPF, DKIM and DMARC records and grade the authentication posture.
- Fix what is flagged, a missing DMARC policy, a too-permissive SPF, a duplicate record, then re-check to confirm.
Why Check Email Authentication?
- Deliverability: mailbox providers increasingly reject or spam-folder unauthenticated mail. SPF, DKIM and DMARC are the difference between the inbox and the void.
- Anti-spoofing: without a DMARC policy, anyone can send email that appears to come from your domain. The policy is what tells receivers to reject the fakes.
- The subtle failures: two SPF records, or two DMARC records, mean receivers apply neither. We surface those the way the engine does, because they read as "present" to a naive check and silently fail.
The Records That Decide Deliverability
Four records carry a domain's email setup. Here is what each does and why it matters.
| Record | What it does | Why it matters |
|---|---|---|
| MX | Routes incoming mail | Names the mail servers that receive email for the domain, in priority order. No MX means the domain cannot receive mail at all; a wrong one sends it to the wrong provider. |
| SPF | Authorises senders | A TXT record listing which servers may send mail as your domain. Receivers check it to catch forgeries. Exactly one SPF record is allowed, two mean receivers apply neither. |
| DKIM | Signs your mail | A cryptographic signature, published per selector, that proves a message was not altered and really came from your domain. Missing DKIM weakens DMARC and hurts deliverability. |
| DMARC | Sets the policy | Ties SPF and DKIM together and tells receivers what to do with mail that fails, none, quarantine, or reject. Without it, spoofed mail is delivered and you never hear about it. |
How to Read the Result
The panel grades the whole setup, then breaks it down record by record.
The overall grade
The headlineStrong, Adequate, Weak or Not configured, the same grade our monitoring engine assigns, based on which records are present and whether any carry a serious finding. It is the one-glance answer to "is my email set up right?".
Your mail servers
RoutingThe MX records in priority order, the servers that receive mail for the domain. No MX at all means the domain cannot receive email, which is either a problem or a deliberate send-only setup.
SPF, DKIM and DMARC
AuthenticationEach of the three is shown as configured or missing, with its key detail, the SPF qualifier, the DKIM selectors found, the DMARC policy. Together they decide whether receivers trust your mail.
How email auth worksDuplicate records
The silent failureTwo SPF records, or two DMARC records, are worse than one: the standards tell receivers to apply neither, so a domain that looks protected is not. We surface these explicitly because a simple "is it present?" check reports them as fine.
What Email Authentication Is
Email was designed with no way to verify the sender, so anyone could put any address in the "from" line. SPF, DKIM and DMARC are the three DNS-published standards that bolted authentication on afterwards, and mailbox providers now lean on them heavily to decide what reaches the inbox.
The three answer different questions:
- SPF: is this server allowed to send for the domain?
- DKIM: was this message signed by the domain and unaltered?
- DMARC: what should happen when SPF and DKIM disagree with the from address?
How They Work Together
SPF and DKIM each provide a signal; DMARC is what turns those signals into a policy and a feedback loop. A DMARC record says "if a message claiming to be from us fails both SPF and DKIM alignment, quarantine or reject it", and, through its reporting address, tells you who is sending as your domain.
This is why a missing DMARC record is the most common serious gap: SPF and DKIM can be perfect, but without DMARC nothing enforces them, and spoofed mail sails through. Start at p=none to observe, then tighten to quarantine and reject as you confirm your legitimate mail passes. Continuous monitoring is what keeps it correct as your senders change.
Where Email Setups Go Wrong
Most email-auth problems are not missing records, they are records that look fine and are not. The common traps:
- Two SPF records, adding a second TXT SPF record instead of merging into one means receivers apply neither, and all your carefully-listed senders are ignored. The fix is always one record.
- Two DMARC records, same failure, same rule: the standard says receivers apply none when there is more than one. A duplicate DMARC leaves you unprotected while appearing configured.
-
SPF too permissive, a record ending in
+allor with too many lookups fails open, authorising senders you did not mean to. The qualifier matters as much as the presence. - DMARC at p=none forever, a policy of none only monitors; it never blocks a spoof. It is the right place to start and the wrong place to stay. Once you have confirmed your legitimate mail passes, tighten it, and run a DNS lookup if a record is not being read as you expect.
Why Email Posture Matters
Stop domain spoofing
Without an enforcing DMARC policy, anyone can send email that appears to come from your domain, to your customers, your staff, or your partners. The policy is what makes the spoof bounce.
Reach the inbox
Mailbox providers increasingly quarantine or reject unauthenticated mail, and some now require DMARC for bulk senders outright. Correct SPF, DKIM and DMARC is table stakes for landing in the inbox.
Blunt business-email fraud
Business-email-compromise scams rely on look-alike and spoofed senders. Authentication removes the easiest version, a message that is actually from your exact domain but should not be.
Protect sender reputation
Spoofed mail sent as your domain damages the reputation that governs your own deliverability. Locking down who can send as you protects the asset your real mail depends on.
Who Checks Email Deliverability
The same read answers a different question depending on who is asking.
IT & Email Admins
Confirm SPF, DKIM and DMARC are correct after setting up a new domain or adding a sending service.
For DNS monitoringSecurity Teams
Verify the anti-spoofing posture of the domains you are responsible for, and catch the duplicate-record failures.
For IT & MSPsEmail Marketers
Diagnose why a campaign is landing in spam, authentication is the first thing mailbox providers check.
For marketersAgencies
Audit a client's email setup and set up monitoring so a broken record does not become a deliverability incident.
For agenciesRelated DNS & Email Tools
Once you know where your setup stands, here is where to go next.
Monitor email auth
SPF, DKIM and DMARC drift as your senders change. Get alerted when a record breaks, instead of finding out from a bounced campaign.
Email auth monitoringFull DNS lookup
See every record for the domain, the full picture when an email-auth record is not being read the way you expect.
Run a DNS lookupCheck propagation
Just added or changed an SPF or DMARC record? Confirm it has propagated to every resolver before you rely on it.
Check propagationDNS monitoring
Put the whole zone under continuous monitoring so any change, to mail records or anything else, reaches you as an alert.
DNS monitoringFrequently Asked Questions
Common questions about MX, SPF, DKIM, DMARC and email deliverability.
What does this email deliverability checker do?
It reads a domain's MX records (which route incoming mail) and its SPF, DKIM and DMARC records (which authenticate outgoing mail), grades the setup, and flags what is missing or misconfigured, including subtle failures like duplicate records.
What is SPF?
Sender Policy Framework, a TXT record that lists which servers are allowed to send email for your domain. Receiving servers check it to detect forgeries. A domain is allowed exactly one SPF record; two cause receivers to apply neither.
What is DKIM?
DomainKeys Identified Mail, a cryptographic signature added to your outgoing messages, with the public key published in DNS under a selector. It proves a message was not altered in transit and genuinely came from your domain.
What is DMARC?
Domain-based Message Authentication, Reporting and Conformance, a policy record that ties SPF and DKIM together, tells receiving servers what to do with mail that fails (nothing, quarantine, or reject), and can send you reports on who is sending as your domain.
Why does having two SPF or two DMARC records break things?
The standards require exactly one of each. When a domain publishes two, receivers are instructed to apply neither, so a domain that looks protected is not. This is a common and silent failure, which is why the checker surfaces it explicitly.
What does the overall grade mean?
It reflects which records are present and whether any carry a serious finding: Strong (well configured), Adequate (present but with a high-severity gap), Weak (a critical problem), or Not configured (no SPF or DMARC at all). It is the same grade our monitoring engine assigns.
My domain has no MX records. Is that a problem?
It depends. No MX means the domain cannot receive email. That is a problem for a domain you expect to get mail on, and perfectly fine for a send-only or parked domain. The checker reports it either way so you can judge.
Does the checker read my actual emails?
No. It reads only the public DNS records that describe your mail setup, MX, SPF, DKIM and DMARC. It never connects to your mail servers or reads any message.
What is the right DMARC policy?
Start at p=none to observe without affecting delivery, use the reports to confirm your legitimate mail passes SPF or DKIM alignment, then tighten to quarantine and finally reject. Staying at none indefinitely provides monitoring but no protection against spoofing.
How is DKIM checked without knowing my selectors?
DKIM keys are published under selectors, and the engine probes the common ones. If your domain uses an unusual selector the checker may not find it; a missing DKIM result is worth confirming against your mail provider's documentation.
I just changed a record. Why does the checker not see it?
DNS changes take time to propagate. If a new SPF or DMARC record is not showing, check whether it has propagated across resolvers, and confirm there is not a second, older copy of the record still present.
How often should I check?
A one-off check confirms today's setup, but email authentication drifts, the day you add a new sending service and forget to include it in SPF, your setup silently breaks. For anything you send real mail from, continuous monitoring is the right tool.
Start Monitoring & Catching Domains Today
Join founders, agencies, and domainers already protecting their portfolio. Your first 5 domains are free.
No credit card required • Cancel anytime
Guides for domain operators
Deep dives on domain names, DNS, SSL, acquisitions and portfolio management.
All guides →
Do Exact Match Domains (EMDs) Still Work? How to Find & Grow Them
Do exact match domains (EMDs) still work in 2026? Discover current SEO ranking data, AI search impact, and how to acquire and grow an EMD with Domainyze.
How to Catch Domains with Hidden Expiry Dates
WHOIS won't show the expiry date for .de, .ai, .nz and other domains. Here is how to monitor domain expiration behaviorally, with no registry dates required.
Do All Pending Delete Domains Go Through Auctions?
Learn why not all pending delete domains go to auction. Explore pre-release sales, dropcatching mechanics, and multi-backorder bidding rules across registrars.