Everyone is talking about it. Everyone is doing it. It solves all deliverability issues. There is only one right way to do it. Are those sentences true or false, when it comes to email authentication? Let’s pick those, one by one, and try to find the answers.
Everyone is talking about it - true, at least as far as it goes for the email marketing world. What is worth underlining first, is that not everything being said is true. There is a lot of myth about authentication circling at conferences and gigs targeting email. Some of it is related to the “ancient” ways of authenticating messages, some is just gossip going around for no reason known even to the oldest of the wisest. The fact is that it is something every professional email sender should be familiar with. Otherwise, his or her email will be treated as unknown in terms of the source and author. And that’s bad news.
Everyone is doing it - false at least to some extent. The truth is, unfortunately, that there’s still a surprisingly high amount of senders out there, not bothering with validation - either not properly or at all. If you find yourself in either of those groups, please, keep reading. Otherwise, you are missing out on an opportunity for a significant deliverability boost.
It solves all deliverability issues - false. It is a very significant factor in email delivery. That’s a fact. If you want to get to the inbox, you must first be let inside the email infrastructure. The Mailbox Providers want to know, who you are. Sure. However, there are other factors to be taken care of, in the group called best practices, which are not less important. Changing records in the DNS won’t fool spam filters if one’s practices are otherwise fishy. You can think of email authentication as a cornerstone of deliverability. It is essential. But what will you build upon it, that’s another story.
There is only one way to do it - false. Whereas there are good and bad ways of handling authentication, even within the good ways, there are some alternatives. We will talk about this in the further part of the article. The best practices are very well described by many white hats of the industry, like M3AAWG or CSA in multiple documents. Those are publicly available, however, it is always good to call in for an expert, if you have no experience or are uncertain about anything.
So what is authentication? It’s a set of protocols using DNS records, encryption, and a bunch of other stuff providing proof for email authenticity, that being:
Email originator
Email source
Email not being tempered with on the way to the recipient
On top of that, it is possible to demand a certain action from the receiver, if any of the above is doubtful.Let’s talk through all the most important protocols for this process.
SPF (Sender Policy Framework)
For better understanding:
Imagine your friend went on a trip. She left you a list of towns she will be visiting on the way. Every time you get a letter signed as “Jenny”, you can easily check a stamp. Whenever the stamp points to the city Jenny should be visiting according to the list, you can open the envelope calmly. However, if the stamp shows a town not on the list, the letter seems suspicious, doesn’t it? She’s never supposed to be in Albuquerque, New Mexico; how come you got a letter saying “Jenny” coming from there? Better be careful. How does it work?A set of text (TXT) records is published in the DNS space of the specific domain (in our case, a sending domain), that contains all the IP or ranges of IP addresses that are allowed to “use” the domain for sending. That means any of the IPs contained in this set of records (or just a single record) can send messages with a Mail From address using this domain. If you are or going to use any ESP, you are using their IP assigned to you or also shared amongst other users. And if you own a domain (to be frank, you should), you will most probably need to add those IPs to your domain’s SPF record. This way you are telling the recipients - “I allow those IPs to send messages with my domain in the Mail From”. This is a base for further steps of authentication. Basically, seeing an IP trying to push a message with a domain that doesn’t allow such an IP, a recipient can easily drop the message.
DKIM (DomainKeys Identified Mail)
For better understanding:
Now let's say that Jenny from the previous example has given you an additional card before she left the city. This card shows a way how she’ll be writing her letters to you. There will be a specific way of doing them. This may be a particular last letter of each sentence or another awesome way of showing that she’s the one writing the letters and no one else.
Whenever you receive a letter that claims to be coming from Jenny, you can compare it with the card she left you and see, if each part of the letter is written according to the “code” or not. Especially the part where she’s asking you for a little financial help for the next train ticket.
Not only you are sure the letter comes from Jenny herself, but also you can be assured the letter has not been compromised along the way and the content of it remains intact.
How does it work? First, a pair of encryption keys are created - a private and a public one. Those keys are inseparable. Private remains in the hands of the owner of the domain which the pair was created for. In our case, of course, it’s our sending domain. If the key is compromised, the whole process needs to be repeated. The public key is published as a TXT record of the subdomain of our sending domain. The subdomain’s suffix is called “selector” and is also added in the message as an additional header. This is necessary for the receiver to know, where to look for a public TXT record of our signature. When the message is sent, the sender uses the private key to encrypt a given part of the message (specific headers, body, subject, etc). The encrypted portion is also added as an additional header, which is later captured by the recipient. Finally, the recipient can use the encrypted part and compare them to the pointed parts of an email, using a public key (still published in the DNS zone). The public key can only be used to decode the hash (encrypted string). It only works one way. A specific domain can not only “sign” a message, but also ensure that the pointed parts of it were not altered on the way.
Pretty slick, huh?
The alternatives:
What differs between the senders are the actual parts of the message that are being encrypted; some will “sign” only recipient headers (To:, CC:), and others will sign author headers as well (From:). It’s possible to sign the subject, body, and every other header. It is also proven that so-called over-signing has its value. Such over-signing prevents a malicious entity from adding a header that the author hasn’t originally added.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
For better understanding:
Finally, our example reaches the point, when neither the list of places nor the letter itself and the “code” your friend has established, do not add up. Now, fortunately, Jenny has foreseen something like that might happen. She left you another note on what to do with such letters. Three options are possible: 1. You can do nothing with the message except for treating it as you would normally do.
2. You should put the message in a drawer and leave it there.
3. You should throw away the message.
Jenny picked the second option. Except for the above, you should also inform her by sending the information about the letter to the address pointed by her in the letter.
Now, you complied with her wishes.
How does it work?DMARC is another TXT record placed in DNS - specifically in the subdomain of the sending domain - _dmarc.example.com. This record should contain flag p= which stands for “policy”. One of three policies is possible: 1. None
2. Quarantine
3. Reject
The above represents analogical behavior to the ones from our example. Another flag is the one for reporting - it specifies the address to which reports should be sent. The aggregated reports about DMARC conformance or violation should be sent by the recipients which then can be analyzed by professionals and used for building a strategy for protection and self-improvement.
In our examples above, you can be pretty sure when mail claimed to be from Jenny can be trusted, and you know, what to do whenever it’s suspicious. If you’d go through a similar process whenever writing a letter to Jenny, your correspondence would be pretty safe and trustworthy. In such a way, we can treat email authentication. Today, it is a highly important part of mailing, even more so in email marketing, where mass email is being sent to multiple subscribers at once. It is important for every sender and if one’s not a specialist in the subject, consulting with a professional is highly advised.
Comments