Introduction to SPF, DKIM, and DMARC
For those of you that are new to the email security subject, you've probably heard about SPF, DKIM, and DMARC. But what are they, and how do they relate to each other?
Like regular postal mail, someone could send you a letter in an envelope and forge the sender's name on the envelope or the letter itself. The same is possible for email. Email is involved in more than 90% of all network attacks through scams such as spear phishing. To better protect against fraud, SPF, DKIM, and DMARC were introduced.
Sender Policy Framework (SPF) is a mechanism that allows a domain to specify which sources (IP addresses) are allowed to deliver email on behalf of that domain.
In the postal mail analogy, this would mean that upon receiving an envelope, you contact the sender printed on the envelope and ask them if postman Pat can be trusted to deliver a letter on their behalf.
DomainKeys Identified Mail (DKIM) is a mechanism that allows a domain to claim responsibility for the message and protect it against modifications by adding a digital signature.
In the postal mail analogy, this means that the envelope has a stamped seal that proves that the letter inside was not altered by anyone who could have had access to the envelope, and the stamp can be verified to be from the sender on the envelope. (not the sender mentioned in the letter, this is a big difference)
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism built on top of SPF and DKIM. It checks the SPF and DKIM validation results and if the 'Header From' domain matches the domain used for the SPF and DKIM checks. The 'Header From' address is the email address that recipients see in their email client.
When SPF and DKIM checks fail or do not align with the 'Header From' address, the recipient server should honor the DMARC policy. For example, it could instruct the receiving server to quarantine (p=quarantine), reject (p=reject), or ignore the results and deliver the email (p=none).
Like with regular mail, the sender's name on the letter does not have to match the sender's name on the envelope. The problem with email is that the envelope is not visible to the recipient, which causes risks.
Imagine your email server as a person handling your incoming messages. If you do not implement SPF, DKIM, and DMARC, this person will receive an envelope from anyone, open it, and put the letter on your desk without checking anything. Unfortunately, now, there is no way for you to check if the sender's name on the letter is trustworthy.
Results and alignment
Only when both SPF and DKIM fail validation and alignment, the DMARC policy will be honored. However, as long as either SPF or DKIM produces a pass and aligns, DMARC will not quarantine or reject the message.
A postman who is not trusted to deliver a message on behalf of the envelope's sender (SPF fail) delivers an envelope sealed with a stamp (DKIM pass) that matches the name on the letter (DKIM alignment pass). This message will get delivered.
A postman who is trusted to deliver a message on behalf of the envelope's sender (SPF pass) delivers an envelope without a seal (DKIM none). If the sender's name on the envelope aligns with the sender's name on the letter (SPF alignment pass), DMARC passes, and the message will get delivered.
A postman that is trusted to deliver a message on behalf of the envelope's sender (SPF pass) delivers an envelope with a seal (DKIM pass). However, the sender's name on the letter does not match the name on the envelope or seal. Therefore, DMARC will instruct the recipient to reject the message (p=reject).
I hope this blog contributed to your knowledge about these email security techniques and convinced you that implementing these mechanisms is necessary to avoid phishing and other email spoofing attacks.
Want to see SPF, DKIM, and DMARC in action and test your email's security in the process? Visit learnDMARC.com