SPF, DKIM, and DMARC are different methods to authenticate your email to serve one dedicated purpose, detecting forged sender addresses in emails used in phishing or spam.
SPF, Sender Policy Framework, allows the receiver to check that an email claiming from a specific domain comes from an IP address authorized by that domain’s admin. A typical SPF record is a TXT DNS entry similar to this:
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
it simply tells that emails from the specific domain are sent either from 192.0.2.0/24 or 198.51.100.123 or should be rejected if came from anywhere else.
Tool to check SPF record: https://mxtoolbox.com/spf.aspx
DKIM, DomainKeys Identified Mail, allows the receiver to check that an email claiming from a specific domain was indeed authorized by the owner of that domain. It requires a digital signature linked to a domain name for each outgoing email message. At the receiver end, the email can be verified by looking up the sender’s public key in DNS. To achieve this, you will need a public key entry in the domain’s DNS as well as a digital certificate on the mail server.
You don’t need to implement both SPF and DKIM. Utilizing either one of them should be good enough.
/Update on May 7, 2019/
Thanks to Dave for pointing out that you do need both SPF and DKIM. Yes, SPF and DKIM accomplish the same goal with a different approach. Implementing both would be ideal. I should have pointed out that most of the mail providers like Office 365 and G Suite have default DKIM in place for those who don’t have it implemented. It’s always recommended to use your own DKIM key on all outgoing messages.
Tool to verify DKIM setup: https://mxtoolbox.com/DKIM.aspx
To set up and enable DKIM in Office 365, follow this documentation.
DMARC, Domain-based Message Authentication, Reporting, and Conformance extends both SPF and DKIM and gives the domain owners a way to protect their domain from unauthorized use, a.k.a email spoofing. A TXT entry was added in DNS as a policy to specify which mechanism (SPF or DKIM) is employed when sending emails from that domain and how to check From field presented to end-users.
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"
it simply translates that DMARC version 1 will be used with none in Policy, Quarantine in the subdomain, percentage of “bad” emails to apply the policy, and an email address to receive aggregate reports.
Note that _dmarc needs to be in the Host field when adding the TXT record. You will need to set up either SPF or DKIM first before setting up DMARC. A message that doesn’t pass SPF or DKIM checks triggers the DMARC policy.
Once it’s published, the mailbox specified in the entry will be getting reports in XML format once per day.
It’s recommended to set the policy to none when first implemented so no impact will be made to your email setup. Once you have collected enough data and analyzed it, you can then change the policy to either reject or quarantine.
Tool to verify DMARC record:
- https://mxtoolbox.com/DMARC.aspx
- https://www.learndmarc.com/ – a visual breakdown of how email servers communicate, giving you a better understanding of SPF, DKIM and DMARC and how they work together.
Resource
- SPF Wiki – https://en.wikipedia.org/wiki/Sender_Policy_Framework
- DKIM Wiki – https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
- DMARC Wiki – https://en.wikipedia.org/wiki/DMARC
- DMARC – https://dmarc.org/overview/
- Email Authenticity 101 – https://www.alexblackie.com/articles/email-authenticity-dkim-spf-dmarc/
>You don’t need to implement both SPF and DKIM. Utilizing either one of them should be good enough.
This is completely wrong. They do completely different things.
Thanks, Dave for pointing it out. I should’ve also mentioned that most mail servers like Office 365 and G Suite have a default DKIM with both public and private keys set up for your domain. DMARC doesn’t require both but you are right, they do two different things and it’s better having both implemented.