Outrings
Web observability and evidence

What is an MX record and why is my email failing?

How mail routing actually works, the six configuration faults that cause almost every delivery problem, and how to check each one.

4 min read
Short answer

An MX record tells other mail servers where to deliver mail for your domain. If inbound mail vanishes, the MX records are the first thing to check. If outbound mail lands in spam, MX is fine and the problem is authentication — SPF, DKIM and DMARC.

Inbound and outbound are different problems

Sorting the symptom first saves most of the diagnostic time, because the two failures share no causes.

SymptomLayerLook at
Mail sent to you never arrivesInboundMX records, and the mailbox existing at the destination
Your mail lands in recipients' spamOutboundSPF, DKIM, DMARC, sending IP reputation
Your mail is rejected outrightOutboundDMARC policy, blocklists, missing reverse DNS
Some recipients get it, others do notOutboundUsually DKIM alignment or a specific provider's policy

Reading your MX records

dig +short MX example.com

You get a priority number and a hostname per line. Lower numbers are tried first; equal numbers share load. The hostnames must resolve to addresses, and — importantly — an MX record must point at a hostname, never an IP address. An IP in an MX record is invalid, and some senders will reject it outright while others quietly accept it, producing the maddening "works for some people" pattern.

The faults that actually cause lost mail

No MX record at all

Some senders will fall back to the A record; many will not. If you receive mail at the domain, publish MX records explicitly rather than relying on fallback behaviour that varies by sender.

MX pointing at a hostname that no longer resolves

Common after a mail provider migration. The MX record still names the old host, which stopped existing. Mail bounces or disappears depending on the sender.

A CNAME as the MX target

The target of an MX record is required to be a hostname with address records, not an alias. Many mail servers refuse to follow a CNAME there, so this produces intermittent, provider-dependent failure.

Mail provider changed but DNS did not

The single most common cause. The mailbox exists at the new provider and the world is still being told to deliver to the old one.

Firewall blocking port 25

If you run your own mail server, inbound SMTP must be reachable. Plenty of hosting providers block port 25 by default, and the symptom is total inbound silence with perfectly correct DNS.

Something worth knowing before you go hunting: your website and your email are entirely independent. Moving your website to a new host does not move your email, and a website migration that copies A records but not MX records will silently break mail. This catches people constantly.

When outbound mail lands in spam

MX is irrelevant here. Three authentication mechanisms decide whether a receiver trusts your mail:

  • SPF — a TXT record listing which servers may send as your domain. Check for exactly one v=spf1 record and no more than ten DNS lookups within it.
  • DKIM — a cryptographic signature on each message, verified against a public key in DNS. Requires the selector your provider uses, which is why it cannot be checked from the domain name alone.
  • DMARC — a TXT record at _dmarc telling receivers what to do when SPF and DKIM fail, and where to send reports.
dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com

A DMARC policy of p=none is monitoring only. Until it is quarantine or reject, anyone can send mail as your domain and receivers have been told to do nothing about it.

Diagnosing in order

  1. Confirm the direction: inbound or outbound. They share no causes.
  2. Inbound — check MX records exist and their targets resolve to addresses.
  3. Inbound — confirm the mailbox exists at the provider those records name.
  4. Outbound — check for exactly one SPF record and count its lookups.
  5. Outbound — check the DMARC policy and read the aggregate reports it produces.
  6. Outbound — check whether the sending IP is on a public blocklist and has valid reverse DNS.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • MX records with priorities and whether each target actually resolves, rather than only whether records exist.
  • SPF validated for syntax, record count and DNS-lookup count against the ten-lookup limit.
  • DMARC policy read from the _dmarc name, reporting whether it is none, quarantine or reject.
  • DKIM reported as untested with the reason, because verifying it requires knowing the selector your provider uses.

For agents and scripts, the same measurement is at /api/v1/dns?url=yoursite.com — see the API documentation.

Related questions

Can I have more than one MX record?

Yes, and you should. Multiple records with different priorities give failover; equal priorities distribute load. Most hosted mail providers publish several by default.

Does changing my website host affect email?

Only if the migration touches the MX records — which it should not, and frequently does when a new host imports a partial zone. Website and email are separate records, and this is a common way to lose mail during a move.

Why is DKIM not checked automatically?

Verifying DKIM requires the selector, which is chosen by your mail provider and is not discoverable from the domain alone. Rather than guess at common selectors and report a misleading result, it is declared untested with the reason.

How long do MX changes take?

As long as the TTL on the previous record. Lower the TTL a day before a planned mail migration and the cutover is minutes rather than hours.

Read next

All 100 guides · How every check works · API for agents