Check for Null MX Before a Prospect Domain Enters a Client List

Some domains say, in public DNS, that they do not accept email. Any address at one of those domains is dead on arrival, no matter how real the person behind it is. If your list pull doesn't check for this, the first send finds out for you, and it finds out on your client's sending domain.

The signal is called a null MX. It takes one DNS lookup per domain to catch, so there's no good reason to let one into a live sequence.

What a null MX record is

RFC 7505, a 2015 IETF standards-track document, defines it. A domain that accepts no mail publishes a single MX record with preference 0 and a target of ., which is not a valid host name. In a zone file it looks like this:

example.com.  IN  MX  0 .

You can see one today. When we looked up example.com on October 16, 2026, its only MX answer was 0 .. That domain exists for documentation and accepts no mail.

The RFC is clear about what senders should do with it. A null MX "will cause all mail delivery attempts to a domain to fail immediately." Servers that reject a recipient for this reason should use reply code 556 and enhanced status code 5.1.10, "Recipient address has null MX." In other words, it's a permanent failure, not a soft one you retry.

Why this shows up in agency lists

Contact data ages. Enrichment tools and scraped lists carry addresses from domains that used to receive mail and have since been retired. A few common ways that happens in B2B:

• A company rebrands or gets acquired and keeps the old domain only for web redirects.
• A brand runs a marketing domain that never handled mail at all.
• A domain is parked, and the owner published a null MX to stop stray delivery attempts.

The person's name, title, and LinkedIn profile can all be accurate while the email address is unreachable. That's what makes this easy to miss in a manual review. The record looks fine. The domain doesn't take mail.

How it differs from "no MX at all"

The two cases are easy to mix up, and they behave differently.

If a domain publishes no MX records, SMTP falls back to an older rule. RFC 5321 section 5.1 says that "if an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR" pointing at the domain's own address records. Mail may still get delivered to whatever server answers there. Or it may sit in a retry queue. RFC 7505 notes that when no SMTP listener answers, delivery is "attempted repeatedly for a long period, typically a week."

If the domain itself does not exist at all, RFC 5321 says that "MUST be reported as an error."

So there are really three outcomes for a prospect domain:

1. MX records point at real mail hosts. Proceed to address-level checks.
2. A null MX (0 .). The domain has said it takes no mail. Drop every address at that domain.
3. No MX and no domain (NXDOMAIN). Also dead. Drop it.

A domain with no MX but a live A record is a gray area. Treat it as high risk and hold it for review rather than letting it auto-enter a sequence.

The check, step by step

Here's the version we'd run per client workspace, at the point a list is imported, before any address can join a campaign.

1. Group the import by domain. A 2,000-row list might only contain 600 domains. Check each domain once.
2. Look up MX for each domain. Any resolver works. A DNS-over-HTTPS query such as https://dns.google/resolve?name=example.com&type=MX returns JSON you can parse in a script.
3. Classify the result. Real MX hosts, null MX, no MX with an A record, or NXDOMAIN. Store the class and the lookup time against the domain.
4. Block null MX and NXDOMAIN at entry. Those addresses should never reach the send step. Mark them with a reason code so the client can see why a contact was held.
5. Re-check before each new campaign. Domains change. A list that passed in August can contain a domain that was retired in October. Keep the lookup time and refresh anything older than your campaign cycle.
6. Watch bounces for 5.1.10. If a send does go out and comes back with that enhanced status code, add the whole domain to the blocked list, not just the one address.

None of this needs a vendor. It's a DNS query and a lookup table. Address-level verification is a separate step, and you still need it, because a domain with healthy MX records can still have dead mailboxes on it.

Why it matters for the client's reputation

Mailbox providers are explicit that invalid addresses hurt the sender. Yahoo's sender best practices tell senders to "monitor hard and soft bounces" and "remove invalid recipients from your list promptly," because sending to people who don't receive the mail "will harm your delivery metrics and reputation."

For an agency, the sender is the client. A batch of guaranteed hard bounces lands on the client's domain, in the client's bounce rate, during the weeks when that domain is still building a history. The prospect who used to work at a now-retired domain was never going to reply anyway. All that send does is cost the client's domain.

There's also a quieter cost. RFC 7505 asks domains that send mail not to publish null MX on those domains, so a null MX also tells you the domain isn't the one that person uses for live email anymore. If the contact matters, that's a prompt to find their current company and address, not to guess.

One check for your own domains too

The RFC cuts the other way as well. It says mail systems "SHOULD NOT publish a null MX record for domains that they use" in the envelope sender or the From address, and that doing so "risks having its mail rejected." Some receivers reject mail from a domain that cannot receive replies, and RFC 7505 even assigns a code for it, 5.7.27, "Sender address has null MX."

That matters when a client sets up a secondary sending domain and their IT team treats it as a "send only" domain. Ask that the domain have working MX records that route replies into a mailbox someone reads. A cold email domain that can't receive a reply defeats the purpose of sending from it.

Where GTM fits

GTM runs each client in an isolated workspace with campaign entry rules, a shared reply inbox, and suppression that survives data purges. Every field keeps its source, and nothing sends without a compliance verdict and an unsubscribe URL. A domain-level "accepts no mail" flag is the kind of entry rule that belongs at the front of that flow, inside the client it applies to.

If you run outbound for several clients and want list checks enforced per client before anything sends, join the waitlist.

Sources

• RFC 7505, "A 'Null MX' No Service Resource Record for Domains That Accept No Mail": https://www.rfc-editor.org/rfc/rfc7505.html
• RFC 5321, "Simple Mail Transfer Protocol," section 5.1: https://www.rfc-editor.org/rfc/rfc5321.txt
• Yahoo Sender Hub, "Sender Best Practices": https://senders.yahooinc.com/best-practices/
• Google Public DNS JSON API, MX lookup for example.com (checked October 16, 2026): https://dns.google/resolve?name=example.com&type=MX