Email Sender Validation Using DNS (SPF, DKIM, & DMARC)
Last updated
Last updated
Copyright © Good Heart Technology
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.
DNS changes can take time to take effect. To avoid disruption, we recommend making DNS changes at the end of working hours.
To test which of these technologies is currently already working, you can send an email from an account on the same domain to [email protected]
You'll receive an automatic reply with a link that contains the full report on the email deliverability of the sender's domain. If everything looks good, it should look like:
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.
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:
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.
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.
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.
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.
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.
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.
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:[email protected]
The policy can optionally be increased to 'reject' if higher security is needed.
SMTP MTA Strict Transport Security (MTA-STS) helps ensure that email communications are encrypted during transmission, significantly reducing the risk of interception or tampering. This is particularly important for nonprofits using Google Workspace or Microsoft 365 to protect sensitive information and maintain trust with their collaborators. These instructions require the use of our preferred DNS host, Cloudflare. Follow these steps to deploy MTA-STS:
Download this file to your computer and extract the contents:
Login to Cloudflare and navigate to the R2 storage service.
Create a new bucket in Cloudflare R2 and name it: mta-sts
Upload the FOLDER called ".well-known" that you extracted in step 1 to the new bucket.
Under the bucket's Settings tab, click Connect Domain.
Specify the subdomain mta-sts. Cloudflare will initialize the domain, which can take 5-10 minutes. Then the file will be available at https://mta-sts.yourdomain.org/.well-known/mta-sts.txt
Finally add both of the following TXT records to your DNS configuration in Cloudflare:
Create TXT record for MTA-STS
Name: _mta-sts
Value: v=STSv1; id=20220101000000Z;
Create TXT record for TLSRPT
Name: _smtp._tls
Value: v=TLSRPTv1;
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:
Protocol or Standard
Record Type
Name
Value
Priority
SPF
TXT
@
v=spf1 -all
DMARC
TXT
_dmarc
v=DMARC1; p=reject;
DKIM
TXT
*._domainkey
v=DKIM1; p=
MX
MX
@
.
0
Not all DNS hosts support wildcards in public DNS records, so the DKIM restriction may not always be possible.
Click Enable DMARC Management:
