What this analysis does
Mailybox evaluates the public email control plane for structural conflicts and optionally compares detected provider evidence with an expected-service list supplied by the user. Unexpected providers are labeled ownership-review candidates rather than inactive services, because public DNS alone cannot prove current sending activity.
Email DNS accumulates. Records are added during onboarding and rarely removed at offboarding, so a domain ends up authorizing services nobody uses and occasionally publishing policy twice. Both conditions are quiet, and both have real consequences.
Duplicate policy records are an error, not a merge
A domain must publish at most one SPF record and one applicable DMARC record. When two are present, conforming evaluators treat the condition as an error rather than combining them, which can invalidate authentication that appeared to be working correctly.
This happens most often when a second sending platform is onboarded by a different team and its setup wizard publishes a new record instead of extending the existing one. The result passes a casual check, because a valid record is present — there are simply two of them.
- At most one SPF record and one applicable DMARC record may be published.
- Evaluators error rather than merging duplicates.
- Onboarding wizards run by separate teams are the usual cause.
Unowned authorizations are a standing risk
An SPF include for a platform the organization stopped using still authorizes that platform’s infrastructure to send as the domain. If the account is dormant or abandoned, that authorization survives regardless, and account recovery on an unmonitored tenant is a well-documented attack path.
The analysis surfaces authorization evidence that does not correspond to services you expect to own. Every entry needs an owner and a purpose; those that cannot be attributed are the ones to investigate before anything else.
Headroom and mixed signals
SPF lookup headroom is a conflict indicator in its own right. A record near the evaluation limit means the next vendor addition breaks authentication, and the accumulated cost is usually attributable to authorizations nobody defends.
Mixed mailbox signals are the other common finding: MX pointing at one suite while verification records, autodiscover entries and selectors from a different suite persist. That residue confuses diagnostics and occasionally routing, and it is safe to remove once ownership is established.
Measure current lookup headroomRead the ownership conflicts guide
Example: two SPF records after an onboarding
Evidence supplied
A domain where a second platform was configured by a different team.
How to read the result
The analysis reports two published SPF records as a critical conflict, explains that evaluators will error rather than combine them, and identifies merging the authorizations into a single record as the corrective action.
Known limits
- Ownership cannot be determined from DNS; findings are candidates for review rather than confirmed problems.
- Some apparent conflicts are deliberate configurations for legitimate reasons.
- Only public DNS is examined; internal routing conflicts are outside scope.
Common questions
How do I merge two SPF records?
Combine the mechanisms from both into a single record, verify the merged version resolves within the lookup limit, then publish it and remove the second record in the same change.
Is it safe to remove an unrecognized include?
Confirm against DMARC aggregate reporting first. If no mail from that source appears over a full reporting cycle, removal is low risk.
Why do old verification records matter?
They rarely affect mail flow directly, but they confuse diagnostics and indicate an offboarding process that did not complete.