How to Configure MX Records for Email: Complete Setup Guide (2025)

Quick Answer

Table of Contents

What Are MX Records?

MX (Mail Exchange) records are DNS records that specify which mail servers are responsible for receiving email on behalf of your domain.

The Role of MX Records

When someone sends email to [email protected], their email server needs to know where to deliver the message. MX records provide this information by listing the mail servers that accept email for example.com.

Without MX records, email sent to your domain will fail with a bounce message like "550 No such domain" or "mail server not found."

MX Records vs. A Records

A records point a domain to an IP address for web hosting:

example.com.    A    192.0.2.1

MX records point to mail server hostnames for email delivery:

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

MX records must point to hostnames (not IP addresses), and those hostnames must have A or AAAA records resolving to IP addresses.

Why MX Records Are Critical

Email Delivery: Without MX records, you cannot receive email at your domain. Senders will receive bounce messages and your emails are lost.

Professional Communication: Custom domain email ([email protected]) looks professional compared to free email services ([email protected]).

Business Continuity: Properly configured MX records with backups ensure email continues flowing even if primary mail servers experience issues.

Service Integration: Many business services require verified email at your domain for account creation and notifications.

MX Records Are for Receiving Email

Important distinction: MX records only affect incoming email (receiving). They don't affect your ability to send email. Sending email requires proper SMTP configuration and email authentication (SPF, DKIM, DMARC).

How MX Records Work

Understanding the email delivery process helps you configure MX records correctly.

Email Delivery Flow

Step 1: Sender Composes Email

From: [email protected]
To: [email protected]
Subject: Meeting Tomorrow

Step 2: Sender's Mail Server Queries DNS

The sender's mail server needs to find where to deliver email for example.com:

DNS Query: What are the MX records for example.com?

Step 3: DNS Returns MX Records

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Step 4: Resolve Mail Server Hostname to IP

The sender's server queries DNS for the A record of the mail server:

DNS Query: What is the IP address of mail1.example.com?
Response: mail1.example.com.    A    192.0.2.1

Step 5: Connect to Mail Server

Sender's mail server connects to 192.0.2.1 on port 25 (SMTP):

SMTP Connection: Connecting to 192.0.2.1:25

Step 6: Deliver Email

SMTP conversation delivers the message:

HELO sender.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
[Email content here]
.

Step 7: Recipient's Mail Server Accepts

If recipient exists and no errors:

250 OK: Message accepted for delivery

Email is delivered to [email protected]'s mailbox.

Multiple MX Records and Failover

When multiple MX records exist, the sending server tries them in priority order:

Configuration:

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

Delivery Attempt:

1. Try mail1.example.com (priority 10) first
2. If mail1 is down or unreachable, try mail2.example.com (priority 20)
3. If mail2 is down, try mail3.example.com (priority 30)
4. If all fail, sender's server queues the message and retries later

This provides redundancy and ensures email delivery even during server maintenance or outages.

Why Hostnames, Not IP Addresses?

MX records must point to hostnames, not directly to IP addresses:

Incorrect:

❌ example.com.    MX    10    192.0.2.1

Correct:

✅ example.com.    MX    10    mail.example.com.
   mail.example.com.    A         192.0.2.1

Reasons for this requirement:

1. Flexibility: Change IP addresses without updating MX records
2. Certificate validation: SSL/TLS certificates match hostnames, not IPs
3. Reverse DNS: PTR records map IPs to hostnames for email reputation
4. Protocol compliance: RFC 5321 requires MX records to point to hostnames
5. IPv6 support: Hostnames can have both A (IPv4) and AAAA (IPv6) records

MX Record Components Explained

MX records have a specific structure with several components.

MX Record Format

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

Breaking down each component:

1. Domain Name (example.com.)

• The domain receiving email
• Trailing dot (.) indicates fully qualified domain name (FQDN)
• Can be root domain (@) or subdomain

2. TTL (3600)

• Time To Live in seconds
• How long DNS servers cache the record
• 3600 = 1 hour, 86400 = 24 hours
• Lower TTL (300-600) useful before changes
• Higher TTL (3600-86400) for stable configurations

3. Class (IN)

• Internet class (always IN)
• Standard for all DNS records
• Other classes exist but rarely used

4. Type (MX)

• Identifies record as Mail Exchange
• Distinguishes from A, CNAME, TXT records

5. Priority (10)

• Numeric value defining preference order
• Lower numbers = higher priority
• Range: 0-65535
• Mail servers tried in ascending priority order

6. Mail Server Hostname (mail.example.com.)

• Hostname of the mail server
• Must have corresponding A or AAAA record
• Trailing dot indicates FQDN
• Cannot be a CNAME (must point to A/AAAA record)

Multiple MX Records Example

Typical configuration with primary and backup servers:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.
example.com.    MX    30    backup-mail.example.com.

mail1.example.com.        A     192.0.2.1
mail2.example.com.        A     192.0.2.2
backup-mail.example.com.  A     192.0.2.3

Email delivery behavior:

• mail1.example.com tried first (priority 10)
• If mail1 unavailable, mail2.example.com tried (priority 20)
• If mail2 unavailable, backup-mail.example.com tried (priority 30)

Subdomain MX Records

Subdomains can have their own MX records:

example.com.            MX    10    mail.example.com.
mail.example.com.       MX    10    mail.example.com.
subdomain.example.com.  MX    10    mail.subdomain.example.com.

Each subdomain's email routes independently. Email to [email protected] goes to mail.subdomain.example.com, not the root domain's mail server.

MX Record Priority System

Priority values determine the order mail servers are contacted.

How Priority Works

Lower numbers = higher priority. Mail servers are tried in ascending numerical order.

Example Configuration:

example.com.    MX    5     primary.example.com.
example.com.    MX    10    secondary.example.com.
example.com.    MX    20    backup.example.com.

