📧 MX Priority · Redundancy · TTL · Email Delivery · Analysis

MX Priority Optimizer

Free MX record priority checker. Look up any domain's MX records, analyze priority configuration and redundancy, identify delivery risks, and get actionable recommendations.

✓ Priority analysis✓ Redundancy check✓ TTL review✓ Fix recommendations✓ No signup

Enter a domain to analyze its MX record priority configuration

What this tool does

Free MX priority optimizer: analyse MX record priorities, redundancy, TTL values, and email delivery configuration

How MX priorities work, why correct configuration matters for email reliability, and what this analyser checks

This MX priority optimizer performs a live DNS lookup and health analysis on any domain's MX records. MX (Mail Exchanger) records, defined in RFC 1035, tell the internet which servers are authorised to receive email for a domain. The priority number on each record controls delivery order. Lower numbers are tried first. Correct priority configuration ensures that if the primary mail server is unavailable, email is automatically routed to a backup rather than bouncing. This tool checks whether that configuration is correctly set up and flags every gap with a specific fix recommendation.

Beyond priorities, this analyser checks TTL (Time to Live) values on each record. TTL controls how long DNS resolvers cache the record before querying for a fresh value. Very short TTLs generate excessive DNS queries and can slow resolution; very long TTLs make DNS changes propagate slowly when you need to migrate or update your mail server. The recommended value under normal operation is 3600 seconds (one hour). The analyser also identifies the email provider from the exchange hostnames. Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, SendGrid, Mailgun, and Amazon SES are all detected automatically.

This tool is specifically focused on the priority and redundancy configuration of MX records. For a broader one-pass domain audit covering MX, SPF, DMARC, and DKIM in a single scored check, use the Email Health Checker.

What this tool checks

Priority Analysis

Detects whether priorities are correctly differentiated between primary and backup servers, or accidentally set equal.

Redundancy Check

Warns when only a single MX record exists. Meaning no fallback if the primary server is unavailable.

TTL Review

Flags TTL values below 300s (too short, excessive DNS load) or above 86400s (too long, slow migration propagation).

Provider Detection

Identifies Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, SendGrid, Mailgun, and Amazon SES.

Fix Recommendations

Every detected issue includes a specific, actionable recommendation explaining the correct configuration.

Live DNS Query

Uses Cloudflare DoH for accurate real-time results. Shows the current live state, not cached data.

Why it matters

Why MX priority configuration matters for email reliability and delivery

MX priority configuration is one of those infrastructure details that works silently when correct and causes painful, hard-to-diagnose failures when wrong. A domain with a single MX record and no backup has a single point of failure for all inbound email. A server outage, a network incident, or even a planned maintenance window means email from every sender queues and eventually bounces if the outage exceeds the sender's retry window (typically 4-5 days per RFC 5321, but some senders give up sooner). For business-critical domains, where a customer reply, an invoice, or a support ticket could be silently lost, this is not an acceptable risk.

Equal-priority records are a subtler problem. When two MX records have the same priority number, sending servers distribute traffic across them randomly. This is the correct behaviour for load-balanced equivalent servers, but it is a silent misconfiguration when one server is intended as a backup. If the intended backup server is not fully provisioned to accept mail, because it was set up quickly as a placeholder or has not been fully configured, randomly routing half your inbound traffic to it causes intermittent delivery failures that are difficult to trace. The analyser flags equal priorities specifically because this pattern is more often an error than an intentional load-balancing decision.

TTL values have a direct impact on how quickly you can respond to mail server problems. If your MX record has a TTL of 86400 seconds (24 hours) and your primary mail server fails, it will take up to 24 hours for changes to your MX records to propagate globally. Meaning every sending server in the world will continue attempting to deliver to the failed server for up to a day. Keeping TTL values at 3600 seconds normally, and reducing them to 300 seconds before planned maintenance, gives you control over your blast radius. Proactively checking TTL values before you have a problem is exactly what this analyser enables.

