MX Records Explained: How Email Finds Its Way

When someone sends an email to name@example.com, the sending mail server doesn't just look up example.com's regular A record. It queries a completely different record type: MX, short for Mail Exchange. The MX record points at the hostname of the server responsible for accepting mail for that domain -- which is very often a different address entirely from the one the website itself lives at.

Priority: the part that surprises people

A domain can have multiple MX records, each with a numeric priority value. Lower numbers are preferred. A sending server tries the lowest-priority (most preferred) mail server first, and falls back to higher-priority values only if that one is unreachable. This is what makes redundant mail delivery possible -- a backup mail server sitting at a higher priority value, ready to accept mail if the primary is down.

• An MX record's target must itself resolve to an A or AAAA record -- it can't point directly at an IP address.
• A domain with no MX record at all typically can't receive email, even if its website works fine -- the two are handled by entirely separate DNS lookups.
• Two MX records with the identical priority value are both valid simultaneously -- the sending server is free to pick either, which is sometimes used deliberately as a crude form of load balancing.

Why this matters beyond just "email works or it doesn't"

MX records are also the starting point for verifying a domain's broader email setup -- SPF, DKIM, and DMARC records all exist to prove that mail claiming to come from a domain is actually authorized to, and checking the MX configuration is usually the first step before verifying those. A migration to a new email provider is, at its core, a DNS change to the MX record (plus the supporting records) -- which means it inherits every propagation-delay caveat that applies to any other DNS update.

A domain that deliberately sends no email

Not every domain wants to receive mail, and leaving that undefined is itself a small security gap: without an explicit signal, some mail systems will still attempt delivery or make assumptions about a missing configuration. RFC 7505 defines a "null MX" specifically for this -- a single MX record pointing at "." (the root, meaning nowhere) with priority 0, which explicitly declares "this domain accepts no mail, don't bother trying." It's a small, easy addition worth setting on any domain -- a marketing redirect domain, an internal-only service domain -- that will genuinely never send or receive email.

The common mistake worth avoiding

A surprisingly frequent misconfiguration is pointing an MX record directly at an IP address, or at a hostname that itself only has a CNAME rather than a real A/AAAA record. Both violate the record type's own rules, and mail systems that follow the specification strictly will refuse to deliver at all rather than guess at what was intended. If a domain's website works perfectly but email delivery fails outright rather than just slowly, checking that every MX target actually resolves to a plain A or AAAA record -- not a CNAME, not a bare IP typed in by mistake -- is one of the first, cheapest things worth verifying.