Blog · Dmarc
How to Detect Vendor Email Compromise When SPF, DKIM, and DMARC All Pass
The paradox: your authentication works but your vendor is being impersonated
Your SPF record is correct. Your DKIM signature validates. Your DMARC policy is set to reject. And yet someone is still receiving emails that appear to come from your vendor, requesting a wire transfer or a change to payment details, and those emails are slipping through.
That is the vendor email compromise problem in one sentence. Standard email authentication proves that a message came from an authorized mail server. It does not prove that the person who sent the message is who they claim to be.
This is not a flaw in your DNS records. It is a gap that sophisticated impersonation attacks exploit deliberately.
Why vendor BEC passes SPF, DKIM, and DMARC
Vendor email compromise works because the attacker operates from infrastructure the real vendor controls or is authorized to use. The email passes authentication because it genuinely originates from servers the vendor has approved.
Here is what is happening at each authentication layer:
SPF passes because the attacker is sending from a mail server the vendor has authorized. If the vendor uses a third-party marketing platform, CRM, or accounting system that has its own sending infrastructure, and that infrastructure is included in the vendor's SPF record, the attacker can send from those same servers and SPF will pass.
DKIM passes because the attacker signs the email with a key the vendor published for one of their authorized sending platforms. Many vendors publish DKIM keys for their marketing platform, support system, or other third-party tools. If the attacker compromises access to one of those platforms, they can sign as the vendor's domain.
DMARC passes because alignment is correct. The RFC5322.From domain matches the domain the vendor uses for sending, and both SPF and DKIM validate against that domain or an authorized subdomain.
The key insight: DMARC alignment checks whether the From domain matches the sending domain. It does not check whether the person using that sending infrastructure is authorized by the vendor to send on their behalf.
What authentication alone cannot tell you
Authentication pass/fail tells you whether an email came from infrastructure the domain owner has authorized. It does not tell you whether that email was sent by a real employee, a compromised account, or someone who has taken over one of the vendor's authorized sending platforms.
Vendor BEC typically involves one of three scenarios:
1. Compromised vendor account - the attacker logs into the real vendor's email account through credential theft, phishing, or a data breach. They send messages from the real account, through the real vendor infrastructure. SPF passes, DKIM passes, DMARC passes. This is the most common scenario.
2. Compromised vendor sending platform - the vendor uses a third-party platform for transactional emails, marketing, or customer support. That platform has its own DKIM key published for the vendor's domain. If the attacker compromises access to that platform, they can sign and send email as the vendor domain. SPF passes because the platform's IPs are in the vendor's SPF record. DKIM passes because the platform has a valid DKIM key for the vendor domain.
3. Lookalike domain with no authentication match - the attacker registers a domain similar to the vendor, such as yourvendor.com vs yourvender.com. They set up SPF and DKIM for this domain and send email appearing to come from the real vendor. In this case, DMARC alignment fails and the email is rejected if the vendor domain has a reject policy. This variant is the easiest to catch and the one most organizations are already protected against.
The first two scenarios are the ones that bypass standard email authentication. Authentication passes. The email looks like it came from the real vendor. But the person sending is not the real vendor.
Header signals that reveal vendor impersonation
Even when authentication passes, specific email header fields reveal signals that something is wrong. Here is what to check:
RFC5322.From vs RFC5321.MailFrom mismatch
The From display name might show the vendor name, but the actual email address is something else. A vendor BEC email might show "From: Accounts Payable
Check the raw email headers, not just the from field as rendered in your email client.
Reply-To address divergence
The email arrives from the vendor domain but replies go to a different address. This is one of the clearest vendor BEC signals. Legitimate vendors using a third-party email platform will usually set the Reply-To to their marketing domain, but unexpected Reply-To domains should always trigger verification.
Unexpected sending infrastructure
The email passes authentication but the sending IP belongs to a network that the vendor does not normally use. A vendor that normally sends from major cloud providers suddenly sending from a residential proxy network is worth investigating.
Inconsistent sender domains across headers
Compare the From domain, the envelope sender (RFC5321.MailFrom), and the DKIM signature domain. If these do not align in a way that matches the vendor's documented sending practices, treat it as suspicious.
Urgency and financial request patterns
Vendor BEC emails almost always involve urgent financial requests: changed bank details, pending invoice payments, immediate wire transfers. The social engineering pattern is consistent even when the technical delivery is sophisticated.
How DMARC aggregate reports help detect vendor impersonation patterns
DMARC aggregate reports do not tell you the content of emails. They tell you which servers are sending email on behalf of your domain and how those emails perform against your authentication policy. This is where vendor BEC detection gets interesting.
When a vendor sends legitimate email on your behalf, their IPs appear in your aggregate reports. You can build a baseline: these are the IPs that normally send for this vendor, these are the sending patterns, this is the volume.
When an attacker sends from infrastructure not in your baseline, the aggregate report shows an unexpected source IP. This is not a failed authentication by default (the attacker may be sending from a legitimate server the vendor uses), but it is an anomaly worth investigating.
DMARCFlow surfaces these anomalies in your aggregate reports. Unexpected sending IPs, sudden changes in sending volume from a vendor domain, and new subdomain activity all appear as signals that something does not match the established pattern.
The practical workflow:
1. Set up aggregate report monitoring for your domain
2. Document which vendors send on your behalf and from which IPs
3. Flag any new sending infrastructure that does not match the documented baseline
4. Investigate before acting on any financial request that arrives from a vendor domain
Practical detection checklist for MSPs and email admins
Use this checklist when a vendor requests a sensitive action (payment, bank change, credentials, account modification):
- [ ] Verify the request through a known-good channel (do not use contact details in the email)
- [ ] Check the RFC5322.From address against the vendor's known domain
- [ ] Examine the Reply-To address: does it match the vendor's normal domain?
- [ ] Inspect raw email headers: do MailFrom, From, and DKIM domains align as expected?
- [ ] Cross-reference the sending IP against your DMARC aggregate report baseline for this vendor
- [ ] Look up the sending IP in a WHOIS database: does it belong to the vendor's infrastructure?
- [ ] Treat any urgency in the request as a signal requiring additional verification
FAQ
Why does vendor impersonation pass SPF and DKIM?
Because the attacker sends from infrastructure the vendor has authorized, or uses a platform the vendor has given sending permissions to. DMARC checks alignment between domains, not whether the sender is authorized to act on behalf of the vendor in a business context. If the attacker compromises a vendor's email account or an authorized sending platform, authentication passes because the technical setup is correct.
How is vendor BEC different from regular phishing?
Regular phishing typically uses forged sender domains that fail DMARC. Vendor BEC uses the real vendor domain with correct authentication, making it invisible to standard email authentication checks. The attack relies on social engineering and account compromise rather than technical sender deception.
What can DMARC aggregate reports tell me about vendor sending patterns?
Aggregate reports show which IPs are sending on your behalf, which ones pass or fail authentication, and what volume they are sending at. By establishing a baseline for each vendor, you can detect new sending infrastructure that does not match their documented setup.
How do I check if a vendor email is legitimate?
Start with out-of-band verification: contact the vendor using contact details from their official website, not from the email in question. Then inspect the email headers, cross-reference sending IPs against your aggregate reports, and verify any financial or credential request through a separate channel.
What header fields reveal vendor impersonation attempts?
Look for mismatches between the displayed From address and the actual RFC5322.From address, unexpected Reply-To domains, sending IPs that do not match the vendor's documented infrastructure, and inconsistencies between the envelope sender (MailFrom) and the From header.
How DMARCFlow helps monitor vendor sending patterns
DMARCFlow aggregates your DMARC reports and maps sending infrastructure to the vendors and services that normally send on your behalf. When a new IP appears that does not match your documented vendor baseline, DMARCFlow flags it as an anomaly. You see a spike in sending from a vendor domain using an IP range you have never seen before. That is the detection signal.
The goal is not to block vendor email. Legitimate vendors send on your behalf, and that is correct behavior. The goal is to detect when the sending pattern changes in ways that suggest an attacker is using the vendor's infrastructure or account.
Configure DMARCFlow to alert on new sending infrastructure for domains where you receive vendor-sent email. Over time, the baseline becomes a reliable way to separate expected vendor sending from unexpected activity that warrants investigation.