Delivery Sequence:

1. Try priority 5 (primary) first
2. If fails, try priority 10 (secondary)
3. If fails, try priority 20 (backup)

Equal Priority Load Balancing

Multiple servers with the same priority create load balancing:

example.com.    MX    10    mail1.example.com.
example.com.    MX    10    mail2.example.com.

Behavior:

• Sending servers randomly choose between equal-priority servers
• Distributes load across both mail servers
• Both servers must accept all email for the domain
• If one fails, all traffic goes to the other

Use Cases:

• High-volume email requiring load distribution
• Redundant servers in different data centers
• Geographic distribution for performance

Priority Gaps Don't Matter

The absolute values don't matter, only the relative order:

These are equivalent:

# Configuration 1
MX    10    primary.example.com.
MX    20    backup.example.com.

# Configuration 2
MX    5     primary.example.com.
MX    100   backup.example.com.

# Configuration 3
MX    1     primary.example.com.
MX    2     backup.example.com.

All three result in the same delivery behavior: try primary first, then backup.

Best practice: Use gaps (10, 20, 30 or 10, 50, 100) to allow inserting new servers between existing priorities later.

Common Priority Patterns

Single Mail Server:

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

Simple, no redundancy. Downtime means lost email.

Primary and Backup:

example.com.    MX    10    primary.example.com.
example.com.    MX    20    backup.example.com.

Most common pattern. Backup takes over if primary fails.

Load Balanced with Backup:

example.com.    MX    10    mail1.example.com.
example.com.    MX    10    mail2.example.com.
example.com.    MX    20    backup.example.com.

Traffic distributed between mail1 and mail2. Backup for failures.

Geographic Distribution:

example.com.    MX    10    us-mail.example.com.
example.com.    MX    10    eu-mail.example.com.
example.com.    MX    10    asia-mail.example.com.
example.com.    MX    50    global-backup.example.com.

Worldwide distribution with shared backup.

Priority Zero

Priority 0 is valid but has special meaning in some contexts:

example.com.    MX    0     mail.example.com.

Microsoft 365 uses priority 0:

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

Priority 0 is the highest possible priority (lowest number). Use it for single server configurations or when explicitly required by provider.

Before You Start: Prerequisites

Ensure you have everything needed before configuring MX records.

1. Access to DNS Management

You need administrative access to manage DNS records for your domain.

Where DNS is managed depends on your setup:

Scenario 1: Domain Registered, DNS at Registrar

• DNS managed at domain registrar (GoDaddy, Namecheap, etc.)
• Log into registrar account
• Navigate to DNS management section

Scenario 2: Domain Uses External DNS (Cloudflare, etc.)

• DNS managed at DNS provider (Cloudflare, Route 53, etc.)
• Log into DNS provider account
• Select your domain

Scenario 3: Custom Nameservers

• DNS managed at your hosting provider or custom location
• Access depends on your specific setup

How to Find Where Your DNS is Managed:

# Check your domain's nameservers
dig example.com NS
nslookup -type=NS example.com

The nameservers (NS records) indicate where DNS is managed.

2. Mail Server Information

Gather MX record details from your email provider:

Information Needed:

• Mail server hostnames (e.g., aspmx.l.google.com)
• Priority values for each server
• Number of MX records required
• Any additional DNS records (A, TXT, CNAME)

Where to Find This:

Email Provider Documentation:

• Google Workspace: "Set up MX records"
• Microsoft 365: "Add DNS records"
• Email hosting provider: "Email setup" or "DNS configuration"

Email Provider Support:

• Contact support if documentation unclear
• They can provide exact records for your account

3. Backup Current DNS Records

Before making changes, document current configuration:

# Export all DNS records
dig example.com ANY > dns-backup.txt

# Or query each record type
dig example.com MX > mx-backup.txt
dig example.com A > a-backup.txt
dig example.com TXT > txt-backup.txt

Take screenshots of DNS management panel as visual backup.

4. Plan for Downtime

DNS propagation takes 1-48 hours. During this time:

• Some users may receive email at old server
• Some users may receive email at new server
• Email may be delayed during transition

Migration Best Practices:

Gradual Transition:

1. Keep old mail servers running during transition
2. Add new MX records alongside old ones (lower priority)
3. After propagation, remove old records
4. This ensures no email is lost during migration

Weekend/Off-Hours Changes:

• Make changes during low email volume periods
• Reduces impact if issues occur

Communication:

• Warn team about potential delays
• Have backup communication channel (chat, phone)

5. Understanding TTL

TTL (Time To Live) determines how long DNS servers cache records:

Before Changes:

• Lower TTL to 300-600 seconds (5-10 minutes)
• Wait for old TTL to expire (if current TTL is 3600, wait 1 hour)
• This speeds up propagation when you make changes

After Changes:

• Once verified working, increase TTL to 3600+ seconds
• Reduces DNS query load
• Improves performance

How to Configure MX Records

Step-by-step process for adding MX records regardless of DNS provider.

Step 1: Log Into DNS Management

Access your DNS management panel:

Cloudflare:

1. Log into Cloudflare dashboard
2. Select your domain from list
3. Click "DNS" in the top navigation

GoDaddy:

1. Log into GoDaddy account
2. Navigate to "My Products"
3. Find your domain, click "DNS"

Namecheap:

1. Log into Namecheap account
2. Domain List → Find domain → "Manage"
3. Click "Advanced DNS" tab

Google Domains:

1. Log into Google Domains
2. Click on your domain
3. Click "DNS" in left sidebar

AWS Route 53:

1. Log into AWS Console
2. Navigate to Route 53
3. Click "Hosted zones" → Select your domain

Step 2: Remove Old MX Records (If Any)

If MX records already exist:

