MX records are the DNS entries that tell the internet where to deliver email for a domain. They are the first thing a sending server looks up when delivering mail, and the foundation on which the rest of the authentication stack relies. This article explains MX records in detail, how routing decisions work, priority behaviour, common UK configurations, and the subtle failure modes that affect deliverability.
An MX (Mail Exchanger) record is a DNS entry that specifies which server accepts email for a domain. When a sending mail server wants to deliver mail to [email protected], it queries DNS for the MX records of firm.co.uk and connects to the indicated server on port 25.
Without MX records, email delivery to a domain is impossible. MX is the single most critical DNS record for receiving mail.
An MX record contains two fields: a priority (or preference) number and a hostname.
firm.co.uk. IN MX 10 mail.firm.co.uk.Fields:
Multiple MX records for the same domain provide failover:
firm.co.uk. IN MX 10 mail1.firm.co.uk.
firm.co.uk. IN MX 20 mail2.firm.co.uk.
firm.co.uk. IN MX 30 backup-mail.provider.com.Sending servers sort MX records by priority ascending. They try the lowest-priority MX first; if connection fails (timeout, refused, 5xx), they try the next highest. This continues until delivery succeeds or all MXes are exhausted.
MX records with the same priority are randomised — load balancing across equal-weight servers. For example:
firm.co.uk. IN MX 10 mail1.firm.co.uk.
firm.co.uk. IN MX 10 mail2.firm.co.uk.Senders randomly pick one; if that fails, the other. Distributes load.
Common patterns:
The specific numbers do not matter semantically — only their relative ordering. Many UK businesses use 10 for their primary and 20 for backup.
When a sender delivers to [email protected]:
firm.co.uk.The whole lookup takes 50-200 ms under normal conditions; DNS caching at the sender reduces repeat cost.
RFC 5321 specifies a fallback: if no MX records exist for a domain, the sender attempts delivery to an A record for the domain itself. This is the "implicit MX" behaviour.
firm.co.uk. IN A 203.0.113.25In the absence of MX, a sender would connect to 203.0.113.25:25. This is fragile and discouraged — publish explicit MX records for any domain that receives mail.
For domains that should not receive mail (brand protection, non-sending), publish an explicit "null MX":
parked.co.uk. IN MX 0 .The dot (null hostname) with priority 0 tells senders "this domain rejects all mail". RFC 7505 defines this pattern.
firm.co.uk. IN MX 10 mx.smartxhosting.uk.One MX pointing at the hosted infrastructure. Simple and reliable.
firm.co.uk. IN MX 10 mail1.firm.co.uk.
firm.co.uk. IN MX 20 mail2.firm.co.uk.Primary plus backup. Failover during primary outage.
firm.co.uk. IN MX 0 firm-co-uk.mail.protection.outlook.com.Microsoft uses priority 0 and a tenant-specific hostname.
firm.co.uk. IN MX 1 smtp.google.com.Single MX at priority 1 pointing at Google's infrastructure.
firm.co.uk. IN MX 10 firm-co-uk.mx-in.mimecast.com.
firm.co.uk. IN MX 20 firm-co-uk.mx-in-eu.mimecast.com.Mail arrives at the filtering gateway, which relays to the internal mail server after inspection.
council.gov.uk. IN MX 10 mx1.council.gov.uk.
council.gov.uk. IN MX 10 mx2.council.gov.uk.
council.gov.uk. IN MX 20 backup.council.gov.uk.Two primary load-balanced MXes, one backup at higher priority.
MX records themselves are about inbound mail delivery. But SPF's mx mechanism references them for outbound authentication:
firm.co.uk. IN TXT "v=spf1 mx -all"This says "any IP listed in my MX records is authorised to send as my domain". Useful when the same servers handle both inbound and outbound mail.
DKIM and DMARC do not reference MX directly. DKIM uses selector-based DNS TXT; DMARC uses its own TXT at _dmarc.
MTA-STS references MX hostnames in its policy — the mx: line must include actual MX hostnames so senders can validate certificates.
DANE TLSA records are published at names derived from MX: _25._tcp.MXhostname.
MX record TTL affects how quickly changes propagate. Common values:
Before an MX change, drop the TTL to a low value (300) at least 24 hours in advance so old caches expire by change time. After the change is stable, raise back to a longer value.
Sender receives NXDOMAIN or empty MX set. Mail cannot be delivered. Check DNS configuration; publish MX records if missing.
MX points at a hostname with no A/AAAA record. Sender fails to reach the server. Fix by ensuring the MX hostname has valid IP records.
RFC 5321 prohibits MX targets being CNAMEs. Some senders tolerate this; others reject. Always use direct A/AAAA at the MX hostname.
MX record is correct but the server is not listening on port 25, or a firewall blocks the connection. Test with telnet mail.firm.co.uk 25.
The MX server presents an invalid certificate; senders using strict TLS policies (MTA-STS enforce, DANE) refuse to deliver. Fix certificate chain, hostname, or rotation issues.
Complete mail outage. Mail queues at senders for typically 4-72 hours before bouncing. Restore any of the MXes to resume delivery.
Occasional misunderstanding: lower priority is tried first. A "backup" MX with priority 5 and "primary" at priority 10 reverses the intended routing.
10 mail.epost.plus.When moving from one mail provider to another (e.g. Microsoft 365 to SmartXHosting, or on-premises to hosted), MX migration needs care:
telnet or openssl s_client.RFC 7505 defines the null MX specifically for domains that receive no email:
parked.co.uk. IN MX 0 .The dot as hostname is the root zone itself — an invalid mail target. Priority 0 is standard. Senders respecting the null MX immediately reject; senders ignoring it may try the implicit-MX (A-record) fallback, but the domain's lack of other mail infrastructure prevents delivery.
Pair null MX with the lockdown records described in How to Protect Non-Sending Domains for complete non-receiving domain hardening.
Q: Can I have multiple MX records with the same priority?
A: Yes. Senders pick one randomly, providing load balancing and failover. Common pattern for multi-server deployments.
Q: Does MX priority affect outbound mail?
A: No. Priority is a receiver-side concept — tells senders which MX to try first when delivering to the domain. Outbound mail from your server is unrelated.
Q: What is the lowest valid priority?
A: 0. Commonly used by Microsoft 365 and some other hosted providers. Lower numbers are tried first.
Q: Can I point MX at an IP address directly?
A: No. MX targets must be hostnames. The hostname is then resolved to IPs via A/AAAA records.
Q: Is there a maximum number of MX records?
A: No hard limit. Practical limit is typically 5-10 before management becomes cumbersome. Most UK businesses have 1-3.
Q: How do I test my MX records from outside my network?
A: Online tools (MXToolbox, DNS Checker, intoDNS) query from multiple locations. Locally: dig MX firm.co.uk @8.8.8.8.
Q: Can MX records point at hostnames in a different domain?
A: Yes. Common for managed mail — your MX points at the hosted provider's infrastructure. SmartXHosting customers often have MX pointing at *.smartxhosting.uk hostnames.
Q: What happens to mail queued at senders when I change MX?
A: Queued mail uses the new MX after DNS TTL expires at the sender. For queues with long retention (24-72 hours), plan MX changes accordingly.
Q: Does having multiple MX records improve uptime?
A: Yes, if the MXes are on independent infrastructure. Two MXes on the same server offer no real redundancy.
Q: Can a null MX (MX 0 .) and normal MXes coexist?
A: No — a null MX is for domains that accept no mail. It cannot coexist with normal MXes. Use it for non-receiving domains only.
Q: Are IPv6 MX records supported?
A: Yes — the MX hostname resolves to AAAA records for IPv6 senders. Modern UK mail infrastructure is typically dual-stack.
Q: What happens if my primary MX is slow but reachable?
A: Sender completes the delivery over the slow link. Does not fail over to backup for slow response, only for connection failure or explicit SMTP errors.
Q: Can I use wildcards for MX?
A: Not typically. MX is published at specific domain names. Wildcards exist (*.firm.co.uk IN MX ...) but behaviour varies across DNS providers and senders.
Q: Are MX records visible to attackers?
A: Yes. MX records are public DNS. Attackers can enumerate your mail infrastructure. Defence is via server hardening, not via MX obscurity.
Q: Does the MX hostname need to have a reverse DNS (PTR) record?
A: For inbound mail, no. For outbound mail (when the MX host also sends), yes — PTR is crucial for sender reputation. See Reverse DNS PTR Records.
Q: Can MX records be signed with DNSSEC?
A: Yes. DNSSEC signing covers MX records alongside all other zone data. Recommended for mail-security-conscious UK domains.
Q: What is the NCSC recommendation for UK public sector MX configuration?
A: Publish redundant MXes with strong TLS, MTA-STS and ideally DANE. NCSC Mail Check reviews MX configurations.
Q: Does publishing an MX record automatically create an A record for the MX hostname?
A: No. You must publish both: an MX pointing at a hostname, and an A (or AAAA) record for that hostname. Common oversight.
Q: How often should I review my MX records?
A: Annually at minimum. Any time you migrate mail providers, update immediately. MX misconfigurations silently break mail delivery.
Q: Are there common UK-specific pitfalls with MX records?
A: UK DNS providers generally handle MX correctly. The common issue is delayed TTL updates during mail provider migrations — plan cut-overs with low TTLs.
Q: How do UK hosted mail platforms typically recommend MX configuration?
A: Single MX pointing at the platform's infrastructure hostname. Platform handles internal redundancy. SmartXHosting, Microsoft 365, Google Workspace all follow this pattern.
Q: Can an MX record point at an external country's infrastructure?
A: Technically yes. Some UK businesses use US-based mail providers whose MX resolves to US data centres. Consider data residency and UK GDPR implications for regulated data; infrastructure location is a compliance concern alongside technical correctness.
Q: What happens when my MX server is behind a load balancer?
A: MX points at a single hostname; the hostname resolves to the load balancer's IP; connections flow through to backend servers. Common UK enterprise pattern. TLS termination at the load balancer affects DANE; plan certificate coverage accordingly.
Q: Is MX the same as "mail server"?
A: Not quite. MX records are DNS entries. "Mail server" is the software and host accepting SMTP. MX records point at the hostname the mail server runs on; multiple MX records can point at one or more mail servers.
Q: Do MX records have an impact on deliverability of outbound mail I send?
A: Indirectly. Your outbound mail's sender domain needs a valid MX — some receivers reject mail from domains without one (unable to respond to bounces). Always publish MX for any domain you send from.
Q: How do I monitor MX health in production?
A: Uptime monitoring services (UptimeRobot, StatusCake) can check SMTP on port 25 against your MX hosts. Specialised email monitoring services include TLS handshake verification. Commercial DMARC platforms often include MX health in their dashboards.
Q: Can I have MX records across different continents for geographic redundancy?
A: Yes. Multi-region MX deployments are common for large UK businesses. The MX hostnames point at infrastructure in different regions; senders pick based on priority. Consider latency and regulatory implications.
Q: What is the relationship between MX and email throttling by UK ISPs?
A: Some UK ISPs throttle outbound port 25 based on sender behaviour (volume, reputation). Receiving-side MX configuration is independent of ISP throttling. Only outbound ISPs are affected.
Q: Are there any security reasons to publish multiple MX records?
A: Yes — redundancy against single-server compromise or outage. If one mail server is attacked, others continue accepting mail. Also supports staged migrations and maintenance windows.
Q: Can I use the same MX hostname for multiple domains?
A: Yes. Common for hosted mail providers — one infrastructure hostname (e.g. mx.smartxhosting.uk) serves many customer domains. Each domain's MX points at the shared hostname.
Q: Does MX need special configuration for mailing lists?
A: Mailing list software usually runs on the mail server behind the MX. No MX-specific configuration needed; the list is reached via normal MX delivery.
Q: How do cloud-hosted MX infrastructure (AWS, Azure) differ operationally from on-premises?
A: Cloud MX hosts are typically behind cloud load balancers with managed TLS. Maintenance and patching is often automated. On-premises MXes give more control but require operational investment.
Q: Is there a best practice for the number of MX records a UK SME should publish?
A: 1-3 typically. Single MX with redundant hosted infrastructure (SmartXHosting, Microsoft 365) is fine for smaller businesses. Larger UK operations benefit from 2-3 across geographic regions.
Q: Does MX record management differ between domains on Cloudflare vs other DNS hosts?
A: Only in UI. The underlying MX record format is standard. Cloudflare, Route 53, Gandi LiveDNS all handle MX records identically.
Q: Can MX records be monitored by UK-specific services?
A: Yes. NCSC Mail Check monitors public sector MX configurations. Commercial services (Hardenize, Mail Hardener) include MX-level checks alongside SPF/DKIM/DMARC for private sector UK domains.
Q: Do MX records have any impact on inbound spam filtering?
A: Indirectly. Spam filters may flag mail from domains with odd or missing MX as suspicious (can't be bounced back). Valid MX is table stakes for good deliverability.
Q: How do I verify my MX is actually receiving mail correctly?
A: Send a test message from an external address to a test mailbox on your domain. Check the recipient received it. More rigorously: use MXToolbox's "SMTP Test" which connects to your MX and reports timing and TLS status.
Q: Does a misconfigured MX affect my business's email reputation?
A: Yes — receivers that cannot deliver to you may mark your domain as problematic. Valid, responsive MX infrastructure is baseline for email reputation.