A supplier bank-change email passes SPF, DKIM and DMARC - what has that actually proved?

## What each check asserts, precisely - **SPF** answers: was this connecting server listed as permitted to send for the envelope sender's domain? It is a statement by a domain owner about which hosts may send on their behalf. - **DKIM** answers: does this cryptographic signature validate against a public key published by the signing domain, over the headers and body it covers? It is a statement that the signing domain vouched for this message and that the covered parts were not altered in transit. - **DMARC** answers: did SPF or DKIM pass *for a domain that aligns with the domain in the visible From header*? Alignment is the part that matters, because SPF and DKIM alone can pass for a domain the reader never sees. Every one of those is a claim about **domain provenance**. None is a claim about the human at the keyboard, and none is a claim about the truthfulness of the contents. Confusing provenance with honesty is the single most common wrong answer here. ## The two ways a fraudulent bank change passes all three **1. A lookalike domain the operator owns.** The operator registers something that reads like the supplier - a swapped character, an added word, a different top-level domain - and configures it properly: SPF record published, DKIM key published, DMARC policy published. Everything passes, because the operator is the legitimate owner of that domain. Authentication was never designed to answer "is this domain the one you meant?" Display names make it worse. The From header carries a human-readable name that receivers show and authentication does not evaluate. A message can render as *Acme Industrial Supplies (Accounts)* while the authenticated domain is something else entirely, and many mail clients show only the name. **2. The supplier's real mailbox.** If the supplier's own account has been taken over, the message is genuinely from the genuine domain, sent by the genuine infrastructure. It will pass every check that legitimate correspondence passes, because at the protocol level it *is* legitimate correspondence. Nothing you can inspect about the message distinguishes it. ## What a failure would have told you, and why that asymmetry matters The checks are far more informative when they fail than when they pass. A DMARC failure on a domain publishing a strict policy is a real signal that something is off. A pass tells you the sender's paperwork is in order - which the operator also has. Treating a pass as evidence of legitimacy inverts the direction of the claim, exactly like treating a successful authentication as proof that a particular person was present. There is a second inversion worth stating: publishing a strict DMARC policy on *your* domain protects other people from receiving forged mail that claims to be you. It does very little to protect your accounts-payable inbox from mail sent by third-party domains, which is where this attack lives. ## Where the assurance has to come from instead Since every property of the message is either forgeable or genuinely owned by the operator, assurance must come from outside the message. The workable rule is that a change to banking details is authorised only after contact through a route the requester did not supply - a phone number captured at onboarding or written into the signed contract, dialled to a named contact. That step does not care whether authentication passed, whether the domain looks right, or whether the mailbox was compromised, because it depends on something the operator cannot substitute. ## Answering well State the scope of each check in one clause each, name the two pass-anyway paths, and land on the conclusion: an all-pass result is the *expected* state of a competent fraud, so it moves the verification decision not at all. Candidates who say "DMARC passed, so it really is the supplier" have made the classic direction-of-claim error and will usually make it again about a successful login.