Ok, you've got an idea of what you need to do to get your emails to the inbox, so let's take that first step on the road toward the Email AuthentiCity...
Who are your trusted senders?
They say the first step is always the hardest, but this initial planning step is critical to properly setting up your email authentication.
Take some time to think through EVERY system that sends email with "[email protected]". Your ESP is the biggest one, but as a web professional, I can almost guarantee you have at least two other sources - your "regular" email and your website.
If your email is set up with one of the big providers (e.g. Google, Outlook, Zoho), then your DNS records are probably already set up; this would have been part of the initial configuration with adding MX records and the other associated records.
Start by making a list of all the systems you send email from. You'll then need to determine if they send email from YOUR domain.
Some systems may let you put in your name as a "display name" but actually send from their domain. For example, my booking system sends confirmation emails from "Stacy Clements", but the email is not sent from MY domain; it uses the booking system domain, bookme.name.
Once you've identified all your sending sources, let's ease on down the road to the Email AuthentiCity.
SPF
Remember, the SPF record is a TXT record in your DNS that shows all the servers that are allowed to send using your domain name. For the Feb 2024 Google/Yahoo changes, the focus is on ESPs, but if you set this up considering only your ESP, you're potentially going to block other important emails.
If I could send from this domain...
Look at your list of platforms from which you send email. For those that use YOUR DOMAIN to send email, check to see if they have an SPF record for you to include.
Watch out! You can only have one SPF record per domain.
Combine SPF entries into one record
The instructions from your ESP or other service may simply tell you to "add this TXT record to your DNS" and give you something like:
v=spf1 include:_spf.google.com ~all
But don't add multiple records for your multiple services. A domain can only have one SPF record; otherwise, SPF checks will return an SPF PermError (permanent error) which may lead to deliverability problems.
If you have multiple SPF records to include, you'll need to combine them.
How to merge multiple SPF entries
Now you've gathered up all the SPF entries you need to include. How do you combine them into one record?
The exact method for creating an SPF record varies slightly depending on what you use to manage your DNS, but essentially there are three main components:
Record type: This should be TXT. There are still a few DNS management systems out there that still show an option for an "SPF" type record, but the DNS SPF record was deprecated in 2014, so be sure to use TXT.
Name: This is the domain name that you are "assigning" the SPF entries to.
Content: This is where you combine the entries you have.
The content must start with "v=spf1"; this declaration should only be used once.
Next you add the allowed domain names (or IP addresses). Each must have an "include" statement for domain names, or if you have an IP to include, the entry shows the type of IP address (most likely ip4) and the IP.
At the end, you add the enforcement rule. This is typically ~a (softfail) or -a (hardfail). I use ~a, for the reasons recommended in this Mailharder article, although -a (hardfail) may be appropriate if stricter enforcement is needed (or if you have a domain that should not be sending emails).
SPF example
You send email from Google, you have Mailgun set up to send transactional email from your website, and you use Mailerlite for marketing emails. Instead of three records:
v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.mlsend.com ~all
v=spf1 include:mailgun.org ~all
You will have one record:
v=spf1 include:_spf.google.com include:_spf.mlsend.com include:mailgun.org ~all
It's unlikely unless you run your own server, but if you need to include an IPv4 address in your SPF record, you'll add it with the ip4 mechanism, so your record might look like this:
v=spf1 include:_spf.google.com include:_spf.mlsend.com include:mailgun.org ip4:188.241.151.48 ~all
Watch out! There are some other things to watch for with SPF records. The ones you are most likely to encounter are:
- Limited to 255 characters
- Don't use uppercase characters
- Limit of 10 DNS lookup entries (not the same as the different "include" entries you added)
Check your SPF record
There are several services where you can check your SPF record for free. A few of my favorites:
I recommend adding a regular check to your business processes. Sure, once you've set it up, as long as you don't change anything with your email senders, it should be okay.
But it's possible your sending sources may make a change. You'll want to make sure there are no glitches that cause errors in your SPF record. And especially if anyone else has access to your DNS records, you'll want to monitor for changes (to any records).
Also, if you do make changes to any of your services, remember to check and validate your SPF record.
Plot twist!
Not every sender that uses your domain will have an SPF entry for you to add. Many of you use Postmark for transactional email, and may remember you did not have to set up SPF for Postmark. Mailchimp is one example of an ESP which does not provide an SPF entry.
Technically, you only need an SPF record for senders which use your domain for the Return-Path address (Postmark wrote a good explanation about this and why you don't need to add an SPF record for Postmark), but mostly what you need to know is just to check the verification methods for your specific sender.
Typically, there will be some sort of "authenticate your domain" wizard which will tell you exactly what records you need to add to your DNS. Instead of an SPF entry, some systems will have you create a CNAME entry which will include authentication information.
Now that you've identified all your sending sources, and set up and checked your SPF records, let's take a look at DKIM.
DKIM
Wait, my head's all full of SPFing...what is DKIM about again?
DKIM, or DomainKeys Identified Mail, is an email authentication standard that allows "digital signing" of emails to verify their integrity and authenticity.
Ok, what does that mean in plain English? Think of it like this:
Say you get a letter, and the "from" address on the envelope says it's from your friend. But anyone can write your friend's address on an envelope and put a letter in the mail.
Think back to the days when royal decrees were sent out. These documents had the royal seal on them, to prove they were signed by the monarch. Sometimes documents were closed using wax, with the seal impressed into the wax. As long as the seal was intact. the receiver of the document would know the documents were authentic and had not been tampered with.
DKIM acts as your verified signature
DKIM is used to "sign and seal" emails sent from your approved servers. This verification is done using a public/private key pair.
Did you ever have a "secret decoder ring" as a kid? DKIM works something like that. Servers authorized to send your emails use their "private key" to encode a message. The "public key" then allows the receiver to verify and decode the message.
DKIM private and public keys
The email service provider is responsible for generating the private/public key pair. The services you use will typically generate the key pair for you, and provide you a DKIM record to publish in your DNS.
This DKIM record is a TXT record that includes the "public key" that is used to verify the DKIM signature on a message. Unlike SPF records, you will likely have multiple DKIM records; a DKIM record also includes a "selector" specifying which public key should be used for verification.
Some services will give you the option of choosing a 1024 or 2048 (or possibly even 4096) bit key. Do not use a key any smaller than 1024 - shorter keys can be cracked in a short amount of time (kind of like using an 8 character password). Be cautious when using a key larger than 2048; there may be limitations on the size allowed by your DNS provider, and there are still some older email systems out there that may not support DKIM keys with larger sizes.
Pro tip: When you add a DKIM record to your DNS, keep a note on what selector goes with what service. Sometimes the selector you are given includes a clue, like "google" for Google Workspace email, but often you are given a generic selector such as "k1". If you don't annotate somehow, you may end up with a bunch of DNS records and no idea what service they belong to. (Ask me how I know.)
Example: you send email from Google, you have Postmark set up to send transactional email from your website, and you use Mailerlite for marketing emails.
You'll have three DKIM records - TXT records that will look something like this:
Name: google._domainkey
Content: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2nRUpz6hucTiwJ8HjpzGw5g7jMJHk3/usrTrRlrn69+qRS+DS6NZqP4YGM28B04H5S1lZs1TWYM1l1hObHluFZF5B1XKzyM7kfnfep0KfgElRAV1H7UUtHXUhcPVsseJy39JpDn48/TQuvrUM5hzHpa96llYHDakhohRKO+lNBhD3sbbOZvAfV/I8SH5xCTmjDWnqhqVZ9MeTDJZt0cATvshs+nyaUWZWePLZpGn1wSfRivxQsArUSnuve/drEa5vvHvI0Fqt0hEGz07YIYO5TGKyb3qqdPS6c3m4lH2zd5dJZKQ5+fiGoATOpO7/ffJbH3OKSPoa8qLXwFD/xWFJwIDAQAB
Name: 20231018181234pm._domainkey
Content:k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFq7sUVCaKkj41K4Vwb6rByjgznDUFS9eXNibWZ6dW7vU1be57WJMYhduMXhclRvzzBGnkSMUj4uIhA9GqqqRRG6klgiJ3RG/BMOkDVvTiBYqdXlwI2jE+Avd22IcVm2Q4LFNhxRZbHBVunLwBYyUEbGNMHKqNdEvMrMFX73h1XwIDAQAB
Name: ml._domainkey
Content: v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzkWjb4fSOJMsz1GsYThyyEz5uwkXpNYI7ZCc7/27KWyBRuNKZdMjC47wJgzmNFhuYwYO4jIyiu85sr+2kIpBh5CuuWaNRCzMLNfEHPr1EJODg1We1X4hm3I615XLxENIbGrlm5v6mL1RAo45oo5VfM0szASkKLawe5x9bMBpw8QIDAQABf
Validate your DKIM record
Usually, you just need to copy and paste the DKIM record your ESP provides, and go on about your business. However, if you have issues, or want to dig into the properties of the record, there are online services that can help validate your DKIM record.
I like the Mailhardener DKIM validator. MXToolbox DKIM record checker is another good option.
Plot twist!
There are some email providers who direct you to insert a CNAME record instead of a TXT record for DKIM. In these cases, the CNAME is pointing to a DKIM record in a DNS zone owned by the ESP.
Typically this is done because the email provider may rotate the DKIM keys. By using a CNAME, the customer (you) don't have to worry about changing your DNS records - your CNAME record automatically points to the correct record.
You may want to consider rotating your DKIM keys periodically, or if you are notified by your ESP of the need to do so - it's like changing your password.
Okay, your sender list is set up (SPF), and you have a way to verify your signature on the emails you send (DKIM), so you're ready to set up a DMARC policy.
DMARC
DMARC stands for Domain-based Message Authentication Reporting & Conformance (but no one remembers that). Essentially, DMARC is a policy mechanism; it works with SPF and DKIM and tells email receivers what to do with emails that don't pass those authentication checks.
DMARC also allows you to set up reporting, so an email receiver can tell you about emails it receives from your domain, and the results of the authentication checks.
How DMARC works
The DMARC process essentially follows these steps:
- Email Sent: The process begins when an email is sent from a sender's domain.
- Receiving Server Check: The receiving email server performs checks to authenticate the email. This includes SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication.
- Authentication Pass/Fail: If the email passes SPF and/or DKIM checks, it proceeds to delivery. If authentication fails for both SPF and DKIM, it moves to the next step.
- DMARC Check: The receiving server checks the DMARC record published by the sender's domain.
- DMARC Policy Enforcement: Based on the instructions in the DMARC policy, the receiving server takes action on the email. This can include delivering the email as usual (p=none), marking it as spam or placing it in quarantine (p=quarantine), or rejecting it outright (p=reject).
- Reporting: The receiving server sends a DMARC report to the domain owner (email address identified in the DMARC record), detailing the outcome of the DMARC checks and actions taken.
If you want to learn more about the technical details of how DMARC works, I recommend you take a look at LearnDMARC.com. You can send an email to "Neo", the LearnDMARC server, and you'll get a behind the scenes look at the technical process of how DMARC works.
Set up a DMARC record
A DMARC record is a TXT record in the DNS for your domain. Like SPF, you should have only one DMARC record per domain (there are some technical situations with complex email setups where you might have multiple records, but for our purposes - we just need one).
Parts of a DMARC record
Name: The "name" section of your DNS system should use _dmarc. What you are doing is setting up a subdomain of _dmarc.yourdomain.com. Depending on what system you use to manage DNS, you may or may not need to put in your domain name; i.e. for Cloudflare, just put _dmarc, otherwise the yourdomain.com part will be duplicated).
Type: The content part of the record must start with v=DMARC1. This tells querying systems that this TXT record is for DMARC.
Policy: This is the direction given to an email receiver on what to do with emails that fail SPF/DKIM checks. Options are p=none, p=quarantine, or p=reject.
When first setting up DMARC, start with p=none. This gives you a chance to identify any sending sources you may have missed, and ensure that your email authentication records are correctly configured. After monitoring for a period of time, step up to p=quarantine and eventually p=reject.
Reporting: This section tells email receivers where to send reports. There are two tags that can be used in this section: rua= where to send aggregate reports and ruf= where to send failure reports. Be sure to use mailto: before your email address in these tags (use the URI, not just the email address).
Technically, the reporting section is optional; you CAN have a valid DMARC record with just v=DMARC1; p=none. However, I recommend against this. A p=none policy does nothing for you, and having emails quarantined or rejected with no reporting mechanism - well, that's just a bad idea.
Optional tags for a DMARC record
Percentage: This is the sample of messages that should be restricted based on your policy. The percentage option (pct) is often used when tightening up DMARC restrictions, i.e. moving to quarantine or reject. If you don't want to risk all your emails going to the black hole, you can set a percentage amount such as pct=50.
Policy for subdomains: By default, the DMARC policy for a domain will be applied to all subdomains as well. If you wish to have a different policy applied to subdomains, you can use the sp tag. For example, if you want to apply a quarantine policy to your main domain, but your subdomains should not be sending email, you could add sp=reject, so the quarantine policy applies to your main domain, but the reject policy applies to subdomains.
SPF alignment mode: The aspf tag allows you to set how strict the SPF alignment should be. The default is aspf=r, which is relaxed mode, meaning that subdomains will be considered valid. If you need very strict security, then aspf=s can be used. This is strict mode, and requires that the "envelope from" domain sending the email must exactly match the return path (where bounces are sent).
DKIM alignment mode: Similarly, you can set how strict DKIM alignment should be, using adkim=r (relaxed) or adkim=s (strict). Generally, unless you need strict alignment for some reason, you don't need to include the adkim or aspf tags; the default is relaxed mode.
DMARC example
1. You have your SPF and DKIM records set up, and you're ready to start implementing DMARC, but you want to start with just monitoring, to ensure you have identified and properly configured your SPF and DKIM.
Your DMARC record will look something like this:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]
- v=DMARC1 indicates the DMARC version.
- p=none specifies the policy as monitoring mode, meaning that emails failing DMARC checks won’t be rejected or quarantined.
- rua=mailto:[email protected] designates the email address where aggregate reports (periodic summaries of DMARC results) should be sent.
- ruf=mailto:[email protected] specifies the email address for failure reports (note that most email providers no longer send failure reports due to privacy reasons)
2. You have been monitoring DMARC for a while, and want to tighten your DMARC restrictions. You want to set a policy of quarantine, but you want to limit it to 50% of emails, to keep from impacting email flow and reputation.
Your DMARC record will change to look like this:
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]; ruf=mailto:[email protected]
3. You're confident your email authentication records are configured correctly, and enforcing a strict DMARC policy won't disrupt legitimate email. Implement the p=reject policy, but start slow, perhaps with 20%, and slowly increase as long as your monitoring shows no issues.
v=DMARC1; p=reject; pct=20; rua=mailto:[email protected]; ruf=mailto:[email protected]
The never-ending story
You've successfully navigated the bewildering forest of SPF, DKIM, and DMARC (oh my!), and made it to Email Authenticity. But you can't just snooze in the poppy field. Managing email authentication is an ongoing process, and you need to stay alert if you want your emails to continue to get home to the inbox where they belong.
Monitoring DMARC
You need to monitor DMARC closely when you initially set up your policy, but even after you've set everything up correctly, you need to continue monitoring.
Setting up DMARC is like having a guard watching over your email castle, but you want to be sure that guard is doing a good job, and not letting any intruders sneak in - or keeping out the visitors you want.
Regular monitoring will help you detect issues that may come up, like an unexpected new email sender (oops, your client forgot to tell you they switched from Mailchimp and suddenly there are hundreds of unauthenticated messages). It will also let you know if unauthorized senders are spoofing your domain (you'd be surprised how often this happens).
Keep an eye on SPF and DKIM
You'll also want to check to ensure your legitimate sending sources haven't changed something that causes your emails to fail authentication. Periodically check your SPF records, and consider changing your DKIM keys, especially if there are indications a key may have been compromised.
This is why you need to set up DMARC reporting, so you can monitor what's happening with your email.
Still have questions?
The process of setting up SPF and DKIM and DMARC is pretty straightforward, but of course sometimes a devil pops up in the details. There are differences in how setup is done across different DNS providers, and also differences in technical implementation by email providers and sending sources. I've collected a questions and "gotchas" from experiences I've had or heard about - maybe one of these email authentication tips will help.
If you've configured your email authentication records, but you aren't quite sure how to go about the ongoing process of monitoring, read this article on what to do now that you have DMARC set up.
If you'd rather just click your heels together and have someone else do this, I've got you!
You can book my service and I'll handle this for you. Or if you can't face doing this for your clients and would rather outsource it, I can help there too. You can either refer them to me, or contact me and we can work out options.
