Historical DNS can reveal a gateway transition. It cannot reveal the contract discussion, migration outcome or budget behind that transition.
Why a single MX snapshot is not enough
A present-day MX record tells you where inbound mail should be routed at observation time. Two or more snapshots can reveal that the published destination changed. But a transient change can come from testing, failover or a migration in progress. A single before/after comparison is not proof of a completed vendor replacement.
Research status: this is a change-detection method, not a claim that SecuTest has observed a particular number of gateway migrations. Historical population statistics need a verified time series from independently collected data.
Store the observations, not just the latest label
Each record should include the normalized MX set, observed timestamp, matched gateway, rule version, resolver status and relevant TTL. Keep a chronological series so you can reconstruct when each label was assigned. Never overwrite historical evidence just to reflect an improved classifier.
A useful event format includes domain, previous_gateway, new_gateway, first_observed, confirmed_at, rule_version and confidence. The field confirmed_at should reflect repeat observations, not a supposed contract signing date.
Filter the noise
DNS changes can be temporary. Check whether the new endpoint persists across more than one observation, whether the old and new MX records coexist, and whether only MX preference changed within the same vendor. A move between two hostnames owned by the same provider usually should not be counted as a provider migration.
| Observed difference | Preliminary classification |
|---|---|
| Same vendor, different host | Infrastructure rotation; not necessarily migration |
| New provider with old provider still present | Possible transition; needs confirmation |
| New provider persists across checks | Confirmed public routing change |
| DNS timeout during one snapshot | No reliable conclusion |
Separate the event from the buying signal
A verified move from one gateway to another can suggest operational activity, but it does not tell you whether the company is shopping, renewing or already satisfied. For MSP sales, a careful follow-up might ask how the mail-routing transition is being managed. Do not claim the prospect requested outside help.
Research design for a credible trend report
Before publishing counts, fix the sampling cadence and retention period, define what constitutes a change, deduplicate repeat events and audit a random sample. Report false-change rates and observation gaps. An incomplete scan history cannot support a claim about "all migrations" in a market.
Use Find Leads for the currently available independently collected signals. Use Scan Prospects for domains you already own. Features requiring historical change detection should only be described as available when they are actually deployed.
Example state machine for change detection
Start from a recognized provider A in the most recent confirmed snapshot. When a newly observed MX set indicates provider B, mark the event candidate transition. If B persists across repeated observations while A disappears, promote it to confirmed public routing change. If the record flips back quickly or the resolver fails, preserve the uncertain state rather than inventing a completed migration.
This state model limits false alerts caused by DNS load balancing, migration overlap or brief cutovers. It also makes historical analysis auditable: a reader can inspect the before-and-after hostnames and observation times. Even a confirmed routing change is only a possible timing clue for MSP outreach. A conversation with the organization is required to understand business context.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.