DMARC: The State of Domain-based Email Authentication – Part 2
Monday, September 11th, 2017Building a safer email ecosystem with DMARC
In our previous post, we described two techniques for authenticating an email sender:
- Sender Policy Framework (SPF), IETF RFC 7208, which verifies if the sending MTA is indeed authorized to send mail on behalf of a domain; and
- DomainKeys Identified Mail (DKIM), IETF RFC 6376, where a domain shows “ownership” of a mail it sends by signing portions of it so that critical aspects cannot be forged by intermediaries.
Like most technologies, these are just individual weapons in the arsenal for fighting phishing and spam. Weapons, like all tools, need to be properly used if they are to be effective. Unfortunately, as we described in the earlier post, both SPF and DKIM are deployed in a manner that reduces their usefulness. With SPF, the validation policy set by the sender is often chosen in a manner that leaves handling authentication failures at the discretion of the recipient. DKIM, on the other hand, does not even have an explicit policy directive set by the sender. Moreover, in a heterogeneous mail environment, some perfectly legitimate MTAs might not be capable of signing messages.
Thus, receivers in actual deployments tend to “soft fail” any SPF and/or DKIM validation failures as there are reasonable situations when legitimate mail can fail such checks. A common example is forwarded mail (which fails SPF), or mail sent via a mailing list (which fails DKIM). Mail providers consider it better to deliver most mail (even if some are fake or spammy) rather than risk dropping legitimate mail. Thus, neither of these techniques individually or combined provide clear guidance to receivers, and the resulting actions can be inconsistent.
Read the rest of this post »
We have recently looked at 
So, you’re minding your own business, going about your daily tasks, checking your email, and suddenly your INBOX is flooded with a series of non-delivery reports (aka 
