MX Record Configuration: Fix Email Delivery Issues (Step by Step)

What Is an MX Record?

An MX (Mail Exchanger) record is a DNS record that tells the internet which mail servers accept email for your domain. When someone sends an email to user@example.com, the sending mail server performs a DNS lookup for example.com's MX records, connects to the listed mail server(s), and delivers the message.

MX records have two components:

• Priority (preference): A number where lower = higher priority. If the primary server is unavailable, the sending server falls back to the next lowest priority.
• Mail server hostname: The fully qualified domain name (FQDN) of the mail server. This must resolve to an IP address via an A or AAAA record.

An MX record must point to a hostname, never directly to an IP address. The hostname must have its own A record. Pointing MX records to a CNAME is technically invalid per RFC 2181 and will cause delivery failures with some sending servers.

MX Record Format

# DNS zone file format
# NAME    TTL  CLASS  TYPE  PRIORITY  MAIL-SERVER
example.com.  3600  IN  MX  10  mail.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

# In most DNS control panels, you just enter:
# Host: @  (or leave blank for the root domain)
# Priority: 10
# Value: mail.example.com

Google Workspace MX Records

To receive email at Google Workspace (formerly G Suite), add these five MX records to your domain. Remove any existing MX records first.

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.

The multiple entries provide redundancy. If ASPMX.L.GOOGLE.COM is unreachable, sending servers fall back to the ALT records. All five servers are managed by Google - do not modify the priority values.

Microsoft 365 (Exchange Online) MX Records

Microsoft 365 uses a single MX record with a domain-specific subdomain. Your exact value is shown in the Microsoft 365 admin center under Domains.

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

Replace yourdomain-com with your domain (with hyphens replacing dots). For example, if your domain is contoso.com, the MX value is contoso-com.mail.protection.outlook.com. Microsoft assigns priority 0 (highest), but some control panels require a non-zero value - use 10 if 0 is not accepted.

Custom / Self-Hosted Mail Server

If you run your own Postfix, Exim, or other mail server:

# Single mail server
Priority  Mail Server
10        mail.example.com.

# Primary + backup (secondary MX)
Priority  Mail Server
10        mail.example.com.       (primary)
20        mail2.example.com.      (backup - receives mail if primary is down)

# The mail server hostname must have an A record
mail.example.com.   IN  A  203.0.113.10
mail2.example.com.  IN  A  203.0.113.11

When running your own server, also ensure:

• Port 25 (SMTP) is open inbound on your firewall and not blocked by your cloud provider (AWS, for example, blocks outbound port 25 by default on EC2)
• Reverse DNS (PTR record) for your server's IP resolves to your mail server's hostname - many receiving servers reject mail from IPs without matching PTR records
• Your IP is not on a blocklist - check MXToolbox Blacklist Checker

Step-by-Step: Setting Up MX Records

1. Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, Namecheap, etc.).
2. Navigate to DNS settings for your domain.
3. Delete any existing MX records for the root domain (@ or blank host). Having old records alongside new ones causes delivery failures.
4. Add the new MX records one by one, entering the priority and mail server hostname for each.
5. Set TTL to 3600 (1 hour). During initial setup, use 300 (5 minutes) so you can correct mistakes quickly.
6. Save changes and wait for propagation (typically 5 minutes to 48 hours, depending on your existing TTL).
7. Verify propagation using our DNS Lookup tool or dig example.com MX.
8. Send a test email to check-auth@verifier.port25.com to verify SPF, DKIM, and DMARC alignment.

Essential Supporting DNS Records for Email

MX records only control inbound delivery. For outbound email to actually reach inboxes instead of spam folders, you need three additional record types.

SPF (Sender Policy Framework)

SPF is a TXT record that lists which servers are authorized to send email for your domain. Receiving servers check this to detect spoofing.

# Google Workspace SPF
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

# Microsoft 365 SPF
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Custom server + Google Workspace
example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

SPF qualifiers: -all (hard fail - reject), ~all (soft fail - mark as suspicious), ?all (neutral), +all (pass all - never use this). Use -all for maximum security once you have identified all your sending sources.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. Receiving servers verify the signature against a public key published in your DNS. Setup is provider-specific:

# DKIM TXT record format
# selector._domainkey.example.com
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The selector (google in this example) and the public key value are provided by your mail provider after you generate a DKIM key pair in their admin console.

DMARC (Domain-based Message Authentication)

DMARC tells receiving servers what to do when SPF or DKIM fail, and sends you reports about authentication results. It is the final layer of email security.

# Monitor only (safe starting policy)
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

# Quarantine (move to spam on failure)
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"

# Reject (block on failure - most secure)
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com"

Start with p=none to monitor without affecting delivery. Analyze the reports (sent to the rua address) to confirm all your legitimate sending sources pass SPF/DKIM, then move to p=quarantine and eventually p=reject.

Verifying Your MX Configuration

# Check MX records
dig example.com MX +short

# Check SPF record
dig example.com TXT +short | grep spf

# Check DMARC record
dig _dmarc.example.com TXT +short

# Check DKIM record
dig google._domainkey.example.com TXT +short

# Test full email authentication (send a test message)
# The response email shows SPF, DKIM, and DMARC results
echo "Test" | mail -s "Auth test" check-auth@verifier.port25.com

Frequently Asked Questions

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

Propagation time depends on the TTL of the record being replaced. If the old MX record had a TTL of 86400 (24 hours), resolvers that cached it will use the old value for up to 24 hours. The practical fix: before making changes, reduce your TTL to 300 (5 minutes) and wait 24 hours for the lower TTL to propagate. Then make your changes - new resolvers will pick up updates within 5 minutes. After confirming everything works, raise the TTL back to 3600.

Do I need multiple MX records?

For Google Workspace and Microsoft 365, yes - they provide multiple records for redundancy and you should add all of them. For a self-hosted server, one MX record is technically sufficient, but a secondary MX with a backup server protects you during downtime. If no secondary MX is configured and your primary server is unreachable, sending servers will retry for 4–5 days before bouncing the message.

Can I use a CNAME as an MX record value?

No. RFC 2181 explicitly prohibits MX records from pointing to CNAMEs. The MX value must be an A or AAAA record. Some DNS providers will silently allow CNAME values but this causes intermittent delivery failures because many SMTP servers correctly reject CNAME targets. Always use a direct hostname that has its own A record.

Why is my email going to spam even though MX records are correct?

MX records only control receipt. Spam placement depends on outbound authentication. Check: (1) SPF record exists and includes all your sending IPs, (2) DKIM is configured and signatures are valid, (3) DMARC policy is set, (4) your sending IP is not on any blocklist, (5) your email content and sending patterns are not triggering spam filters. Use check-auth@verifier.port25.com to get a full authentication report.

What happens if I have conflicting MX records from two different mail providers?

Sending servers use all MX records and deliver to whichever server accepts the connection, starting from the lowest priority number. If you have MX records pointing to both Google Workspace and your old provider, some mail will go to Google and some will go to the old server - resulting in split delivery where users miss emails. Always remove old MX records before adding new ones. Never run two providers simultaneously.

Use our free tool here → DNS Lookup to verify your MX, SPF, DKIM, and DMARC records from any browser in seconds.