A software company's email inventory often starts with its marketing platform and ends too early. Passwordless access, support replies, invoices and status updates can depend on separate vendors, credentials and domains. They also fail at different moments. A status email that depends on the same unavailable application it is supposed to describe is an operational dependency problem even when its DKIM configuration is correct.
Map the service behind the sender
Create rows for product events, support conversations, billing and status-page notifications. For each, record the owner, vendor tenant, trigger, From domain, envelope identity, DKIM domain and selector, reply handling and recovery contact. Trace which application or person can initiate a send. Identify dependencies on the production database, identity provider, secrets store and deployment pipeline, then decide which are acceptable for incident communication.
Do not approve an IP address because it belongs to a familiar cloud provider. Shared infrastructure does not prove that the company's tenant sent the message. Connect the observation to an approved account, supported domain configuration and accountable owner. Retain uncertain traffic as unresolved until the evidence supports attribution.
Define acceptance by workflow
A product event test should start inside the product, a support test inside the support system and a billing test inside its authorised sandbox. For status updates, exercise the designated incident publisher and check whether that person can operate during a primary-service failure. Confirm the intended reply route so customers do not answer an unmonitored address unexpectedly.
RFC 9989 supports evaluation of aligned domain use, not application availability or correctness of an invoice. A signature from the vendor's own domain can verify while failing the intended alignment relationship. Authentication results must therefore accompany, rather than replace, the workflow acceptance test.
Do not let product mail hide the status route
Suppose product, support and billing routes use DKIM d= domains matching their respective From domains, while status.software.example is the status notice’s From domain and provider.example.net is its signer. Even assuming valid cryptography, the latter fails strict DKIM alignment. Confirm the status provider’s supported identity configuration rather than changing unrelated billing mail. These identities are hypothetical, not supplied signed specimens or actual verification results.
A single signature’s alignment is not a full DMARC verdict: evaluate other valid aligned signatures and SPF as applicable under RFC 9989 Sections 4.4 and 5.3.5. For p=reject deployment, Sections 7.4 and 8 require valid DKIM rather than relying only on SPF. Neither signature success nor alignment establishes that the status publisher can operate during an outage. No live platform or cryptographic test was performed.
Test the incident dependency, not just the DNS
Run an authorised exercise in which the ordinary product operator is unavailable and the backup incident publisher follows the documented route. Do not deliberately interrupt production simply to test this guide. Record which credentials, accounts and systems were necessary, whether a controlled recipient received the update and what the receiving boundary reported. If the fallback requires the unavailable identity provider, record that limitation and redesign with the security owner rather than improvising a shared password.
For signing changes, follow the vendor's current instructions and keep rollback evidence. Remove obsolete authorisations only after confirming no retained product, support or billing workflow uses them. Low-volume receipts and infrequent incident messages can disappear from short observation windows without becoming obsolete.
Make the inventory part of change control
Require a route review when a team adds a notification vendor, changes a From address, moves a support queue or replaces the status service. Retest affected flows and preserve evidence dates. The inventory is complete only to its declared scope; new product features can add new senders. Close each migration with an owner-approved test and a usable recovery procedure, not a domain-wide average.