A polished phishing message can be persuasive, but its writing style does not change the DMARC pass condition. Investigate the domain identities and authentication evidence before deciding which control failed. You do not need to prove that AI wrote the text to stop an unauthorized business request.
Evaluate identifiers, not prose
DMARC compares the author domain with domains authenticated through SPF or DKIM. At least one passing, aligned path is needed for a pass. Word choice, grammar, urgency and whether a model helped draft the message are not inputs to that identifier test. RFC 9989.
That does not mean the body can never affect authentication. DKIM signs a canonicalized body and selected headers. Editing a signed message can invalidate its signature. The distinction is between changing bytes after signing and producing polished text before a valid signature is created. RFC 6376. A semantic judgment about whether prose sounds machine-written is neither operation.
Separate three abuse paths
An attacker-owned lookalike domain can authenticate as itself while impersonating a company in display text. A compromised legitimate account can use an aligned sending route. A message claiming your exact domain without an aligned authentication path can fail DMARC. These cases call for different technical investigations even when the payment request reads identically.
Use trusted receiver results rather than sender-supplied claims. Keep the actual author, envelope and signing domains visible in the case record. The fraud team should also preserve the business request, requested change and independent verification status. Authentication does not establish that a person intended or approved a transfer.
Compare fixed identifier assumptions
For each written case, assume a single valid visible From field and an otherwise eligible DMARC evaluation. Compare plain and polished labels without changing any authentication input.
- Case A: From alerts@brand.test; SPF pass for MAIL FROM bounce@brand.test; no DKIM signature. DMARC passes under both style labels through aligned SPF.
- Case B: From alerts@brand.test; SPF pass for bounce@other.test; DKIM pass with d=other.test; assume other.test is not aligned with brand.test. Neither authenticated identifier aligns, so DMARC fails under either label.
- Case C: From billing@lookalike.test; SPF pass for bounce@lookalike.test; no DKIM signature. DMARC passes for lookalike.test under both labels, not for the company being impersonated in display text.
These are narrative deductions from stipulated outcomes, not six executed function calls, mail-server tests or an AI benchmark. No model generated the prose or detector classified it. A message-level SPF pass is not an endorsement of SPF-only deployment: RFC9989 section7.4 requires valid DKIM for p=reject domains.
Verify the business action independently
For a payment-change request, contact the supplier through an established, independently sourced channel and apply the normal approval process. Do not use a phone number supplied only by the suspicious message. The FBI recommends independently verifying payment and account changes. FBI business email compromise guidance.
The hypothetical business scenario stipulates domain_pass=true but known_contact_confirmed=false and second_approval=false, so the proposed payment rule would hold the request. Those verification fields are invented, not a completed callback. Record the real authorized verification before releasing funds. Focus the response on the risky action and compromised authority, rather than waiting for uncertain attribution to an AI system.