Catch Broken Email DNS Before Your Client Hears “Your Messages Are Bouncing”

A potential customer emails your client's sales address. Seconds later the message comes back: address not found, mailbox unavailable, or domain could not be reached.

That customer sees the failure first. They tell your client. Your client calls you. By then nobody knows how many enquiries were lost, and a small DNS problem has become an embarrassing business problem.

Exchange can be healthy. The mail server can be running. Every internal dashboard can be green. If the public MX, SPF, DKIM or DMARC records are missing or wrong, customers still see the failure.

A homepage uptime check will never catch it. Web and email share a domain name and almost nothing else. The website depends on an A, AAAA or CNAME record. Email depends on four different DNS records that an ordinary website check never reads.

Staying out of a client's mail platform does not mean staying blind. An MSP, agency or developer can watch these four public records from the outside and warn the client before the client's customers become the monitoring system.

Here are the four, how each one usually gets broken, and how to check it from a terminal.

MX: where your mail is delivered

dig example.com MX +short
10 mail1.example.net.
20 mail2.example.net.

MX records tell every other mail server where to deliver mail for your domain. They break during migrations. Someone moves the domain to a new DNS provider and the zone import drops a record, or keeps an MX for a mailbox provider you left two years ago. They also break when a domain changes hands inside a company and the new owner rebuilds the zone from memory.

A wrong MX does not bounce mail straight away. If the listed host is gone, senders keep retrying for days before they give up. If it still accepts mail for your domain, the mail is delivered, into a mailbox nobody reads.

MX record monitoring is the easiest kind to justify, because the record almost never changes and when it does the meaning is obvious. If you want to see what a domain publishes right now, this MX lookup asks the domain's own nameservers instead of a cache.

SPF: who may send as you

dig example.com TXT +short | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net -all"

SPF is a TXT record at the apex of the domain, which is its weakness. The apex collects TXT records from every service that ever asked you to verify ownership. A year later somebody cleans up the junk, and the SPF line looks like junk too.

The other common break is a second SPF record. A new tool's setup guide says to add v=spf1 include:newtool.com ~all, and someone adds it as a new record instead of merging it into the existing one. Two SPF records is a permanent error, and receivers treat it as no SPF at all.

Either way your mail still sends. It just starts failing authentication at the other end, and you hear about it from a customer weeks later.

DKIM: the key that signs your mail

dig selector1._domainkey.example.com TXT +short
dig selector1._domainkey.example.com CNAME +short

DKIM public keys live under selector names that mean nothing to a person reading the zone. s1._domainkey, k2._domainkey, mte1._domainkey. They look like leftovers, and they get deleted as leftovers. Your provider keeps signing with the private key, receivers can no longer find the public one, and every signature fails.

You need the selector name to query it, and most people don't remember theirs. Send yourself an email and look for s= in the DKIM-Signature header, or run a DNS record scanner that tries the common selector names against your domain.

DMARC: what receivers do when the checks fail

dig _dmarc.example.com TXT +short
"v=DMARC1; p=reject; rua=mailto:[e-mail]"

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both. The usual accident here is a debugging session. Deliverability is bad, someone sets p=none to rule DMARC out, the real cause turns out to be something else, and the policy never goes back to reject. Nothing breaks. You have just quietly stopped telling the world to refuse forged mail from your domain, and no test you own will ever notice.

The other one to watch is the rua address. If it changes to an address you don't recognise, your aggregate reports, which list every IP sending as you, are going to someone else.

What to do about it

All four are plain DNS records, so the dig commands above are most of a monitor already. Run them on a schedule, compare with the values you expect, and send yourself the old and new value when they differ. I went through the ways that comparison produces false alarms in an earlier post. For email records the two that matter are to query the authoritative nameservers, and to join split TXT strings before comparing. SPF and DKIM values are long enough to be split into several strings, and servers don't always split them the same way twice.

This is also what I built DNS Notify to do. Its email DNS monitoring watches the MX set, the SPF and DMARC records and whichever DKIM selectors you pick, and the alert is the record name with the accepted value and the current value next to each other. It doesn't validate SPF syntax or read DMARC reports. There are good tools for both and it isn't trying to be them. It tells you a record changed, within minutes, while you can still remember who was in the DNS panel that day.

Whichever way you do it, write down the four values today. The hardest part of fixing a broken SPF record is working out what it used to say.