Email domain health monitoring: what to check and when

Your email domain is mostly a handful of DNS records. They were correct the day you published them, and then people changed hosting, added a sending tool, rotated a key or cleaned up "unused" TXT entries. Nothing announces the damage. Mail keeps flowing for a while, then bounces and spam placement creep up and nobody can say when it started. This guide explains what email domain health means, which records it covers, what breaks without a sound, and how a one-off check differs from monitoring that runs every day.

The short answer#

Email domain health is the question "are the DNS records that let the world deliver to and trust mail from this domain present, valid and unchanged?" In practice that means six things: MX (can anyone deliver to you), SPF (which servers may send as you), DKIM (is your signing key published), DMARC (what should receivers do when checks fail), plus MTA-STS and BIMI, which are optional extras. A one-off check tells you the state right now. Monitoring repeats the check on a schedule and tells you when something changes, which matters because most failures are regressions, not setup mistakes. Run the free domain health check today to get a baseline, then decide whether a daily watch is worth it for the domains you depend on.

What a domain health check covers#

Every record in the table answers a different question, and each can fail on its own.

The first four are the ones that decide whether your mail is delivered and trusted. Setting up DMARC and the overview of SPF, DKIM and DMARC together cover how to write them. MTA-STS and TLS-RPT and BIMI are optional hardening, so a missing one is information, not an emergency.

Remember that mailbox providers now ask for this. The Google and Yahoo sender requirements expect SPF, DKIM and a DMARC record for bulk senders, with the From domain aligned to SPF or DKIM, and Microsoft applies similar rules to high-volume senders to Outlook.com addresses. A record that quietly disappears can move you from compliant to non-compliant overnight.

What breaks without anyone noticing#

Authentication failures rarely look like failures. Mail is still accepted, some of it lands in spam, and the cause is a record nobody has looked at in months. These are the ones that show up again and again.

• A DNS migration drops TXT records. You move DNS hosts, the import tool copies A and CNAME records, and SPF, DKIM and DMARC TXT entries go missing or get mangled. The full story is in when SPF, DKIM and DMARC stop working.
• A second SPF record appears. A marketing tool tells someone to "add this TXT record", and now the domain has two SPF records. Receivers treat that as a permanent error, so SPF fails for everything.
• SPF grows past 10 DNS lookups. Every new tool adds an include:, and one day the record crosses the limit. SPF too many DNS lookups explains the counting and the fix.
• A DKIM key is rotated or removed. The provider moves to a new selector, or someone deletes the old key while mail is still signed with it. Finding your DKIM selector covers how to know which key a sender actually uses.
• DMARC is deleted or never gets reports. Either the record is gone, or rua= points nowhere useful, so you cannot see who is sending as you.
• A short DKIM key lingers. A 1024-bit key still works, which is exactly why it stays for years. The standard says signers should use at least 2048.

None of these needs an attacker. They are ordinary maintenance, which is why a periodic human review misses them: nothing looks broken until the numbers move.

One-off check or daily monitoring#

A one-off check is the right tool in three situations: after you publish or change records, when you are diagnosing a specific complaint, and when you take over a domain you did not set up. It is free, it takes seconds and it gives you a snapshot. Run the domain health check for the whole picture, or the SPF, DKIM and DMARC checker when you only need the authentication records.

Monitoring answers a different question: what changed since yesterday, and who needs to know? The failures above all happen between checks. The gap that matters is the time from "record broke" to "someone noticed", and with a manual process that gap is however long it takes for bounce rates to prompt an investigation. Daily checking turns it into a day at most.

A fair way to decide:

1. One domain, rarely changed, one sending tool: a one-off check after every change is probably enough.
2. Several domains, several senders, or more than one person with DNS access: a daily watch earns its cost the first time someone edits a record without telling you.
3. Parked or secondary domains you never send from: check them occasionally, because a missing or loose DMARC record there is an invitation to spoofing.

What to alert on#

An alert is only useful if it is rare and specific. The records worth waking someone for are the ones where a change means mail is failing now. As a rule of thumb, we would separate them like this.

Act the same day:

• MX missing or an MX host that no longer resolves.
• SPF missing, SPF published twice, a syntax error, or lookups over 10.
• DMARC missing or invalid, including two DMARC records.
• A DKIM selector you rely on that no longer returns a key (the product can only report this for selectors you have told it about).

Review this week:

• SPF at 9 or 10 lookups, one addition away from failing.
• DMARC still at p=none, or no rua= address to receive reports.
• A 1024-bit DKIM key, or a key still flagged as testing (t=y).
• A ?all qualifier, or the discouraged ptr mechanism in SPF.

Informational:

• MTA-STS and BIMI records appearing or disappearing.

Qualisend's Domain Health Monitoring maps these onto two severities: 20 issue codes across MX, SPF, DKIM and DMARC, each marked "bad" or "warn", and a grade for the domain that is simply the worst severity present. Everything in the first list is "bad" and everything in the second is "warn". It emails you when an issue appears and when it clears. DNS errors such as timeouts mark the check as "could not check" and never alert, so resolver trouble does not become a false alarm. An issue clears after the second clean check, so the all-clear can lag by up to two days unless you re-check by hand.

A baseline and a routine#

You do not need a platform to get most of the value. Do this once per domain.

1. Write down your senders. List every system that sends as the domain: mailbox provider, marketing platform, transactional service, CRM, helpdesk, invoicing. Each one should be reflected in SPF and signed with DKIM.
2. Run a baseline check and save the result. Note the SPF lookup count, the DKIM selectors that exist, and your DMARC policy.
3. Record the DKIM selectors each sender uses. Selector names are easy to forget and hard to guess later. How to find a DKIM selector shows where to read them.
4. Publish a reporting address in DMARC so that failures leave a trail. Reading the reports and DMARC monitoring cover what to do with them.
5. Re-check after every DNS change and after adding or removing any sending tool, then once a month regardless.

If a domain matters to revenue, that last step is the one people stop doing, and it is the one monitoring replaces.

What monitoring cannot see#

Be clear about the limits so you do not trust it for the wrong thing.

• It reads public DNS. It does not send test mail, watch your actual outgoing messages or measure inbox placement. An SPF record can be perfectly valid and still miss a sender you forgot to add. To see how a real message authenticates and what a receiving server sees, use the email deliverability test. It does not measure inbox placement either.
• DMARC is parsed; MTA-STS and BIMI are checked only for presence. It does not fetch an MTA-STS policy file or validate a BIMI logo or certificate.
• It watches domains, not sending IPs, and it never changes your DNS. You fix issues at your own DNS host.
• Daily means daily. A change is detected within 24 hours, not in real time.
• It does not tell you who is sending as your domain. That is what DMARC aggregate reports are for, and DMARC Reports is the separate product built around them.

Pricing is flat per tier at standard rates: $8.99 a month for one domain, $89 for up to 10 and $499 for up to 60, with no credits involved and no requirement to buy anything else.

One more thing to keep in mind: standards move. DMARC was defined in RFC 7489, which RFC 9989 obsoleted in May 2026, so check the current text if you depend on edge-case behaviour.

Healthy DNS gets your mail trusted, but it does not clean the list behind it. The free plan on the pricing page includes 100 credits that run the full verification on a list, because a well-monitored domain still needs a healthy list to earn the inbox.