1. Locate existing MX records in DNS panel
2. Note down all values (for backup)
3. Delete all existing MX records

Why remove first?

• Prevents conflicts between old and new mail servers
• Ensures clean configuration
• Old records can cause email delivery to wrong servers

Exception: During migration, you may temporarily keep old MX records with higher priority numbers as backup.

Step 3: Add New MX Records

For each MX record provided by your email service:

Cloudflare:

1. Click "Add record"
2. Type: MX
3. Name: @ (or leave blank for root domain)
4. Mail server: mail.example.com
5. Priority: 10
6. TTL: Auto or 3600
7. Click "Save"

GoDaddy:

1. Click "Add" button
2. Type: MX
3. Host: @ (root domain) or subdomain name
4. Points to: mail.example.com
5. Priority: 10
6. TTL: 1 hour
7. Click "Save"

Namecheap:

1. Click "Add New Record"
2. Type: MX Record
3. Host: @ (or subdomain)
4. Value: mail.example.com
5. Priority: 10
6. TTL: Automatic
7. Click green checkmark

Generic DNS Panel:

• Type/Record Type: MX
• Name/Host: @ (root domain) or subdomain
• Value/Points to: mail.example.com (mail server hostname)
• Priority/Preference: 10 (lower = higher priority)
• TTL: 3600 (1 hour) or provider default

Step 4: Add All Required MX Records

Most email providers require multiple MX records for redundancy:

Example (Google Workspace):

Priority    Mail Server
1           aspmx.l.google.com
5           alt1.aspmx.l.google.com
5           alt2.aspmx.l.google.com
10          alt3.aspmx.l.google.com
10          alt4.aspmx.l.google.com

Add each record separately following Step 3 process.

Step 5: Verify Record Entry

Before saving, double-check:

• ✅ Type is "MX" (not A, CNAME, or TXT)
• ✅ Priority matches documentation
• ✅ Mail server hostname is spelled correctly
• ✅ No typos in server name
• ✅ Trailing dot (if required by provider) is included or omitted correctly
• ✅ Name/Host is @ for root domain email

Common Entry Errors:

Wrong:

Type: A
Value: mail.example.com

Correct:

Type: MX
Priority: 10
Value: mail.example.com

Step 6: Save Changes

Click "Save," "Add Record," or equivalent button.

Most DNS providers show confirmation:

✓ MX record for example.com added successfully

Step 7: Wait for DNS Propagation

DNS changes don't take effect immediately:

Typical Propagation Times:

• Local DNS cache: 5-15 minutes
• Most DNS servers: 1-4 hours
• Full global propagation: 24-48 hours

During propagation:

• Some email may go to old servers (if still running)
• Some email may go to new servers
• This is normal and expected

Monitoring propagation:

• Use https://www.whatsmydns.net
• Enter your domain
• Select "MX" record type
• Check propagation across multiple locations

Google Workspace MX Records

Configuring MX records for Google Workspace (Gmail for business).

Google Workspace MX Configuration

Required MX Records:

Priority    Mail Server
1           aspmx.l.google.com
5           alt1.aspmx.l.google.com
5           alt2.aspmx.l.google.com
10          alt3.aspmx.l.google.com
10          alt4.aspmx.l.google.com

Step-by-Step Google Workspace Setup

Step 1: Access Google Admin Console

1. Log into https://admin.google.com
2. Go to "Apps" → "Google Workspace" → "Gmail"
3. Click "Activate Gmail"

Step 2: Get Your MX Records

1. Scroll to "Set up MX records"
2. Google provides exact records for your domain
3. Note all 5 MX records

Step 3: Remove Old MX Records

1. Log into your DNS provider
2. Delete all existing MX records
3. This prevents email going to old servers

Step 4: Add Google MX Records

Add each record with these exact values:

Record 1:

• Type: MX
• Name: @ (or blank)
• Mail server: aspmx.l.google.com
• Priority: 1
• TTL: 3600

Record 2:

• Type: MX
• Name: @
• Mail server: alt1.aspmx.l.google.com
• Priority: 5
• TTL: 3600

Record 3:

• Type: MX
• Name: @
• Mail server: alt2.aspmx.l.google.com
• Priority: 5
• TTL: 3600

Record 4:

• Type: MX
• Name: @
• Mail server: alt3.aspmx.l.google.com
• Priority: 10
• TTL: 3600

Record 5:

• Type: MX
• Name: @
• Mail server: alt4.aspmx.l.google.com
• Priority: 10
• TTL: 3600

Step 5: Verify in Google Admin

1. Return to Google Admin Console
2. Click "Activate Gmail"
3. Google verifies MX records automatically
4. May take up to 72 hours for verification

Additional Google Workspace DNS Records

SPF Record (Required):

Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com ~all

DKIM Setup (Recommended):

1. Google Admin → Apps → Gmail → Authenticate email
2. Generate new record
3. Add provided TXT record to DNS:

   Type: TXT
   Name: google._domainkey
   Value: v=DKIM1; k=rsa; p=MIGfMA0GCS... (from Google)
   

DMARC Record (Recommended):

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]

Testing Google Workspace Email

Send Test Email:

1. Send email to your domain: [email protected]
2. Check if received in Gmail
3. May take 15-30 minutes during propagation

Verify MX Records:

dig example.com MX
nslookup -type=MX example.com

Expected output:

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

Common Google Workspace Issues

Issue: Gmail not activated in Admin Console

• Solution: Navigate to Apps → Gmail → Activate Gmail before testing

Issue: MX records not verified after 72 hours

• Check records exactly match Google's specifications
• Ensure no typos in server hostnames
• Remove any old MX records still present
• Contact Google Workspace support

Issue: Some email received, some not

• DNS still propagating (wait up to 48 hours)
• Old MX records cached somewhere (will expire naturally)

