How to set up DNS for WordPress email: SPF, DKIM, DMARC

Three DNS record types control whether email sent from a WordPress site is trusted by receiving servers: SPF (which servers are authorized to send), DKIM (cryptographic signature proving the message was not altered), and DMARC (policy telling receivers what to do when checks fail). Without these records, WordPress email is more likely to land in spam or be rejected outright.

These records are configured at the DNS host, typically the domain registrar or the hosting provider’s control panel.

What is DNS?

The Domain Name System (DNS) is the telephone book of the internet. Its entries are instructions that link domain names, such as google.com to IP addresses such as 142.250.179.206, which are the unique server identifiers of the internet.

DNS can provide a wide range of additional types of information beyond this. Cloudflare, a DNS service provider, lists 25 such types. For setting up DNS records for sending emails from WordPress, the types we need to focus on are DKIM, MX, SPF, and DMARC.

What is SPF?

An SPF (Sender Policy Framework) record is DNS record of type TXT record that specifies the servers authorized to send emails from a particular domain. DNS TXT records allow domain administrators to input arbitrary text into the Domain Name System (DNS). Initially created to include essential notices about the domain, TXT records have evolved to serve other purposes, including email authentication.

The need for SPF records arises from the fact that the Simple Mail Transfer Protocol (SMTP), the standard protocol for email, does not inherently authenticate the “from” address in an email. Without SPF or other authentication mechanisms in place, attackers can easily impersonate senders and deceive recipients into taking actions or divulging information they otherwise wouldn’t.

An SPF record functions like a guest list managed by a door attendant. If someone isn’t on the list, the attendant won’t let them in. Similarly, if a sender’s IP address or domain isn’t on the SPF record, the receiving server (acting as the door attendant) may mark those emails as spam or not deliver them at all.

SPF records are just one of many DNS-based methods that help email servers determine whether an email originates from a trusted source. Domain-based Message Authentication Reporting and Conformance (DMARC) and DomainKeys Identified Mail (DKIM) are two other mechanisms used for email authentication.

SPF records once had a dedicated DNS record type. However, this dedicated record type has been deprecated, and now only TXT records are used for SPF purposes.

Without an SPF record, receiving servers have no way to verify that your WordPress site’s mail server is authorized to send on behalf of your domain. Most mailbox providers penalise unauthenticated mail.

What is DKIM?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message. The sending server signs the message with a private key; the receiving server retrieves the matching public key from a DNS record and verifies the signature. If the signature checks out, the receiver knows the message was sent by an authorized server and was not altered in transit.

Where SPF verifies the sending server’s IP address, DKIM verifies the message content itself. Together they cover both “who sent it” and “was it tampered with.”

DKIM is particularly important for WordPress sites using third-party SMTP services, since the sending IP belongs to the service (covered by SPF), but the DKIM signature proves the message is authorized by the domain owner.

What is DMARC?

DMARC (Domain-based Message Authentication Reporting and Conformance) sits on top of SPF and DKIM. It does two things:

  1. Policy. Tells receiving servers what to do when a message fails SPF and DKIM checks: none (monitor only), quarantine (treat as suspicious), or reject (refuse delivery).
  2. Reporting. Receiving servers send aggregate reports back to the domain owner, showing which IP addresses are sending mail on behalf of the domain and whether those messages pass or fail authentication.

DMARC also introduces the concept of alignment: the domain in the From header must match the domain authenticated by SPF or DKIM. This closes a loophole where a spammer could pass SPF (by sending from their own server, listed in their own SPF record) while spoofing a different domain in the From header.

For WordPress sites, DMARC reporting reveals whether all outgoing email (core notifications, plugin emails, contact form submissions) is passing authentication – or whether a misconfigured plugin or forgotten sending service is generating failures.

Setting up SPF, DKIM, and DMARC records

Setting up DNS records involves adding TXT and CNAME records to the domain’s DNS zone, using values provided by the email service. The general steps are below, with links to host-specific instructions where available.

Step 1: Collect the information from your email service provider

Your email service provider needs to tell you what DNS records you need to set up to work with their servers. In the example below, email service provider ImprovMX requires us to set up four entries:

Email service DNS entries

Note that each entry has three parts:

  1. The DNS entry type (TXT, CNAME).
  2. The subdomain of your domain for which this record needs to be entered (the part to the left of nanopo.st, e.g. dkimprovmx1._domainkey or _dmarc.nanopo.st). Where there is no subdomain, you usually enter @.
  3. The value of the entry (v=spf1 include:spf.improvmx.com ~all or v=DMARC1; p=none;).

Not all email service providers will require a DMARC record.

Step 2: Enter these records into your DNS settings

On Cloudflare’s DNS management screen, this might look something like this:

Cloudflare DNS records

Step 3: Click verify on your email service provider’s screen

Next to where your email service provider provides the details you collected in step 1 above, they will display a button labeled something similar to “Check” or “Validate“, like this:

Email DNS verify

Clicking that will cause your DNS records to be checked. If you entered them correctly, a confirmation will appear.

DNS setup instructions for select email service and hosting providers

DNS setup steps vary by provider. The links below go to each provider’s own documentation for configuring SPF, DKIM, and DMARC records.

Hosting providers Email service providers
A2 Hosting<br>Bluehost<br>Cloudways<br>Dreamhost<br>FastComet<br>GreenGeeks<br>Hostinger<br>Inmotion Hosting<br>Kinsta<br>Liquid Web<br>Nexcess<br>Pagely<br>Pantheon<br>Pressable<br>Presslabs<br>Siteground<br>WP Engine<br>WPX Hosting<br>iThemes Hosting Amazon SES as a WordPress SMTP Server<br>Brevo (Sendinblue) as a WordPress SMTP Server<br>Elastic Email as a WordPress SMTP server<br>Gmail as a WordPress SMTP server<br>MailPoet as a WordPress SMTP server<br>Mailchimp Transactional Email (formerly Mandrill) as a WordPress SMTP server<br>Mailgun as a WordPress SMTP Server<br>Mailhawk as a WordPress SMTP server<br>Mailjet as a WordPress SMTP Server<br>MessageBird Email (formerly Sparkpost) as a WordPress SMTP server<br>Netcore Email API (formerly Pepipost) as a WordPress SMTP server<br>Postmark as a WordPress SMTP server<br>SMTP.com as a WordPress SMTP server<br>SMTP2GO as a WordPress SMTP Server<br>SendGrid as a WordPress SMTP server<br>SendLayer as a WordPress SMTP server<br>Zeptomail (by Zoho) as a WordPress SMTP server<br>Zoho Mail as a WordPress SMTP server

Troubleshooting

Occasionally things go wrong, in which case you’ll need some deeper inspection tools. We’ll link them here, but won’t go into details, as this is intended as an introductory tutorial:

Tools to test SPF, DKIM, and DMARC records

Summary

SPF, DKIM, and DMARC are the three DNS-based authentication standards that determine whether receiving servers trust email from your domain. Configuring all three correctly – through your domain registrar or hosting provider’s DNS panel – protects against spoofing, improves inbox placement, and is a prerequisite for DMARC enforcement. Without them, WordPress email sent through any provider is more likely to land in spam.

References and further reading