MX record history

MX hostnames and priorities

In 10 mx.example.net, 10 is the preference and mx.example.net is the receiving host. Lower numbers are preferred. Several hosts often provide redundancy; they are not automatically several mailbox providers. A priority change on the same host is a routing change, not evidence of a new provider.

The history is a collection of observations, not snapshots of the full MX set. Hosts with different dates may have coexisted. Filter on MX, open the records and compare the names before interpreting the dates.

Providers this site recognises

A provider is named only when the whole hostname matches one of these patterns; *. stands for zero or more host labels. A hostname such as google.com.example.net does not match. Case and a final dot do not change a match. Other hostnames stay unclassified. The dates shown with a provider are when the source first recorded each value, not when a service started or stopped.

A filtering gateway receives mail first and passes it on to mailboxes hosted elsewhere, often Microsoft 365 or Google Workspace. A forwarding service relays mail to another address or to an application. Google hostnames ending in mx-verification.google.com and Microsoft hostnames ending in msv1.invalid prove domain ownership and do not receive mail, so they are never named. Nor are hostnames ending in norelay.stc.com.sa: this Saudi Telecom name did not resolve on 2026-10-17 and appears in the history of unrelated domains.

Google Workspace: two MX formats for one service

Google documents smtp.google.com with priority 1 for its current Workspace setup. Accounts set up before 2023 may use the older aspmx values, which remain supported. A history containing both formats can therefore still refer to Google Workspace.

Both hostnames match the Google Workspace patterns used by this site. Compare their recorded dates to see which values appear in the sample, then query current MX records to see what is published now. The first date attached to the new hostname cannot establish when mail delivery changed.

For the supported values and setup instructions, see Google Workspace MX documentation.

Comparing mail providers over time

• Different providers at different dates: check the other records for a possible mail-routing change. The dates alone cannot confirm a migration. See the example with Microsoft and OVHcloud.
• Different hosts from the same provider: Google uses both aspmx and smtp.google.com formats. Microsoft also uses two MX families. Either provider can change its hostnames while continuing to handle the domain’s mail.
• A gateway appears: a domain may add a filtering service while keeping its existing mailboxes.
• Several services appear: they may have been used during a transition, for parallel delivery or at different times. The rows are historical observations collected separately.

Checking SPF alongside MX

Compare the TXT and SPF records around the MX dates. For example, a Proofpoint MX and a Microsoft SPF include could mean that Proofpoint receives mail while Microsoft sends it. SPF only lists authorised senders, so it cannot confirm where the mailboxes are hosted.

Null MX and missing MX records

0 . is a null MX: the domain explicitly says it accepts no email. A missing MX row in this history only means none was returned. Even an actual DNS answer with no MX is different: SMTP has an implicit fallback to the domain’s address records. See RFC 7505 and RFC 5321 §5.1.

Checking current MX records

Run dig @1.1.1.1 example.com MX to inspect a current resolver answer. If you administer the domain, compare it with the provider’s assigned MX hosts and your authoritative zone. Historical hostnames should not be copied into production without checking the active account configuration.