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. This blog is the 1st post of a 5 post series titled Your Complete Guide to Microsoft Email Security. The 5 steps to email security are:
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. Let’s get started!
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.
Wait 30 seconds for MxToolbox to run over 158 tests against: Blacklisted domains, MX records, DMARC entries, SMTP, SPF, web servers, DNS entries, and DNS servers
Setting up SPF
What is an SPF record?
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.
Considerations for setting the SPF
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?
Create an SPF rule
The example in this section assumes that you have the following considerations for your email on a specific domain:
The authorized servers are your cloud server (that is, the incoming mail exchange (MX) details also send mail) and Microsoft Exchange Online mail.
No other servers are authorized.
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:
v=spf1 Sets the SPF version that is used.
include:spf.protection.outlook.com Includes Microsoft Exchange online servers as authorized servers.
-all Indicates that servers that are not listed previously are not authorized to send an email. If an unauthorized server does send an email, the action is taken according to the receiving mail server’s policy. For example, the email is deleted or marked as spam.
About the SPF all settings
The all setting is an essential aspect of the record and has the following basic markers:
-all: Any server that is not previously listed is not authorized to send an email.
~all: If mail is received from a server that is not previously listed, it is marked as a soft fail, which allows the email to be scrutinized further.
How to add an SPF record to protect your email
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.
Go to your DNS provider (i.e., GoDaddy, Network Solutions, etc.)
Go to the DNS Management page. As every DNS provider has a different interface, you will need to find the location of your DNS editor
Select to add a next TXT entry
Complete the following fields:
Record Type: TXT
Hostname: Enter the hostname for the TXT record (For example, type @ to map the record directly to your domain name, or enter the subdomain of your hostnames (labeled Host), such as www or ftp.)
TXT Value: Enter the value you want to assign to the record.
Note: For a TXT SPF record, enter the SPF rule in the TXT Value field. For example, enter v=spf1 mx -all to indicate that all email is sent from this server and no other mail servers are authorized.
TTL: Specify the Time to Live (TTL). Usually, I use 3600 as value
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.
How Do I Setup DKIM with Microsoft Office 365?
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:
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:
MX preference = 0
mail exchanger = contoso-com.mail.protection.outlook.com
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:
Part 1: You need to verify that the two DKIM CNAME records were successfully published + the CNAME “redirect” process is successfully implemented
Use the MxToolboxsite, for verifying information about the DKIM CNAME record that you published. To perform a CNAME look, you will use the following link – MXTOOLBOX CNAME record lookup
To verify that your CNAME record was successfully published, and in addition, perform the required “redirection,” you will need to provide the “first part” of the CNAME record. In our specific scenario, the host name is “_domainkey.contoso.com"
In the result’s pen, you can see that the “CNAME redirection” process, was successfully completed.
Run the same test with “selector2._domainkey.contoso.com"
Part 2: Verify the “content” of the Office 365 DKIM text record that represents the public domain name.
To be able to perform this test, you need to know the Host name of the “real Office 365 DKIM selector” host name. In this scenario, you query the public DNS about the content of a “TXT DNS record.”
Once you have clicked, do not close the window. Note that it can take 1 hour before you can enable. If you can successfully pass all the test above, your DKIM set up should be completed within one hour.
Setting up DMARC
What is DMARC?
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.
Considerations for setting up DMARC
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.
Create a DMARC rule
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:
You will get a screen as shown below with the validation of the rules you have put in place
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:
Curious how your cybersecurity stacks up? Take our 5-minute quiz here: