compromised vendor mailbox passes spf dkim and dmarc but sends fraudulent bank-detail changes

TL;DR

Stop grading the message and start grading the request, because this mail is genuinely from the vendor mailbox and passes SPF, DKIM, and DMARC honestly: put a hard process rule on bank detail changes, call back on a number from your own records, require a second approver for any account change, and notify the vendor through a separate channel that their mailbox is likely compromised. No mail filter setting will catch a real account sending a plausible request, so the finance process is the control.

compromised vendor mailbox passes spf dkim and dmarc but sends fraudulent bank-detail changes

Use this when

• A bank detail change or urgent payment request arrived from a real vendor contact address.
• Authentication results show aligned passes for the vendor domain.
• The vendor later confirms, or you suspect, their mailbox was compromised.

Not for this skill when

• The vendor address is spoofed and fails authentication. Block and tune the filter for that case instead.
• Your own mailbox is the compromised one. Run your internal account incident process first.

Steps

1. Freeze any payment tied to the request and preserve the message with full headers for the vendor and for insurers or police if needed. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the payment is on hold and the evidence copy is stored
2. Contact the vendor through a pre existing phone number or a separate contact, never the number in the suspect message, and ask whether they sent it. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the vendor confirms or denies the request through an independent channel
3. If denied, alert your finance team tenant wide about the vendor compromise and search for other messages from that account in the risk window. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: all messages from the vendor account in the window are listed and reviewed
4. Write or tighten the bank change procedure: independent callback, dual approval, and a cooling off period before first payment to new details. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the updated procedure is published and finance leads have acknowledged it
5. Agree with the vendor what their all clear will look like and which new contact path to trust, then lift the freeze deliberately. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the all clear criteria are recorded and the freeze is lifted in writing

Why it happens

Authentication proves a message came from the account it claims, not that the account is still controlled by its owner. A compromised vendor mailbox is therefore the perfect BEC vehicle: every technical check passes, the writing style and thread history are real, and only the request itself is wrong. Organisations that treat authentication as trust keep losing this exact fraud; organisations that treat bank changes as a privileged operation, verified out of band every time, do not.

Variants and edge cases

compromised vendor mailbox passes spf dkim dmarc fraudulent bank details

The passes everything wording that confuses mail teams.

vendor email compromise bank change fraud callback procedure fix

The procedure variant for finance and security together.

real vendor account sends fake invoice payment diversion defence

The payment diversion variant naming the loss type.

Compatibility: Defender and gateway authentication reporting, finance payment control procedures, vendor incident communication.

Edge cases to check:

• Thread hijacking means the fraudulent request may reply inside a genuine invoice thread; train staff that thread continuity is not proof either.
• Keep a vendor contact sheet with verified numbers collected at onboarding, before any incident needs them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zwO8GGuP-D4itJ2LqQnqlA