Email deliverability monitoring: catch broken records before campaigns die

A one-time SPF, DKIM, and DMARC check is not enough. The records that made your domain inbox-ready in January will not still be inbox-ready in March. DKIM keys rotate. ESPs change their include chains. DMARC policies get tightened by a well-meaning IT admin. A single broken record can quietly push every outbound email into the spam folder for weeks, and the first sign is usually a client or prospect saying "your emails stopped landing."

Deliverability monitoring is the practice of re-checking those records on a schedule and alerting the moment one breaks. This guide covers what to monitor, how often, and what to do when an alert fires.

1. What actually breaks

Most deliverability incidents trace back to one of five things:

• SPF include lost. The domain switches ESPs or adds a second sending tool, and the old include is removed without adding the new one. SPF now fails for the new sender.
• DKIM key rotation. The ESP rotates its DKIM key. The old key stops signing. If the new selector is not published in DNS, every message fails DKIM.
• DMARC policy tightened. An admin moves from p=none to p=reject without confirming that all legitimate senders are aligned. Suddenly, mail from a third-party tool that was passing now gets rejected.
• Reverse DNS (PTR) mismatch. The sending IP changes, and the PTR record is not updated to match. Gmail and Microsoft both penalize this.
• Blacklisting. The sending IP or domain lands on a blocklist because of a spike in bounces or a shared-IP neighbor. This is the one that does not show up in DNS records at all.

The first four are DNS problems. A monitoring tool that re-resolves the records daily will catch them within 24 hours. The fifth requires checking blocklists, which is a separate check but belongs in the same daily loop.

2. How often to check

Daily is the floor. Here is the reasoning:

• Daily catches DNS record changes within 24 hours. This is the minimum for any domain that sends more than a few hundred emails a day.
• Every 6 hours is what you want for a domain that is mid-campaign. If a DKIM key rotates at 2am, you want to know before the 9am send, not the next morning.
• Real-time on send is what the ESP itself does. It is not a substitute for monitoring the DNS records, because the ESP only sees what it sends, not what a third-party tool on the same domain is doing.

For most agencies and developers, daily monitoring of every sending domain is the right default. If a domain is about to send a large campaign, bump it to every 6 hours for the duration.

3. What to check on each pass

Each monitoring pass should resolve and validate the same seven checks a one-time audit runs:

1. MX records exist and point to a live mail server.
2. SPF is present, has a valid all mechanism, and stays under the 10-lookup limit.
3. DKIM is published for every selector the ESP actually signs with.
4. DMARC is present, has a valid policy, and the SPF/DKIM alignment matches the From domain.
5. PTR (reverse DNS) matches the sending IP.
6. STARTTLS is available on the MX port 25 connection.
7. Blocklists do not contain the sending IP or domain.

The output of each pass is a score (0 to 100) and a list of failing checks. The score tells you the overall health. The failing checks tell you exactly what to fix. A monitoring tool that gives you both is worth more than one that gives you only a score.

4. What to do when an alert fires

An alert is only useful if it leads to a fix. The workflow:

1. Read the failing check. The alert should name the exact record and the exact problem. "SPF missing include for mailer.example.com" is actionable. "SPF error" is not.
2. Fix the record. For SPF and DKIM, this means updating the DNS TXT record at the domain registrar or DNS provider. For DMARC, it means adjusting the _dmarc TXT record. For PTR, it means asking the hosting provider to update the reverse DNS.
3. Re-check. Run the audit again on the affected domain. Confirm the failing check now passes and the score is back up.
4. Notify the stakeholder. If the domain belongs to a client, send them a short note with the before and after scores. This is the moment that turns a deliverability incident into a reason the client stays.

The whole loop, from alert to fix to confirmation, should take under an hour for a DNS record change. The monitoring tool should make the first step (reading the failing check) instant, so the time goes into the fix, not into diagnosis.

5. The agency use case: many domains, one dashboard

An agency runs cold email for many clients on many domains. Monitoring one domain is a script. Monitoring twenty is a system. The system needs:

• Per-domain scores so you can see which client domains are healthy and which are at risk.
• Alerts so you are not manually re-checking twenty domains every morning.
• Branded reports so the client sees your name on the deliverability report, not a tool's. This is what justifies the retainer.
• A history so you can show the client a trend line: "your domain has been 95+ for six weeks, and here is the one day it dipped and what we fixed."

The deliverability stack for agencies covers the full workflow. This page covers the monitoring layer.

Start with one domain

Run a free check on one of your sending domains right now and see the seven-check score and the exact fixes: cold email deliverability checker. When you are ready to monitor the whole book daily and get alerted the moment a record breaks, that is what the Pro and Agency tiers are for.

Related: Deliverability for developers · What an audit tool checks · How to monitor DMARC reports · Is my domain blacklisted? · What is a good deliverability score?