Loading page
About this tool
Plan MX record preference values for single-provider, primary-plus-backup and provider-migration setups.
The MX Record Priority Planner assigns MX record preference values using the RFC 5321 rule that sending servers try the lowest preference first and load-balance across equal values. It covers three real setups — a single provider, a primary with a backup MX, and a three-phase provider migration — and validates that every target is a well-formed hostname rather than an IP address literal, as RFC 5321 requires. It is for admins moving mail providers or adding failover without bouncing messages.
Open MX Record Priority Planner on AltFTool — it loads instantly in your browser.
Choose a Scenario — single provider, primary plus backup, or migration — then paste mail server hostnames one per line and set the TTL in seconds.
The planner validates every target as a hostname (IP-address MX targets are rejected per RFC 5321) and assigns preference tiers spaced by 10.
Review the record table of Name, TTL, Type, Preference and Target, or the three migration phases, then press Copy plan for zone-file lines.
Lowest-preference-first and equal-value load balancing drive every tier the planner emits.
Three explicit phases keep both providers accepting mail while DNS caches expire.
IP-address MX targets are blocked — RFC 5321 requires a hostname with A/AAAA records.
It is a preference value from 0 to 65535, and sending mail servers must try the record with the LOWEST value first (RFC 5321 section 5.1). Records sharing the same value are tried in random order, which spreads load across those servers.
No. RFC 5321 requires the MX target to be a hostname that resolves via A or AAAA records, and RFC 2181 section 10.3 additionally forbids the target from being a CNAME. Publish an A record for the mail host and point the MX at that name.
Add the new provider's servers at a higher preference first and verify they accept mail for your domain, then swap so the new provider holds the lowest preference with the old one kept as a temporary backup, and finally remove the old records once their TTL has expired and the old queue is empty. Lower the MX TTL at least one full old-TTL period before the swap.
Usually not: RFC 5321 requires senders to queue and retry undeliverable mail, typically for at least 4-5 days, so a short outage loses nothing. A backup MX only helps if it enforces the same recipient validation and spam filtering as the primary — otherwise spammers deliberately target it as the weakest door.