Think Like an Email Expert: Solving for DMARC Low Block Rates
Email senders can take important steps to ensure that their legitimate mail is authenticating properly and suspicious mail is blocked. But occasionally, the delivery decisions of mailbox providers like Google, Yahoo!, and AOL are perplexing.
Our “Think Like an Email Expert” blog series seeks to clarify the motivations behind mailbox providers’ filtering decisions and arm senders with actionable advice to protect their email programs.
Over the past two weeks, we have examined why some mailbox providers misinterpret authentication protocols, resulting in SPF failures and DKIM alignment failures. This week, we will look at why suspicious messages from one sender’s DMARC-protected domain were not getting blocked at the rate they should have been.
The problem: Mailbox providers delivering “suspicious” messages
When one of our client’s main sending domains was ready for a DMARC reject policy, we expected to see the percent of suspicious messages blocked rise significantly.
Once DMARC reject is in place on a particular domain, receivers of email from that domain, per the sender’s instruction, will block malicious messages that fail DMARC before they reach the inbox.
After implementation in this case, however, a strong portion of suspicious traffic continued to be delivered. While the client’s legitimate mail was performing well—the authentication protocols passed, and good mail was delivered—the percentage of suspicious messages blocked was as low as forty percent for a given seven day period.
Highlighted area shows the worst DMARC block rate.
The diagnosis: Forwarding messages
As we looked into this problem further, we saw that many of the suspicious messages that were delivered in spite of failing DMARC were in fact emails that had been automatically forwarded by another legitimate mailbox provider due to the end users’ own inbox settings.
These forwarded messages usually retained the original Header From address, thus appearing to come from the original sender. However, because these messages were forwarded, their original sending IP address changed. As a result, they were no longer recognized as “legitimate” sources within the DMARC reporting data.
To understand whether mailbox providers were doing a good job of blocking messages that actually were malicious, we took a look at activity before the low DMARC block rate period occurred. In the graph below, we can see a very large spike in the number of suspicious messages reported, and a nearly one hundred percent block rate of those same messages.
Our team at Return Path deduced that the vast majority of the suspicious messages included in the spike pictured above were in fact fraudulent: they failed DMARC and they did not come from the “good” forwarding IP addresses of legitimate mailbox providers. As a result, the mailbox providers did not, in this case, overrule DMARC to deliver the message, and implemented the blocking policy as expected.
The solution: Filtering out false positives
While DMARC is an excellent way to help mailbox providers block malicious email, mailbox providers occasionally apply their own filtering preferences and deliver messages that they feel are legitimate, despite the fact that they failed DMARC.
So how can a sender decipher what “suspicious messages” are really malicious? The answer lies in classifying DMARC data.
It is possible to organize results so it is easier to identify false positives within DMARC reporting to allow for a more undiluted view of what is happening to the malicious activity sending from your domains.
Once we classified DMARC data for this client’s domain, the percentage of “suspicious” emails that both failed DMARC and were blocked by the mailbox providers (as is intended by the DMARC policy) rose to more acceptable levels:
Highlighted area shows a return to more favorable protection against suspicious emails.
To get the most out of your DMARC reports, it is important to understand the difference between these two types of “suspicious” messages—false positives vs. malicious mail—and work with a partner who can help you understand what is going on at the mailbox provider level.
Want to learn more about how you can protect your customers, employees, and business with DMARC? Check out our guide, Getting Started with DMARC.
About Aaron Stevenson
Aaron Stevenson is a Strategic Project Manager at Return Path. He works closely with our clients to help them diagnose and resolve Email Authentication issues so that they can make full use of the Email Fraud Prevention capabilities of DMARC. Connect with him on Linkedin https://uk.linkedin.com/in/stevensonaaron