Email DNS Health Checker
Drop in a domain and read its MX, SPF and DMARC records, then score whether the domain is wired to send and receive mail or quietly broken.
This email DNS health checker reads the records that decide whether your mail lands or rots in spam. Drop in a domain and it pulls the MX so you know incoming mail has somewhere to go, the SPF so you know which servers are allowed to send as you, and the DMARC policy that says what happens when SPF or DKIM fall over. Then it scores the result and flags the usual breakage: no MX, two SPF records quietly cancelling each other out, or a DMARC stuck in monitoring that earns almost nothing. It reads whatever public DNS will hand over, which is most of it. DKIM stays manual because every provider hides it behind its own selector, so that one piece you verify on its own.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Live mail DNS audit
"Our emails keep landing in spam." I hear that constantly, and it always ends with me poking at the same DNS records by hand. Got old fast. So now I just drop a domain in here. It pulls the MX, the SPF, the DMARC, then tells you whether the domain is actually wired to send and receive mail or whether something's quietly broken. Thirty seconds. That's the check I run before I waste time on anything fancier.
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.