MX Record Lookup: Which System Will Filter Your Message

An MX lookup answers one question well: which mail system will apply filtering rules to your message when it arrives. That answer is worth having before a campaign starts, because it decides which postmaster guidance applies to the domain and where you look first when placement drops. It says nothing about whether the mailbox exists, and teams that read it as a verification signal send to dead addresses with confidence.

What the Two Common Answers Look Like

Reading a lookup takes a few seconds once you know the patterns, and two of them cover most B2B domains.

Google publishes a single value. The Workspace documentation on setting up MX records gives the record as type MX, host left blank or set to @, priority 1, and a value of smtp.google.com. It also notes that organisations using Google Workspace before 2023 may still be running legacy records beginning with aspmx, which continue to work. Either answer identifies the same provider, and the older one tells you the tenant has been in place for years.

Microsoft's pattern carries a per-tenant component. The Microsoft 365 DNS reference gives the target as <MX token>.mail.protection.outlook.com with a "Time To Live (TTL) Value: 3600" and a "Preference/Priority: Lower than any other MX records (this ensures mail is delivered to Exchange Online)." The token differs per customer, so the recognisable part is the suffix.

Run the query directly and read the raw answer:

An answer matching neither pattern usually belongs to a filtering gateway publishing its own hostnames, which means inbound mail is scanned by one company and stored by another. Your message clears two sets of rules on the way in, and the mailbox provider you would have guessed from the company's domain is not the system that made the decision.

The Answer Changes Where You Look, Not What You Send

Provider identity earns its place in your data for one operating reason. When reply rates fall, the first question is whether the drop is spread across the list or concentrated in one receiving system, and you cannot answer that without knowing which system each contact sits behind.

A campaign performing normally at one provider and poorly at another points at reputation or authentication with that provider, which is a domain-level repair. A campaign performing poorly everywhere at once points at the offer, the targeting or the sequence, which is a copy and list repair. Without the MX field, both of those produce the same blended reply-rate line on the dashboard, and the team spends a week rewriting sequences to solve what was a DKIM alignment gap at one provider.

Our view: store the provider as a field on the contact record and segment reporting by it from the first send, not after something goes wrong. Adding the field retroactively during an incident means rerunning lookups against a list whose DNS has since changed, and the numbers you most want are the ones from before the problem started.

Where the Lookup Genuinely Helps Your List

Two uses hold up, and both are narrow.

The first is detecting domains that cannot receive mail at all. A domain with no MX answer is either parked, misconfigured or defunct, and those records should leave the sequence before the first send instead of generating hard bounces. This is a cheap pre-send filter that costs one DNS query per domain.

The second is spotting shared infrastructure. Several contacts at what look like separate companies answering with the same distinctive MX target points at one parent organisation, one managed service provider, or one holding company behind several brands. Treat those domains as a single destination when you set sending pace, because the volume you believe is spread across unrelated companies is arriving at one system.

Run both before verification rather than instead of it, because they cut the record count a paid verifier has to process and verifiers charge per record. Our guides to email list cleaning tools and how to fix a high bounce rate cover the checks that confirm a mailbox accepts mail.

How We Use It

We resolve MX for every domain on a list before the first send, store the provider as a field, and drop domains that return no answer. The field then drives how results are read for the rest of the engagement, because a placement report split by receiving system separates a domain problem from a campaign problem in one glance.

The cost of that choice is honest to state. It adds a step to list preparation and the data goes stale, since a company that migrates providers mid-engagement carries an outdated field until the next refresh. We re-resolve rather than trusting the stored value whenever a segment's numbers move sharply, because a sudden change in one segment is sometimes a migration rather than a reputation event.

We do not use the field to change message content. Writing different copy for recipients on different mail systems optimises for a filter instead of for the person reading, and it makes performance across segments impossible to compare.

Do This Before the Next Campaign

1. Resolve MX for every domain on the list and record the provider as a field on the contact.
2. Remove domains returning no MX answer, since those produce hard bounces with no possible reply.
3. Flag domains whose answer matches neither Google nor Microsoft, because a filtering gateway means an extra set of rules.
4. Look for repeated distinctive MX targets across apparently unrelated companies and treat those as one receiving system for pacing purposes.
5. Run the same query against your own sending domains and confirm each returns exactly one answer pointing at the mailbox you monitor.

Step five takes a minute and catches a failure the other four cannot: a second MX on your own sending domain routes replies to a mailbox nobody monitors, so the campaign reports zero responses while the responses are sitting somewhere unread.

If you want your list preparation, sending domains and reply routing reviewed together before the next campaign goes out, book a free ICP and campaign-fit discovery call →.