Ask Laura: Confused about Authentication

AskLaura_Heading3


Dear Laura,
I have a client moving from an external ESP to an internal system. They send approximately eight million messages per year, and these are primarily survey emails on behalf of their clients.
We’ve had some conversations about authentication, and I’m trying to help them figure out if they just need DMARC or if they also need DKIM and SPF. It seems some ISPs prefer different methods, and I’m not sure what to advise them.
Help!
Authentically Confused


Dear Authentically Confused,
The different technologies authenticate different things.
DKIM authenticates the email and ties the reputation in the d= value. We recommend DKIM to all our clients.
SPF authenticates the Envelope From/Return Path/5321.from value (and sometimes the HELO/EHLO value). We recommend SPF to all our clients.
DMARC uses DKIM and/or SPF authentication to authenticate the value in the visible from address (5322.from). DMARC requires that the d= value or the SPF value are in the same “organizational domain” as the visible from address (there is more about this in my DMARC primer post A brief DMARC primer). Once you can authenticate the visible from address, there are two things DMARC does for you. The first is a reporting scheme where you can get reports every time one of your email messages fails SPF or DKIM authentication. The second is a policy process where you ask receiving ISPs to implement a particular policy when the authentication fails (quarantine or reject).
We recommend clients monitor mail for at least 6 months before publishing a p=reject policy so you have a clear understanding of what mail will fail. Publishing a p=reject policy will cause valid mail that you send to fail in some tiny percentage of cases. For some senders this is a reasonable policy decision and should be implemented. For some senders this mail is too important to be rejected for authentication failures.
To summarize, we do recommend DKIM and SPF for all of our clients. There are some free tools on our site you might find helpful. It does not seem like DMARC would be useful for your client right now, since the emails they are sending are not transactional in nature or important account information that would be problematic if rejected.
Feel free to reach out if we can help you with more specific issues related to authentication.
Laura


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

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

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

Authentication and Repudiation

Email Authentication lets you demonstrate that you sent a particular email.
Email Repudiation is a claim that you didn’t send a particular email.
 
SPF is only for email authentication1
DKIM is only for email authentication
DMARC is only for email repudiation
 
1 SPF was originally intended to provide repudiation, but it didn’t work reliably enough to be useful. Nobody uses it for that now.

Read More