How to Monitor MX Records and Email Server Health

Email infrastructure is one of the most fragile and least-monitored parts of a typical web service. MX records get changed during a vendor migration and never get checked. SPF records grow until they exceed the 10-lookup limit and silently fail. DKIM keys rotate and the public key in DNS never gets updated. The result is intermittent or complete delivery failure that no application-layer monitoring will catch. This guide covers what to monitor at the DNS and SMTP layers so the breaks surface before the customer notices.

What can go wrong with MX records

An MX record points senders at the mail server that accepts mail for your domain. Wrong MX records mean nothing arrives.

The common failure modes: the MX record was updated during a vendor change but the old record was not removed, producing competing servers. A typo in the MX hostname (mailserver.example.com instead of mailservers.example.com) silently routes everything to a non-existent server. The MX record points at a hostname that does not have an A record. Each of these produces partial or complete delivery failure that an inbox-side test will catch but a DNS-only check will not.

The four DNS records worth monitoring

Four DNS records together cover the configuration side of email health. Monitor all four for every domain you send from.

• MX: the mail servers themselves. Alert if the record changes unexpectedly or if the resolved hostname has no A record.
• SPF (TXT at the root): which servers are authorised to send. Alert on changes and on records that include more than 10 nested DNS lookups (a deliverability killer).
• DKIM (TXT at ._domainkey): the public key that verifies outbound signatures. Alert on changes; missing DKIM means most providers downgrade trust.
• DMARC (TXT at _dmarc): the policy for handling SPF and DKIM failures. Alert on changes and on overly-permissive policies (p=none in production).

SMTP-level checks beyond DNS

DNS-level monitoring catches misconfiguration. SMTP-level monitoring catches a mail server that is configured correctly but is not actually running. Both are needed.

The check: open a TCP connection to the mail server on port 25 or 587. Read the SMTP banner (220 mail.example.com ESMTP). Close the connection cleanly. Run hourly. The check is lightweight and catches the failure where the server has crashed but the DNS still points at it. Add TLS verification on port 587 if you use STARTTLS; most modern mail servers do.

End-to-end delivery monitoring

DNS and SMTP checks tell you the infrastructure is up. End-to-end checks tell you mail is actually being delivered. Two patterns cover the common cases.

• Round-trip test: send a test email from your application to a mailbox you control (a Gmail address, a Mailosaur inbox, an internal address). Verify it arrives within a few minutes.
• External tool: services like GlockApps, MXToolbox Inbox Insight, and Mail-Tester score deliverability across inbox providers. Worth running monthly if email is a significant traffic driver.
• Customer feedback loop: subscribe a dedicated address to your own marketing list. If the test address stops receiving your mail, customers have too.

Catching SPF 10-lookup failures

SPF records that include more than 10 DNS lookups (counting all the includes, redirects, and a/mx mechanisms) are silently rejected by receiving mail servers. The classic failure mode: each new SaaS that you authorise to send on your behalf (Mailchimp, Customer.io, Sendgrid) gets added to your SPF includes. After the eleventh one, deliverability silently drops.

Monitor the SPF lookup count, not just the record content. Tools like dmarcian and Postmark's SPF tester report the count. Alert at 8 to give yourself headroom. Flatten the record (replace include: directives with their resolved IPs) if you are close to the limit. Maintain the flattened version with automation; manual flattening drifts.

A monitoring stack for email infrastructure

The minimum useful setup: an MX monitor on the apex domain, an SPF monitor (TXT record content + lookup count), a DKIM monitor on the selector you actually use, a DMARC monitor on _dmarc, an SMTP banner monitor on the primary mail server on port 587. Add an end-to-end round-trip test once a day to a mailbox you actually check. Total: six monitors. Total coverage: most of the email failure surface. Total monthly cost on a Pro tier: well under what you spend on coffee.