What this analysis does
Mailybox correlates MX, SPF, DKIM fingerprints and provider evidence with optional sanitized application or SMTP configuration. It surfaces service families, endpoint-bound dependencies, legacy authentication clues and SPF headroom so a provider change can be tested against the dependencies most likely to be missed.
Public DNS shows what a domain authorizes. It does not show the application relaying through a server that predates the current team, or the appliance configured once and never touched. Those undocumented dependencies are what break at cutover, and they are found by combining DNS evidence with evidence from inside the estate.
Two evidence sources, two blind spots
DNS evidence is complete for what is publicly authorized and blind to anything internal. Endpoint evidence — sanitized configuration exports, relay logs, connection records — covers the internal estate and misses services that send directly from vendor infrastructure without touching your network.
Combining both is what produces a usable inventory. Each source covers the other’s blind spot, and dependencies appearing in one but not the other are usually the most interesting entries in the result.
- DNS covers public authorization only.
- Endpoint evidence covers internal relay paths only.
- Entries present in one source and absent from the other deserve attention first.
The categories that recur
Legacy relay is the most common: an internal SMTP server that applications authenticate against, frequently without authentication at all, configured before anyone currently responsible joined. Multifunction devices scanning to email are a close second, and both stop silently at a cutover because their failures land in logs rather than in mailboxes.
Vendor integrations sending on behalf of the domain are the third category. They authenticate against the vendor rather than your infrastructure, so they survive an internal migration but break when the authentication configuration changes.
Sanitize evidence before submitting it
Configuration exports and logs frequently contain credentials, internal addressing and personal data. Remove passwords, API keys and authentication material before submitting anything, and reduce the evidence to the fields that identify sending paths.
Hostnames, ports, sender addresses and connection counts are sufficient for dependency discovery. Message bodies, recipient lists and credentials add nothing to the analysis and should not leave your environment.
Example: a relay with no DNS footprint
Evidence supplied
DNS evidence for the domain plus a sanitized export of internal relay connection records.
How to read the result
The analysis identifies an internal SMTP relay used by several applications that appears nowhere in public DNS, and reports it as a migration blocker because those applications will fail when the relay is decommissioned.
Known limits
- Discovery is bounded by the evidence supplied; systems absent from both sources remain undiscovered.
- Endpoint evidence quality varies with logging retention and configuration.
- A discovered dependency is a candidate for review, not a confirmed production requirement.
Common questions
What endpoint evidence is most useful?
Relay connection records and mail-client configuration exports, sanitized of credentials. Hostnames, ports and sender addresses are the useful fields.
Can this be done from DNS alone?
Partially. DNS reveals public authorization, but internal relay dependencies have no DNS footprint and are the ones that break migrations.
How far ahead of a migration should this run?
Before the plan is finalized. Discovery frequently changes scope and sequencing, so running it after scheduling defeats the purpose.