Email Sender Validation Using DNS (SPF, DKIM, & DMARC)
Three primary DNS-reliant technologies can be used to help validate the authenticity of email (SPF, DKIM, and DMARC). This article will describe how to configure each of these technologies to ensure security for your organization. We recommend enabling these services for all your domains wherever possible. When configured correctly, these services all work together and help ensure emails sent from a client's environment are delivered successfully to recipients without getting caught in spam filters. They can also help to reduce the number of phishing emails you receive.
Contents
Testing Your Current Configuration
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DNS changes take time. To avoid disruption, we recommend making DNS changes at the end of business hours.
Testing Your Current Configuration
To test which of these technologies is currently already working, you can send an email from an account on the same domain to ping@tools.mxtoolbox.com
Sender Policy Framework (SPF)
SPF records tell spam filters what mail services a particular domain name typically sends emails from. It's essential to have a correctly configured SPF record that lists any mail-sending servers. This includes any hosted mail server environments (Microsoft 365, Google Workspace, etc.), third-party mailing list services (website, MailChimp, HubSpot, Constant Contact, etc.), and external IP addresses of any sites with on-premise devices or servers sending mail (local Exchange servers, scanners, etc.). These services must be identified before an accurate record can be generated. Each third-party service should provide details on what to include in an SPF record for their particular environment. These must be combined into a single correctly formatted TXT record in the DNS zone of each domain used to send mail.
Google Workspace SPF Setup
When using Google Workspace, always use the 'soft fail' parameter (the "~" character) near the end of the SPF record. For example, your SPF record for Google Workspace should look like this:
Microsoft 365 SPF Setup
When using Microsoft 365, use the 'hard fail' parameter at the end of the SPF record: -all
For example, the SPF record should look like this:
And NOT these:
v=spf1 include:spf.protection.outlook.com ?all
v=spf1 include:spf.protection.outlook.com all (this typo allows email from everywhere!)
v=spf1 include:spf.protection.outlook.com
Microsoft recommends the 'hard fail' parameter, but 'soft fail' parameter (the "~" character instead of "-") also works and may be more helpful for some organizations in allowing third parties to send emails on your behalf.
DomainKeys Identified Mail (DKIM)
DKIM signs each message that leaves the mail server so the destination server knows that the message came from the sender's organization. Luckily, DKIM is easy to configure with Microsoft 365 and Google Workspace.
Microsoft 365 DKIM Setup
Enable DKIM on all your domains using the DKIM wizard in the Microsoft admin security center. Follow the instructions for adding DNS records to your DNS host.
Microsoft's default domains (onmicrosoft.com domains) have DKIM set up by default.
Google Workspace DKIM Setup
Enable DKIM on all email domains by following this article from Google Support.
You must wait 24 to 72 hours after enabling Gmail with a registered domain before you can create a DKIM record. Google does this to prevent its platform from being used for spam.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC is the technology that allows for message traversal reporting and builds upon both SPF and DKIM. DMARC is important to implement, especially for email reputation.
DMARC Using Cloudflare
We recommend configuring DMARC through Cloudflare. Cloudflare will automatically create the correct DMARC record for you.
Sign into your Cloudflare account where your domain already exists, and DNS is being managed.
In the Cloudflare dashboard sidebar, navigate to Email > DMARC Management
Click Add.
By default, the policy is deployed in 'none' mode (report-only). We recommend increasing this security by simply replacing 'none' with 'quarantine' in the TXT DMARC record that was just created under DNS > Records.
Setup DMARC Manually
When creating a DMARC DNS record manually, you specify a policy. We recommend deploying the DMARC TXT record with the "quarantine" policy,
Create a TXT (text) record with '_dmarc' as the name/target.
The content of the TXT record should be as follows:
v=DMARC1; p=quarantine; rua=mailto:your_reporting_email_address@here.com
The policy can optionally be increased to 'reject' if higher security is needed.
Vanity or Parked Domains
Vanity or parked domains are extra domains acquired to safeguard an organization's brand and likeness but not actively utilized for any services, including email. Best practice involves prohibiting email sending on vanity or parked domains. Use all of the following DNS records to prohibit email sending on a domain:
Not all DNS hosts support wildcards in public DNS records, so the DKIM restriction may not always be possible.
Last updated
