A client can have a fast website, valid SSL certificate and perfect-looking contact forms, yet still miss leads because their email has stopped arriving. The fault is often not in Microsoft 365, Google Workspace or the mailboxes themselves. It is in DNS. So, what is an MX record? It is the DNS instruction that tells other mail servers where to deliver email for a domain.
For agencies and web teams managing multiple domains, MX records are easy to overlook. They rarely change, which is exactly why an accidental edit, failed migration or expired DNS service can go unnoticed until a client asks why nobody has replied to their enquiries.
What is an MX record?
MX stands for Mail Exchange. An MX record is a type of DNS record that identifies the mail server, or servers, responsible for accepting incoming email for a domain.
When someone sends a message to [email protected], the sender's mail server does not guess where that mailbox lives. It queries DNS for the MX records attached to example.co.uk. Those records return hostnames such as `example-co-uk.mail.protection.outlook.com` or `aspmx.l.google.com`. The sending server then connects to the appropriate destination using SMTP and attempts delivery.
In plain terms, an MX record is the signpost for inbound email. Without a valid signpost, messages may bounce immediately, queue for later delivery or disappear into a delivery problem that is difficult for a non-technical client to explain.
An MX record has two main parts: a priority value and a destination hostname. A lower numerical value has higher priority. For example, a record with priority 10 is attempted before one with priority 20.
``` example.co.uk. 3600 IN MX 10 mail1.example.co.uk. example.co.uk. 3600 IN MX 20 mail2.example.co.uk. ```
The final dot indicates a fully qualified domain name. DNS management interfaces often add it automatically, but the destination must still resolve correctly to an IP address through an A or AAAA record.
How email delivery uses MX records
The delivery process is simple in principle, but each dependency matters. A sending server looks up a domain's MX records, sorts them by priority, resolves the chosen hostname to an IP address, then opens an SMTP connection. The receiving mail system decides whether to accept the message, apply spam controls or reject it.
That means an MX record only controls where inbound email is sent. It does not create mailboxes, configure Outlook, prove that a user licence is active or guarantee that a message will reach an inbox. Those functions sit with the email provider and its security policies.
It also does not authenticate outbound email. SPF, DKIM and DMARC serve different jobs:
- SPF identifies servers permitted to send mail for a domain.
- DKIM adds a cryptographic signature to outgoing messages.
- DMARC tells receiving services how to handle messages that fail alignment checks and where to send reports.
- MX records direct incoming messages to the mail platform.
These records work together, but treating them as interchangeable causes avoidable troubleshooting mistakes. A domain can have flawless MX records and still have outbound messages rejected because its SPF or DKIM configuration is wrong.
Priority does not always mean failover
Multiple MX records are commonly described as primary and backup mail servers. That is broadly true, but it needs care. A sender will normally try the lowest-numbered priority first and move to another eligible server if it cannot connect or receives a temporary failure.
However, backup delivery only works if the lower-priority server is genuinely configured to receive mail for the domain. Pointing a second MX record at an unrelated host does not create resilience. It can create bounces, open-relay risk or a second destination that accepts mail but cannot hand it back to the primary platform.
Cloud email providers usually publish a specific MX value for each tenant. In that situation, adding old hosting-provider MX records as a precaution is often the wrong move. Follow the provider's documented configuration rather than mixing records from previous services.
There is also a legitimate configuration called a null MX record. It explicitly states that a domain does not accept email. This can be useful for domains used only for web redirects or defensive brand registrations, but it should never be added to a domain expected to receive client enquiries.
Common MX record failures across client portfolios
Most MX failures happen during a change, not during normal operation. A new website launch may move DNS from a registrar to a hosting provider. A mailbox migration may leave legacy records behind. Someone may replace an MX record while trying to update a TXT record. The website continues working, so the issue is not spotted straight away.
The most common problems include an MX hostname with no corresponding A or AAAA record, a typo in the destination, incorrect priority values, duplicate or obsolete records, and DNS delegation pointing to the wrong nameservers. A domain can also lose its records when a DNS zone is rebuilt from scratch during a hosting migration.
TTL, or time to live, affects how quickly changes are seen. If an MX record has a one-hour TTL, some sending servers may keep using the previous answer for up to an hour after a change. Reducing TTL before a planned migration can help, but it does not remove the need for a tested cutover plan. Raising it again afterwards reduces unnecessary DNS query traffic.
Another awkward scenario is an MX target that points to the domain's own website hostname. If `mail.example.co.uk` is intended to receive email, it needs a functioning mail service behind it, not merely the same web server that hosts the site. The DNS record may look valid while the SMTP connection fails.
How to check an MX record properly
Checking the record in a DNS management panel is not enough. The configured value may not be the value published to the internet, particularly after a nameserver change. Query public DNS and confirm what external senders can actually see.
On a command line, `dig MX example.co.uk` or `nslookup -type=MX example.co.uk` will show the published records. Compare the result with the email provider's required value. Then resolve each MX hostname and test that the destination accepts SMTP connections on port 25, where appropriate.
For a single domain, this is a short task. Across 50, 200 or 1,000 client domains, manual spot checks are an operational gap. The important question is not whether the MX record was correct when the mailbox was set up. It is whether it remains correct after every DNS, hosting, registrar and email-platform change.
Automated DNS monitoring should alert when an MX record is added, removed or altered, and should check that its target remains resolvable. Pair that with SPF, DKIM and DMARC validation to see the full email-deliverability picture rather than a single fragment of it. TLDTrack can place these checks alongside uptime, SSL, domain expiry and wider website monitoring, so an agency has one view of risks that clients will experience as a service failure.
A practical response when email stops arriving
When a client reports missing email, begin by identifying whether the problem is inbound, outbound or mailbox-specific. If all external senders are unable to deliver to the domain, inspect MX records and DNS delegation first. If messages arrive but land in junk, investigate authentication and filtering. If one person cannot receive messages, the cause is more likely to be a mailbox, forwarding rule, licence or storage issue.
For an MX incident, verify the public MX response, confirm the hostname resolves, and check whether the email provider reports a service issue. Look for recent changes in DNS audit logs, registrar settings, website migrations and mailbox-provider administration. Revert unauthorised or incorrect changes carefully, then allow for DNS caching before declaring the issue resolved.
Avoid making several record changes at once under pressure. A rushed fix can replace a clear fault with an unclear one, especially where SPF, DKIM and DMARC records are also being edited. Record the previous state, make the smallest justified correction and validate it externally.
Email is often treated as separate from the website estate until it breaks. For the client, there is no distinction: a missing enquiry is a missed opportunity, whether the cause was a web form, DNS record or mail server. Treat MX records as a monitored operational dependency, and you are far more likely to catch the quiet failures before the client does.
