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.
Testify, brother. Open those RFE’s folks!
Steve Mitchell, Can you clarify your comment (“Testify, brother. Open those RFE’s folks!”)?
“Testify” to what?
What’s “RFE” in this case? Is it any of the ones listed in “https://en.wikipedia.org/wiki/RFE”?
Thank you!
I believe he means Proofpoint customers should open a “Request For Enhancement” with Proofpoint.
In your “ProofPoint Email Authentication Guide,” would it work to set up a single Policy Route with:
Condition: Message Header From (address Only)
Operator: Is in domain set
Value: default_inbound
This just seems more simple than setting up a route for every domain, but maybe I’m not seeing some very obvious pitfall.
Sean,
Im looking for a DMARC consultant. Ive got my DMARC and doing pretty good, all pass/pass except every once in a while get a failure. Are you able to help me figure out why? Its only a couple of DMARC reports with fail and Ive been doing it a month, probably got 90 reports over my 2 domains. Please email me and then I can give you my phone # and we can talk. Or if you know someone who can help me. Im looking for hourly consulting
I wanted to let you know I just finished writing a 3 part DMARC guide and cited you and this article in the Enterprise section, under Invisible Email Servers. Thanks for writing it!
https://www.brightball.com/articles/enterprise-challenges-with-dmarc-deployment