# MX record: Definition and How It Works

Source: https://wraps.dev/glossary/mx-record

An MX record is a DNS record naming which mail server accepts email for a domain, with a priority value that determines the order receiving servers should be tried in.

## Priority controls order, not exclusivity

Each MX record carries a priority number, and lower numbers are tried first — a domain with \`10 mail1.example.com\` and \`20 mail2.example.com\` should attempt delivery to \`mail1\` first and fall back to \`mail2\` only if that attempt fails. Multiple records at the identical priority are treated as equally preferred alternatives, which a sending server can choose between arbitrarily.

## Redundancy means more than one priority tier, not just more records

Two MX records at the same priority aren't redundancy in the failover sense — if the mail server behind that priority is down, a sender still can't reach the domain through the other identical-priority record if it's hosted on the same infrastructure. Real redundancy is multiple distinct priority tiers pointing at genuinely independent mail infrastructure, which is exactly the distinction Wraps' email-check package looks for rather than just counting record totals.

## The exchange has to actually resolve, and shouldn't be an IP

An MX record names a hostname, which then needs its own A and/or AAAA records to actually resolve to an address — a common misconfiguration is an MX record whose hostname has no matching A record, meaning mail addressed to that domain has nowhere to actually be delivered even though the MX record itself looks fine. Pointing an MX record directly at a bare IP address instead of a hostname is technically invalid per the DNS specification and flagged as bad practice by any thorough checker.

## MX is what SPF's mx mechanism actually checks

SPF's \`mx\` mechanism authorizes sending from any IP that domain's MX records resolve to — a shortcut for "whatever server receives mail for this domain is also allowed to send it," which is common for smaller setups where the same infrastructure both sends and receives, but is a poor fit for a domain that uses one provider (like SES) to send and a completely different one to receive.

## Why it matters

MX records are foundational infrastructure for receiving mail, and they matter for sending, too, both because SES's custom MAIL FROM domain needs its own dedicated MX record to verify, and because SPF's mx mechanism ties authorized senders directly to whatever the MX records currently say.

## How to check it

```
dig +short MX example.com
```

## Common questions

### Does having two MX records mean I have redundancy?

Only if they're at different priorities pointing at genuinely independent infrastructure. Two records at the same priority hosted on related infrastructure don't give you a real failover path if the underlying system goes down.

### Can an MX record point directly at an IP address?

It's technically invalid per the DNS specification and flagged as bad practice by any thorough MX checker. An MX record should name a hostname, which then resolves to an address through its own A or AAAA records.

### How does SPF's mx mechanism relate to my MX records?

SPF's mx mechanism authorizes sending from whatever IPs your domain's current MX records resolve to. That's a reasonable shortcut when the same infrastructure sends and receives your mail, but a poor fit once you send through one provider (like SES) and receive through another.