For domains used exclusively for non-email purposes, parked domains, subdomain-only web services, acquired brand domains, the correct MX configuration is a null MX record (priority 0, exchange '.') rather than no MX record at all. A null MX explicitly tells senders the domain accepts no email, preventing fallback delivery attempts to the A record. Combined with SPF v=spf1 -all and DMARC p=reject, a null MX fully locks down a non-sending domain. This analyser surfaces domains with no MX records and recommends publishing a null MX where appropriate.

Troubleshooting

Common MX priority problems: causes and fixes

Most MX priority issues trace to one of a small number of root causes. Here is what each one means and how to resolve it.

Only one MX record found. No redundancy

Why it happens: A single MX record means no failover if the primary mail server is unavailable. For Google Workspace, this usually means the other four MX records were never published. For Microsoft 365, a single record is actually correct. See FAQ below.

Fix: For Google Workspace: publish all five required MX records (ASPMX.L.GOOGLE.COM at priority 1, ALT1 and ALT2 at priority 5, ALT3 and ALT4 at priority 10). For self-hosted mail: add a secondary MX record pointing to a backup server at a higher priority number (e.g. if the primary is priority 10, set the backup at priority 20). For Microsoft 365: one record is correct. Disregard this warning if your provider is M365.

All MX records have the same priority number

Why it happens: Equal priorities cause random distribution across all servers. This is intentional for load-balanced equivalent servers but is a misconfiguration if one server is meant to be the primary and another a backup.

Fix: If you intend to have a primary and a backup server, assign them different priority numbers. For example, primary at 10 and backup at 20. If you are intentionally load-balancing across equal servers, this warning can be disregarded. Confirm the equal-priority setup is intentional and all listed servers are fully provisioned to accept mail.

TTL is very short (under 300 seconds)

Why it happens: A TTL below 300 seconds causes DNS resolvers to re-query your MX record very frequently, increasing load on your DNS server and occasionally causing small delays in mail delivery while the resolver waits for a fresh DNS response.

Fix: Increase the MX record TTL to 3600 seconds (1 hour) for stable operation. Short TTLs are appropriate only in the 24-48 hour window immediately before a planned MX change, to speed up propagation. After the change is confirmed, restore the TTL to 3600.

TTL is very long (over 86400 seconds)

Why it happens: A 24-hour or longer TTL means that if you need to change your MX records, for a migration or in response to a server failure, sending servers worldwide will continue using the old records for up to 24 hours after the change is made.

Fix: Reduce the TTL to 3600 seconds (1 hour). If a migration is planned, reduce to 300 seconds 24-48 hours before the migration date, complete the migration, then restore to 3600. This gives you effective control over propagation speed without maintaining a permanently short TTL.

No MX records found at all

Why it happens: The domain has no MX records. For domains that should receive email, this is a critical configuration gap. Email will either fail to deliver or fall back to the A record depending on the sending server's behaviour. For non-sending domains, this is a security gap.

Fix: If the domain should receive email: publish the MX records required by your email provider immediately. For Google Workspace, Microsoft 365, Zoho, and Proton Mail, the records are listed in each provider's setup documentation. If the domain should not receive email: publish a null MX record (priority 0, exchange '.') to explicitly signal no inbound mail is accepted. Also add SPF v=spf1 -all and DMARC p=reject to fully lock down the domain.

Examples

MX priority configurations: what correct and incorrect setups look like

Four configurations showing what the analyser returns and whether each is correct, misconfigured, or intentional.

Example 1Google Workspace. Five records, three priority tiers (correct)✓ Healthy

Priority	Mail Server	TTL
1	ASPMX.L.GOOGLE.COM	3600s
5	ALT1.ASPMX.L.GOOGLE.COM	3600s
5	ALT2.ASPMX.L.GOOGLE.COM	3600s
10	ALT3.ASPMX.L.GOOGLE.COM	3600s
10	ALT4.ASPMX.L.GOOGLE.COM	3600s

