SPF, DKIM, DMARC in Office 365
Updated: Nov 29, 2022
Email spam is an on-going battle for mail administrators and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated and their practices have evolved over the years; fortunately, the technologies available to protect against such attempts have equally improved. There are several technologies that can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year however it seems like these features get very little talk.
SPF (Sender Policy Framework)
SPF is pretty well known and commonly implemented. If you’re not familiar with SPF, it’s essentially a DNS record (TXT) that contains a list of approved senders by IP address, domain name or some other mechanism. With Exchange Online, Microsoft provides you the information to properly configure your SPF record. However, if you have third-party services sending on your behalf, you may need to customize the provided value. There are some limitations on the number of DNS queries you can have in your SPF record and it’s not uncommon to see syntax errors so you should always validate your SPF record with one of the online validation tools. If a message is received from a source not authorized in the SPF record, you as the receiving party can do what you choose with that information. You may decide to block the message, you might rank it higher as prospective spam or you could ignore it.
How SPF works
In order to facilitate our discussion, let's assume this setup:
your business domain is domain.com; you will send emails to your employees and customers from user1@domain.com;
your email delivery server, which sends the email for you, has an IP address of 192.168.0.1;
some attacker uses a scam email server at IP address 1.2.3.4 to try to send spoofed emails.
When an email delivery service connects to the email server serving up the recipient's mailbox:
the email server extracts the domain name from the envelope from address; in this case, it's business.com;
the email server checks the connecting host's IP address to see if it's listed in domain.com’s SPF record published in the DNS. If the IP address is listed, the SPF check passes, otherwise not.
For example, let's say your SPF record looks like this:
v=spf1 ip4:192.168.0.1 -allit means only emails from IP address 192.168.0.1 can pass SPF check, while all emails from any IP address other than 192.168.0.1 will fail. Therefore, no email from the scam server at IP address of 1.2.3.4 will ever pass SPF check.
SPF DNS lookup limit
Each time an email message hits the email service host, the host looks up in the DNS to perform SPF check. Care has been taken to prevent this from turning into Denial of Service (DoS) attack.
The SPF specification imposes that the number of mechanisms and modifiers that do DNS lookups must not exceed ten per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError is returned.
What if your SPF record exceeds the 10-DNS-lookup limit?
If your SPF record exceeds the 10-DNS-lookup limit, SPF authentication returns a permanent error indicating "too many DNS lookups". An SPF permanent error is interpreted in DMARC as fail. Therefore, when this happens, it has a negative impact on your email deliverability.
DKIM (DomainKeys Identified Mail)
DKIM uses a public/private key to sign messages as opposed to the published TXT record. One advantage of DKIM over SPF is there is no limit to the number of partners you can authorize to send on your behalf (assuming they support DKIM). If you use a number of third-party senders, you likely have run into issues of when trying to include them in your SPF. Another way to address the SPF limitation is to have senders send their messages under a subdomain and publish a separate SPF for that subdomain. What Does It Protect? DKIM is also looking at the “Mail From” field and will show a “None”, “Pass” or “Fail” once the message has been evaluated. The same potential phishing issue exists with DKIM where the “Mail From” does not necessarily match the “From” field that the user sees.
Create DKIM records for Office 365
In order to set up DKIM in Office 365, first you need to create 2 CNAME-typed DKIM records on each domain. These records look like the following:
Host name: selector1._domainkey.CompanyDomainNamePoints to: selector1-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.com
Host name: selector2._domainkey.CompanyDomainNamePoints to: selector2-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.com
Enable DKIM signing in Office 365
Next you need to enable DKIM signing in Office 365. Log into the Exchange admin center, then go to protection > dkim, choose the domain you want to enable DKIM on, then click Enable on the right pane.
Note that if the 2 DKIM records you published in the DNS haven't taken effect yet, this operation will fail. When this happens, wait some time and try again. If you keep getting this error, check if your DKIM records are published correctly.
DMARC or Domain-based Message Authentication Reporting and Conformance
Once you have SPF and DKIM properly configured, you may choose to start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports.
h. Even if you can’t get to the point where you configure an action of “quarantine” or “reject”, you can still use DMARC to help mitigate phishing attempts.
DMARC, among other things, can be the answer to the above phishing issue. DMARC looks for a passed SPF or DKIM but also looks for “alignment” of the “Mail From” and “From” fields. Additionally, your configuration of DMARC allows you to tell recipient mail servers what to do with a message if DMARC fails.
This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC. A typical DMARC record might look this this :
Host: _dmarc TXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:dmarc_aggr@dmarc.com; ruf=mailto:dmarc_fail@dmarc.com;"
Walking through the logic of the text record :
v=DMARC1; = This just indicates the version (1) that is being used for DMARC
p=none; = The policy is set to “none” in this case, meaning that recipient servers need take no special action on your messages if they fail authentication (you can also choose to advertise quarantine or reject–more on that later)
rua=mailto:<dmarcfeedback@contoso.com>; = this is where you can specify a place to send failure reports (aggregate), you can also choose to get message-specific reports using ruf=
fo=1 = this indicates that a DMARC failure report should be produced for anything other than a “pass” result on either DKIM or SPF; other options are 0 (report only if both mechanisms fail), d (DKIM failures only), or s (SPF failures only)
Alif empowers Microsoft MSP-CSP partners to provide exceptional IT services to their clients to ensure that the partners reduce their costs and focus on their business. We provide white-labelled Microsoft 365 managed services/ office 365 managed services. If you wish to hire administrators, architects, developers, or associates on full time/ part time/ project basis connect with us (Microsoft 365/ office 365).