How to Detect Vendor-Compromise Phishing With DMARC

Your vendor sends you an email. Real company name, real reply-to address, real mail server - SPF passes, DKIM passes, DMARC might pass too. The only thing different from last month's invoice: the PDF attached contains credential-harvesting links instead of a real invoice.

You've been hit by a vendor-compromise phishing campaign. And your existing email security didn't catch it.

The reason this attack works is that email authentication protocols verify sending authority, not content legitimacy. SPF confirms a server is allowed to send for a domain. DKIM confirms a message wasn't altered in transit. DMARC checks that SPF and DKIM align with the From header domain. None of this tells you whether the person sending is a legitimate employee or an attacker who compromised the vendor's mail system.

DMARCFlow helps you close this gap - not by changing email authentication, but by giving you continuous visibility into exactly which servers are sending as your domain, which authentication results they're getting, and when new sending infrastructure appears. Most email security stops at the border. DMARCFlow watches the whole picture.

The attack pattern: how a trusted vendor becomes a phishing vector

A vendor with poor security gets breached. The attacker doesn't set up their own mail server - they use the vendor's. They send emails to the vendor's customer list. The emails look legitimate: correct domain, correct branding, correct email tone. The only difference from the vendor's normal traffic is the attachment or link.

These campaigns are effective because recipients trust the sender domain. That trust was earned by the vendor over years of legitimate correspondence. Attackers borrow it for free.

Common vendor types used in these campaigns include logistics companies sending shipping notification PDFs, invoice processors sending payment reminders, event management companies sending ticket confirmations, and HR service providers sending payslip notifications.

The key indicator: same vendor, same sending infrastructure, changing malicious payload. If you see a spike in phishing reports mentioning a vendor you work with, and only the attachment changed between campaigns, that's the signature of this attack pattern.

Why your existing email security misses it

Your secure email gateway checks for malicious links, known malware signatures, and suspicious attachment types. It likely checks SPF, DKIM, and DMARC alignment in passing. None of this flags an email from a legitimate vendor sending from their legitimate infrastructure - because that's exactly what it is.

The attack doesn't exploit a technical vulnerability in email authentication. It exploits the trust relationship between a vendor and their customers. The authentication protocols work exactly as designed; the threat actor simply uses them from an authorized source.

Reading DMARC reports to find vendor-compromise campaigns

Your DMARC aggregate reports tell you which IPs are sending mail as your domain, whether they pass authentication, and what domains they're claiming to send from. If a vendor is compromised and sending phishing as your domain (or using your domain as the From address), you'll see evidence in these reports.

Unknown sending IPs: Your DMARC report should list every IP that sends as your domain. If you see an IP you don't recognize - especially one associated with a vendor you didn't knowingly authorize - that's a signal worth investigating. Mismatched From domains: If a vendor sends email where the From header shows your domain but the vendor's mail server is the actual source, DMARC reports capture that. Alignment failures show up as "fail" results. With a p=none policy you see these in reports but they still deliver - which is why moving to p=reject matters once you've mapped your legitimate sending sources. Volume anomalies from a single source: A vendor that normally sends 10 emails a month suddenly sending 500? That shows up in sending volume data. DMARCFlow tracks this across all your domains so unusual patterns surface quickly instead of sitting unnoticed in raw reports. Cross-domain alignment issues: If a vendor is compromised and trying to send from your domain without proper authorization, DMARC alignment will fail - but only if you're collecting the reports.

How to investigate when you suspect a vendor compromise

If you receive reports of suspicious emails appearing to come from a vendor, here's the investigation sequence:

1. Check your DMARC reports for that vendor's IPs: Look up the sending IP in your aggregate reports. Does it match the vendor's known mail server ranges? An unexpected IP doesn't automatically mean compromise, but it means you should verify.

2. Compare the sending volume to historical baseline: If the vendor normally sends 20 invoices per month and suddenly sent 200 in a day, that's an anomaly. Either they had a marketing blast, or someone else was using their infrastructure.

3. Look at authentication results for the sending IPs: Are SPF and DKIM passing for IPs you don't recognize? Passing results from unexpected sources suggest the attacker has compromised the vendor's entire email system and set up proper sending infrastructure to maximize deliverability.

4. Check what domain the email claims to be from: If the email's From header shows your domain but the vendor's infrastructure sent it, that's a misalignment that DMARC catches - if you're collecting reports.

5. Contact the vendor through a verified channel: Don't reply to the suspicious email. Find the vendor's known contact details separately and ask if they've had a security incident.

What you can do before compromise happens

Vendor-compromise phishing is hard to prevent entirely - you can't control a vendor's security posture. But you can reduce your exposure and catch compromises faster.

Require DMARC enforcement for your own domains: If your domains have p=reject set, vendors cannot send mail using your domain as the From address without proper SPF/DKIM alignment. Any attempt from a compromised vendor to use your domain gets rejected at destination mail servers that enforce DMARC. Monitor your DMARC reports continuously: You can't act on data you don't see. DMARCFlow aggregates and analyzes your DMARC reports, surfacing new sending sources, authentication failures, and volume anomalies so you can respond when something looks wrong - not after users report the phishing. Set up alerts for new sending sources: When a new IP starts sending as your domain, you should know immediately. Manual report review misses this until the damage is done. Vet vendor email authentication during procurement: A vendor with proper SPF, DKIM, and DMARC is harder to abuse in this attack pattern. Make it a vendor security requirement in your procurement process.

What DMARC p=reject would and wouldn't prevent

If your domain has p=reject, unauthorized vendors cannot successfully send mail using your domain as the From address - their alignment failures get rejected at destination servers that enforce DMARC. This protects your domain's reputation.

However, p=reject doesn't prevent a vendor from sending phishing from their own domain while impersonating your organization through other means - display name spoofing, lookalike domains that differ by one character. The DMARC protection applies specifically to domain-level alignment in the From header.

In the vendor-compromise scenario, the most likely failure mode is a compromised vendor whose legitimate domain is the actual sending source. Their own DMARC policy is what matters - not yours. If they have p=none or no DMARC at all, they can be used to send phishing that appears to come from their own domain to your users. This is why vendor email security matters: a vendor with weak DMARC is a risk to their customers.