An inherited sender inventory is a decision tool, not a list of IP addresses. Before standardising acquired domains, connect observed mail to the customer-specific service that produced it, its business owner and its approved identities. A familiar provider can host both legitimate and unwanted traffic, so infrastructure recognition alone is not approval.
Start with multiple evidence sources
Gather authorised configuration exports, application registers, vendor account records, DNS observations and available mail evidence. Preserve where each observation came from and when it was collected. Aggregate reports can reveal source IPs and authentication patterns but cannot independently establish the organisation's business intent or complete sender population. RFC 9990.
For each service, record purpose, accountable owner, provider account or tenant, criticality, visible From domain, envelope domain, DKIM signing identity, last representative test and approval evidence. Keep unknown fields explicit. Record sending and receiving purpose separately for domains that may be dormant or defensive.
Attribute identities before adding authority
Compare the observed identifiers with the actual vendor configuration and business workflow. DMARC uses alignment between the author domain and a successful authenticated identifier; a generic pass result without the identifiers can conceal the problem you need to solve. RFC 9989.
Do not add an unknown source to SPF simply because mail appears to originate there. SPF authorises hosts for the evaluated identity, and its evaluation includes DNS lookup limits. RFC 7208, section 4.6.4. A new include may expand authority, exceed operational limits or fail to fix alignment. Establish the intended service and appropriate authenticated route first.
Keep approval and testing separate
An approved service can still fail a migration test; an authenticated message can still come from an unapproved service. Store both states. Approval evidence should identify the accountable decision, while testing evidence should describe the actual transaction, identities, result and time. Do not use a test pass as a substitute for business ownership.
Suppose an inherited billing service has a named business owner and approved purpose, but the target account’s signing identity has not been verified. A second service has an aligned passing message but no identified business owner. The first needs route evidence before migration; the second needs attribution and approval before being treated as an authorized service. Neither gap is resolved by the other service’s reassuring result.
These are hypothetical inventory decisions, not generated records or executed tests. Keep separate fields for ownership, intended identities, approval and current test coverage. When the application owner supplies the missing account evidence, update only the state it establishes; do not automatically change an untested migration result to passed.
Turn attribution into a migration plan
Group services by verified owner, dependency and readiness. Define the intended target identities and tests before editing records. Preserve unknown routes for investigation, with a named owner and deadline, rather than silently approving or deleting them. Retain the old configuration and an approved recovery plan for each consequential transition.
After standardisation, reconcile actual observations against the approved inventory and investigate new identities. Keep retired services and their decisions in history. A useful inventory remains an operating record through vendor changes and incident response, rather than a spreadsheet abandoned when the merger project ends.
This inventory and review workflow is a recommended operating model. NIST SP 800-53 Rev. 5 CM-8 and CM-3 provide a general basis for accountable inventories and controlled changes; they do not prescribe these email-specific fields or confer approval. NIST control catalogue.