Sending email used to be simple: hit send, trust it lands. That stopped being true once spam and phishing pushed Gmail, Outlook, and Yahoo toward aggressive, machine-learning filters. Now the mailbox provider inspects how your domain is authenticated before it decides where your message goes. Get the DNS wrong and your legitimate mail gets quarantined or bounced right alongside the junk.
The Email Health Check exists to catch those problems before your recipients do. You type in a domain, and it reports on every record that decides whether your mail reaches the inbox.
What the tool actually checks
Historically, auditing a domain meant hopping between tools: look up MX records in one place, paste SPF into a syntax validator, query DKIM keys somewhere else, then eyeball DMARC alignment and transport security by hand. It was tedious, and it was easy to miss something.
The Email Health Check runs all of that at once. Give it a domain and it evaluates the MX, SPF, DMARC, MTA-STS, and TLS-RPT records together, then hands back a single report showing what is configured, what is missing, and where the syntax is broken.
The five records that matter
MX: where your mail is delivered
MX records are the foundation of receiving email. They tell the rest of the internet which servers accept mail for your domain. The check confirms the records exist, point to hostnames that actually resolve, and carry sensible priority values so that if your primary server goes down, a secondary one picks up the traffic. It flags the common failure modes: no redundancy, a server that won't respond, or one sitting on a blacklist.
SPF: who is allowed to send
SPF is your first defense against spoofing. It's a TXT record listing the IP addresses and third-party services (Mailchimp, Salesforce, Zendesk, and the like) that are permitted to send on your behalf. The tool parses the syntax, spells out in plain language who you've authorized, and watches for the SPF 10-lookup limit. That limit trips people up constantly: exceed ten DNS lookups and your SPF returns permerror, which can quietly break delivery for mail that should have passed.
DMARC: what happens when authentication fails
DMARC ties SPF and DKIM together and lets you tell receivers what to do with messages that fail both. You publish a policy:
| Policy | Effect |
|---|---|
p=none |
Monitor only, deliver as normal |
p=quarantine |
Send failing mail to spam |
p=reject |
Refuse failing mail outright |
The check reads your DMARC record, confirms it's valid, and points you toward tightening the policy. Most domains should aim to reach p=reject eventually, but you get there in stages: start at p=none, read the reports, fix what's failing, then move up. Jumping straight to reject before your legitimate senders pass authentication is how you block your own invoices.
MTA-STS: forcing encryption in transit
For years, email encryption over STARTTLS was opportunistic. If a secure connection couldn't be negotiated, servers silently fell back to plaintext, and anyone in the middle could read the message. MTA-STS closes that gap by telling sending servers to connect to you only over verified TLS. The tool checks both halves of it: the DNS record and the policy file that has to be hosted on a web server at your domain.
TLS-RPT: knowing when encryption breaks
Strict encryption has a downside. If a certificate expires or a TLS negotiation fails unexpectedly, mail can bounce with no warning to you. TLS-RPT is the feedback channel. When a receiver can't deliver to you because of a TLS problem, it sends a diagnostic report to the address in your TLS-RPT record. The check confirms the record is present and well-formed so those reports actually reach you.
Why a bad configuration costs you
When email health slips, the messages that suffer are the ones you can least afford to lose: password resets, order confirmations, invoices, support replies. They land in spam, and you find out from an annoyed customer rather than a dashboard.
The security side is worse. Without enforced SPF and DMARC, nothing stops someone from forging mail that appears to come from your domain. Attackers use that to phish your customers and staff, and every spoofed campaign drags your domain's reputation down, which makes even your genuine mail harder to deliver. The Email Health Check is a diagnostic you run to find those gaps before an attacker finds them for you.
Reading the results and acting on them
The report interprets, it doesn't just dump records at you. A missing DMARC record shows up as a critical issue, not a footnote. Redundant or recursive SPF includes that break RFC limits get called out specifically so you know what to remove.
Treat it as part of your change routine. Any time you onboard a new marketing platform, migrate mail providers, or stand up a new sending server, run the domain through the check afterward. It's the fastest way to confirm that the change didn't silently break authentication.
If a scan turns up problems, two companion tools help you fix them: the SPF Generator builds a valid record from your list of senders, and the DMARC Generator walks you through a policy. And if your domain has already taken a reputation hit, the Blacklist Lookup tells you which lists you're on.
In short
MX routing, SPF authorization, DMARC enforcement, and TLS in transit are separate records, but they only work as a set. Checking them together gives you the honest picture: whether your domain is protected, and whether your mail is getting through. Run it now, and run it again the next time anything about your sending setup changes.