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

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

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

Salesforce SPF and now DKIM support

Salesforce has published a SPF record for sending emails from Salesforce for years and with the Spring ’15 release, they will provide the option to sign with DKIM.
The SPF record is straight forward, include:_spf.salesforce.com which includes _spf.google.com, _spfblock.salesforce.com, several IP address blocks, mx, and ends with a SoftFail ~all.
Salesforce Knowledge Article Number: 000006347 goes in-depth with information regarding their SPF Record.

Read More