Information Security
| On
June 4, 2019 4:31 am

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

By Sean Whalen

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 third party DMARC analytics inboxes, despite the fact that sharing those reports is a cornerstone of the DMARC standard.

Note the phrase third party. Not sending DMARC aggregate reports is bad enough. 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: It’s time to rethink your priorities, starting with 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.


This post was last modified on May 23, 2021 1:43 pm

Sean Whalen

Sean Whalen is an Information Security Engineer in the healthcare industry, and founder of the InfoSec Speakeasy, specializing in intelligence and malware analysis. Previously, he worked as an intelligence analyst in the defense industry. He has a passion for open source software, and sci-fi.

View Comments

  • Testify, brother. Open those RFE's folks!

    Cancel reply

    Leave a Comment

  • 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 ""?
    Thank you!

    Cancel reply

    Leave a Comment

    • I believe he means Proofpoint customers should open a "Request For Enhancement" with Proofpoint.

      Cancel reply

      Leave a Comment

  • 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.

    Cancel reply

    Leave a Comment

Leave a Comment