Five records across three priority levels. Priority 1 is preferred; ALT1/ALT2 at priority 5 are first backups; ALT3/ALT4 at priority 10 are second backups. Two records sharing the same priority (5 and 10) is intentional load-balancing. Not a misconfiguration. No issues detected.

Example 2Microsoft 365. Single record at priority 0 (correct)ℹ️ Single record

Priority	Mail Server	TTL
0	contoso-com.mail.protection.outlook.com	3600s

One MX record is correct for Microsoft 365. It handles internal redundancy itself. The analyser warns about single records by default, but this warning can be disregarded for M365 domains. Priority 0 is the highest priority value and is M365's standard configuration.

Example 3Self-hosted. Equal priorities (misconfiguration)⚠ Issue detected

Priority	Mail Server	TTL
10	mail.example.com	3600s
10	backup.example.com	3600s

Both records are at priority 10. If mail.example.com is intended as primary and backup.example.com as failover, this is a misconfiguration, 50% of email goes to the backup even when the primary is healthy. Fix: set mail.example.com to priority 10 and backup.example.com to priority 20.

Example 4Parked domain. No MX records (security gap)✗ No MX records

No MX records found

No MX records exist. For a domain that should not receive email, this is a security gap. Some sending servers fall back to the A record for delivery. Publish a null MX (priority 0, exchange '.') plus SPF v=spf1 -all and DMARC p=reject to fully lock down the domain against inbound delivery and outbound spoofing.

FAQ

MX record priority questions and answers

Answers to the most common questions about MX priorities, redundancy, TTL, null MX, and provider-specific configurations.

What is MX record priority and how does it work?

MX record priority (also called preference) is a numerical value that controls which mail server receiving servers try first when delivering email to your domain. Lower numbers mean higher priority. A server with priority 10 is tried before a server with priority 20. When a sending mail server queries your domain's MX records, it attempts delivery to the lowest-priority-number server first. If that server is unreachable or returns a temporary error (4xx), it falls back to the next-lowest-priority server. This mechanism provides redundancy. If the primary mail server is down, email is delivered to the backup rather than bouncing. Priority 0 is the highest possible priority and is used by Microsoft 365. Priorities 1, 5, 10 are used by Google Workspace across its five servers.

Why does having only one MX record cause problems?

A single MX record means there is no fallback if that mail server is unavailable. If the server goes down for maintenance, experiences an outage, or has a network issue, sending mail servers will queue your email and retry for a period (typically up to 4-5 days per RFC 5321), after which the message bounces permanently. For critical business domains, this is unacceptable. The solution is to publish at least two MX records with different priority numbers. A primary server at a lower priority number and a backup at a higher number. Most hosted email providers (Google Workspace, Microsoft 365, Zoho) automatically provide multiple MX records. Self-hosted mail servers require the administrator to configure and maintain the backup server.

What happens when all MX records have the same priority?

When two or more MX records share the same priority number, sending mail servers treat them as equal-priority and distribute delivery across them randomly. This is called round-robin load balancing. This can be intentional for load distribution across multiple equivalent servers. However, if you have a primary and backup server and accidentally assign them the same priority, the sending server has no way to prefer the primary. Your backup server receives half the traffic even when the primary is perfectly healthy. The analyser flags this pattern when it detects multiple MX records at identical priorities, so you can verify whether the equal-priority configuration is intentional or a misconfiguration.

What is MX record TTL and what values should I use?

TTL (Time to Live) is the number of seconds that DNS resolvers cache your MX record before querying for a fresh value. A TTL of 3600 means resolvers cache the record for one hour before checking for changes. Very short TTLs (under 300 seconds) cause your MX record to be queried very frequently, increasing DNS load and occasionally causing delivery delays if DNS queries are slow. Very long TTLs (over 86400 seconds, 24 hours) mean that if you need to change your mail server, it can take over a day for the change to propagate globally, during which time some email still goes to the old server. The recommended value for MX records under normal operation is 3600 seconds (1 hour). When planning a migration, lower the TTL to 300 seconds 24-48 hours before making the change, complete the migration, then restore the TTL.

