SPF, DMARC, DKIM – OH MY

Recently, Google has started imposing additional requirements on bulk email senders who send more than 5000 messages a day to GMAIL accounts.

For most WordPress sites this will be a non-issue since they’re not sending more than 5000 emails a day. Though, from the press this change has received you’d think the sky is falling.

Still, it is very good practice to do what Google is suggesting because it will increase the deliverability of your emails.

View All Google Email Sender Guidelines

What Does Google Want You To Do?

In short, Google wants you to:

• Set up additional records in your DNS – if you don’t know what “DNS” means, you should probably stop reading and contact your web site professional. Seriously – if you make a mistake with these records your deliverability to GMAIL and YAHOO will drop to something close to zero percent.
• Use TLS for sending emails – most email providers already do this so it should be a non-issue.
• Keep your spam reports to below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.

In this article we’ll talk about the DNS records you’ll need to setup – in particular, the SPF, DMARC and DKIM records.

In all three cases, the records will be TXT records where the host name or name of the record is your domain and the value is the value for SPF, DMARC and DKIM.

What Does This Have To Do With WordPress?

In short, nothing. These requirements have nothing to do with core WordPress at all – it applies regardless of where your emails originate. All configuration changes you need will be done outside of WordPress.

But, if you’re sending a lot of emails from WordPress (more than 5000 per day), you will be impacted so you must take action now.

And, even if you don’t, we suspect that Google will continue to tighten up the requirements until they do eventually affect you.

So, let’s move on to talk about what these DNS records do and why they’re so important.

SPF

In the Google docs, they define the SPF record as follows:

An SPF record identifies the mail servers and domains that are allowed to send email on behalf of your domain. Receiving servers check your SPF record to verify that incoming messages that appear to be from your organization are sent from servers allowed by you.

Domains can have one SPF record. However, the SPF record for a domain can specify multiple servers and third parties that are allowed to send mail for the domain.

If you’ve ever seen someone spoof your email address or received an email where it’s clear that the sending address is not valid, setting this up will stop those right in their tracks (at least for your email addresses).

The value of your SPF record will be something like this:

v=spf1 include:mailgun.org ~all

Here is another example:

v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.net ~all

Most common SPF records consist of up to FOUR segments:

• v=spf1 – right now this is ALWAYS included and simply indicates that the DNS TXT record is an SPF record and that the version of SPF to use is version 1.
• ipv4= – this indicates which IPv4 addresses are allowed to send emails for your domain.
• include: – this indicates which third party email servers are allowed to send emails on behalf of your domain. In the first example MAILGUN is allowed to send emails on behalf of the domain.
• –all – This tells the receiving mail server that all emails that do not match the rules should be rejected.

There are additional components that you can specify in an SPF record:

• ip6 – works similar to ipv4 described above but uses IPv6 addresses instead
• mx – authorize one or more mail servers using simply the mx record url – e.g.: mx:mail.server.com
• a – authorize one ore more mail servers using a domain – e.g.: a:mydomain.com
• ptr – using this is not recommended
• exists – this mechanism executes a DNS A record search for the domain provided. A match happens when a valid A record is found

A domain cannot have more than on SPF record. BUT, you can have separate ones for each subdomain.

SPF Misc Rules

• An SPF record cannot contain any uppercase characters.
• There is a character limit of 255 characters. Any string exceeding this number will result in failed authentication.
• Instead of ‘-all’ you can use ‘~all’ which will soft-fail the authentication. In other words, it’s unlikely that the server with matching IP address is authorized to send for the domain. The receiving server will typically accept the message but mark it as suspicious.

Here is an example of an SPF TXT record setup at CloudFlare:

---

DMARC

In the Google docs, they define the DMARC record as follows:

DMARC tells receiving mail servers what to do when they get a message that appears to be from your organization, but doesn’t pass authentication checks, or doesn’t meet the authentication requirements in your DMARC policy record.

Messages that aren’t authenticated might be impersonating your organization, or might be sent from unauthorized servers.

DMARC checks your SPF or DKIM records to see if the incoming message is authorized. If it fails authorization, DMARC kicks in to determine how the message should be handled.

Here is the simplest example of a DMARC record

v=DMARC1;p=none;pct=100;

It consists of three components:

• v= – This is the DMARC protocol version. The default is “DMARC1”;
• p= – Apply this policy to emails that fail the DMARC check. This policy can be set to ‘none’, ‘quarantine’, or ‘reject’. ‘none’ is used to collect DMARC reports and gain insight into the current email flows and their status;
• pct= – The percentage tag instructs ISPs to only apply the DMARC policy to a percentage of failing email’s. ‘pct = 50’ will tell receivers to only apply the ‘p = ‘ policy 50% of the time against email’s that fail the DMARC check. NOTE: this will not work for the ‘none’ policy, but only for ‘quarantine’ or ‘reject’ policies;

Other components that can be used are as follows:

• rua – A list of URIs for email service providers to send aggregate reports to. NOTE: this is not a list of email addresses. DMARC requires a list of URIs of the form ‘mailto:[email protected]’. If you want to see a list of failing emails, set this component – here’s an example:

v=DMARC1;p=none;pct=100;rua=mailto:[email protected];

