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.

DNS changes can take time to take effect. To avoid disruption, we recommend making DNS changes at the end of working 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 [email protected]

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:

    v=spf1 include:_spf.google.com ~all

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:

    v=spf1 include:spf.protection.outlook.com -all
  • 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:

    • The policy can optionally be increased to 'reject' if higher security is needed.

Optional - SMTP MTA Strict Transport Security (MTA-STS)

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:

  1. Download this file to your computer and extract the contents:

  2. Login to Cloudflare and navigate to the R2 storage service.

  3. Create a new bucket in Cloudflare R2 and name it: mta-sts

  4. Upload the FOLDER called ".well-known" that you extracted in step 1 to the new bucket.

  5. Under the bucket's Settings tab, click Connect Domain.

  6. 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

  7. 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

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

Copyright © Good Heart Technology