An authenticated message can still carry a fraudulent request. That statement does not make SPF, DKIM or DMARC unimportant. It defines their boundary.
Email authentication supplies evidence about domain identities and message handling. Business authorisation answers a different question: was this person or system entitled to make this request, and should the organisation act on it? A safe process needs both.
Ask what the pass actually proves
Under RFC 9989 §5.3.5 and RFC 9989 §5.4, a message-level DMARC pass means the receiver found at least one passing SPF or DKIM path whose authenticated domain aligned with the domain in From. It does not prove:
- which individual controlled the account;
- that the account was not compromised;
- that an invoice or bank change is legitimate;
- that a link or attachment is harmless;
- that the domain is the brand the recipient had in mind.
The precise statement is useful: the message presented a From domain and produced qualifying authentication evidence related to that domain. Avoid converting it into the broader claim that the sender or message is safe.
Classify the identity abuse before choosing a response
Different attacks can look similar in an inbox but sit on different sides of the authentication boundary.
- Pattern: Exact-domain forgery; What authentication may show: No aligned passing path, subject to receiver evidence and handling; Control and response focus: DMARC policy, sender coverage, receiver controls and investigation
- Pattern: Lookalike domain; What authentication may show: The lookalike may authenticate its own domain successfully; Control and response focus: Domain monitoring, user cues, filtering, reporting and proportionate abuse action
- Pattern: Display-name deception; What authentication may show: An unrelated domain can authenticate while presenting a familiar name; Control and response focus: Display-name analysis, context, user reporting and independent verification
- Pattern: Compromised authorised account; What authentication may show: The real domain can pass authentication; Control and response focus: Account security, session and sign-in investigation, containment and business verification
- Pattern: Compromised supplier; What authentication may show: The supplier's real domain can pass; Control and response focus: Supplier incident coordination, transaction controls and alternate-channel confirmation
DMARC is strongest against unauthorised use of the domain identity it covers. It does not create ownership of visually similar domains, verify the truth of a display name or decide whether a real account was used with proper authority.
Follow a fictional payment-change incident
The following scenario is synthetic. It is designed to show the evidence chain without implying a customer incident.
A finance employee receives a request from accounts@supplier.example asking to change bank details. Assuming an applicable policy, trusted receiver results show an aligned DKIM pass for supplier.example, so the message passes DMARC. The thread history and writing style also appear familiar.
The employee does not approve the change based on those signals. They call a previously verified supplier number and learn that the mailbox was compromised. The organisation freezes the requested change, preserves the original message and provides the supplier with timestamps and relevant headers.
Authentication worked as designed: it showed that the message used the supplier's authenticated domain. The independent verification control stopped an unauthorised transaction that domain authentication could not adjudicate.
Preserve protocol evidence and business evidence
For a consequential incident, retain an access-controlled original message before producing a redacted copy. RFC 8601 §7.1 defines trusted result boundaries; edits to signed material can affect re-verification under RFC 6376 §3.7. Useful technical evidence can include the trusted Authentication-Results, relevant Received fields, From, Reply-To, Return-Path, DKIM signatures, message identifiers, timestamps and receiving logs.
Useful business evidence includes the request, the intended action, established approval rules, contact method used for verification and the outcome. Keep facts separate from inference. A raw pass is not proof of compromise, and a DMARC failure is not proof that harm occurred.
Under RFC 9990 §3.1, aggregate DMARC reports can help domain owners understand observed authentication and disposition patterns. They are not a complete record of individual messages, and they do not usually provide the content needed to decide whether a particular request was authorised. Under RFC 9989 §5.3.9, failure reports, where generated, require careful privacy and access handling and are not universally available.
Build independent verification into sensitive workflows
High-impact actions should use controls that do not depend solely on the incoming message. Examples include:
- verifying bank-detail changes through a previously approved channel;
- requiring dual approval for payments above defined thresholds;
- preventing an email thread from supplying both the request and the verification contact;
- using authenticated portals for sensitive data exchange;
- treating urgent secrecy, unusual timing or control bypass as risk signals.
These are business controls, not substitutes for authentication. Authentication reduces ambiguity about domain use, while transaction controls reduce the consequence of an authenticated but unauthorised request.
Communicate the boundary without weakening the programme
Saying that DMARC does not stop every phishing technique is accurate. Saying that it is therefore ineffective is not. An enforced policy can reduce successful unauthorised use of a protected domain, improve receiver evidence and make ownership of legitimate sending paths explicit.
The right message is layered: protect the domain, secure the accounts, detect lookalikes and deceptive presentation, and independently verify sensitive actions. Use the DMARC identity guide for the domain-level result and the sender inventory for authorised-service ownership.
Keep the conclusion within the evidence
The fictional payment-change case keeps two independent outcomes: domain authentication passed; the proposed transaction was not approved after separate verification. Do not report compromise from a pass alone. Preserve only authorized incident disclosures and keep a trusted verification contact outside the incoming request. No supplier was contacted and no transaction or incident response was performed.