A domain's MX records reveal which email provider handles its mail — but the hosting provider, the geographic routing, and the redundancy architecture embedded in those records reveal far more about an organisation's email infrastructure than most people realise when they perform a simple lookup
The previous articles on this site covered MX basics, diagnosing email delivery failures, the correct migration sequence, MX priority and failover mechanics, catch-all configuration limitations, and MX records as public security reconnaissance. This article addresses MX record architecture decisions — specifically how large organisations structure their MX records for resilience, how multi-region email delivery works, and the specific MX configurations that signal different email infrastructure approaches.
Reading MX records to identify email providers and architectures
MX hostnames follow recognisable patterns that immediately identify the underlying email infrastructure:
Google Workspace:
10 aspmx.l.google.com
20 alt1.aspmx.l.google.com
30 alt2.aspmx.l.google.com
40 alt3.aspmx.l.google.com
50 alt4.aspmx.l.google.com
Five MX records at different priorities provide redundancy within Google's infrastructure. All resolve to Google's servers globally distributed.
Microsoft 365:
0 company-com.mail.protection.outlook.com
Single MX record. Microsoft 365 uses a single hostname per tenant but resolves to multiple IPs globally — the redundancy is inside the single hostname, not expressed across multiple MX records.
Proofpoint (email security gateway) in front of Microsoft 365:
10 mail1.company.com (resolves to Proofpoint IP)
20 mail2.company.com (resolves to Proofpoint IP)
When a security gateway (Proofpoint, Mimecast, Barracuda) sits in front of the inbox provider, the MX records point to the gateway's servers, not to Microsoft/Google directly. The inbox provider is invisible in DNS. This pattern is common in enterprise email security configurations.
Why MX redundancy doesn't work the way most people expect
MX priority numbers suggest a failover hierarchy — priority 10 is tried first, then 20, then 30. This leads many administrators to believe their email is highly redundant. The reality is more nuanced:
What actually happens with priority: sending mail servers follow a strict algorithm:
- Look up all MX records for the domain
- Group by priority
- Try all records at the lowest priority number first (randomly within the group)
- Only fall to the next priority group if all servers in the lower-numbered group are unreachable
The "multiple MX records, one provider" problem: if all your MX records point to servers in the same provider's infrastructure (as is the case for Google Workspace with its five records), a Google-wide outage affects all of them simultaneously. The multiple records provide load balancing and individual server fault tolerance within Google's infrastructure — they don't provide protection against a provider-level outage.
True MX redundancy requires different providers: some organisations configure MX records pointing to a primary inbox provider (priority 10) and a secondary backup provider (priority 50) that queues and retries delivery if the primary is down. This is rare in practice because modern inbox providers (Google, Microsoft) have near-100% uptime, and maintaining a secondary mail flow adds operational complexity.
SMTP delivery queuing: what happens when MX is temporarily unavailable
When a sending mail server cannot reach the MX servers (all MX records unreachable), it doesn't immediately bounce the message. SMTP has a built-in retry mechanism:
Standard SMTP retry behaviour:
- Immediate retry failure → queue the message
- Retry at increasing intervals (typically: 5 min, 10 min, 30 min, 1 hr, 2 hr, 4 hr, 8 hr...)
- Maximum queue time: typically 1-5 days (configurable by the sending mail server)
- After queue expiry: send a non-delivery report (bounce) to the original sender
The practical implication: a temporary MX outage (a few hours) typically causes no lost email — messages are queued and delivered when the MX becomes available. A prolonged outage (longer than the sending server's queue timeout) results in bounced messages.
The queue timeout varies by provider: Gmail's sending servers queue for approximately 5 days. Most corporate mail servers queue for 4-7 days. Some high-volume sending services queue for shorter periods (1-2 days) to prevent queue build-up.
Subdomains and MX records: common patterns
Subdomains can have their own MX records independently from the main domain, enabling different email routing for different parts of an organisation:
@company.com → Microsoft 365 (main corporate email) @sales.company.com → Salesforce email routing @bounces.company.com → Return-path subdomain for bounce processing @mail.company.com → Transactional email sending infrastructure
The security relevance: subdomains without explicit MX records fall back to the parent domain's MX — or, if no parent MX exists and the subdomain doesn't have its own MX, email to that subdomain is undeliverable. Attackers who send phishing from subdomains may or may not be blocked by the parent domain's DMARC policy, depending on whether the DMARC record has sp= (subdomain policy) specified.
MX records and SPF authorisation consistency
SPF uses the mx mechanism to authorise the MX servers as sending IPs: v=spf1 mx -all means "the servers that receive my mail are also authorised to send my mail."
The consistency requirement: when you use mx in SPF, every MX record's resolved IP is added to the SPF authorised senders. Adding a new MX server automatically adds it to SPF. Removing an MX server automatically removes its IP from SPF authorisation.
The problem when MX and SPF diverge: if you have a security gateway as your MX but use include:_spf.google.com in SPF (authorising Google's sending IPs), there's a mismatch — your SPF authorises Google's IPs, but mail is received via Proofpoint's IPs. When your Google Workspace users send email, SPF passes (Google is authorised). But if someone attempts to verify your MX against your SPF authorisation, they don't align.
How to use the MX Lookup on sadiqbd.com
- Provider identification: look up your own domain's MX records to verify they point to the expected provider — an unexpected MX hostname may indicate a misconfigured migration or unauthorized change
- Security gateway detection: if MX hostnames don't match your inbox provider's known pattern, a security gateway is likely in front — look up the MX hostname's A records to identify which gateway vendor
- Pre-migration verification: before migrating email providers, document current MX records and TTLs — the TTL determines how long to allow for propagation after switching
Frequently Asked Questions
If I have MX records for my domain, does that mean email is working? MX records confirm that a mail server has been configured to receive email for your domain — not that email is actually being delivered and received successfully. A valid MX record with an unreachable server produces queuing followed by bounces. A valid MX record at a mail server with a full mailbox produces specific SMTP error codes (452 or 550). A valid MX record at a mail server that accepts email but routes it to /dev/null produces successful delivery from the sender's perspective but no inbox delivery. To verify email is actually working end-to-end, send a test message and verify receipt — MX records are a necessary but not sufficient condition for functional email delivery.
Is the MX Lookup free? Yes — completely free, no sign-up required.
Try the MX Lookup free at sadiqbd.com — check any domain's mail server records, priority values, and hosting provider instantly.
