MX Priority Checker — Validate Mail Exchanger Order

SMTP senders sort MX by ascending priority value. The lowest number is tried first for new mail. Higher numbers are backups reached when lower-priority hosts are unreachable. Equal priorities mean receivers may shuffle among peers — valid for load balancing but confusing if unintended.

Misconfigured priorities send production mail to decommissioned backups or skip intended spam filters. This checker surfaces structural issues before they become delivery incidents.

When two MX records share the same priority number, issues lists the duplicated values. Duplicates are legal in DNS — they imply peers without strict ordering. Problems arise when admins thought they set 10 and 20 but both show 10 due to copy-paste errors.

Review whether duplicates are intentional load share. If not, adjust priorities so primary spam filtering or mailbox hosting is unambiguously lowest.

If every MX record carries identical priority, issues notes load balancing without preference order. Some architectures want this; many accidental all-10 configurations leave senders picking randomly among hosts with different capabilities.

Document intentional equal-priority designs in runbooks. Otherwise split priorities — 10 for primary, 20 for backup — classic pattern everyone understands.

primaryHost is the hostname on the first row after sorting — the preferred SMTP target under RFC behavior. lowestPriority repeats its numeric priority for quick reference in tickets.

When primaryHost surprises you — old provider hostname still lowest — you found the root cause of mail routing to legacy infrastructure.

valid true only when at least one MX exists and issues is empty. Missing MX yields valid false with issue explaining inbound mail is not configured. Duplicates or all-equal sets keep valid false while still returning entries for inspection.

Automate monitoring by alerting when valid flips false after DNS API changes.

SMTP server finder resolves each MX to IPv4 and names primary with IP context. MX priority checker focuses on configuration correctness — duplicates, missing MX, equal priorities. Run finder after priority checker passes to complete network picture.

Together they answer is MX structurally sound and where does it resolve.

Before MX cutover, record current primaryHost and priorities. After TTL expiry, rerun checker — confirm only new vendor hosts remain and priorities match vendor spec (often multiple Google or Microsoft MX with staggered priorities).

Leaving legacy MX at priority 5 while adding new at 10 sends mail to legacy first — extend finder verification when priorities look correct but mail still misroutes.

Higher priority numbers should point to hosts that queue or forward when primaries fail — not dormant servers that reject mail. Checker cannot ping SMTP; operators must test backup behavior separately.

Some spam appliances publish equal secondary MX to same cluster — acceptable when documented.

Trailing dots, duplicated MX rows, priority field left default zero for multiple rows, or accidental deletion of lowest MX during TXT edits. Priority zero is valid and highest preference — surprising if unintended.

After fixes, wait TTL and rerun. Pair with email deliverability checker for holistic mail DNS.

MX data is public DNS. Validate domains you operate or support. Export issues and entries into change tickets for audit trails.

We do not modify DNS records — read-only analysis only.