Good morning DMARC
I’m thinking I may need to deploy DMARC report automation sooner rather than later.
… and so on, and on, and on for a lot further down the mailbox.
Related Posts
About that DMARC "exploit"
- laura
- Dec 6, 2017
A security researcher has identified a rendering flaw that allows for “perfect” phishing emails. From his website:
Read MoreARC: Authenticated Received Chain
- steve
- May 22, 2017
On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.
What breaks?
DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.
This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)
The feds are deploying DMARC
- steve
- Oct 19, 2017
The US National Cybersecurity Assessments & Technical Services Team have issued a mandate on web and email security, including TLS+HSTS for web servers, and STARTTLS+SPF+DKIM+DMARC for email.
It’s … pretty decent for a brief, public requirements doc. It’s compatible with a prudent rollout of email authentication.