There you are, a happy web designer doing your thing and starting to implement your plans for 2024, and all of a sudden, there's a tornado of chatter about new email authentication requirements.
- "I/my client got an email from Mailchimp / MailerLite / Shopify / Mailgun / some other platform about new Google email requirements and I don't know what to do."
- "I'm just a web designer; I don't understand this email stuff."
- "Can someone please explain in small words what I need to do about these new email compliance updates?"
As a web professional serving clients, what do you really need to know about email authentication?
You're not in Kansas anymore. You're in the Land of Email, and the wicked Google (and Yahoo, but let's be real, we know who's really driving) is going to keep your emails out of the inbox.
You just want your emails to get to their proper home, but you've got to get through this confusing forest full of SPF, DKIM, and DMARC (oh my!).
Bottom line: If you want people with Gmail or Yahoo email addresses to receive your emails, you must send from a domain you own and have properly authenticated.
What is this "new email requirements" fuss even about?
Google and Yahoo announced that starting in February 2024, they will start requiring bulk email senders to:
- Authenticate emails they send, using industry best practices and implementing SPF, DKIM, and DMARC
- Enable one-click unsubscribe in email headers, and honor unsubscribe requests within 2 days
- Only send email that users want - in other words, keep spam rates below a certain threshold
References:
Google's announcement of new email sending requirements
Yahoo's announcement on enforcing new email standards
Wait, so if this is just for "bulk senders" I don't have to do anything, right?
Well, not exactly. While the big announcement focused on bulk senders, and that's where the "bulk" of the issue is, if you look a little deeper into the sending requirements that Google and Yahoo have recently published, you'll see requirements for ALL senders, including things like:
- Properly authenticating email - setting up at least DKIM or SPF
- Keeping spam complaints low
- Using a TLS connection to transmit email
References:
Google's requirements for all email senders
Yahoo's requirements for all senders
But whyyy? I'm not a spammer!
Of course you're not, but there are plenty of bad guys out there who are spammers or scammers or both. Email authentication has been around for years, and these "new" email requirements have been best practices for a long time.
Basically, what Google is doing is like making everyone get an entry badge to get into the inbox. That'll make it a little easier to keep the spam and malicious emails out.
You see, Google really isn't the Wicked Witch...more like the Wizard making you jump through hoops to get what you need.
Ok, fine, so how do I do this authentication?
Before we start tackling the alphabet soup, realize one important thing - you can only authenticate a domain that you own. For example, I can authenticate the email addresses for my domain, milepost42.com, but I can't authenticate my @gmail.com address.
If you have clients who are still using their @gmail.com address (or hotmail, yahoo, aol, or what have you), let them know about this. It won't affect their "regular" email; Google authenticates its own domain, so sending from [email protected] works just fine.
But if they're using that email for bulk email sending (e.g. through Mailchimp or another email marketing service), especially if they have over 5,000 contacts, that's a problem. If they have a list less than 5,000, it might be okay - for now - but their emails are going to be less likely to make it to the inbox.
Are you thinking, "I need to let my clients know about this", but aren't sure what to say? This post about the new email authentication requirements is the email I sent to my clients; you're welcome to take out my "offer" and use it for your clients. (Or if you'd rather have someone else do this stuff for your clients, you can leave my offer in and refer them to me).
What is this SPF, DKIM, DMARC stuff?
SPF, DKIM, and DMARC are email security protocols that work together to "authenticate" emails and protect against spoofing and malicious behavior. We implement these protocols by adding specific DNS records.
SPF (Sender Policy Framework)
- SPF is a TXT record that is basically a list of the servers that are allowed to send email using your domain name - such as your website, ESP, CRM, or maybe your invoicing system.
- There used to be an actual "SPF record", but that was deprecated several years ago, so when you see "SPF record" what is really meant is a TXT record with the a list of IPs, names, or servers allowed to send email for your domain.
- Important: You can only have one SPF record per domain. You may have multiple senders who all give you an SPF record that looks something like this: v=spf1 include:_spf.google.com ~all, but don't add them all as separate records; you need to combine them.
DKIM (Domain Keys Identified Mail)
- DKIM is like a signature for your emails, saying they really came from you and haven't been tampered with.
- A DKIM record is also a DNS TXT record, but this one is actually the public half of a pair of cryptographic keys.
- You need a DKIM record for each valid sender. The email sender generates a public and private key pair. The public key is the DKIM record you put in your DNS; when an email is sent, this is compared against the private key for validation. It's similar to setting up a passkey - the public key is on the service you are using, while the private key is on your phone or device, and they have to match or you don't get in.
DMARC (Domain-based Message Authentication Reporting & Conformance)
- DMARC is essentially a policy that tells an email provider (e.g. Gmail) how to handle nonvalidated emails. It gives instructions saying that if an email arrives saying it's from you, but doesn't match the SPF or DKIM information, here's what to do with that email.
- You can set a DMARC policy to do nothing (just let the email provider decide), quarantine the email (usually meaning it goes to spam), or reject the email completely.
- Note that not all email providers follow your DMARC policy; sometimes they do what they want, so there's no guarantee that an email will get through. Even if it's authenticated, if the email provider thinks it's spammy, it'll get sent to spam.
- A DMARC record also lets you put in a email address to receive reports on what happened to your emails. This is really useful when you first implement DMARC, so you can understand where emails from your domain are coming from and what's happening to them. Once you have everything set, it lets you monitor what's happening with your emails and help prevent someone from spoofing your email (sending emails to people pretending to be from you and hurting your reputation).
Are you ready to authenticate your emails?
In part 2, we'll follow the yellow brick road step by step to Email Authenticity...
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 a way.