Microsoft 365 MX Records

Configuring MX records for Microsoft 365 (Outlook/Exchange Online).

Microsoft 365 MX Configuration

Required MX Record:

Microsoft 365 uses a single MX record:

Priority: 0
Mail Server: yourdomain-com.mail.protection.outlook.com

Note: Replace "yourdomain-com" with your actual domain name (dashes replace dots).

Example:

• Domain: example.com
• MX Record: example-com.mail.protection.outlook.com

Step-by-Step Microsoft 365 Setup

Step 1: Access Microsoft 365 Admin Center

1. Log into https://admin.microsoft.com
2. Go to "Settings" → "Domains"
3. Select your domain

Step 2: Get Your Specific MX Record

1. Click "DNS records" or "Set up DNS"
2. Microsoft provides your exact MX record
3. Note the format: yourdomain-com.mail.protection.outlook.com

Step 3: Remove Old MX Records

1. Log into DNS provider
2. Delete all existing MX records
3. Ensures clean Microsoft 365 setup

Step 4: Add Microsoft 365 MX Record

Record Details:

• Type: MX
• Name: @ (or blank for root domain)
• Mail server: example-com.mail.protection.outlook.com
• Priority: 0
• TTL: 3600

Important: Microsoft 365 uses priority 0 (highest priority possible).

Step 5: Verify in Microsoft 365 Admin

1. Return to Admin Center → Domains
2. Click "Verify" or "Continue"
3. Microsoft checks MX record
4. Verification may take 15 minutes to 72 hours

Additional Microsoft 365 DNS Records

SPF Record (Required):

Type: TXT
Name: @
Value: v=spf1 include:spf.protection.outlook.com -all

Autodiscover CNAME (Required):

Type: CNAME
Name: autodiscover
Value: autodiscover.outlook.com

DKIM CNAMEs (Recommended):

Microsoft provides two CNAME records for DKIM:

Type: CNAME
Name: selector1._domainkey
Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Type: CNAME
Name: selector2._domainkey
Value: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

DMARC Record (Recommended):

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]

Testing Microsoft 365 Email

Send Test Email:

1. Send email to [email protected]
2. Check Outlook inbox
3. May take 30 minutes during propagation

Verify MX Record:

dig example.com MX

Expected output:

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

Common Microsoft 365 Issues

Issue: Wrong MX format

• Incorrect: example.com.mail.protection.outlook.com
• Correct: example-com.mail.protection.outlook.com (dashes replace dots)

Issue: Multiple MX records when only one needed

• Microsoft 365 only needs one MX record
• Remove additional MX records
• Priority should be 0

Issue: Autodiscover not working

• Ensure autodiscover CNAME record added
• Required for Outlook client configuration
• Format: autodiscover.outlook.com (no trailing dot needed)

Custom Mail Server MX Records

Configuring MX records for self-hosted or custom mail servers.

Custom Mail Server Requirements

Before configuring MX records, ensure your mail server:

1. Has a static IP address (dynamic IPs don't work for mail servers)
2. Hostname resolves to IP (A record exists)
3. Reverse DNS (PTR) configured (IP resolves back to hostname)
4. Port 25 open (incoming SMTP connections)
5. Valid SSL/TLS certificate (for encrypted connections)
6. Proper mail server software (Postfix, Exim, Exchange, etc.)

Step 1: Create A Record for Mail Server

Your mail server needs an A record:

mail.example.com.    A    203.0.113.1

DNS Configuration:

• Type: A
• Name: mail (or your chosen hostname)
• Value: 203.0.113.1 (your mail server IP)
• TTL: 3600

Step 2: Configure Reverse DNS (PTR Record)

PTR records are configured by your IP provider (hosting company, ISP):

1.113.0.203.in-addr.arpa.    PTR    mail.example.com.

How to Set Up PTR:

1. Contact your hosting provider or ISP
2. Request PTR record pointing to your mail hostname
3. Provide: IP address and desired hostname

Why PTR is Critical:

• Major email providers (Gmail, Outlook) check PTR records
• Missing or mismatched PTR = email marked as spam
• FCrDNS (Forward-Confirmed reverse DNS) required for deliverability

Step 3: Add MX Records

Single Mail Server:

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

Primary and Backup Configuration:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Add in DNS:

• Type: MX
• Name: @
• Mail server: mail.example.com
• Priority: 10
• TTL: 3600

Step 4: Configure SPF Record

SPF authorizes your mail server:

Type: TXT
Name: @
Value: v=spf1 a mx ip4:203.0.113.1 -all

Explanation:

• a: Authorize IPs from A record
• mx: Authorize IPs from MX records
• ip4:203.0.113.1: Explicitly authorize this IP
• -all: Reject email from other sources

Step 5: Set Up DKIM

Generate DKIM keys on your mail server:

Using OpenDKIM (Linux):

opendkim-genkey -b 2048 -d example.com -s mail

This creates:

• mail.private: Private key (keep on server)
• mail.txt: Public key (publish in DNS)

Add DKIM DNS Record:

Type: TXT
Name: mail._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... (from mail.txt)

Step 6: Implement DMARC

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]

Complete Custom Mail Server DNS Configuration

Example complete setup:

# Mail server A record
mail.example.com.                A       203.0.113.1

# MX records (primary and backup)
example.com.                     MX  10  mail.example.com.
example.com.                     MX  20  backup.example.com.

# SPF record
example.com.                     TXT     "v=spf1 mx ip4:203.0.113.1 -all"

# DKIM record
mail._domainkey.example.com.     TXT     "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC record
_dmarc.example.com.              TXT     "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Testing Custom Mail Server

Test Mail Server Connectivity:

telnet mail.example.com 25

Expected response:

220 mail.example.com ESMTP

