Last month, we sent the first issue of the Faculty newsletter since the pandemic. We didn’t know what to expect. Would people remember us? Did they want to hear from us?

Thankfully, everyone loved it.

But, we had a problem. Many subscribers didn’t realize we had sent it until they saw me mention it on social media. They never got it.

What happened?

It turns out that our newsletter was being flagged as spam. In the years since we sent the last issue, a lot has changed. Google, Yahoo, and others started requiring email authentication (SPF or DKIM) in 2022. Beginning February 2024 (tomorrow), they’ll also require DMARC for bulk senders. If you have a newsletter with more than 5,000 subscribers, that includes you.

Email authentication, like HTTPS, has evolved from being a nice-to-have to a standard expectation.

I’ll show you how to set up SPF, DKIM, and DMARC.

SPF

SPF was the first real attempt at email authentication. It uses a DNS TXT record to indicate which servers are allowed to send email from your domain.

It’s easy to implement, but you’ll need to know two things:

• How to create a TXT record for your domain
• Which servers you use to send email

The SPF record syntax is pretty straightforward, but there are a lot of options, so it can be overwhelming. Here’s the record I use for my personal email:

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

For clarity, this is the value of a TXT record with a host of @. It’s what Google recommends if you only send email from Google.

When a server receives an email claiming to be from me, it can look up my SPF record to see that only Google is allowed to send email from my domain, and then verify whether the email was in fact sent by Google. (It does this by looking up the SPF record for _spf.google.com, which Google keeps updated.) If not, it’s flagged as spam.

At Faculty, we use Google for our regular email and Mailchimp for our newsletter. To allow both of these to send email from our domain, our SPF record is a little different. We need to include _spf.google.com to allow Google to send email on our behalf and servers.mcsv.net to let Mailchimp send email on our behalf. You can only have one SPF record, so to allow both, you need to include both like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

I have a friend who uses Google for her personal email and MailerLite for her newsletter. Here’s her SPF record:

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

If your situation is different, seek examples from your email service provider(s). Just remember that if you send personal email using one provider and a newsletter using a different provider, you might have to combine two examples into a single SPF record.

More information:

• SPF & DKIM records, a comic by Julia Evans
• The check_host() function and examples from RFC7208 if you want to learn more about how SPF records are checked
• The SPF Surveyor from Dmarcian

DKIM

DKIM lets you sign your outgoing emails using public-key cryptography. You publish the public key in DNS, so receivers can use it to verify the signature.

Google makes DKIM easy to implement but hard to find. Gmail settings are currently found here:

Admin → Apps → Google Workspace → Gmail

From here, you should be able to authenticate email.

Google will generate a key pair and provide the TXT record you need to add to your DNS. This record contains the public key, and once Google confirms you’ve added it, it will use the corresponding private key to sign your outgoing email.

Once you set it up, it’s seamless.

Setting up DKIM with Mailchimp is a little different. Instead of publishing your own DKIM record, Mailchimp wants to do it for you. To give Mailchimp the ability to do this, you need to add a few CNAME records instead. Mailchimp uses selectors k1, k2, and k3, so you’ll need to have CNAME records for each of these. Here’s what we use for Faculty:

k1._domainkey.faculty.com → dkim.mcsv.net

k2._domainkey.faculty.com → dkim2.mcsv.net

k3._domainkey.faculty.com → dkim3.mcsv.net

If you use Mailchimp, just substitute faculty.com with your domain, and this should work for you, too.

MailerLite uses the same approach as Mailchimp, but you only need to publish one CNAME record:

litesrv._domainkey.example.com → litesrv._domainkey.mlsend.com

If you use MailerLite, just substitute example.com with your domain.

More information:

• DKIM Record Checker from Dmarcian
• DKIM Validator from Dmarcian

DMARC

DMARC uses a DNS TXT record to indicate whether email from your domain is protected by SPF and DKIM, what to do when a check fails, and how to report back. It’s required for anyone sending more than 5,000 emails per day, which includes a lot of newsletters.

Because reports are sent as individual emails, I decided to use a service. DMARC services can receive and consolidate all of the reports on your behalf, providing you with a user-friendly summary. It’s better than wading through thousands of emails or ignoring the reports altogether.

I’m currently using Dmarcian. It’s free for personal use, but if you have a newsletter, you might have to pay. My friend Jason recommends DMARC Digests from Postmark, which offers less detail but is less expensive.

Setting up DMARC with a service is easy, because the service will provide the record you need to add, complete with a unique email address where reports will be sent.

If you want to receive your own reports rather than use a service, you probably at least want to set up a separate email address that you can check independently. To set up a DMARC record for example.com and receive reports at dmarc@example.com, publish the following TXT record with a host of _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc@example.com;

Just substitute example.com with your domain.

More information:

• DMARC.org
• RFC 7489
• Dmarcian, the service I use
• DMARC Digests, another DMARC service

Testing

By far the most helpful tool I have found is AboutMy.email. This is a service that provides an email address for you to send email to, and it will give you every kind of insight you can imagine. If you have a newsletter, send a test email to this tool before sending to all of your subscribers, and you should be able to identify problems before they affect deliverability.

I can’t recommend it enough.

Summary

With email authentication set up correctly, your emails should reliably find their way to their recipients. With DMARC in particular, you’ll be able to quickly identify problems as they arise or reassure yourself that all is well.

If you like this post, perhaps you’d like to subscribe to my blog. And, if you like reading about design, technology, and assorted miscellany, I hope you’ll subscribe to the Faculty newsletter.

Thanks for reading.