What is the correct MX priority configuration for Google Workspace?

Google Workspace requires five MX records at three priority tiers: ASPMX.L.GOOGLE.COM at priority 1, ALT1.ASPMX.L.GOOGLE.COM and ALT2.ASPMX.L.GOOGLE.COM at priority 5 each, and ALT3.ASPMX.L.GOOGLE.COM and ALT4.ASPMX.L.GOOGLE.COM at priority 10 each. All five records are required for full redundancy. Priority 1 is the primary server; the two priority 5 servers are first-tier backups; the two priority 10 servers are second-tier backups. If you see only some of these records in the analyser, you are missing redundancy. If you see equal priorities where different priorities are expected, there may be a DNS misconfiguration.

What is the correct MX priority configuration for Microsoft 365?

Microsoft 365 uses a single MX record at priority 0 in the format yourdomain-com.mail.protection.outlook.com (where hyphens replace the dots in your domain). Unlike Google Workspace's five-record configuration, Microsoft 365 uses a single MX entry and handles its own internal redundancy. Having only one MX record for Microsoft 365 is therefore correct and expected. The single-record warning from this analyser can be disregarded in that case. The exact MX hostname for your domain is shown in the Microsoft 365 admin centre under Settings > Domains > your domain > DNS records.

How does MX priority differ from the actual mail server used?

MX priority only controls the order in which sending servers attempt delivery. It does not affect routing after the message is accepted. Once a message is delivered to whichever MX server accepts it, all delivery is handled internally by that provider's infrastructure. The priority system is purely a mechanism for sending servers to determine their first connection attempt. A message delivered to any of your MX servers (whether primary or backup) arrives in the same mailbox. The backup server is not a separate inbox, it is a different network entry point to the same email service.

What is a null MX record and when should I use one?

A null MX record has priority 0 and an exchange value of '.' (a single dot). Defined in RFC 7505, it explicitly signals to sending servers that this domain does not accept email, preventing fallback delivery attempts via the A record. Use a null MX on: parked domains, acquired or legacy domains that should not receive email, subdomains used only for web services, and any domain where accidental email delivery would be a security risk. Pair a null MX with SPF v=spf1 -all and DMARC p=reject to fully prevent both inbound delivery and outbound spoofing of any non-sending domain.

Why would I use the MX Priority Optimizer instead of the MX Record Lookup?

The MX Record Lookup shows you the raw MX records for a domain, all servers and their priorities, and identifies the email provider. The MX Priority Optimizer does everything the lookup does and additionally performs a health analysis: it checks whether you have adequate redundancy (multiple records), whether priorities are correctly differentiated (or accidentally set equal), whether TTL values are in a healthy range, and generates specific fix recommendations for any issues found. Use the Lookup for a quick reference check; use the Optimizer when diagnosing delivery issues or auditing a domain's email configuration.

Can MX record misconfiguration cause email to go to spam?

MX misconfiguration typically causes email delivery failures (bounces or queuing) rather than spam filtering. If your MX records are missing or incorrect, email will not be delivered at all. It will bounce with a DNS error or queue and eventually expire. Spam filtering decisions happen after delivery is accepted by the MX server and are based on content, sender reputation, authentication (SPF, DKIM, DMARC), and blacklist status. However, if your MX records route email to an unexpected or unauthorised server, that server's reputation could affect filtering. Check your authentication records using the Email Health Checker for a complete deliverability audit.

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

MX record changes propagate based on the TTL value. If your current TTL is 3600 seconds, resolvers around the world will continue serving the old record for up to one hour after you make the change. Full global propagation typically takes 1-4 hours for TTLs under an hour, and up to 48 hours for TTLs of 24 hours or more. The best practice for migrations is to reduce the TTL to 300 seconds (5 minutes) 24-48 hours before the planned change date. This allows cached values to expire quickly. After the migration is confirmed working, restore the TTL to 3600.

What does the email provider detection show?

