KNOWLEDGE ARTICLE
What Is MX records?
Mail Exchanger records
Specify which mail servers should receive email addressed to a domain.
At a glance
MX records contain mail-server hostnames and preference values. A domain without MX records may not receive mail directly, although compatible fallback behavior can also apply.
How MX records direct email delivery
An MX, or Mail Exchanger, record tells a sending server which hosts should receive mail for an address such as [email protected]. Its value combines a preference number with a hostname; lower numbers are normally preferred. Multiple records can describe primary and backup delivery or equal-priority distribution. The target must be a hostname that resolves to an address, not a literal IP address.
The sender looks up the recipient domain's MX records, resolves the target's A or AAAA records and opens an SMTP connection. If the preferred host is temporarily unavailable, it may try another preference level or retry later according to its queue policy. A brief outage therefore does not necessarily cause an immediate bounce.
Hosted mail, security gateways and self-hosted mail
- Hosted services such as Google Workspace and Microsoft 365 typically publish provider MX hosts. Messages enter the provider's gateways before reaching the relevant tenant.
- A secure email gateway may sit in front of the mailbox platform to filter spam, scan for malware and enforce policies. Public MX records then describe the entry point rather than the final mailbox storage.
- A self-hosted mail server needs working hostname resolution, PTR, TLS, queues, sender reputation and spam protection. MX records only announce the receiving entry point.
- A null MX, with preference 0 and a single dot as its target, explicitly declares that a domain does not accept email. This is clearer than making senders repeatedly attempt nonexistent mail services.
Common problems during email migration
Before changing MX records, create all accounts and aliases at the new service. Keep the old service able to receive mail during the DNS-cache transition. Changing MX does not migrate historical messages or update SPF, DKIM, DMARC, autodiscovery or client settings automatically.
Typical failures include an MX target that cannot resolve, a single fragile entry point, a backup server that does not recognize recipients, reversed preference values and old TXT policies that still authorize a retired provider. A complete review separates incoming routing from outgoing identity.
Practical use and interpretation
Recognizable MX hostnames identify the current mail entry point and may indicate a hosted mailbox provider or security gateway. Custom hostnames, intermediate gateways and hybrid deployments complicate attribution. Target domains, certificates and other DNS records can provide corroborating evidence.
Without ordinary MX records, check for a null MX, whether the domain is used only for a website and whether the lookup completed. Confirmed absence without signs of email use can be described as no receiving service found. Incomplete evidence leaves the state unknown.
Points to consider
Reading MX alongside SPF, DKIM and DMARC gives a fuller picture of a domain's email infrastructure.
Frequently asked questions
Does a larger MX preference number mean higher priority?
Usually the opposite: a lower number is preferred. Senders can choose between equal-preference hosts for distribution or redundancy.
Can a domain send mail as soon as MX is configured?
MX primarily controls incoming routing. Outgoing mail also needs an SMTP service and appropriate SPF, DKIM, DMARC, PTR, TLS and sender-reputation management.
Does a missing MX record affect access to a website?
Usually not. Web access relies on A, AAAA, CNAME and HTTP services. Missing MX records primarily concern mail sent to the domain.