Proofpoint is requiring their customers to pay for Email Fraud Defense to get aggregate DMARC data from their gateways

I have written extensively about the DMARC email security standard, including publishing a comprehensive guide on how to implement it, with or without additional third party vendors.  I also do a little consulting on DMARC deployment best practices. One of those consulting clients uses Proofpoint for their email gateway. They also use Dmarcian, a reasonably priced DMARC report analytics service that also publishes a ton of public content for the good of the community. We were considering moving the client’s DMARC policy from monitor only (p=none) to an enforced state (p=reject) after many hours of steadily improving the SPF and DKIM alignment of their email sources. As I took another look at the aggregate (rua) DMARC data in Dmarcian, I noticed something odd: Dmarcian was getting aggregate reports from all of the expected third party email recipients, like Google, Yahoo, Comcast, and the client’s industry partners, but I didn’t see any reporting from the client’s own Proofpoint gateways.

This is a problem, because that meant Dmarcian wasn’t seeing who was spoofing the client’s domain in emails bound for the client’s own gateways. We were blind to potential phishing activity, and critical items like payroll could break if we switched to an enforced DMARC policy without aggregate data from the Proofpoint gateway. Surly, I thought, there must be some configuration option in the Proofpoint console I was overlooking. I’ve never been a Proofpoint customer, so I reached out to some information security partners who are Proofpoint email gateway customers to find out what was going wrong. The answer was simple, infuriating, and confirmed by Proofpoint sales engineers: Proofpoint does not provide DMARC aggregate/rua reports to DMARC analytics inboxes, despite the fact that sharing those reports is a cornerstone of the DMARC standard.

Proofpoint does provide aggregate DMARC data about the mail traffic flowing through a customer’s gateway, but only via Proofpoint’s own DMARC report analytics offering, Proofpoint Email Fraud Defense. In essence, Proofpoint is ensuring that only their DMARC analytics offering provides their existing email gateway customers with the full picture needed to deploy DMARC, at an additional cost, of course.

Update: Office 365 now supports sending DMARC aggregate (rua) reports as a public preview feature.

As a less than ideal workaround for this problem, Proofpoint customers can create a Policy Route that matches on message From headers that end with their domains, and then create a DMARC policy in Proofpoint that applies to that route, and configure the policy to copy any messages that fail DMARC to a separate quarantine folder for later review. That way, they can at least get samples of the emails that failed DMARC, even though they won’t show up in third party analytics.

Update: I have written a complete Proofpoint email authentication guide that describes how to implement this workaround in detail.

Even if a Proofpoint customer employs the above workaround, or pays for Email Fraud Defense, the lack of shared aggregate data harms non-Proofpoint users. Domain owners aren’t getting the valuable DMARC feedback they need from Proofpoint mail recipients to identify email delivery problems and malicious campaigns.

DMARC can only be successful if everyone implementing it does the bare minimum effort of honoring DMARC policies by default, including sending out DMARC aggregate/rua reports to all services. By only sharing aggregate DMARC data in their own Email Fraud Defense service, Proofpoint is valuing vertical integration and market capture over the trustworthiness of email for all, including their own email gateway customers.

To Proofpoint leadership: Please start honoring DMARC policies by default, and sending proper DMARC aggregate/rua reports to everyone according to the RFC by default.

Update: Proofpoint Essentials now supports honoring a domain’s DMARC policy, but it must be turned on by an account administrator and still does not send aggregate/rua email reports.