A CFO should ask how an organization verifies a request to move money, not only whether its email domain passes authentication. Domain authentication helps receivers evaluate use of a domain. It does not certify a supplier invoice, confirm a bank-account change or prove that the human behind a legitimate account is authorized to make a request.
Distinguish three fraud paths
Direct domain impersonation uses your domain without the required aligned authentication. A lookalike attack uses a different domain that resembles a trusted one. A compromised-account attack can originate through a legitimate, authenticated service. These paths require different evidence and cannot all be closed by publishing a stricter policy on your domain.
RFC 9989 explains authentication alignment with the author domain. A passing result for attacker-controlled billing-supplier.example does not establish that it belongs to a real supplier. Display names and Reply-To destinations can also mislead readers; record them separately from the domain evaluated by DMARC.
Inspect the decision path
Ask finance operations how payment changes are verified using contact information established before the suspicious request. A phone number or link supplied in the same email is not an independent verification route. Use the organization’s approved workflow and separation of duties, especially for changes to bank details or urgent payment exceptions.
The written fictional scenario below describes a message displaying “Supplier Accounts” while the visible From domain is an attacker-controlled lookalike. Its receiver result is a synthetic aligned pass for that lookalike domain. The requested action is a bank-detail change, with account numbers omitted. No real customer incident or actual payment instruction is represented.
Test the control boundary
The example’s legitimate supplier domain is supplier.example.test; the observed sender uses supplier-payments.example.test. Finance pauses the change and calls a previously verified contact from the supplier master record. The fictional contact denies the request. This business verification is part of the scenario, not an actual conversation conducted for this checkpoint.
Compare two stipulated verification routes. Case A uses the pre-existing supplier master-record contact, assumed independently verified before the suspicious request; the fictional denial keeps the change on hold. Case B uses only a number supplied by the suspicious email; verification is inadequate and the change stays on hold. Neither case was computed, called or verified against a real directory. This is an editorial control example, not a mandated financial procedure.
Ask for evidence of routine operation
Request sampled evidence that callbacks and dual approvals occur, that exceptions are escalated and that sender-domain anomalies reach finance staff in understandable terms. Ask who owns remediation for unprotected domains and who owns payment-process failures. Keep reporting proportional: a count of failed DMARC messages is not a count of prevented fraudulent payments.
If an actual suspicious payment request arrives, preserve the message and relevant receiver records, follow the organization’s incident process and independently verify the request before acting. Authentication is valuable evidence, but the money-moving decision must rest on the authorized business process. Do not let an impressive pass rate replace that process.
Ask for a bounded control scorecard
Request the count of sampled payment changes, how many had documented independent verification, unresolved exceptions and their owners. Keep this separate from DMARC message counts. Missing evidence is a gap to investigate, not proof that fraud occurred or that a stated financial loss was prevented.