An email sender inventory is useful when it can explain which service uses a domain, why that service is authorised and how its messages were verified. A list of provider names or source IP addresses cannot answer those questions on its own.
Build the inventory around business workflows and their identities. Keep observed evidence separate from approval, and make maintenance part of the way software is purchased, changed and retired.
Define a record that leads to an action
Use one accountable service or workflow as the record's starting point. A provider may host several customer accounts, and one application may use different routes for campaigns, receipts and password resets.
- Service and workflow: Identifies the business function being investigated.
- Business and technical owners: Establishes who can approve use and change settings.
- Visible From identities: Names the domains that users see.
- Envelope and signing identities: Connects the actual SPF and DKIM paths.
- Provider account and route: Distinguishes your configuration from shared infrastructure.
- Evidence and approval state: Separates observation, investigation and authorised use.
- Review and retirement conditions: Keeps the record current.
Use appropriate access controls for account details and evidence links. The inventory should point to controlled records, not become a repository of private keys or reusable administrative credentials.
Start from both observations and business knowledge
Aggregate reports can reveal source patterns worth investigating. Original received messages and sending-provider logs can add identity and route evidence.
Business owners can identify periodic services that have not appeared in a short observation window. Procurement and application records can also reveal services purchased outside the central mail team.
Combine those inputs rather than treating one as complete. An observed IP may belong to shared infrastructure or an intermediary. A purchased product may have been retired or configured to use another sending service.
Keep attribution separate from authorisation
Give entries clear states such as observed, investigating, approved, exception or retired. Define what evidence is needed to move between them.
A recognisable brand name is not enough for approval. Confirm the customer-specific account or route, intended From identity and business purpose. Likewise, an unknown failing source is not automatically an attacker.
Record uncertainty explicitly. A supported hypothesis with an investigation owner is more useful than a confident-looking label that nobody can explain later.
Verify the actual workflow
For each critical route, send a controlled message through the service users rely on. Preserve the original at the receiving side and compare its trusted results, From domain, envelope identity and relevant signatures.
A public DKIM key demonstrates one configuration dependency. It does not establish that the application is signing with it. A passing employee-mail test does not establish that the billing application shares the same route.
Use the alignment diagnosis where raw authentication and the visible identity differ. Link the verified result and configuration record to the inventory entry.
Make onboarding change the inventory before DNS
Consider a synthetic example: a new customer-support tool asks the administrator to add an SPF include. The company already uses that provider for a different account.
The existing provider label does not approve the new account. In the hypothetical review, the team should first record the service owner, supported identities, route and required permissions. Approval and message verification are the required next steps, not actions performed for this article.
This avoids two common failures: authorising an unfamiliar service without ownership, and assuming that a shared provider name means an existing setup covers everything.
Close the loop on changes and retirement
Trigger a review when a service changes its domain, signer, gateway or sending model. Record whether an exception is temporary, who owns it and what closes it.
At retirement, confirm that legitimate use has ended before removing permissions or selector delegations. Include periodic workflows and acquired systems. Keep a historical decision record so an unfamiliar later observation can be investigated.
A useful inventory survives personnel changes because another operator can follow the service, owner, identities, approval and evidence. Use it to support policy selection, non-sending-domain decisions and ongoing report investigation.
The proposed inventory design is informed by NIST CM-8 component accountability, not a mandatory email-specific template. RFC 9989 section 5.3.5 defines message-level DMARC results; RFC 9990 section 3.1 describes aggregate observations. Neither establishes internal business approval.
Keep the next investigation attached to the record
When a service is observed but not attributed, name the evidence needed to match the account and workflow. When attributed but unapproved, route the decision to the business owner. When approved but untested, schedule an authorized representative test. These are separate states, not one green inventory badge.