Test MX Records:

dig example.com MX

Test Reverse DNS:

dig -x 203.0.113.1

Send Test Email: Use https://www.mail-tester.com

1. Send email to provided address
2. Review score and diagnostics
3. Fix any reported issues

Common Custom Mail Server Issues

Issue: Email marked as spam

• Check PTR record matches forward DNS
• Verify SPF, DKIM, DMARC configured
• Ensure IP not on blacklists (check MXToolbox)

Issue: Port 25 blocked

• Many ISPs block port 25 for residential connections
• Use business hosting with port 25 open
• Or use mail relay service

Issue: SSL certificate errors

• Obtain valid SSL certificate for mail hostname
• Use Let's Encrypt for free certificates
• Certificate hostname must match mail server hostname

Popular Email Providers MX Settings

Quick reference for common email hosting services.

Zoho Mail

MX Records:

Priority: 10    Mail Server: mx.zoho.com
Priority: 20    Mail Server: mx2.zoho.com
Priority: 50    Mail Server: mx3.zoho.com

SPF:

v=spf1 include:zoho.com ~all

DKIM: Configured in Zoho admin panel Documentation: https://www.zoho.com/mail/help/adminconsole/configure-email-delivery.html

ProtonMail

MX Records:

Priority: 10    Mail Server: mail.protonmail.ch
Priority: 20    Mail Server: mailsec.protonmail.ch

SPF:

v=spf1 include:_spf.protonmail.ch ~all

DMARC and DKIM: Configured in ProtonMail settings Documentation: https://protonmail.com/support/knowledge-base/dns-records/

Fastmail

MX Records:

Priority: 10    Mail Server: in1-smtp.messagingengine.com
Priority: 20    Mail Server: in2-smtp.messagingengine.com

SPF:

v=spf1 include:spf.messagingengine.com ~all

Documentation: https://www.fastmail.help/hc/en-us/articles/1500000280261

Amazon WorkMail

MX Records:

Priority: 10    Mail Server: inbound-smtp.region.amazonaws.com

Replace "region" with your AWS region (e.g., us-east-1).

SPF:

v=spf1 include:amazonses.com ~all

Documentation: https://docs.aws.amazon.com/workmail/latest/adminguide/add-domain.html

Rackspace Email

MX Records:

Priority: 10    Mail Server: mx1.emailsrvr.com
Priority: 20    Mail Server: mx2.emailsrvr.com

SPF:

v=spf1 include:emailsrvr.com ~all

Documentation: https://docs.rackspace.com/support/how-to/

ImprovMX (Free Email Forwarding)

MX Records:

Priority: 10    Mail Server: mx1.improvmx.com
Priority: 20    Mail Server: mx2.improvmx.com

Note: ImprovMX is forwarding only (receiving and forwarding to existing email).

Documentation: https://improvmx.com/guides/

Testing MX Records

Verify your MX configuration is working correctly.

Command Line Testing

Check MX Records (Linux/Mac):

dig example.com MX

# Or use nslookup
nslookup -type=MX example.com

Expected Output:

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

Check MX Records (Windows):

nslookup -type=MX example.com

Online MX Testing Tools

