Mail generated by an AI system still travels through an application, sending service and domain identity. Inventory those components rather than treating AI-generated as a new authentication category. A receiver evaluates protocol identities and signatures, not whether a human or model composed the text.
Separate the identities in the mail flow
Record the visible From domain, SMTP envelope sender domain, DKIM signing domain and selector, provider account and application credential owner. The first three serve different protocol roles. RFC 9989 defines DMARC's relationship to the From domain and aligned SPF or DKIM results. The local part and display name are not the basis of DMARC domain alignment.
A provider's infrastructure domain can authenticate successfully without aligning with the organisation's visible From domain. Conversely, an aligned DKIM signature can support DMARC when the SPF path does not align. Do not diagnose the result from a single pass label without identifying which domain the result authenticates.
Establish organisational ownership separately
Map the message to the actual provider tenant, application, business purpose and accountable team. Shared IP addresses and provider names are clues, not sufficient proof that a particular sender belongs to the organisation. Ask the application owner to confirm how the service is provisioned and which credentials or signing settings it uses.
DKIM distinguishes the signing domain's assertion of responsibility from the purported author. A valid signature does not identify the human who approved a message, validate an AI model or certify its content. Preserve application-level audit records for those questions.
Compare three hypothetical identity cases
Assume strict alignment and From alerts.example. In case A, SPF passes for an unrelated provider domain and a valid DKIM signature uses d=alerts.example: the aligned DKIM path supplies a DMARC pass. In case B, SPF and every valid DKIM signature use unrelated provider domains, so neither path aligns. In case C, only a marketing display name changes while the domain identities and authentication outcomes remain unchanged; domain alignment does not change.
These are hand-worked identity comparisons, not an executed evaluator or signature test. They assume all relevant paths are accounted for and do not implement relaxed alignment, policy discovery or receiver disposition. Under RFC 9989 sections 7.4 and 8, p=reject deployment separately requires valid DKIM signatures and forbids reliance solely on SPF. A message-level pass does not waive that obligation.
Verify configuration rather than rewriting labels
Changing a stored field from a provider domain to alerts.example does not make a service sign as that domain. Use the provider’s supported account configuration and authorized DNS values, then test the actual route and trustworthy receiver evidence. If configuration readback matches but the sample still uses the old signing identity, leave the message-path result failed or unresolved instead of treating a file edit as repaired authentication. This is a hypothetical diagnostic boundary, not a local transformation, real approval or DNS publication.
Choose a maintainable sending design
Use a documented sending identity that the organisation can monitor, rotate and revoke. Separate streams or subdomains when that improves ownership and operational isolation, but do not claim a subdomain guarantees reputation isolation or delivery. Verify provider-specific domain and signing configuration from current first-party instructions before implementation.
Track every agent or application that shares a sender credential. If one key serves several unrelated services, an authentication report may not identify which application generated a message. Improve application logging and credential separation rather than overstating what DMARC can reveal.
When an application retires, revoke its sending access, review its provider configuration and remove obsolete authorization only after checking shared dependencies. Maintain a testable inventory linking domain evidence to business ownership. These recommendations are provider-neutral and do not assert a specific EmailAuth integration or automated attribution capability.