The email passed authentication. The payment request still needs authorization
DMARC can validate authorized use of a sending domain. It does not establish that the message is truthful, expected, or approved under the recipient’s payment process.
An email security banner says a message passed SPF, DKIM, and DMARC. The sender domain belongs to a real supplier. The message asks finance to replace the supplier’s bank account before today’s payment run. Has the technical check settled the important question?
It has settled one narrower question: the use of the author domain aligns with an authenticated sending domain under the domain owner’s policy. That is valuable. It makes some forms of direct domain spoofing harder and gives receivers a more reliable stream for reputation decisions. It does not prove that the mailbox owner intended this payment change, that the mailbox is uncompromised, or that the request satisfies the recipient’s business controls.
The current IETF specification, RFC 9989, says this unusually clearly: a DMARC pass validates authorized use of the author domain, but does not make a value assertion about the message or domain owner and does not guarantee that delivery is safe or desirable. Email authentication and transaction authorization are related controls with different jobs.
Alignment between the visible author domain and an SPF- or DKIM-authenticated domain.
Whether a person’s mailbox is compromised or a requested payment change is valid.
Verify sensitive changes through a separately governed channel and approval record.
Three different meanings of “authentic”
Email discussions often use one word for three layers:
- Domain authentication: was this message sent using infrastructure authorized for the displayed domain?
- Account control: did the expected person control the mailbox when the message was sent?
- Business authorization: is the requested action allowed under the organization’s process?
A passing DMARC result supports the first layer. It may increase confidence in the source domain, but it cannot carry the other two layers automatically. An attacker who compromises a supplier mailbox can send from the genuine domain and inherit its authentication. A dishonest employee can use a real account. A legitimate executive can ask for an action they are not authorized to approve alone.
The distinction resembles physical mail. A genuine company letterhead and postmark can help establish origin. They do not make every instruction inside the envelope binding.
| Situation | DMARC result may be | Remaining decision |
|---|---|---|
| Attacker directly spoofs the supplier’s protected domain | Fail | Quarantine/reject under policy and investigate |
| Supplier mailbox is compromised | Pass | Verify account control and request through another route |
| Supplier intentionally changes bank details | Pass | Follow the contractual change-and-approval process |
| Lookalike domain sends a message | Pass for the lookalike’s own domain | Notice the identity mismatch; do not confuse authentication with affiliation |
| Internal authorized sender requests an exception | Pass | Decide whether the exception is permitted and independently approved |
Why invoice workflows remain attractive
Accounts-payable teams operate under deadlines and repeated patterns. A request that preserves the familiar supplier name, invoice format, and conversation thread can feel like a small administrative change. Bank details, however, alter the destination of value. That field deserves a stronger boundary than the rest of the invoice.
A good process does not ask a finance employee to become an email-forensics expert. It defines a separate verification route for changes to payee details. The verifier uses a phone number or portal already recorded in the supplier master, not the number in the change message. The conversation is recorded against the supplier account. A second authorized person reviews the change before the next payment.
This is the same channel-switch principle explored in our trust reset analysis: moving from email to phone adds little if the email supplies the phone number and the same unknown party controls both. Independence comes from how the destination was sourced.
What an email gateway should communicate
Technical security interfaces can accidentally overstate certainty. A green “authenticated” badge may be read as “safe” or “approved.” A more accurate interface names the property: “Domain authentication passed.” For sensitive requests, the system can add a process cue: “Payment-detail changes still require independent verification.”
Gateways also need to preserve evidence for analysts. Authentication-Results headers, aligned domains, DKIM signing domains, and routing information help explain why a message passed. They should not be surfaced as a wall of acronyms to the employee making the payment decision.
Organizations should deploy DMARC properly because it reduces unauthorized use of their domains and produces reporting data. The protocol is not weakened by admitting its scope. In fact, precise language prevents teams from assigning it responsibility it was never designed to carry.
Authentication says which identity made a technical claim. Authorization says whether that identity may cause this particular effect.
A bank-change control that survives a real mailbox
The process should assume that the email may come from a genuine account. That design removes the need to solve mailbox compromise before protecting the payment.
Separate the change from the invoice. Route bank-detail amendments into a supplier-master workflow rather than letting them ride as free text in an invoice thread.
Use pre-existing contact data. Call a known supplier representative or use an established vendor portal. If the old contact is unavailable, escalate; do not let the message author nominate their own verifier.
Read back the consequence. Confirm the legal entity, bank, account ending, effective date, and invoices affected. Avoid asking a yes/no question that reveals the expected answer without requiring the other party to identify the change.
Require dual control. The person who records the new destination should not be the only person who releases the first payment. High-risk changes may warrant a cooling period or a low-value confirmation transaction under policy.
Notify through the old route. Send an alert to the previously recorded contact or portal when details change. That creates a chance to detect unauthorized amendments.
Preserve an audit trail. Record who requested, verified, approved, and activated the change. The evidence should be searchable without relying on one employee’s inbox.
These controls also help with legitimate mistakes. A supplier can mistype an account number; an employee can select the wrong record; a rushed executive can misunderstand a request. Security and operational accuracy converge at the same boundary.
When the message is suspicious
Do not reply asking whether the sender was hacked. If the mailbox is under another person’s control, that question returns to the disputed channel. Pause the transaction and contact the supplier through the established route. Report the message to the email-security team with its original headers or approved reporting button.
Review adjacent activity: recent supplier-master changes, pending payments, mailbox forwarding, delegated access, and similar messages to other employees. If money was sent, contact the bank immediately; recovery options shrink quickly.
Training should reflect this nuance. Instead of “trust messages that pass authentication,” teach “use email authentication to assess domain use, then apply the business process to the requested action.” Our article on invoice bank-change verification turns that distinction into a practical sequence for finance teams.
DMARC is a strong answer to an important technical question. Payment approval is a different question. Organizations become safer when every control is allowed to be precise rather than being promoted into a universal trust signal.
The FBI’s business email compromise guidance reaches the same operational boundary from the fraud side: verify changes in account numbers or payment procedures with the requester through an independently located route.
Found a factual error or a source that has changed?
Send a correction →
