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

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More