Spam and phishing emails are for sure one of the most hated and annoying attack an organization is facing nowadays: you will be very surprise if you know that 1 out of 25 branded emails (means from well-know brands like banks, stores, software companies etc..) are spam and phishing messages!
To prevent these attacks, both sender and receiver messaging systems like Exchange Online in Office 365 , need to collaborate to verify the authenticity of the email exchanged: they need to implement some sort of “signature” system to inform the receiving system if the mail received is “valid” or not.
this is the key point: Collaboration. Every messaging system should provide to the receiver the tools to verify the authenticity of the mail. and these tools are SPF,DKIM and DMARC.
The Basic: SPF
In the old days, SPF (Sender Policy Framework) record in the sender DNS was a quick-win solution to reduce the amount of SPAM received: in the SPF record you just includes all servers (IP addresses or FQDN) authorized to send email for that specific mail domain. When the receiver email system get an email, it check the ip of the sender, does a query to the mail domain DNS to get the SPF record, if the sender is in that list the email is valid. Seems bullet-proof right? well.. NO.
The reason why SPF is not enough is that there are more than one “From” in the SMTP RFC protocol. email usually contains two different “from” fields identified as:
- MAIL FROM (technically referred to as RFC.5321 from address – also called Return-Path address) is the address from which the email is really sent
- DISPLAY FROM or FROM (technically referred to as RFC.5322 from address) is the from address that is displayed to the end user within the mail client (like Outlook)
An example of spoofed email looks usually like this:
- MAIL FROM: email@example.com
- FROM: Your Bank Financial Account <firstname.lastname@example.org>
- TO: email@example.com
- SUBJECT: Urgent Action: verify your account
the issue is that SPF actually check the domain in the MAIL FROM (RFC.5321) and not in the FROM (RFC.5322) and this message can bypass SPF check if it’s sent from the real server of hackerdomain.com and this is where DKIM and DMARC comes in the pictures.
The Next Step: DKIM
DKIM (Domain keys Identified Mail) is another scheme like SPF that try to prevent spoofing of your domain name by spammers. Like SPF, this not help only with emails from your domain to other organizations, but also inbound emails to your users when attackers are trying to impersonate your domain.
DKIM is implemented as a digital signature in the header of email messages and works like this:
- The mail domain owner publishes a cryptographic public key as a specially-formatted TXT record in the domain’s overall DNS records.
- When a mail message is sent out to the receiver system, the sender system generates and attaches a unique DKIM signature header to the message. This header includes two cryptographic hashes, one of specified headers, and one of the message body (or part of it). The header contains information about how the signature was generated.
- When the receiver system get the email, it looks up the sender’s public DKIM key in DNS and uses this key to decrypt the signature and compare it against a freshly computed version: If the two values match, the message can be proved to authentic and unaltered in transit.
looking at the previous example anyway, DKIM is helping us to say that the message was not altered but it will pass anyway the check because the public keys are matched always with the domain listed in the MAIL FROM (RFC.5321) that is a valid domain sender.
The Complete Solution: DMARC
DMARC (Domain-based Message Authentication, Reporting & Conformance) can be considered to be build on top of SPF and DKIM and works this way:
- The mail domain owner publishes (always using DNS TXT Records) the policy defining its email authentication practices and how receiving mail servers should handle mail that violates this policy.
- When the receiver system get the email, it evaluate the message for three factors:
- Is the DKIM signature valid?
- Is the sender listed in the SPF correctly?
- If the message fails one or both these checks, the receiver system will apply the policy defined it the DMARC TXT record.
So what is the difference between DMARC and just SPF+DKIM you will ask? As you can guess, the difference is that these checks are performed against the DISPLAY FROM (RFC.5322) preventing the spoofing of your domain.
DMARC is the first and only widely deployed technology that can make the DISPLAY FROM address (what users see in their email clients) trustworthy and also it discourages cybercriminals who are less likely to go after a brand with a DMARC record: the only way to bypass DMARC is that the attacker has control of your DNS.. and in this case spoofing emails should be the not your top priority..
The common misunderstanding
Let’s be clear here:
After the implementation of SPF, DKIM and DMARC for all your mail domains you are not reducing the amount of spam/phishing/spoofing emails that are arriving to your system and in your user’s mailboxes. You are reducing the possibilities that someone can use or impersonate your domain as sender.
But if everyone is anyway doing its job and collaborates to protect their own domains, this is drastically reducing the amount of SPAM attacks. Maybe in the future you could send directly in the SPAM (or even reject or discard) emails coming from senders systems not implementing SPF+DKIM records.
Ready to start with the implementation? let’s see how to do it for custom Office 365 domains in the next post.