Payment-Change Email With SPF Fail but DKIM Pass
A CFO forwards a payment-change request to you. The message appears to come from [email protected], a long-standing supplier, and asks that future invoices be paid to a new bank account. The full headers show: SPF fail for the connecting IP 185.220.101.47 (not listed in vendor-example.com's SPF record); DKIM pass with d=vendor-example.com and a selector the vendor has used for two years; DMARC pass because DKIM aligns; Received chain shows the message entered a freemail relay then the corporate gateway. The body contains no obvious lure, references a real outstanding invoice number, and the CFO has already replied once. The vendor's published phone number reaches a receptionist who says 'our email is fine.' You have 48 hours before the payment run.
1. Given SPF fail but DKIM pass and DMARC pass, what are the plausible explanations for this message's origin, and which do the headers support?
Read the worked answer
The authentication results conflict because they test different things, and none of them proves who typed the message.
- SPF authenticates the connecting IP against the envelope sender domain. A fail means the sending IP is not authorized for that envelope domain. It may not be the same domain as the visible From address.
- DKIM pass means the signed headers and body hash verify against a key published for d=vendor-example.com. The signer had the vendor's private key, and the content has not changed since signing. This is strong evidence the message passed through vendor-controlled signing infrastructure or a service holding that key.
- DMARC pass follows from DKIM alignment. It authenticates the domain, not the human sender.
Plausible explanations:
- Vendor mailbox or account compromise: the attacker sent through vendor webmail or a relay that signs with the vendor key.
- Vendor relay or ESP misconfiguration: the sending IP is missing from SPF but the message is legitimately signed.
- Malicious insider at the vendor.
- Theft of the DKIM key plus separate sending infrastructure.
The headers support a message that was signed by the vendor domain but sent from an IP the vendor has not authorized. They do not by themselves distinguish account compromise from a legitimate-but-misconfigured relay. The freemail hop and the connecting IP warrant checking against the vendor's outbound logs and against other messages from the same IP.
2. What preservation and verification steps do you take in the next 48 hours, and what do you tell the CFO?
Read the worked answer
Preserve first, verify through an independent channel, and stop the payment.
Preservation
- Obtain the original message as an .eml or raw export with full headers from the CFO's mailbox; hash it; do not rely on a forwarded copy.
- Place a legal hold on the CFO's mailbox and preserve the reply, sent items, and any subsequent messages.
- Capture the mail gateway logs for the Message-ID, connecting IP, and authentication results.
- Record the bank details exactly as provided.
Verification
- Contact the vendor through a number you already hold, not through the email; ask for the accounts payable manager.
- Ask the vendor's mail administrator to search their logs and sent items for the Message-ID and to confirm whether the message originated from their infrastructure.
- Check domain registration, DNS, and lookalike domains; check whether the new bank account name matches the vendor's legal entity.
- Do not reply to the suspicious message to "test" it; that alerts the sender and may expose more information.
Advice to the CFO: halt the payment, require call-back verification to a previously known number, and preserve all related messages. If funds have moved, contact the bank's fraud unit immediately and consider law enforcement. Document the timeline of advice given. A receptionist saying "our email is fine" is not verification; the response may itself be from a compromised environment.
3. The vendor later says its mail server was compromised and attackers downloaded the mailbox. How does that change attribution, and what records would you request?
Read the worked answer
It changes the mechanism from external spoofing to account takeover at the vendor, and it changes what the headers mean.
If attackers had mailbox access, they could send from the vendor's own infrastructure, so SPF and DKIM may be legitimate and DMARC will pass. The message is then authentic at the domain level, but the human sender is not the vendor's billing staff. Attribution to a specific person still requires corroboration; the connecting IP may be a VPN or proxy.
Request from the vendor:
- Sign-in and mailbox audit logs for the relevant accounts, including IP addresses, user agents, MFA events, and failed attempts.
- Inbox rules, forwarding rules, delegate access, and OAuth application grants created around the incident.
- Sent Items and message trace for the Message-ID and for any other payment-change messages.
- The exact time window of unauthorized access and the list of messages read or downloaded.
Follow-on analysis: compare the attacker IP with other fraud messages; check whether the CFO's reply was read and whether a follow-up message was sent; consider that other customers may have received similar requests. Preserve the vendor's written statement but treat it as a lead, not proof, until supported by logs. The report should distinguish domain authentication from human identity and should not say "the vendor sent it" without qualification.