An MX record tells you which server handles inbound email for a domain — but a single domain can have multiple MX records pointing to entirely different mail servers, and the priority numbers on those records determine a routing protocol that most email senders follow without knowing it exists
The previous articles on this site covered MX lookup basics, diagnosing email delivery failures, the correct MX migration sequence, and how mail server priority determines failover. This article addresses MX record security — specifically how attackers exploit MX records, what dangling MX records expose, and why MX record monitoring should be part of any domain security posture.
How attackers use MX lookup for reconnaissance
MX records are publicly queryable — anyone can look them up for any domain. This makes them a reconnaissance resource for attackers targeting email infrastructure.
What an attacker learns from MX records:
- Which email provider hosts the target (Google Workspace, Microsoft 365, Proofpoint, Mimecast — all have characteristic MX hostnames)
- Whether a custom mail gateway is in use (security filters like Proofpoint and Mimecast appear as the MX record, with the actual inbox provider invisible)
- Whether backup MX servers are configured — and how well-protected they are
The backup MX vulnerability: when a domain has a primary MX and a backup MX, spam filters on both must be equivalent. A common attack targets the backup MX directly — if the primary MX has strong filtering (a cloud security gateway) but the backup MX is a more permissive legacy server, attackers can route spam directly to the backup, bypassing the primary's filters. This was a widely-exploited pattern before security gateways began applying consistent policy at all MX hosts.
Dangling MX records: the forgotten server problem
A "dangling" MX record points to a hostname that no longer exists or is no longer controlled by the domain owner. This can happen when:
- A company switches email providers but forgets to update MX records (the old provider's server is still listed)
- A subdomain's mail server is decommissioned but the DNS record remains
- An email service contract is cancelled but the MX record pointing to that provider persists
The security risk: if the MX hostname itself is no longer registered or resolves to a decommissioned server, an attacker who registers the same hostname (or takes over the server) can receive email destined for the domain. This is a subdomain takeover vulnerability — but specifically targeted at email interception rather than web traffic hijacking.
Practical example: a company uses mail.oldprovider.com as their MX. They switch providers, update A records and SPF, but leave the MX record unchanged. If oldprovider.com is later abandoned, its subdomains become available. An attacker who provisions mail.oldprovider.com could receive email directed at the target domain.
MX records and DMARC: the "parked domain" security case
Non-sending domains — domains owned by a company but never used for email (brand protection registrations, legacy domains, subsidiary domains) still appear in email systems as potential spoofing targets. Attackers can spoof @legacydomain.example even if that domain never sends email.
The complete defense for parked domains requires:
- An MX record of
0 .(the null MX — RFC 7505, signaling "this domain accepts no mail") - SPF:
v=spf1 -all(reject all senders — no IP is authorized) - DMARC:
v=DMARC1; p=reject;(reject all that fail alignment — which everything will)
The null MX (0 .) specifically signals to sending servers that the domain accepts no inbound email — different from having no MX record at all. No MX may cause some senders to attempt SMTP delivery to the domain itself (as a legacy fallback); null MX explicitly prohibits this.
MX record TTL and its operational implications
TTL (Time to Live) on MX records controls how long DNS resolvers cache the record before re-querying. This directly affects email delivery during migrations:
High TTL (86400 — 24 hours): resolvers worldwide cache the current MX for up to 24 hours. If you change the MX, some senders will continue routing to the old server for up to 24 hours.
Low TTL (300 — 5 minutes): resolvers re-query frequently; the new MX propagates quickly after a change.
Best practice before an MX migration: lower the TTL to 300 (5 minutes) 24-48 hours before the planned change. This ensures that after the change, the new MX propagates within minutes rather than hours. After the migration is confirmed stable, raise the TTL back to a longer value.
During the migration transition period (when some senders still have the old MX cached), mail delivery to both the old and new servers may occur simultaneously — which is why the email migration sequence article recommends keeping the old server running and receiving during the transition.
SPF and MX record interaction
SPF records often reference MX records via the mx mechanism: v=spf1 mx -all. This shorthand says "the IP addresses that my MX records resolve to are authorized senders."
The maintenance trap: using mx in SPF means that when you change your MX records, SPF automatically updates. But it also means that if you add a backup MX or a low-priority MX that's a less-secure server, that server is now automatically authorized to send on your behalf — which may not be intended.
More explicit SPF (v=spf1 include:_spf.google.com -all rather than mx) is more deliberate — you're specifying exactly which sending infrastructure is authorized, and MX changes don't automatically affect SPF authorization.
How to use the MX Lookup on sadiqbd.com
- For security auditing: look up MX records for all domains in your portfolio, not just the primary — parked and subsidiary domains with inadequate MX security (no null MX, no DMARC) are spoofing targets
- Verify the MX hostname resolves: confirm that the MX hostname itself resolves to an IP — a dangling MX that doesn't resolve is a security risk requiring immediate cleanup
- Pre-migration TTL check: before an email provider migration, check the current TTL on your MX records; if it's 86400, reduce to 300 at least 24 hours before the planned change
Frequently Asked Questions
Can I see who is sending email to my domain by looking at MX records? No — MX records show where inbound email is directed, not who is currently sending you mail. To see incoming mail sender patterns, you'd need access to your mail server's logs or message trace tools in your email admin panel (Google Workspace Admin Console, Microsoft 365 Exchange Admin Center). MX records are pure routing infrastructure — they tell senders "deliver here" but don't record or expose what's been delivered.
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 and priority values instantly.
