Ask Laura: Can you help me understand no auth / no entry?

AskLaura_Heading3
Dear Laura,
I’m a little confused by the term “no auth / no entry”. Gmail and other major receivers seem to be moving towards requiring authentication before they’ll even consider delivery.
Does this just mean SPF and DKIM, or does this mean the much more stringent DMARC, as well?
Thanks,
No Shirt, No Shoes, No What Now?

Shirtless & Shoeless,
“No auth / no entry” is one of those adorable little catchphrases that people are starting to use because it makes them sound smart. And when you ask them what it means, they look at you like you’re stupid. Of course we all know what it means. Except when we don’t.
Many people have, wrongly to my mind, interpreted no auth / no entry to mean that ISPs are requiring mail to have a DMARC p=reject record. They’re using this to push people to move to strict DMARC policies. The reality is that no ISP of any size is currently requiring DMARC p=reject for delivery.
Now, ISPs do want to see mail authenticated, either with SPF or DKIM. But even then, unauthenticated mail does get through if it comes from a trusted source and is sent over IPv4.
Mail coming from IPv6 is a different story.  Many ISPs require either SPF or DKIM authentication to receive email over IPv6. Hotmail, Office365 for instance, is outright rejecting unauthenticated email over IPv6. Other ISPs have stated that they expect any email over IPv6 to be authenticated with either SPF or DKIM. This is, to my mind, the true “no auth / no entry.” ISPs are refusing unauthenticated email sent over IPv6. 
At the same time, many of those same ISPs are asking for — but not requiring — SPF or DKIM authentication, for mail sent over IPv4. There are practical reasons for this: many legacy mail servers are still sending legitimate, wanted mail, but that mail is not authenticated. It’s generally accepted by most folks that the upgrade process will be prohibitively resource intensive, and therefore the ISPs aren’t necessarily going to force authentication on IPv4, yet.
I think we are rapidly approaching the point where folks running old, legacy servers are going to have to upgrade and start authenticating email with SPF and DKIM. There’s just too much bad traffic and authentication is too useful a tool. I don’t think that will happen soon, but I do think it will happen within the next year or so.
I think the time when DMARC p=reject is required for delivery is much further down the pike. First off, not every sender, particularly a small sender, can publish DMARC right now. In some cases, it has nothing to do with mail, but more to do with their DNS provider. If a major registrar won’t allow _ (underscore) in DNS records, that means no one using that provider can publish either DKIM or DMARC records. In other cases, the sender might be using a provider that doesn’t allow for alignment. Until these issues are fixed — and they’re mostly outside the control of anyone in the email community — I don’t expect providers to be requiring any DMARC authentication for delivery.
laura

When we work with brands and senders to improve email delivery, there are many questions that come up again and again. For 2016, we thought it might be interesting to answer some of those questions here on the blog so others can benefit from the information.
Confused about delivery in general? Trying to keep up on changing policies and terminology? Need some Email 101 basics? This is the place to ask. We can’t answer specific questions about your server configuration or look at your message structure for the column (please get in touch if you’d like our help with more technical or forensic investigations!), but we’d love to answer your questions about how email works, trends in the industry, or the joys and challenges of cohabiting with felines.
 
Your pal,
Laura

Related Posts

Email Authentication in a nutshell

There are 3 types of authentication currently in use for email.

Read More

Ask Laura: Confused about Authentication

AskLaura_Heading3

Read More

What to expect in 2016

WttWColorEye_forBlogI don’t always do predictions posts, even though they’re  popular. Most years I skip them because I don’t see major changes in the email space. And, I’m not the type to just write a prediction post just to post a prediction.
This year, though, I do see changes for everyone in the email space. Most of them center on finally having to deal with the technical debt that’s been accumulating over the past few years. I see ISPs and ESPs spending a lot of development effort to cope with the ongoing evolution authentication requirements.
When people started seriously looking at how to authenticate email, the first goal was getting organizations to implement the protocols. This was a practical concession; in order for a new protocol to be used it needs to be widely implemented. Phase one of authenticating email was simply about publishing protocols and getting organizations to use them.
During phase one, the organization that authenticated a mail hasn’t been important. In fact, the SPF spec almost guarantees that the ESP domain is the authenticated domain. In DKIM, the spec says any domain could sign as long as they could publish a public key in that domain’s domainkeys record.
ESPs took full advantage of this and lowered their own development overhead by taking most of the authentication responsibility on themselves. Their domains were in the 5321.from and they published the SPF records. Domains they control were in the d= and they generated and published the DKIM keys. Mail was authenticated without ESP customers having to do much.
We’ve hit the end of phase one. Most of the major players in the email space are authenticating outbound email. Many of the major players are checking authentication on the inbound. Phase one was a success.
We’re now entering phase two, and that changes thing. In phase two, SPF and DKIM are used as the foundation for user visible authentication. Neither SPF nor DKIM were designed to be user visible protocols. To understand what they’re authenticating you have to understand SMTP and email. Even now there are days when I begin talking about one of them and have to take a step back and think hard about what is being authenticated. And I use these things every day!
DMARC is the first of these end user visible protocols built on SPF and DKIM. It uses the established and widespread authentication to validate the user visible from address. This authentication requires that the d= value or the 5321.from address belong belong to the same domain in the visible from address. While you can pick whether the alignment between the visible from and the authentication is “strict” or “relaxed” you have no choice about the alignment.
Prior to DMARC no one really paid much attention to the domain doing the authentication. Authentication was a yes or a no question. If the answer was yes, then receivers could use the authenticated domain to build a reputation. But they weren’t really checking much in the way of who was doing the authentication.
In the push to deploy authentication, ESPs assumed the responsibility for authentication deployed ESPs took the responsibility and did most of the work. For many or most customers, authentication was as simple as clicking a checkbox during deployment. Some ESPs do currently let customers authenticate the mail themselves, but there’s enough overhead in getting that deployed that they often charged extra to cover the costs.
DMARC is rapidly becoming an expectation or even a full on requirement for inbox delivery. In order to authenticate with DMARC, the authenticating domain must be in the same domain space as the visible from. If senders want to use their own domain in the visible from, DNS records have to be present in that domain space. Whether it’s a SPF TXT record or a domainkeys record the email sender customer needs to publish the correct information in DNS. Even now, if you try to authenticate with DKIM through google apps, they require you to publish DNS records.
ESPs aren’t in a situation where they can effectively manage authentication alignment for all their customers. Hosting companies are in even worse shape when it comes to letting customers authenticate email. Developers are facing the fact they need to go back and rework their authentication code. Businesses are facing the fact they need to change their processes so customers can authenticate with DMARC.
It’s not just the infrastructure providers that are facing challenges with authentication. Senders are going to discover they can no longer hand authentication off to their ESPs and not worry about it. They’re going to have to get DNS records published by their own staff.
Getting DNS updates through some big companies is sometimes more difficult than it should be. I had one client a few years ago where getting rDNS changed to something non-generic took over a month. From an IT standpoint, changing DNS should require approvals and proper channels. Marketers may find this new process challenging.
And, if organizations want to publish reject policies for their domains, then they will have to publish records for every outside provider they use. Some of those providers can’t support DMARC alignment right now.
In 2016 a lot of companies will discover their current infrastructure can’t cope with modern authentication requirements. A lot of effort, both in terms of product development and software development, will need to be spent to meet current needs. This means a lot of user visible features will be displaced while the technical debt is paid.
These changes will improve the security and safety of email for everyone. It won’t be very user visible, which will give the impression this was a slow year for email development. Don’t let that fool you, this will be a pivotal year in email.

Read More