Reading a DNS timeline

How observations are selected and sorted

The source returns up to 50 observations, the most recent first. The chart then uses each observation’s supplied timestamp, which comes from a source timestamp or a first-recorded date. The list starts with the newest of these timestamps. Each row was collected separately, so rows sharing a date may not represent the domain’s whole configuration on that day.

A dot shows a value recorded with that date. The value may have been used before or after it. An old value can still be active, and a newer value may already have been removed. Records without a date appear only in the list.

Example: Microsoft and OVHcloud MX records

In this example, a Microsoft MX was recorded in March 2022 and an OVHcloud MX in September 2024. A mail-routing change is one possible explanation. The two rows do not show whether the services overlapped, when Microsoft stopped receiving mail or which provider is used today.

Check the other MX values, compare dated SPF records, then consult the current DNS answer and migration logs if you have them. A gateway or a period of parallel delivery can explain the same observations.

How providers and SPF changes are identified

The notes below the chart use the records returned by the search. MX and NS hostnames are checked against documented provider patterns, ignoring the MX priority, letter case and a final dot. Each recognised provider is shown with one record, using the earliest available date in these results. Hosts without a match remain unclassified, and records without dates cannot be placed in time.

Two hosts belonging to Google Workspace still count as one service. A Microsoft MX using mx.microsoft and one using mail.protection.outlook.com also belong to the same service. The MX guide lists the recognised patterns. Custom hostnames and unlisted regional variants may not be recognised.

The SPF comparison uses dated policy values and ignores differences in spaces, letter case or the order of terms, an explicit + before a term and the qualifier of all (~all, -all or ?all). It is omitted if several values share the earliest or latest day, or if a TXT value’s quoting cannot be read reliably. SPF includes are not resolved, and delivery is not tested. Each note lists the records it is based on.

Why an SPF comparison may be absent

The record list can contain SPF values without showing a comparison note. The site needs at least two different dated policies and an unambiguous earlier and later value. It also skips text whose quotation or escaping makes the recorded policy ambiguous.

For example, suppose two different policies are first recorded on 2024-03-06 and a third on 2025-06-18. These dates are invented. The two earlier values share a date, so choosing either one as the starting policy would imply an order the sample does not establish. The records remain visible; the automatic comparison is omitted.

This also applies when several different policies share the latest date. A missing note does not mean the SPF policy stayed the same. Open the TXT records and compare their values, using the SPF comparison example to distinguish literal changes from sending behaviour.

Missing records

A missing value may be older than the 50 returned observations, or it may never have been collected. Brief changes may also happen between collections. A gap in the chart does not confirm that a record was deleted or that the domain was unavailable.

Checking current DNS

For a current answer, query a public resolver explicitly, for example dig @1.1.1.1 example.com MX, dig @1.1.1.1 example.com NS or dig @1.1.1.1 example.com TXT. Resolver caches and DNS TTLs can delay the appearance of a recent change. For administrative confirmation, check the authoritative zone and your change logs.

An MX hostname does not locate the mailbox data. A nameserver change does not establish who owns the domain.