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.
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.
If your email address is provided by another organization, they bear the responsibility of setting this up for you. For example, if your email address ends in
gmail.com, Google is handling email authentication for you.
If you send email from a custom domain, particularly for a newsletter, keep reading.
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
If you don’t know which servers you use to send email, performing an MX lookup on your domain might help you figure it out.
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.
~all part indicates a soft failure, so the email will end up in someone’s spam folder rather than being rejected. If you’re confident everything is working correctly, you can change this to
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.
- SPF & DKIM records, a comic by Julia Evans
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 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
k3, so you’ll need to have CNAME records for each of these. Here’s what we use for Faculty:
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:
If you use MailerLite, just substitute
example.com with your domain.
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
firstname.lastname@example.org, publish the following TXT record with a host of
v=DMARC1; p=none; rua=mailto:email@example.com;
example.com with your domain.
p=none as a good place to start. Once you can be sure everything is working correctly, you can use
p=quarantine or even
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.
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.