MX priority is easy to misread. A lower preference number identifies a more-preferred mail exchanger. A higher number identifies a less-preferred candidate. It does not mean a faster server, a more trusted provider or a percentage of traffic.
Reading a simple MX lookup
Imagine these published records for an example business domain:
| Preference | Mail exchanger | Intended role |
|---|---|---|
| 10 | primary.example.com | Preferred receiving route |
| 20 | backup.example.com | Less-preferred secondary route |
These are illustrative hostnames, not SecuraWall setup values. Use the exact records supplied for your account. A public lookup shows what a recursive resolver currently returns; it does not establish that the hosts can accept or deliver email.
Equal-priority records are a different design
When multiple exchangers have the same preference, the DNS configuration does not label one of them as the standby route. Do not assign equal values if your intended distinction is a preferred primary and a less-preferred secondary without understanding the provider’s design.
Similarly, increasing a preference from 20 to 100 does not schedule a longer outage delay. SMTP implementations and network failures influence the actual sequence of connection attempts and later retries.
DNS availability is not SMTP availability
A domain may have valid MX records while its mail server is unreachable, refusing messages or rejecting a particular recipient. A working SMTP service may still reject a message under its recipient or security policies. These are separate observations and should not be collapsed into one green “healthy” badge.
SecuraWall’s MX Lookup is deliberately a DNS tool. It lists preference values, mail exchangers and TTLs. It does not connect to port 25, test a mailbox, validate a complete failover deployment or guarantee delivery.
No MX record does not always mean no email
SMTP defines an implicit destination case when a domain has no MX answer. Separately, a Null MX record explicitly declares that the domain does not accept mail. A lookup must distinguish missing records, a nonexistent domain and a published Null MX instead of treating every empty result as the same error.
Common deployment mistakes
- A loop: the backup destination resolves back to the backup itself.
- An unconfigured standby: DNS points to a secondary provider before the domain and destination are authorized there.
- Assumed independence: different hostnames share the same underlying failure point.
- Confused product roles: a backup route is expected to provide incoming threat inspection that the selected package does not include.
A change procedure your team can verify
Save the current records and TTLs, configure the receiving destination, and document which service each MX hostname represents. After publishing, use a public lookup and compare the result with the intended record set. Allow for resolver caching. Finally, test delivery and recovery with your email administrator; a DNS screenshot cannot replace that final check.
Try the MX Lookup tool, read the Backup MX and secondary MX guide, or review the SecuraWall Backup MX service.
Technical references
RFC 5321 describes SMTP destination selection. RFC 7505 defines Null MX.