A supplier changed their bank details. How do you know it’s really them?

An email arrives from a supplier asking you to use new payment details. The name is familiar, the amount looks right, and the message fits a real project. Those details make the request plausible. They do not establish that the person making it is authorized.

That request could come from an impersonator or from a real supplier mailbox that someone else now controls. Either way, the payment process needs to verify the change. Judging the spelling, tone or apparent familiarity of the email is not enough.

What email authentication actually checks

Email authentication validates aspects of a message’s domain origin. SPF checks whether a sending system is authorized for an envelope-sender domain. DKIM verifies a domain’s cryptographic signature over selected message content. DMARC evaluates alignment between the visible From domain and a qualifying SPF or DKIM result and publishes handling policy. These checks are valuable, but they do not approve a bank-account change.

The DMARC specification and its SPF/DKIM alignment model

A compromised supplier mailbox can send mail that passes the domain’s authentication checks. A lookalike domain can also authenticate its own messages correctly while impersonating another business in the display name or body. A DMARC pass tells you about domain alignment. It does not tell you that the supplier approved new banking instructions.

To approve the change, verify the supplier through an established contact route and keep a separate approval record. Email authentication is useful evidence for the mail system; it cannot stand in for that business decision.

Keep the original message

Preserve an unexpected payment-change request through your organization’s reporting process. Record the message identifier, receipt time and timezone, visible From and Reply-To addresses, claimed supplier and requested action. The response lead may also need full headers and provider traces. A screenshot alone often leaves out those details.

A different Reply-To address may have a legitimate business explanation, and a matching one does not establish legitimacy. The same is true of a message appearing in a familiar conversation. Assess those observations together with provider logs and the independently verified supplier response. Avoid sending the suspicious attachment to additional coworkers simply to ask what they think.

Give payment changes a clear approval process

Keep a record of the request, independent verification, approval and application of the new details. Name the person responsible for each step and retain the previous instructions through the accounting system’s authorized workflow. For higher-risk changes, have someone other than the verifier apply the new details. The record should still make sense if the email thread is later lost.

For example, a supplier requests new banking details a few hours before a scheduled payment. Accounts payable calls the number already in the supplier record, confirms the change with the established contact, and sends it to the designated approver. If that check fails, the payment stays paused and the response lead gets the original request. Nobody has to make a payment decision based on whether the email looks convincing.

When the supplier’s real mailbox was compromised

The account owner’s response needs to consider active sessions, delegated applications and forwarding or mailbox rules, in addition to the password. Microsoft’s documentation illustrates why application sessions and tokens can have their own revocation behavior. Use the affected provider’s supported incident controls and preserve relevant records before making broad changes.

Microsoft’s explanation of application session revocation

The receiving business still needs to verify the transaction and escalate quickly through its known banking and incident contacts. The technical investigation and any payment-recovery work should exchange confirmed facts through the response lead.

Pause at changes involving money or access

Treat a change to bank details, a request for credentials, an unexpected sign-in approval, or a demand for confidential files as a decision that needs verification. Urgency, secrecy, and pressure to bypass the usual process are reasons to slow down.

Good grammar offers little reassurance here. Neither does a familiar email thread or a genuine sender address: the account itself may be under someone else’s control.

Verify through a route you already trust

Contact the supplier using a number from your existing records or another independently established channel. Do not use the new phone number supplied in the message you are checking. Follow your organization’s approval process before changing payment instructions.

For sign-in requests, open the service from your own bookmark or trusted application. An unexpected request to approve MFA should be reported through the team’s established route. Avoid engaging with a suspicious sender to argue about whether the message is real.

Make it easy to raise a concern

• Give the team one clear place to report suspicious requests.

• Explain which details the response lead needs and how to preserve the original message safely.

• Make it acceptable to pause a transaction while checking it.

• Thank people for reporting promptly, including when they have already clicked or replied.

If a payment has already gone out or an account may be affected, contact the bank or provider through a known channel and notify your response lead promptly. Report what happened, including any clicks or replies. Trying to fix it quietly on your own can cost time the response team needs.

Sources & further reading

NIST: Phishing guidance for small businesses

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.