Blog · Dmarc
How to Detect Vendor Cancellation Email Scams That Pass SPF, DKIM, and DMARC
DMARC only governs the From domain. An attacker who controls a lookalike domain signs the message with their own keys, so SPF, DKIM, and DMARC all pass on the attacker's domain, not yours. A vendor cancellation notice lands in someone's inbox. It looks like the real vendor. Authentication passes on every check. The recipient has about sixty seconds to decide whether to click. Here is the detection checklist and the verification workflow that prevents the click, plus an honest note on what email authentication can and cannot see here.
Why do vendor cancellation email scams pass SPF, DKIM, and DMARC?
Authentication is passing because the attacker chose infrastructure that would pass, not because the message is legitimate. There are two ways these messages end up authenticated.
Mechanism 1: the attacker sends from a lookalike domain. The attacker registers something close to the real vendor's domain (acme-billing.co when the real vendor is acme.com), sets up SPF and DKIM on that domain, and sends the cancellation notice from there. The recipient's DMARC policy does nothing because the From domain is not the recipient's domain. Authentication passes on the attacker's domain, which has nothing to do with the recipient.
Mechanism 2: a real vendor's sending infrastructure was compromised. Phished credentials, an OAuth grant to the wrong app, or a hijacked SMTP relay. The cancellation notice is genuinely from the vendor's infrastructure. SPF, DKIM, and DMARC pass because the message really did come from where it claims. The recipient cannot tell from authentication alone.
Both mechanisms produce the same outcome: a message that looks authentic and passes every technical check. Authentication passing is not legitimacy. The fix is verification on a channel the attacker does not control.
What does a vendor cancellation scam look like in the inbox?
Here is a synthetic example. The real vendor is "Acme Cloud" at acmecloud.com. The cancellation notice comes from what looks like Acme Cloud's billing team.
```
From: Acme Cloud Billing
Six signals give it away. None of them require specialist tooling.
How do you tell whether a vendor cancellation notice is real or fake?
Run these checks in order. The first one that matches is enough to slow down.
Display name vs actual From domain. The display name says "Acme Cloud Billing". The actual From address is acmecloud-billing.com, not acmecloud.com. A real vendor sends from its own domain. Hover the sender to see the real address. If they do not match, treat the message as suspect.
Lookalike domain patterns. Common tricks include adding a hyphen (acme-cloud.com), adding a word (acmecloud-billing.com), swapping the TLD (acmecloud.support), or using a country code TLD the real brand does not use (acmecloud.co when the real brand is .com). If the domain is not exactly the one the vendor has used in every previous invoice, treat it as suspect.
Reply-To mismatch. In the example, the Reply-To is acmecloud-helpdesk.net, which is not the same as the From domain. The attacker uses a different Reply-To so that any reply goes to a mailbox they control. Real vendors keep the Reply-To on their own domain.
Link target mismatch. The link says acmecloud-helpdesk.net/billing/verify. The real vendor's domain is acmecloud.com. The link points somewhere else. Hover without clicking. If the link target is not the vendor's real domain, treat it as suspect.
Urgency and timing. A cancellation that demands action within 48 hours, sent late on a Friday afternoon at the end of a month, is a textbook BEC pattern. Urgency is the attacker's tool because it shortens the verification window. Real vendors send reminders weeks in advance and they do not threaten suspension by email out of the blue.
Generic greeting. "Dear Customer" when the real vendor has been emailing this recipient by name for years is a tell. So is any cancellation notice that does not reference an account number, a recent invoice, or a specific contract. The attacker usually does not have those details, so they omit them.
Helpdesk portal on a different domain. The link in the example goes to a domain that is not the vendor's domain, mimicking the vendor's login page. Real vendors do not send you to a portal on a different domain. If the link target is not on the same root domain as the vendor's homepage, treat the link as suspect.
If two or more of these match, do not click and do not reply. Move to the verification workflow.
What verification workflow should staff run before they click or reply?
The whole point of the workflow is to use a channel the attacker does not control. The gateway, the banners, and the monitoring tools are safety nets. The verification workflow is the defense.
Step 1: do not use any contact details from the email. Treat every link, phone number, and Reply-To address in the suspicious email as attacker-controlled until proven otherwise. Even if the URL looks plausible, the attacker registered it yesterday.
Step 2: navigate to the vendor's known domain directly. Open a new browser window. Type the vendor's real domain by hand, or use a bookmark from a previous successful interaction. Do not use the link in the email under any circumstance.
Step 3: log in to the vendor portal the way you normally do. Use the credentials you already have. Look for the cancellation notice inside the portal. If the cancellation is real, it will be visible in the account management section, in the billing section, or in a notification list inside the portal.
Step 4: call the vendor using a known phone number. Use a phone number from a previous invoice, a previous legitimate email, or the vendor's official website. Do not use any phone number from the suspicious email. Ask the vendor's support or account manager to confirm the cancellation.
Step 5: report and move on. If the notice is real, the vendor confirms it on the phone and the portal reflects it. If not, report the email to your security team, delete it, and let your team know that a lookalike is in circulation. Real vendors also appreciate a heads-up.
What can inbox-side controls actually catch here?
Be honest about the limits.
URL rewriting and link sandboxing in a secure email gateway will catch known-bad destinations. They will not catch a brand-new lookalike that the gateway has never seen. Most lookalike domains in active scams are less than a week old when they start sending.
Banner warnings on first-contact senders are useful. They are also noisy. Staff learn to ignore them. Use them, but do not assume the warning stops the click.
Blocking the sender domain is a blunt instrument. Blocking acmecloud-billing.com would also drop a real cancellation if the actual vendor ever sends from that domain. It would not block the next lookalike the attacker registers. Reserve domain blocks for confirmed-bad infrastructure and revisit weekly.
SEG-based BEC filters help when they are trained on the organization and the vendor relationships. They cannot catch a brand-new lookalike with no prior signal. The first message from a fresh lookalike is exactly the message the filter has the least data on.
The inbox side of this problem is a noise problem, not a detection problem. The detection has to come from the human and from the verification workflow.
What can DMARC monitoring see, and what can it not see?
This is the honest section. Two cases are within DMARC monitoring's reach. One important case is not.
Case 1: a real vendor in your auth chain is compromised. If a vendor you whitelist (a payroll provider, a transactional sender, a marketing platform) is compromised and starts sending messages that do not align with your domain, RUA monitoring surfaces the misalignment. You catch it because the message claims to be from your domain but is not.
Case 2: a new sender starts using your domain without authorization. This is the inverse of the cancellation scam. If an attacker registers a lookalike of your domain and tries to impersonate your customers or your vendors by sending as your domain, RUA monitoring shows the new sending source. You catch it because your domain suddenly has a sending IP you did not authorize. This is where DMARC monitoring earns its keep.
The case DMARC monitoring cannot see. A lookalike sending as itself. The attacker registered acmecloud-billing.com and is sending from that domain to your finance team. Their auth chain is theirs, not yours. Your DMARC policy never gets a chance to evaluate the message because the From domain is not yours.
RUA monitoring is still useful for the inverse scenario. Reading RUA reports manually gives you the same picture. Tools like DMARCFlow exist specifically to turn RUA data into something an admin can act on without parsing XML every morning, which is exactly where DMARC monitoring helps: catching the case where your own domain is being used to scam your customers or vendors, not the case where an attacker sends from a fresh lookalike that has nothing to do with you.
The short version: what to do today
Verify on a known channel before anyone clicks. Treat cancellation notices with the same suspicion as payment-change notices. Use DMARC reporting for the inverse problem, your domain being impersonated, not for the attacker's lookalike sending as themselves.
The verification workflow is the defense. The gateway is the safety net. The monitoring is the inverse-scenario net. None of them replace all of them.
FAQ
How can a vendor cancellation scam pass SPF, DKIM, and DMARC?
DMARC only governs the From domain. An attacker who controls a lookalike domain signs the message with their own keys and passes every test on their own domain. The receiver's policy does not enter the domain. The message authenticates on the attacker's domain, not on the recipient's.
What is the difference between a vendor email compromise and a lookalike domain impersonation?
In a vendor email compromise, the attacker sends from a real vendor's infrastructure using stolen credentials or a hijacked account. Authentication passes because the message really did come from the vendor. In a lookalike impersonation, the attacker sends from a domain they registered that looks like the vendor's domain. Authentication passes on the attacker's domain, which has nothing to do with the recipient.
How do I verify a vendor cancellation notice without using any contact details from the email?
Navigate to the vendor's known domain directly in a new browser window. Log in using credentials you already have. Look for the cancellation in the portal. Then call the vendor using a phone number from a previous invoice or the vendor's official website, not from the email. If the notice is real, the vendor will confirm it and the portal will show it.
Should I block the sender of a suspicious vendor cancellation email?
Not as a first move. Blocking the specific address or lookalike domain only catches that one lookalike. The attacker registers the next one within hours. Use inbox-side reports to your security team so they can decide on broader blocks based on patterns, not single messages.
Will a DMARC monitoring tool catch vendor cancellation scams sent from lookalike domains?
No. DMARC monitoring only sees authentication results for your own sending sources. A lookalike sending as itself is on the attacker's auth chain. DMARC monitoring catches the inverse case, where an attacker tries to send from your domain, and it catches compromised legitimate senders in your auth chain. It does not see lookalikes sending as the lookalike.
What is the actual workflow finance and AP teams should follow when a cancellation notice arrives?
Treat the email as suspect. Do not click any link, do not call any number, and do not reply to any address in the email. Open the vendor's real domain by hand. Log in to the vendor portal. Call the vendor using a known phone number. If the notice is real, the portal and the phone will both confirm it. If not, report the email and delete it.