What this analysis does
Mailybox correlates multiple public signals rather than relying on MX alone, which helps distinguish the inbound mailbox provider from third-party sending services authorized by the domain.
The provider that receives a domain’s mail is often not the platform that sends it, and neither is necessarily the one people assume. Public DNS carries enough fingerprint evidence to identify both, which is the starting point for migration planning, vendor review and inbound diligence.
Different records answer different questions
Mail exchangers identify the mailbox provider that accepts inbound mail. SPF includes identify the platforms authorized to send outbound. DKIM selector patterns often identify a specific vendor because selector naming conventions are characteristic. Verification TXT records left behind by onboarding processes frequently name services long after they stopped being used.
Reading them together is what produces an accurate picture. A domain receiving mail through one suite while sending marketing through a second platform and transactional mail through a third is an ordinary arrangement, and each of those is a separate dependency.
- MX identifies the inbound mailbox provider.
- SPF includes identify authorized outbound platforms.
- DKIM selector naming and stale verification records frequently name specific vendors.
Stale evidence is common and informative
DNS accumulates. Verification records from trials that ended, includes for platforms that were replaced, and selectors for services nobody remembers all persist because removing them is nobody’s task. That residue is genuinely useful for understanding history, and it is also a security finding in its own right.
An SPF include for a platform the organization no longer uses still authorizes that platform to send on the domain’s behalf. If the associated account is dormant, unowned or has been taken over, the authorization remains live. Detection is the first step toward removing it.
Build a full sender inventoryFind unowned authorization candidates
Fingerprints are evidence, not proof
Detection infers a vendor from patterns that vendors themselves can change. Custom domains, white-label configurations and self-hosted deployments all reduce or eliminate the signals detection relies on, and a domain running its own infrastructure may match nothing at all.
Treat the output as a well-evidenced hypothesis to confirm rather than a settled fact, particularly when the conclusion will drive a migration plan or a vendor security review.
Example: a split mail architecture
Evidence supplied
A domain whose MX points at one suite while SPF authorizes two unrelated sending platforms.
How to read the result
The analysis names the inbound provider from MX evidence and lists both outbound platforms from SPF, reporting them as separate dependencies rather than collapsing them into a single provider conclusion.
Known limits
- Detection is based on public fingerprints that vendors can change without notice.
- White-label and self-hosted configurations may produce no recognizable signal.
- A detected authorization does not establish that the platform is currently in use.
Common questions
Why does detection name a service we stopped using?
Because the DNS evidence authorizing it is still published. That is a finding worth acting on rather than an error in detection.
Can this identify a self-hosted mail server?
Sometimes, from hostname and PTR patterns, but self-hosted infrastructure often produces no vendor fingerprint at all.
Is any of this visible to the domain owner?
Everything queried is public DNS. No access is required and no notification is generated.