• ruf – A list of URIs for ISPs to send forensic reports to. NOTE: this is not a list of email addresses. DMARC requires a list of URIs of the form ‘mailto:[email protected]’.
• o – Forensic options. Allowed values: ‘0’ to generate reports if both DKIM and SPF fail, ‘1’ to generate reports if either DKIM or SPF fails to produce a DMARC pass result, ‘d’ to generate report if DKIM has failed or ‘s’ if SPF failed;
• adkim – Specifies the ‘Alignment Mode’ for DKIM signatures, this can be either ‘r’ (Relaxed) or ‘s’ (Strict). In Relaxed mode, authenticated DKIM signing domains (d=) that share an Organizational Domain with an email’s From domain will pass the DMARC check. In Strict mode an exact match is required;
• aspf – Specifies the ‘Alignment Mode’ for SPF, this can be either ‘r’ (Relaxed) or ‘s’ (Strict). In Relaxed mode, authenticated SPF domains that share an Organizational Domain with an email’s From domain will pass the DMARC check. In Strict mode an exact match is required;
• ri – The reporting interval for how often you’d like to receive aggregate XML reports. This is a preference and ISPs could (and most likely will) send the report on different intervals (normally this will be daily).

Here are a few more DMARC examples:

• v=DMARC1; p=none; rua=mailto:[email protected]; this DMARC record sets DMARC policy to monitoring mode (p=none), which allows you to monitor email authentication status, without sending failed emails to spam or rejecting them; also, sends aggregate reports to [email protected].
• v=DMARC1; p=quarantine; rua=mailto:[email protected]; this DMARC record sets DMARC policy to quarantine mode (p=quarantine), which allows you to monitor email authentication status, and sends emails that fail DMARC authentication to spam; also, sends aggregate reports to [email protected].
• v=DMARC1; p=reject; rua=mailto:[email protected]; this DMARC record sets DMARC policy to reject mode (p=reject), which allows you to monitor email authentication status, and rejects emails that fail DMARC authentication; also, sends aggregate reports to [email protected]. This DMARC record offers complete email protection against spoofing.

---

DKIM

DKIM is probably the most complex record to setup. You can setup SPF and DMARC records with little or no input from your email provider. But you cannot do that for DKIM. This is because DKIM is a cryptographic spec that requires the use of public and private keys.

In particular, your email provider will need to provide you with a public key for your DNS DKIM record. The corresponding private key will be held on the email server and will be used to sign your outgoing emails.

Not all email providers are able to do this – usually because of the way their email servers work. I’m aware of some very large hosts who cannot provide DKIM keys!

In the Google Docs, they define DKIM as follows:

DKIM is a standard email authentication method that adds a digital signature to outgoing messages. Receiving mail servers that get messages signed with DKIM can verify messages actually came from the sender, and not someone impersonating the sender. DKIM also checks to make sure message contents aren’t changed after the message has been sent.

A DKIM record looks something like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA671V0PY29IRdJVrT+fy1DPwdzuXjTvaDUCBRAKZrUJyoE/gd2ZZXlCO0q3oMy+vwHKaH9g0Jji187rRhqMiZBiiABR6dv3UZXcgHYEdSSUJ+C69mPgcrKwHpd6rOrquWFbcHiQY174sfMDw/38uwBa88eza3dxmlttn+CSaSbhxhUD68CbHEepwMyMbUV6wWLv+ThMW/SFfPj7k0w2Cyn1s3HNurEo4Oqs9ZKpYeKMNqyVKjTvI6rhLiR1JBCX35qazi5+cyGNAfGgyJ3eE1MhDJfytz+6c3QF7DenG8ZozR3vPMy3jB6asIv48xt6V5nSqWCIKwuEfIXtarglfHKwIDAQAB

As with SPF and DMARC records, DKIM records have a number of components:

• v=DKIM1 – this is always included and specifies the version of DKIM to be used.
• p= – this is the public key and is provided to you by the email provider who operates your email servers.

One twist with DKIM records is that the NAME of the TXT record has a specialized format:

selector._domainkey.domain.com

The selector is a specialized value issued by the email service provider used by the domain. It is included in the DKIM header to enable an email server to perform the required DKIM lookup in the DNS. The domain is the email domain name.

._domainkey. part is included in all DKIM record names.

Here is an example of a DKIM TXT record name – notice that the ._domainkey. portion is included:

x._domainkey.wpclouddeploy.com

---

To look up the DKIM record, email servers use the DKIM selector provided by the email service provider, not just the domain name.

Suppose yourdomain.com uses MAILGUN as their email service provider, and suppose MAILGUN uses the DKIM selector xemail. Most of yourdomain.com’s DNS records would be named yourdomain.com, but their DKIM DNS record would be under the name xemail._domainkey.yourdomaincom.

Wrap Up

After reading all that it might be hard to see why all three records are needed. But, they work hand-in-hand with each other.

An SPF record tells the receiving email server whether or not the sending server is authorized to send emails. The DMARC record controls what happens when an email is detected to be invalid. And the DKIM record protects the integrity of your email – making it impossible (or close to impossible) for someone to change the contents or send content on your behalf.

If you’re not comfortable with creating these records for your email account, you can usually get help from one of the many tech folks involved with your account – either your hosting provider, your email provider or a web developer.

In the case of the DKIM record, you’ll definitely need that information from your email service provider.

Once these records are setup, you should send a test email each day for the following three days to verify that your messages are not being rejected or sent to spam.

---

References

The following references were used when creating this article:

• DMARCLY – Everything about a DMARC record
• Cloudflare – DKIM records
• Cloudflare – DMARC records
• CloudFlare – SPF records
• Google – Spoofing, Phishing and Spam