Imagine that your phone rings. On the screen, the number of your best friend appears. You take your phone in hand, pick it up and put it to your ear. There, to your surprise, it's not your best friend saying hello... but the smooth voice of a commercial phone server offering to buy the latest model of an appliance you don't need.
Impossible you may say! Indeed, with your phone, unless you face a very ingenious hacker, it is impossible. On the other hand, when it comes to email, nothing could be simpler: you can send an email on behalf of firstname.lastname@example.org to all your friends. Or rather, you could. In fact, basically the SMTP protocol does not provide an authentication mechanism: anyone can send an email on behalf of... anyone!
Obviously, with the increase in the number of emails sent, and especially the number of spam (and other phishing), a solution had to be found. It is in the early 2000s that discussions are engaged, which will lead to the publication in 2006 of SPF and the following year of DKIM. And the need to ensure the authentication of emails.
Email authentication and SPF = Sender Policy Framework.
Unfortunately, we won't be able to continue with our example of the phone call... the analogy would be too shaky 🙂
When sending an email, the main source of identification of the sender is the email address contained in the FROM: field. This email address consists of two parts: the part to the right of the "@" sign, the domain name, and the part to the left, the user name. SPF is a technique that will define which servers have the right to send an email for the domain name (i.e. the right part of the address).
Let's take for example... "example.net". Example.net is a big online payment site. And so, they don't really want anyone to try to impersonate them, it's bad for their reputation. So they decided to publish an SPF record on their DNS server, here is what it looks like (this is an example, everything is fictitious):
example.net. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all" example.net. IN SPF "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
Here we have two similar DNS records: one is of type SPF and the other is of type TXT for backward compatibility. What do these records mean? That servers with IP address 198.51.100.123 and all IP addresses in the 192.0.2.0/24 block are allowed to send emails on behalf of Example.net. The "a" means that all IP addresses of the A record are also allowed to send emails for this domain name. The "-all" means that all other IPs must be rejected ("SPF=FAIL").
Reading content isn't everything. The best way is to talk to us.
But beware, an email that does not pass the SPF test will not be considered as SPAM. On the other hand, a domain name with a well-configured SPF record will be less likely to be exploited by spammers.
Email authentication and DKIM = DomainKeys Identified Mail.
DKIM is the fusion of two technologies, one developed by Yahoo! (DomainKeys) and the other developed by Cisco (Identified Internet Mail). Where SPF tries to link a domain name to the IP address sending the message, DKIM tries to associate a domain name to a message by adding a digital signature. The verification of the signature is done via a key located in a DNS record. In doing so, DKIM can verify whether a message has been tampered with during its transport between different SMTP servers. And it guarantees that the content will arrive intact to the recipient.
Like SPF, DKIM does not prevent SPAM. But it does allow it to be seen as more legitimate by the servers receiving the messages. Filters can then focus on unsigned messages and filter them more aggressively.
Example of a DKIM signature contained in the header of an email:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date:keywords; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR
Email Authentication and DMARC = Domain-based Message Authentication, Reporting and Conformance.
DMARC plays on the synthesis between SPF and DKIM. Not by replacing them, but by uniting them. And by making them more intelligent. There are two main uses of DMARC:
- Indicate what the ISP/Webmail should do with the message if the authentication fails (let it through, delete it, classify it as spam, ...).
- Allow the sender to be notified when authentication fails.
DMARC has been designed by several big names in the email industry (Return Path, Gmail, AOL, Microsoft, ...) in order to fight more effectively against phishing attacks, which are on the rise. This is why companies such as Paypal, Facebook or LinkedIn have also joined this initiative.
I am well aware that the subject of email authentication is very technical. So don't hesitate to ask for more details in the comments, I'll be happy to answer them. Moreover, I will probably come back in more detail on these different technologies in the future.