Provider detection identifies the email platform from the exchange hostnames in the MX records. ASPMX.L.GOOGLE.COM and related records indicate Google Workspace. mail.protection.outlook.com indicates Microsoft 365. mx.zoho.com indicates Zoho Mail. mail.protonmail.ch indicates Proton Mail. For self-hosted or custom mail servers, the display shows 'Custom' as the provider. Provider detection is based on well-known hostname patterns. For private branded mail infrastructure (where the hostname does not include the provider's name), the analyser will display 'Custom' even if a known commercial platform is being used behind the scenes.

What is the difference between MX priority 0 and priority 1?

In practice, priority 0 and priority 1 are both 'highest priority' in the sense that they will be preferred over any record with a higher number. The distinction only matters when comparing multiple records against each other. Microsoft 365 uses priority 0 for its single MX record. Google Workspace uses priority 1 for its primary server. Neither 0 nor 1 is inherently better. They are simply different numbers chosen by the respective providers. What matters is the relative ordering between your records, not the specific numbers. You could use 1, 2, 3 or 10, 20, 30 or 100, 200, 300. All are valid as long as the numbers correctly rank your servers from most-preferred to least-preferred.

How many MX records should a domain have?

For hosted email services (Google Workspace, Microsoft 365, Zoho, Proton Mail), you should have exactly the number of MX records your provider specifies. Typically between one and five. Adding extra records beyond those specified can route some email to servers that are not configured to accept your mail, causing delivery failures. For self-hosted mail servers, a minimum of two MX records (primary and backup at different priorities) is strongly recommended. The maximum is not technically limited but practically more than five is unusual and can complicate troubleshooting. Microsoft 365 is the notable exception to the multi-record pattern. Its single MX record is correct by design.

Does MX record priority affect outbound email sending?

No. MX records are only used for inbound email delivery. They tell the rest of the internet which servers can receive email for your domain. Outbound email sending is governed by your mail server configuration, SMTP settings, and the SPF record which lists which servers are authorised to send on your behalf. MX priority has no effect on outbound email. If you are troubleshooting outbound delivery failures, check your SPF record with the SPF Record Checker, verify DKIM signing with the DKIM Analyser, and check your DMARC policy with the DMARC Checker.

Technical background

MX records in context: how priority fits into the full email DNS picture

MX records handle the inbound half of email routing. When any mail server anywhere in the world sends email to [email protected], it performs a DNS MX query to find which server to connect to. The priority system in MX records is entirely server-side. The sender consults your priorities and connects accordingly. Your mail server has no control over which MX record the sender chooses, only over which records you publish and at what priorities.

The outbound half of email routing, controlling which servers are allowed to send email appearing to come from your domain, is governed by SPF (Sender Policy Framework). Published as a TXT record at your root domain, SPF lists the IP addresses and sending services authorised on your behalf. Use the SPF Record Checker to validate your record and confirm the DNS lookup count is within the RFC 7208 10-lookup limit. If your SPF has too many include: chains, the SPF Flattening Tool resolves them to direct IP ranges.

DKIM (DomainKeys Identified Mail) adds cryptographic signing to outgoing messages. The private key signs the message; the public key is published in DNS at selector._domainkey.yourdomain.com. Recipients verify the signature to confirm the message was not altered in transit. Use the DKIM Analyzer to look up your key, estimate bit strength, and check for test mode or revoked keys.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with alignment enforcement. The DMARC record at _dmarc.yourdomain.com specifies the policy (none/quarantine/reject) and provides aggregate reporting on authentication pass/fail rates across all senders. Use the DMARC Checker for a policy health summary or the DMARC Analyzer for a full tag-by-tag breakdown.

For a complete one-pass audit covering MX, SPF, DMARC, DKIM, and disposable domain status with a scored A-F grade, use the Email Health Checker. For a security-focused risk score covering authentication posture and BIMI, use the Email Privacy Auditor.

Related Email & DNS Tools

Need a disposable email address?Get a free instant throwaway email. No signup, no trace.

Get Free Temp Mail →