Domain authentication is useful evidence about a message path. Payment approval is a decision about a business obligation, recipient and amount. Treating the first as the second creates a gap that remains even when SPF, DKIM and DMARC are configured correctly.
Define what the pass establishes
A DMARC pass means an authenticated domain aligns with the message's author domain through an eligible SPF or DKIM path. It does not certify invoice accuracy, bank-account ownership or a person's authority to change payment instructions. RFC 9989. A valid DKIM signature likewise associates signed content with a signing domain, not an automatic approval of every request it contains. RFC 6376.
An attacker may use an authenticated lookalike, a compromised supplier account or a legitimate service. Investigating those mechanisms matters, but the payment team can hold an unverified change while the mail investigation continues. No authentication score should silently replace the organization's payment controls.
Use a separate verification route
Define who may request a change, who independently verifies it and who approves release. Contact the supplier through an already established channel, not a new number or reply address supplied only in the disputed message. Confirm the business instruction using the organization's approved procedure. The FBI specifically recommends independently checking payment and account changes. FBI guidance.
Record the time, authorized verifier, source of the trusted contact and decision without copying unnecessary financial identifiers into a broad incident log. Keep payment details in the approved financial system with appropriate access. For high-risk changes, the example policy uses a second authorized approver; that is a proposed local control, not a universal protocol requirement.
Work through three decisions
Use a proposed rule requiring both independent confirmation and a second authorized approval for the high-risk change. Assume all other organization-specific checks still apply.
- Case A: hypothetical compromised supplier account; domain pass true; independent confirmation false; second approval false. Hold the change.
- Case B: hypothetical authenticated lookalike; domain pass true; independent confirmation false; second approval false. Hold the change.
- Case C: hypothetical legitimate supplier change; domain pass true; independent confirmation true; second approval true. Eligible for further release processing under this example, not an instruction to transfer money or proof that all financial controls passed.
These labels and booleans are stipulated teaching assumptions. No program, callback, account verification or transfer was executed. In a real case, the finance owner needs authorized evidence for every completed check, while technical attribution remains separately documented.
Keep exceptions visible
Urgency, seniority and a familiar signature block should not become hidden bypasses. If an established contact is unavailable, route the case to the designated exception owner and document the decision. Do not quietly treat email authentication as the missing callback. Provide the technical team with the original message while keeping the financial hold under the payment owner's control.
If a suspicious transfer already occurred, promptly involve the financial institution and the organization's incident-response contacts using known channels. Prompt contact can allow the financial institution to assess available recovery options. Do not promise that funds can be recalled. Preserve the request, approvals and timeline, and distinguish containment decisions from unproven attribution.