Email Authentication in a nutshell

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

  • DKIM
  • SPF
  • DMARC

The different strategies do different things with email.

  • DKIM cryptographically signs emails, preventing changes in transit, and designates a “responsible domain” through the d= value in the signature.
  • SPF compare the sending IP and the envelope from (also known as the bounce string, return path or 5321.from) domain to determine if that IP is authorized to send mail using that envelope from domain.
  • DMARC uses DKIM authentication (d= value) or the SPF authentication (envelope from) to authenticate 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 data about this in my brief DMARC primer post from April 2014. In addition to authenticating the visible from address, there are two things senders can get from publishing a DMARC record. 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 all our clients authenticate with DKIM and SPF. The specifics of how to authenticate depend on the overall mail stream of the sender and technology available at different service providers.
Our recommendations for DMARC are a little more complex, due to the newness of the protocol and the choices that DMARC offers to senders. We’re currently recommending that clients be aware of the availability of DMARC reporting and start internal discussions and plan to implement reporting in the future. Managing DMARC reports requires some level of infrastructure to accept and process the incoming reports, and this will need to be planned for.
It’s important to understand that even if every message leaves fully authenticated different processes during mail sending (forwarding, etc) may result in authentication failures at the recipients.  This means senders publishing a p=reject policy will lose legitimate mail. In the absence of security concerns, we’re not recommending publishing a policy statement (p=reject or p=quarantine) at this time. For senders who still want to implement DMARC we’re currently recommending that clients collect failure reports for a period of time (6 – 12 months in cases with complex mail systems) before making the decision to publish a p=reject record. Senders with security concerns can implement a p=reject message, but need to be clear that this may result in legitimate mail being lost.
 
 

Related Posts

Gmail and the via

I was hoping to have a detailed post up today about the conditions where gmail presents the user with a “via” but time seems to have gotten away from me. But I can give you the conclusions.

Read More

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More

Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

Read More