SPF, DKIM, and DMARC are all options that can be used to better secure and protect your email environment and your email users.
If you're using the default onmicrosoft.com domain, then you can stop reading this article. For default domains, you don't need to do anything to configure or implement DMARC for your organization as Microsoft automatically configures SPF for you and automatically generates a DKIM signature for your outgoing mail.
But, if you're using your own custom domain, then you'll probably want to enable these features as they only help to increase the security of your emails for both you and the people you send mail to.
Sender Policy Framework (SPF)
SPF is designed to cut down on email spoofing. At a high level, SPF is a way for you to specify a list of mail servers that you approve of to send messages coming from your domain name.
For example, if a hacker tries to spoof your email address and attempts to send the malicious email message using his own server, then the receiving end should block that message because it's coming from a foreign mail server that's not in your list of approved servers in your SPF record.
To implement SPF you'll need to create a new TXT record in your domain's DNS. The name of the record should just be your root domain, sometimes represented with the @ symbol. The value of the TXT record must begin with "v=spf1" and there are multiple things you'll need to put after that. The last option in the SPF record is the enforcement rule and that specifies what to do with messages that fail the SPF check (hard fail, soft fail, neutral). See the link below for more details.
There can only be 1 SPF record per domain. So, that means if you have multiple 3rd parties that are allowed to send your email (like Office 365, Salesforce, etc.) then you must include all of them in your 1 SPF record.
For details on how to create your own SPF record, check out this article.
DomainKeys Identified Mail (DKIM)
DKIM is similar to SPF in that its purpose is to identify legitimate messages coming from your mail servers and to cut down on spoofing. But, DKIM is a little bit different because it uses encryption.
DKIM uses a Private encryption key to create a hashed value which is placed into the message header of all the emails that are sent from your systems. The receiving mail system will process those messages and try to decrypt the hash using the Public encryption key that you host in your DNS system. If it's successful in decrypting the value then it knows this is a legitimate email from you.
There are 2 steps to configure DKIM:
First, you have to identify all of the applications that send mail using your domain. You may have multiple, like Office 365, Salesforce, or something else. You'll want to configure DKIM on the application side for each one. Each application will have its own way of doing this. Also, each application will get its own set of encryption keys.
The next step is to publish the Public encryption keys as new records in your domain's DNS. Each application would get its own DKIM record in your domain's DNS. Each application has its own specific way of implementing the DKIM record: Some applications may require you to create a new TXT record in your DNS system. The record's name would be "selector._domainkey" where selector is a unique value. The application may dictate what value to use for selector, or you may get to pick your own value. The value of the TXT record starts with "v=DKIM1" and after that would be a few more items, including the full Public encryption key. Other applications may want to have total control over the encryption keys. For these types of applications, you'd create the DKIM record as a CNAME record. The record's name would still be "selector._domainkey." Just like above, the application may dictate what value to use for selector, or you may get to pick your own value. But, where this situation differs is that the record's value would point to a URL where the application hosts the Public key. The application would tell you the exact URL to use. This is how Office 365 works.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC works in conjunction with SPF & DKIM. DMARC is an extra layer on top of those two technologies and it adds a couple of nice features. One of the biggest features of DMARC is that it adds reporting. The reporting will help you gain insight into who is trying to send email using your domain, it doesn't matter whether that e-mail is legitimate or not. In other words, you can use the reporting feature to find out who is trying to send spoofed emails using your domain. Another feature of DMARC is that it allows you to specifically tell the receiving email system what to do with messages that fail DMARC checks, removing any guesswork or assumptions from the process. A message will fail DMARC if both SPF & DKIM fail.
Implementing DMARC involves creating a new TXT record in your domain's DNS. The record's name should be "_dmarc." The record's value should begin with "v=DMARC1" with various DMARC options after that. You only need 1 DMARC record per domain.
This DNS record can have a lot of different parameters that specify a lot of different options:
You can specify the "policy" to use. You can set it to "none" and this will implement DMARC in a monitoring-only mode. This is good option when you're just starting. You can examine your reports and then move into a more restrictive policy when you feel more comfortable. The next option is "quarantine." With this option you're telling receiving mail systems to quarantine the messages if they fail DMARC. The last option is "reject" which tells receiving mail systems to just reject the message if it fails DMARC.
You can configure the checks for both SPF and DKIM to be either "relaxed" or "strict." I won't go into the differences here. These are optional parameters, the default for both is "relaxed."
You can specify a "percentage." Let's say you picked 50%. That means the receiving mail system will only apply the DMARC policy to 50% of the failed messages.
You can specify different reporting options. This includes things like the address to send the DMARC reports to and the specific type of formatting to use in the report. You can also specify "forensic options" to outline what scenarios you want to be notified about (DKIM and SPF both fail, either DKIM or SPF fails, only DKIM fails, or only SPF fails).
For a full detailed list of all the parameters, check out this page.
Sources: