Difficulty Level: Intermediate to Advanced | Time Investment: 2 hours
Summary: In this blog post, we're going to walk you through configuring SPF, DMARC, and DKIM. While this is an essential step, it is only one portion of a comprehensive email security strategy. .
MxToolbox is an indispensable (free!) tool every IT and security team should have. We use it as part of our arsenal of tools for protecting our clients’ emails, ensuring we have enabled Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC). Don’t know what this gibberish means? No worries, we’ll explain what they mean, why they’re important, and how to enable them.
This tool offers monitoring and lookup solutions to help IT teams assess the overall health of their company's DNS by means of 158 different tests that can completed in seconds. We use it everyday to determine the health of our leads, our clients, and our own network.
A Sender Policy Framework (SPF) record is a type of Domain Name System (DNS) record that can help to prevent email address forgery. Spammers can falsify email headers to make it look like they're sending from an email address on your domain. They can pretend to be you, allowing them to phish your users for private account information, or otherwise abuse your reputation. When they hijack an email account, they alter the email header details to show the messages they're sending are coming from the valid owner of the account.
Adding an SPF record can help prevent others from spoofing your domain. You can specify which mail servers are permitted to send an email on behalf of your domain. Then, when incoming mail servers receive email messages from your domain name, they compare the SPF record to the outgoing mail server information. If the data doesn't match, they identify the email message as unauthorized, and will generally filter it as spam or reject it.
Adding an SPF record can decrease spoofing attempts to your domain; however, they are not a full-proof guarantee against all spam.
To correctly set the SPF for your domain, answer the following two questions:
From what server or servers will email from the domain originate?If you’re sending email from your workstation by using your internet service provider’s (ISP) mail servers, you might want to consider their servers. You must take all possible (legitimate) sending servers into account.
How do you want illegitimate email to be handled?Do you want it to be rejected outright, or do you want the message to be classified as a soft fail, meaning that the email will be subjected to further scrutiny?
The example in this section assumes that you have the following considerations for your email on a specific domain:
In this situation, you would create the following rule and add it to a TXT record:
The following list shows how each part of the record is defined:
The all setting is an essential aspect of the record and has the following basic markers:
A Sender Policy Framework (SPF) record is a type of Domain Name Service (DNS) TXT record that identifies which mail servers are permitted to send an email on behalf of your domain. The purpose of an SPF record is to detect and prevent spammers from sending messages with forged From addresses on your domain.
To test your SPF, go to https://mxtoolbox.com/spf.aspx and enter your domain. If set correctly, your SPF will pass for its tests as shown below
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam.
DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than the message's authors and recipients.
First, for each domain, you will need to create two CNAME records in your public DNS Zone. To build the CNAME records, you will use the following format:
selector1-<domainGUID>._domainkey.<inititalDomain>
The <domainGUID> will be the first part of the MX record as listed for Exchange Online. For example, to enable Domain Name "contoso.com" for DKIM, I will look up the MX record (you can use https://mxtoolbox.com/MXLookup.aspx to find the MX record), and see that the MX record points to:
You take the first part, “contoso-com”, and leave off the “.mail.protection.outlook.com”. The <InitialDomain> is the prefix part of your tenant name. In this case, the tenant domain is contoso.onmicrosoft.com. So, the <initialdomain> is contoso.
Now, to see it all together, you will build it as follows:
Now that you have created the DKIM first record. You will need to repeat the same steps and enter a second record as shown below.
Once done, you should see something similar within your DNS editor (below, I am using GoDaddy)
Now let’s validate that your DKIM entries have been configured correctly. Here is what you currently have:
The results include the information that is “stored” in the TXT record. In our case, the Office 365 TXT record stores the Public key of the Office 365 DKIM selector, that represent our domain name.
When using the DKIM records lookup, you will need to provide:
Once you have the DNS records in place and have verified, they are publicly accessible, go to:
Domain-based Message Authentication, Reporting & Conformance (DMARC), is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
DMARC policies define how SPF and DKIM records should be handled by email servers. A critically important element of DMARC policy is that it also provides a reporting mechanism so domain administrators can identify if email is failing or if an attacker is attempting to spoof a given domain.
DMARC policies are published in the DNS as text (TXT) and announce what an email receiver should do with non-aligned mail it receives. DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
v=DMARC1; p=quarantine; rua=mailto:reports@contoso.com; ruf=mailto:reports@contoso.com; adkim=r; aspf=r; rf=afrf
v=DMARC1; p=quarantine; pct=100
To check that you have correctly set your DMARC, do the following steps:
That’s it! You have now successfully implemented SPF, DKIM and DMARC for your domain. By implementing enabling these tools, you have drastically reduced the probability of your company becoming a victim of a data breach via email. The next step for should be to enable Office 365 Advanced Threat Protection (ATP) and Office Message Encryption (OME) in order to fully protect your company from email attacks.
Questions? Schedule a free consultation with one of our experts: