What Is an MX Record

An MX (Mail Exchange) record specifies which mail servers are responsible for receiving email for your domain. When someone sends an email to user@yourdomain.com, MX records tell the sending server where to deliver the message. Without properly configured MX records, email for your domain simply will not arrive.

MX records are one of the most important DNS record types alongside A records and NS records. While A records handle web traffic, MX records handle the entire email delivery pipeline.

How MX Records Work

MX records include two key components:

1. Priority (preference) - A number indicating server priority (lower = higher priority)
2. Mail server - The hostname of the mail server

example.com.    3600    MX    10 mail.example.com.
example.com.    3600    MX    20 backup.example.com.

When sending an email to user@example.com:

1. Sender's mail server queries MX records for example.com
2. Tries the server with lowest priority (10 = mail.example.com) first
3. If unavailable, falls back to higher priority servers (20 = backup.example.com)
4. For each mail server hostname, the sender resolves the A record or AAAA record to get the IP address, then connects on port 25 (SMTP)

MX records must point to hostnames that have A or AAAA records, never to CNAME records. An MX target that is a CNAME violates RFC 2181 and can cause delivery failures with strict mail servers.

Understanding Priority Values

The priority field is the key to MX failover and load balancing:

Priority spacing tip: Use gaps of 10 between priorities (10, 20, 30) rather than consecutive numbers (1, 2, 3). This leaves room to insert new servers later without renumbering everything.

Common Use Cases

Single Mail Server

Basic setup with one mail server:

example.com.    3600    MX    10 mail.example.com.

Multiple Mail Servers with Failover

Primary and backup servers:

example.com.    3600    MX    10 mail1.example.com.
example.com.    3600    MX    20 mail2.example.com.
example.com.    3600    MX    30 mail3.example.com.

If mail1 is down, sending servers automatically try mail2, then mail3. The backup servers queue and forward messages to the primary once it recovers, or they can be configured as full replicas.

Third-Party Email Services

Google Workspace:

example.com.    3600    MX    1  aspmx.l.google.com.
example.com.    3600    MX    5  alt1.aspmx.l.google.com.
example.com.    3600    MX    5  alt2.aspmx.l.google.com.
example.com.    3600    MX    10 alt3.aspmx.l.google.com.
example.com.    3600    MX    10 alt4.aspmx.l.google.com.

Microsoft 365:

example.com.    3600    MX    0  example-com.mail.protection.outlook.com.

Zoho Mail:

example.com.    3600    MX    10 mx.zoho.eu.
example.com.    3600    MX    20 mx2.zoho.eu.
example.com.    3600    MX    50 mx3.zoho.eu.

When switching email providers, lower your MX record TTL to 300 seconds a day or two before the migration. This ensures the old MX records expire quickly from caches. See DNS TTL Best Practices for more strategies.

Load Balancing

Equal priority distributes load:

example.com.    3600    MX    10 mail1.example.com.
example.com.    3600    MX    10 mail2.example.com.
example.com.    3600    MX    10 mail3.example.com.

When multiple MX records share the same priority, sending mail servers choose randomly among them, effectively distributing inbound email load.

Null MX (RFC 7505)

If a domain should never receive email, you can explicitly declare this with a null MX record:

example.com.    3600    MX    0 .

The single dot (.) as the mail server hostname tells sending servers that this domain does not accept email. This is useful for domains that are used only for websites, CDNs, or API services. Without a null MX, sending servers may attempt delivery to the A record of the domain directly, which can cause confusing bounce messages.

Record Format

Querying MX Records with dig

# Query MX records
dig MX example.com
 
# Get just the MX values
dig MX example.com +short
 
# Query a specific nameserver
dig MX example.com @ns1.dnscale.eu
 
# Verify the mail server hostname resolves
dig A mail.example.com
 
# Full trace of MX resolution
dig MX example.com +trace

Example output:

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail1.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.

After verifying MX records with dig, also confirm that the mail server hostnames themselves resolve to valid IP addresses. Run dig A mail1.example.com to check.

Adding an MX Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Usually @ for the apex domain
   • Type: Select MX
   • Priority: Enter the priority value (e.g., 10)
   • Value: Enter the mail server hostname
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create an MX record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "mail.example.com",
    "ttl": 3600,
    "priority": 10
  }'

Set up Google Workspace MX records:

# Primary MX
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "aspmx.l.google.com",
    "ttl": 3600,
    "priority": 1
  }'
 
# Secondary MX
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "alt1.aspmx.l.google.com",
    "ttl": 3600,
    "priority": 5
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "example.com.",
      "type": "MX",
      "content": "mail.example.com.",
      "ttl": 3600,
      "priority": 10,
      "disabled": false
    }
  }
}

Email Authentication Records

MX records handle where email is delivered, but modern email also requires authentication to prevent spoofing and improve deliverability. These records work alongside MX records as part of a complete email setup. See our dedicated guide on Email Security: SPF, DKIM, and DMARC for full details.

Example complete email setup:

example.com.    3600    MX     10 mail.example.com.
example.com.    3600    TXT    "v=spf1 mx -all"
example.com.    3600    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Troubleshooting Email Delivery

Email not arriving? Work through these checks:

1. Verify MX records exist: Run dig MX yourdomain.com. If no MX records are returned, email cannot be delivered.
2. Check mail server resolves: Each MX target must have an A or AAAA record. Run dig A mail.yourdomain.com.
3. Verify port 25 is open: The mail server must accept connections on port 25 (SMTP). Many cloud providers block outbound port 25 by default.
4. Check reverse DNS: Ensure your mail server IP has a matching PTR record. Many receiving servers reject mail without proper reverse DNS.
5. Validate SPF: An incorrect SPF record can cause legitimate email to be rejected. Test with dig TXT yourdomain.com.
6. Propagation: If you recently changed MX records, allow time for DNS propagation or flush your DNS cache.

Best Practices

1. Always have backup MX servers - Use multiple MX records with different priorities for redundancy

2. Use appropriate priority gaps - Leave room between priorities (10, 20, 30) to insert new servers later

3. MX targets must be A/AAAA records - MX records should point to hostnames with A/AAAA records, not CNAMEs

4. Configure reverse DNS - Ensure your mail servers have proper PTR records for deliverability

5. Add SPF, DKIM, and DMARC - Complement MX records with email authentication records

6. Use null MX for non-mail domains - Explicitly reject email on domains that don't use it

7. Monitor MX health - Regularly verify that all MX targets are reachable and accepting connections

Testing MX Records

Verify your MX records with dig:

dig MX example.com
 
# Check specific nameserver
dig MX example.com @ns1.dnscale.eu

Or use online tools like MXToolbox to verify your email configuration, test SMTP connectivity, and check your authentication records.

Related Record Types

• TXT - SPF, DKIM, DMARC records
• A - Mail server IP addresses
• AAAA - Mail server IPv6 addresses
• PTR - Reverse DNS for mail servers
• CNAME - Used for DKIM selectors and email verification
• SRV - Autodiscover for email clients
• TLSA - DANE for SMTP encryption
• CAA - Certificate authority authorization

Conclusion

MX records are the foundation of email delivery for your domain. Proper configuration with backup servers, appropriate priorities, and complementary authentication records ensures reliable and secure email communication. Whether you're self-hosting mail with failover servers or using a third-party provider like Google Workspace or Microsoft 365, understanding MX priorities, null MX, and the relationship between MX records and PTR/SPF/DKIM is essential. DNScale makes managing MX records straightforward through its dashboard and API.