BLOG
Are you ready for DMARC?
The next step in email authentication is DMARC. I wrote a Brief DMARC primer a few years ago to help clear up some of the questions about DMARC and alignment. But I didn’t talk much about where DMARC was going. Part of the reason was I didn’t know where things were going and too much was unclear to even speculate.
We’re almost 2 years down the line from the security issues that prompted Yahoo to turn on p=reject in their DMARC record. This broke a lot of common uses of email. A lot of the damage created by this has been mitigated and efforts to fix it continue. There’s even an IETF draft looking at ways to transfer authentication through mailing lists and third parties.
For 2016, DMARC alignment is going to be a major factor in deliverability for bulk email, even in the absence of a published DMARC record.
What’s DMARC alignment?
DMARC alignment is where either the Return Path (5321.From, Envelope From, Bounce String) or the DKIM d= value is in the same domain space as the visible from address (5322.From, sender).
Why do you think so?
I’m already seeing some delivery issues for certain domains that are unaligned, particularly at ISPs like AOL and Yahoo.
What do I do?
If you’re an ESP customer, ask your ESP about using a custom bounce string / return path so your domain aligns. You just need to add a MX record for that domain that points to the ESPs bounce handler.
If you’re an ESP customer and can’t add a MX, ask them about signing your mail with a custom DKIM key that is at your domain. You will need to do a little DNS work – either publishing your public key yourself or publishing a DNS record that points to their public key server.
If you’re an ESP, and you can’t sign with custom keys or handle custom 5321.From addresses, you need to look at your development path and figure out how fast you can do either.
I’m not publishing DMARC, so this doesn’t affect me.
ISPs are already evaluating DMARC alignment on all incoming mail.
dmarc=pass (aol.com: the domain example.com reports that SPF aligns in relaxed mode, DKIM is unaligned.) header.from=test.example.com;
It’s a short step to use that as part of their delivery decisions, particularly when there is no alignment.
My unaligned mail is delivering just fine.
I’m sure it is. I also don’t think that’s a given for the future. I think it’s wise to be looking to have as much of your mail as possible aligned sooner rather than later.
Great post, and I am still trying to wrap my head around the impact of this.
Let’s say an ESP is mailing using a client’s custom subdomain. That subdomain is used in the smtp.mailfrom and the return path of the email. The client has SPF and DKIM records in their external DNS under the subdomain, and the ESP is signing with valid SPF and DKIM.
The IP is pooled, with many subdomains, and the ESP is using their own domain name in the EHLO / HELO in order to avoid issues with reverse DNS mismatches. This domain name is obviously going to be different from the domain used in mailfrom and return path.
Would this be considered aligned, since the smtp.mailfrom and return path use the same subdomain name?
Or does introducing a different domain name in the EHLO / HELO cause any issues with alignment?
If the smtp.mailfrom and the visible from are in the same domain space then that would be considered aligned, no matter what the HELO / EHLO value is. As I understand it DMARC looks at “whatever passes” in terms of the authentication. So if SPF passes and is aligned, then the message is DMARC authenticated. If DKIM passes and is aligned then the message is DMARC authenticated. The pass is enough to make it aligned and passed, even if the d= is unaligned (or doesn’t pass) or SPF doesn’t pass.
In a case of conflict the pass wins. What that means to me is even if the HELO/EHLO is unaligned, it will be ignored and won’t “break” authentication.
Additionally, the current DMARC spec (https://tools.ietf.org/html/rfc7489) specifies checking the smtp.mailfrom and not the HELO/EHLO value. Section 4.1 says:
I don’t see any problem with an unaligned HELO/EHLO. Of course, different places might implement the spec differently and check the HELO/EHLO but I don’t see that as being a widespread problem or a problem at the major ISPs.
Does that answer your question?
That is a very thorough (and helpful) answer. Thanks!