← DNS RecordsRecord Type / Mail

MX Record

Specifies the mail servers responsible for accepting email for a domain. Priority values determine delivery order when multiple servers are configured.

Overview

Mail Exchanger Record

When another mail server sends email to user@example.com, it looks up the MX records for example.com to find where to deliver the message. The MX record points to a mail server hostname, and the sending server then resolves that hostname to an IP address.

The priority value (a lower number = higher priority) determines which server to try first. Multiple MX records create redundancy: if the primary mail server is unreachable, the sending server retries with the next-lowest-priority server. Equal-priority MX records enable load balancing.

  • MX target must be a hostname — never an IP address or CNAME (RFC 2181)
  • The target hostname must have its own A/AAAA record (a "glue" requirement)
  • Lower priority number = higher preference (10 is preferred over 20)
  • Equal priority values = load balanced; sending servers choose randomly
  • No MX record = sending servers fall back to the A record (not recommended)
  • MX records must be at the zone apex for a domain to receive email
; Syntax ; Name [TTL] IN MX priority mail-host. ; Single mail server @ 3600 IN MX 10 mail.example.com. ; Redundant (primary + fallback) @ 3600 IN MX 10 mail1.example.com. @ 3600 IN MX 20 mail2.example.com. ; Load balanced (equal priority) @ 3600 IN MX 10 mail1.example.com. @ 3600 IN MX 10 mail2.example.com. ; Google Workspace MX records @ IN MX 1 aspmx.l.google.com. @ IN MX 5 alt1.aspmx.l.google.com. @ IN MX 5 alt2.aspmx.l.google.com. @ IN MX 10 alt3.aspmx.l.google.com. @ IN MX 10 alt4.aspmx.l.google.com.
MX Cannot Point to a CNAMERFC 2181 §10.3 explicitly prohibits MX (and NS) records from pointing to CNAMEs. The target must resolve directly to an A or AAAA record. Some mail servers will refuse delivery to domains with CNAME-pointing MX records.
Email Auth Stack

MX Records and Email Authentication

MX records work alongside SPF, DKIM, and DMARC records to authenticate inbound and outbound email. While MX records define where to deliver email for your domain, SPF defines which servers are authorized to send on your behalf.

The mail server hostname in your MX record should also have a matching PTR (reverse DNS) record. Many spam filters reject or score negatively mail from servers where the sending IP's PTR record doesn't match the server's hostname. This is configured at your IP hosting provider or ISP, not in your domain's DNS.

; Complete mail-related DNS records ; for example.com ; MX — where to deliver email @ MX 10 mail.example.com. ; A — IP of the mail server mail A 203.0.113.50 ; SPF — who can send as @example.com @ TXT "v=spf1 ip4:203.0.113.50 ~all" ; DMARC — policy for failures _dmarc TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" ; PTR — set at your ISP/hosting provider ; 50.113.0.203.in-addr.arpa PTR mail.example.com.
Diagnostics

Querying MX Records

Look up MX records

# Query MX records (with priority) dig thedns.guru MX +short # Full answer with TTL dig thedns.guru MX # Verify MX target has A record MX=$(dig thedns.guru MX +short | \ awk '{print $2}') dig $MX A +short

Test SMTP connectivity

# Check if MX host accepts connections telnet mail.example.com 25 # Or use nc: nc -zv mail.example.com 25 # Check for STARTTLS support openssl s_client -starttls smtp \ -connect mail.example.com:25

Verify PTR matches

# Get MX server IP MX_IP=$(dig mail.example.com A +short) # Check PTR record dig -x $MX_IP +short # Should match the MX hostname # Mismatch = spam score penalty

Test with swaks

# swaks: Swiss Army Knife for SMTP swaks --to user@example.com \ --from test@yourdomain.com \ --server mail.example.com # Check full SMTP conversation swaks --to user@example.com \ --tls --auth LOGIN