MXToolbox (https://mxtoolbox.com)

1. Visit https://mxtoolbox.com/MXLookup.aspx
2. Enter your domain
3. Review MX records and configuration
4. Check for warnings or errors

What MXToolbox checks:

• MX records exist and are valid
• Mail servers have A records
• Reverse DNS (PTR) configured
• Mail server connectivity (port 25)
• Potential blacklist issues

Google Admin Toolbox

1. Visit https://toolbox.googleapps.com/apps/checkmx/
2. Enter your domain
3. View comprehensive DNS and email configuration
4. Identifies issues with MX, SPF, DMARC

IntoDNS (https://intodns.com)

• Comprehensive DNS health check
• Tests MX records, SPF, nameservers
• Provides detailed explanations of issues

Send Test Email

Manual Test:

1. Send email from external address (Gmail, Outlook, etc.)
2. Send to address at your domain: [email protected]
3. Verify email arrives in your mailbox
4. Check timing (immediate or delayed indicates issues)

Automated Testing:

Mail-Tester (https://www.mail-tester.com)

1. Get unique test address from mail-tester.com
2. Send email from your domain to test address
3. Review score and diagnostic report
4. Includes MX, SPF, DKIM, DMARC, blacklist checks

Port25 Verifier

• Send email to: [email protected]
• Receive detailed authentication report via reply
• Shows MX, SPF, DKIM, DMARC results

Checking DNS Propagation

WhatsmyDNS (https://www.whatsmydns.net)

1. Enter your domain
2. Select "MX" record type
3. View propagation across global DNS servers
4. Green checkmarks indicate propagation complete

Propagation Checklist:

• ✅ Records visible in multiple locations (50%+)
• ✅ Same records returned from different DNS servers
• ✅ No old MX records still appearing
• ✅ Complete propagation typically 24-48 hours

Testing Mail Server Connectivity

Telnet Test:

telnet mail.example.com 25

Expected Response:

Trying 192.0.2.1...
Connected to mail.example.com.
220 mail.example.com ESMTP Postfix

Type quit to exit.

What This Tests:

• Mail server is running
• Port 25 is open
• Server accepts connections
• Server responds with valid SMTP greeting

If Connection Fails:

• Mail server may be down
• Port 25 blocked by firewall
• Incorrect hostname or IP in MX record

Checking Email Headers

After receiving test email, view headers:

Gmail:

1. Open email
2. Click three dots (⋮)
3. Select "Show original"
4. Review Received headers and authentication

Look For:

Received: from mail.example.com (mail.example.com [192.0.2.1])
Authentication-Results:
    mx.google.com;
    spf=pass smtp.mailfrom=example.com;
    dmarc=pass

Headers Show:

• Which MX record was used
• Mail server that delivered message
• Authentication results (SPF, DKIM, DMARC)
• Delivery path and timing

Common MX Record Mistakes

Avoid these frequent configuration errors.

Mistake 1: MX Pointing to CNAME

Incorrect:

example.com.        MX    10    mail.example.com.
mail.example.com.   CNAME     server.hosting.com.

Why It's Wrong:

• RFC 2181 prohibits MX records pointing to CNAMEs
• Some mail servers reject this configuration
• May cause delivery failures

Correct:

example.com.        MX    10    mail.example.com.
mail.example.com.   A         192.0.2.1

MX must point to A or AAAA records, never CNAMEs.

Mistake 2: MX Pointing to IP Address

Incorrect:

example.com.    MX    10    192.0.2.1

Why It's Wrong:

• MX records must point to hostnames, not IPs
• Protocol violation (RFC 5321)
• Will be rejected by many mail servers

Correct:

example.com.        MX    10    mail.example.com.
mail.example.com.   A         192.0.2.1

Mistake 3: Missing A Record for Mail Server

Incorrect:

example.com.    MX    10    mail.example.com.
# (No A record for mail.example.com)

Why It's Wrong:

• Mail server hostname must resolve to IP
• Senders cannot connect without IP address
• All email delivery fails

Correct:

example.com.        MX    10    mail.example.com.
mail.example.com.   A         192.0.2.1

Mistake 4: Wrong Priority Values

Incorrect:

example.com.    MX    10    primary.example.com.
example.com.    MX    5     backup.example.com.

Why It's Wrong:

• Backup has priority 5 (higher priority than primary)
• Backup will be tried first
• Primary will only be used if backup fails

Correct:

example.com.    MX    10    primary.example.com.
example.com.    MX    20    backup.example.com.

Remember: Lower number = higher priority.

Mistake 5: Typos in Mail Server Hostname

Incorrect:

example.com.    MX    10    mal.example.com.

Why It's Wrong:

• Typo: "mal" instead of "mail"
• Hostname doesn't exist
• All email delivery fails

Prevention:

• Copy/paste hostnames from documentation
• Use DNS validation tools
• Test after configuration

Mistake 6: Forgetting Trailing Dot

Context-Dependent Issue:

Some DNS providers require trailing dot for FQDN:

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

Others automatically append your domain:

# In DNS panel, you might enter just:
mail    MX    10    mail.example.com
# Provider appends .example.com making it:
mail.example.com    MX    10    mail.example.com.example.com  (Wrong!)

Solution:

• Read your DNS provider's documentation
• Use @ or blank for root domain
• Use fully qualified names when required
• Test after adding records

Mistake 7: Multiple MX Records When One Needed

Issue (Microsoft 365 Example):

example.com.    MX    10    example-com.mail.protection.outlook.com.
example.com.    MX    20    backup-mail.example.com.

Why It's Problematic:

• Microsoft 365 should be only MX record
• Backup MX receives some email
• Email split between Microsoft 365 and other server
• Users miss emails going to wrong server

Correct:

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

Remove all other MX records.

Mistake 8: Old MX Records Not Removed

Issue:

# Old mail server
example.com.    MX    10    oldmail.example.com.
# New mail server
example.com.    MX    5     newmail.example.com.

Why It's Wrong:

• Some email still delivered to old server
• Users missing emails
• Inconsistent delivery during transition

Correct:

# Remove old record, keep only new
example.com.    MX    10    newmail.example.com.

Mistake 9: No Backup MX Records

Insufficient:

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

Why It's Risky:

• Single point of failure
• If mail server down, email bounces or is queued
• No redundancy for maintenance or outages

Better:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Mistake 10: Wrong TTL During Migration

Issue:

• High TTL (86400 = 24 hours)
• DNS changes take long to propagate
• Extended transition period

Best Practice:

• Lower TTL to 300-600 before changes
• Wait for old TTL to expire
• Make changes
• Raise TTL after verification

Troubleshooting MX Record Issues

Solutions for common MX record problems.

Problem: Email Not Received

Symptoms:

• Senders receive bounce messages
• Email never arrives
• No messages in spam folder

Diagnostic Steps:

1. Verify MX Records Exist:

dig example.com MX

If no results, MX records aren't published.

2. Check MX Points to Valid Hostname:

dig mail.example.com A

Must return IP address.

3. Test Mail Server Connectivity:

telnet mail.example.com 25

Should connect and show SMTP banner.

Solutions:

• No MX records: Add MX records following provider documentation
• MX hostname doesn't resolve: Add A record for mail server
• Can't connect to mail server: Check firewall, ensure server running

Problem: Some Email Received, Some Not

Symptoms:

• Intermittent delivery
• Some senders successful, others fail
• Inconsistent behavior

Likely Causes:

1. DNS Propagation Incomplete:

• Some DNS servers have new records
• Some DNS servers have old records
• Resolves naturally after 24-48 hours

Check Propagation:

https://www.whatsmydns.net - check MX records globally

2. Multiple MX Records with Conflicts:

• Old and new MX records coexist
• Email split between servers

Solution:

• Remove old MX records
• Keep only current mail server MX records

3. SPF Authentication Failures:

• MX records correct but SPF blocks legitimate senders

Check SPF:

dig example.com TXT | grep spf

Ensure SPF includes all legitimate mail servers.

Problem: Bounce Messages About MX Record

Common Bounce Messages:

"No MX or A records for domain"

• Meaning: Domain has no MX records
• Solution: Add MX records

"Host not found"

• Meaning: MX record points to non-existent hostname
• Solution: Verify mail server hostname, add A record

"Connection refused"

• Meaning: Mail server not accepting connections
• Solution: Check mail server is running, port 25 open

"Temporary DNS failure"

• Meaning: DNS lookup failed temporarily
• Solution: Usually resolves automatically, retry later

Problem: Email Goes to Spam

Symptoms:

• Email delivered but marked as spam
• Not an MX issue, but related to email authentication

Check:

1. Reverse DNS (PTR Record):

dig -x 192.0.2.1  # Your mail server IP

Should return your mail server hostname.

2. SPF Record:

dig example.com TXT | grep spf

Should authorize your mail server.

3. DKIM Configuration:

dig selector._domainkey.example.com TXT

Should return DKIM public key.

4. DMARC Policy:

dig _dmarc.example.com TXT

Should have DMARC policy.

5. Blacklists: Check https://mxtoolbox.com/blacklists.aspx See if your mail server IP is blacklisted.

Problem: MX Priority Ignored

Symptoms:

• Backup server receiving email instead of primary
• Wrong server handling email

Causes:

1. Swapped Priorities:

# Wrong
example.com.    MX    20    primary.example.com.
example.com.    MX    10    backup.example.com.

Lower number is higher priority—backup tried first.

Solution: Swap priority values.

2. Primary Server Down:

• Sending servers follow priority order
• If primary fails, try backup
• May appear as "priority ignored" but working correctly

Verify Server Status:

telnet primary.example.com 25

Problem: DNS Changes Not Taking Effect

Symptoms:

• Updated MX records hours ago
• Old records still returned by DNS queries
• Email still going to old server

Causes:

1. TTL Not Expired:

• Old records cached based on previous TTL
• If old TTL was 86400 (24 hours), must wait 24 hours

Solution: Wait for TTL expiration, or lower TTL before future changes.

2. Local DNS Cache:

# Flush DNS cache (Mac)
sudo dscacheutil -flushcache

# Flush DNS cache (Windows)
ipconfig /flushdns

# Flush DNS cache (Linux)
sudo systemd-resolve --flush-caches

3. Changed at Wrong Location:

• DNS changes made at old DNS provider
• Domain now uses different nameservers

Verify Current Nameservers:

dig example.com NS

Ensure DNS changes made at current DNS host.

Best Practices for MX Records

1. Always Use Backup MX Records

Minimum Configuration:

example.com.    MX    10    primary.example.com.
example.com.    MX    20    backup.example.com.

Benefits:

• Redundancy during outages
• No lost email during maintenance
• Better deliverability reputation

2. Use Proper Priority Spacing

Good:

MX    10    primary.example.com.
MX    20    secondary.example.com.
MX    30    backup.example.com.

Why:

• Allows inserting new servers between priorities
• Clear priority hierarchy
• Easy to adjust later

3. Point MX to A Records, Not CNAMEs

Correct:

example.com.        MX    10    mail.example.com.
mail.example.com.   A         192.0.2.1

Avoid:

example.com.        MX    10    mail.example.com.
mail.example.com.   CNAME     server.host.com.

4. Set Appropriate TTL

During Changes:

• TTL: 300-600 (5-10 minutes)
• Speeds up propagation

Normal Operation:

• TTL: 3600-86400 (1-24 hours)
• Reduces DNS query load

5. Implement Email Authentication

Required DNS Records:

• ✅ MX records (email delivery)
• ✅ SPF record (sender authorization)
• ✅ DKIM record (message signing)
• ✅ DMARC record (policy enforcement)

Complete authentication improves deliverability.

6. Document Your Configuration

Maintain records of:

• Current MX configuration
• Priority values and reasoning
• Mail server purposes (primary, backup, etc.)
• Date of last change
• Provider contacts

7. Test Before and After Changes

Before:

• Verify current configuration working
• Document existing setup
• Lower TTL 24 hours in advance

After:

• Use MXToolbox to verify records
• Send test emails
• Monitor email delivery for 48 hours

8. Monitor MX Records

Regular Checks:

• Verify MX records monthly
• Check for unauthorized changes
• Ensure mail servers operational
• Review DNS provider security

Automated Monitoring:

• Use domain monitoring service
• Set alerts for MX record changes
• Monitor mail server uptime

9. Keep A and MX Records Synchronized

If mail server IP changes:

1. Update A record for mail.example.com
2. No need to change MX record (still points to hostname)
3. Verify connectivity after change

Advantage of hostname-based MX:

• Change IPs without touching MX records
• Cleaner migrations
• Less potential for errors

10. Plan for Migrations

Transition Strategy:

1. Lower TTL 48 hours before migration
2. Add new MX records with lower priority
3. Test new mail server
4. Swap priorities (new becomes primary)
5. Monitor for 48 hours
6. Remove old MX records
7. Raise TTL back to normal

This ensures zero downtime and no lost email.

Frequently Asked Questions

What are MX records and why do I need them?

MX (Mail Exchange) records tell email servers where to deliver email for your domain. Without MX records, email sent to addresses at your domain ([email protected]) will bounce with "no mail server found" errors. MX records are required for receiving email—they're not optional. Even if you don't currently use email at your domain, you should configure MX records if you plan to in the future.

How long does it take for MX record changes to take effect?

MX record changes take 1-48 hours for complete global propagation, depending on TTL (Time To Live) values. Most users will see changes within 1-4 hours. Lower TTL values (300-600 seconds) before making changes to speed up propagation. During propagation, some email may be delivered to old servers while other email goes to new servers—this is normal and temporary.

Can I have multiple MX records?

Yes, and it's recommended. Multiple MX records provide redundancy and load balancing. Use different priority values to define which server is tried first (lower number = higher priority). For example, priority 10 is tried before priority 20. Servers with the same priority are selected randomly, distributing load. Most email setups have 2-5 MX records for reliability.

Do MX records affect sending email or just receiving?

MX records only affect receiving email at your domain. They tell other mail servers where to deliver incoming messages. Sending email requires SMTP server configuration on your mail server and email authentication (SPF, DKIM, DMARC) but doesn't use MX records. When you send email, your mail server connects directly to the recipient's MX records.

What's the difference between priority 0 and priority 10?

Priority values determine the order mail servers are tried—lower numbers mean higher priority. Priority 0 is the highest possible priority, while priority 10 is tried after priority 0 but before priority 20. The absolute values don't matter, only relative order. Microsoft 365 uses priority 0 for their single MX record. Most other providers use priority 10 for primary servers. Use gaps (10, 20, 30) to allow inserting new servers between existing priorities later.

Can I point MX records to my website domain?

Technically you could point MX records to your website domain, but it's not recommended. Typically, websites and mail servers run on different servers with different IPs. Best practice is using a dedicated hostname like mail.example.com for mail servers. This allows independent management of web and email infrastructure and clearer separation of services.

What happens if my mail server is down?

If your primary mail server is down and you have backup MX records configured, sending mail servers automatically try the backup server. This provides continued email delivery during outages. Without backup MX records, senders will receive temporary failure messages and their servers will queue the email to retry later (usually for 24-48 hours before giving up).

Do I need to remove old MX records when migrating email providers?

Yes, you should remove old MX records when migrating to a new email provider. Having MX records for both old and new providers causes email to be split between them—some messages go to the old server, some to the new one. This results in users missing emails. Best practice: keep old mail server running during DNS propagation (24-48 hours), then shut down old server and remove its MX records.

Can subdomains have different MX records than the main domain?

Yes, subdomains can have completely separate MX records. For example, example.com and mail.example.com can each have their own MX records pointing to different mail servers. This allows different departments or services to use separate email infrastructure. If a subdomain has no MX record, email will fall back to the parent domain's MX records.

Why does MXToolbox show warnings about my MX configuration?

Common MXToolbox warnings include: reverse DNS (PTR) not configured, mail server in blacklist, no backup MX records, or very high TTL values. Most warnings indicate potential deliverability issues rather than complete failures. Address warnings about PTR records and blacklists immediately, as these significantly impact email reputation. Backup MX warnings are advisable to fix for redundancy but won't prevent email delivery.

Key Takeaways

• MX records specify mail servers that receive email for your domain
• Priority values determine order with lower numbers tried first (10 before 20)
• MX records must point to hostnames (A or AAAA records), never IP addresses or CNAMEs
• Multiple MX records provide redundancy protecting against mail server outages
• Google Workspace requires 5 MX records with specific priorities and hostnames
• Microsoft 365 uses single MX record with priority 0 and unique hostname format
• DNS propagation takes 24-48 hours plan migrations with this timeline in mind
• Lower TTL before changes speeds up propagation when updating MX records
• Test MX records after configuration using dig, MXToolbox, and test emails
• Email authentication is separate but related—configure SPF, DKIM, and DMARC alongside MX
• Backup MX records are essential for professional email reliability
• Document your MX configuration for troubleshooting and future maintenance

Next Steps

Configure Your MX Records

1. Choose Your Email Provider

   • Google Workspace for Gmail-based business email
   • Microsoft 365 for Outlook/Exchange Online
   • Custom mail server for full control
   • Third-party email hosting for affordable options

2. Gather Required Information

   • Mail server hostnames from provider
   • Priority values for each MX record
   • Access to DNS management
   • Additional required DNS records (SPF, DKIM)

3. Lower TTL 48 Hours Before Changes

   • Change TTL to 300-600 seconds
   • Wait for old TTL to expire
   • Ensures faster propagation during actual changes

4. Add MX Records

   • Remove old MX records (if any)
   • Add all required MX records
   • Verify no typos in hostnames
   • Save and verify in DNS panel

5. Wait for Propagation

   • Monitor propagation with whatsmydns.net
   • Test MX records with dig or MXToolbox
   • Send test emails to verify delivery
   • Wait 24-48 hours for full propagation

6. Configure Email Authentication

   • Add SPF record authorizing mail servers
   • Set up DKIM with cryptographic signing
   • Implement DMARC with monitoring policy
   • Test authentication with mail-tester.com

7. Monitor and Maintain

   • Review MX records quarterly
   • Check mail server connectivity
   • Monitor for DNS changes
   • Update when adding email services

Monitor Your Domain with DomainDetails Pro

Upgrade to DomainDetails Pro for advanced DNS and email monitoring:

• Automatic MX record monitoring - Track changes to your mail server configuration
• Email deliverability tracking - Monitor SPF, DKIM, and DMARC records
• Change history - See when DNS records were modified and by whom
• Email alerts - Get notified immediately of MX record or DNS issues
• Bulk domain monitoring - Track MX records across entire domain portfolio
• Export reports - Download MX and email configuration data for audits

Start Your Free Trial →

Related Articles

• Understanding DMARC, SPF, and DKIM for Email
• Setting Up Email with Your Domain
• DNS Record Types Explained
• How to Change Nameservers

Research Sources

1. RFC 5321 - Simple Mail Transfer Protocol (SMTP)
2. RFC 1035 - Domain Names - Implementation and Specification
3. RFC 2181 - Clarifications to the DNS Specification
4. RFC 974 - Mail Routing and the Domain System
5. Google Workspace MX Record Documentation - https://support.google.com/a/answer/140034
6. Microsoft 365 MX Record Setup - https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider
7. IETF MX Record Best Practices - https://datatracker.ietf.org/doc/html/rfc5321
8. DNS OARC MX Record Guidelines - https://www.dns-oarc.net/
9. MXToolbox Email Delivery Resources - https://mxtoolbox.com/emailhealth
10. ICANN DNS Best Current Practices - https://www.icann.org/resources/pages/dns-best-practices