Email DNS Health Checker
Check a domain's MX, SPF and DMARC records and score whether it is set up to send and receive mail or quietly broken.
This email DNS health checker reads the MX, SPF and DMARC records that decide whether a domain can send and receive mail. Enter a domain and we pull the MX so incoming mail has a destination, the SPF so you know which servers may send as you, and the DMARC policy that defines what happens when SPF or DKIM fail. We score the result and flag the common faults: a missing MX, two SPF records that cancel each other out, or a DMARC stuck on p=none that protects almost nothing. We read whatever public DNS returns, which is most of it. DKIM stays manual because each provider hides it behind its own selector, so you verify that piece on its own. Run it as a first check before a migration or a large send.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Live mail DNS audit
This health checker reads the MX, SPF and DMARC records that decide whether a domain can send and receive mail. Enter a domain and we pull the MX so incoming mail has a destination, the SPF so you know which servers may send as you, and the DMARC policy that defines what happens when SPF or DKIM fail. We score the result in a few seconds and flag the common faults: a missing MX, two SPF records that cancel out, or a DMARC stuck on p=none. DKIM stays manual because each provider hides it behind its own selector. This is the first check we run before anything heavier.
What this email DNS health check covers
Mail delivery isn't one setting. It's a bunch of DNS records that all have to get along, and honestly I think that's why so many people get it half-right. MX catches your incoming mail. SPF says which servers are allowed to send as you. DKIM signs each message so nobody can quietly tamper with it. DMARC? That's the rulebook for what happens when SPF or DKIM fall over. This checker reads whatever public DNS will hand over. Which is most of it.
How to improve a weak result
- Does this domain actually receive mail? Then point its MX records at the right host. Skip that and there's no inbox for anything to land in.
- One SPF record. Just one. List every service that sends on your behalf inside it, because publishing two SPF records is the classic foot-gun, and it quietly breaks both of them at once.
- Start DMARC in monitoring mode and sit with the reports for a while. Once you trust what you're seeing, tighten it to quarantine, then reject. Jumping straight to reject is how people bounce their own newsletters on day one.
- DKIM lives inside your mail platform, not in this checker. You'll need its selector to confirm it, so go verify that piece on its own.
FAQ
Can this guarantee inbox placement?
Nope. Don't trust anything that claims it can. Clean DNS just gets you a seat at the table. Your sending reputation still matters, what's in the message matters, and whether people open or delete your mail matters too, and any of those can drop you in spam regardless. That said, I've never once watched a domain deliver well while these records were a mess. So clean them first, then go worry about the rest.
Why is DKIM not fully automatic here?
Because DKIM hides behind a selector, and every provider invents its own. Google picks one name. Your transactional service picks something else entirely. There's no clean way to guess it from the domain without firing off a hundred blind lookups, which I'd rather not do. So once you've dug yours up, pop it into the DKIM lookup tool and check it over there.
Frequently asked questions
Can this guarantee inbox placement?
Nope. Don't trust anything that claims it can. Clean DNS just gets you a seat at the table. Your sending reputation still matters, what's in the message matters, and whether people open or delete your mail matters too, and any of those can drop you in spam regardless. That said, I've never once watched a domain deliver well while these records were a mess. So clean them first, then go worry about the rest.
Why is DKIM not fully automatic here?
Because DKIM hides behind a selector, and every provider invents its own. Google picks one name. Your transactional service picks something else entirely. There's no clean way to guess it from the domain without firing off a hundred blind lookups, which I'd rather not do. So once you've dug yours up, pop it into the DKIM lookup tool and check it over there.
What does a low health score actually point to?
It points at whichever record is missing or doubled up. No MX means there is no inbox for mail to land in. Two SPF records quietly break each other. A DMARC stuck in monitoring earns less than one set to quarantine or reject. The score is just a quick read on which of those four pieces needs your attention first.
Why publish only one SPF record?
Because two SPF records is the classic foot-gun, and it breaks both of them at once. The fix is to keep a single SPF record and list every service that sends on your behalf inside that one string. Receiving servers treat a domain with more than one SPF record as a permanent error, so the policy you worked on stops counting.