From February 1st 2024, Google have introduced new authentication requirements for bulk email senders. In this article, we will outline what these requirements are and whether you need to be doing anything about them.
In reality, much of what Google has announced is based on existing best practices and is simply designed to help tackle the challenges around spam or phishing emails. While we do recommend that you follow these guidelines, they’re nothing to fear and for the most part will help you to improve your email deliverability and reduce the risk of phishing emails coming from your domain.
Currently, these changes are specifically relating to bulk senders which Google defines as those that send more than 5,000 emails a day to Gmail inboxes. However, we believe these changes will eventually become a standard across all platforms, for all senders, and we advise to be ahead of the curve, even if you currently don’t meet the threshold to be deemed a bulk sender.
Understanding Email Authentication Terms
There are three terms mentioned several times in this article and across the internet regarding email authentication: DKIM, SPF, and DMARC.
DKIM and SPF Authentication
DKIM (DomainKeys Identified Mail) and SPF (Sender Policy Framework), are methods for authenticating the legitimacy of your emails. While both methods rely on DNS records to authenticate your emails, they function slightly differently.
DKIM uses encryption to attach a digital signature to your email header, that can be verified against your public DNS (Domain Name System) records to verify the sender.
SPF operates as a record in your DNS settings that tells the recipient whether the server that sent the email is authorised to do so.
To meet Google’s new standards, you will want to have both of these methods in place. More on how to go about that in a moment...
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) performs a few different actions. Firstly, it tells the recipient’s email server what to do with an email coming from your domain if it fails the DKIM and SPF checks. In other words, if an email appears to be from your domain, but does not pass the authentication checks, how should the recipient handle the email?
To ensure that your domain isn’t being used to successfully deliver phishing emails that appear to be from you, you will need to set you DMARC to reject or quarantine these emails.
DMARC can also provide you with reports on whether your emails are passing or failing DKIM and SPF authentication checks. This means you can keep tabs on how your emails are performing and crucially during this period of change, ensure that all tools, servers and processes you currently use to send emails are meeting the DKIM and SPF standards.
How to check your email authentication
There are tools available that will help you check whether your emails are meeting these standards. We recommend using dmarcian’s DMARC Domain Checker as this will check all three (DMARC, SPF and DKIM). You might find that this highlights areas where you need to supply more information (particularly around DKIM) or highlights that your DMARC policy needs to be made stricter.
Source: DMARC Domain Checker
If the checker tool asks you to provide a Selector to validate DKIM, you can read this article on how to locate the required information. Remember though this will vary depending on the tool or platform an email was sent from, so you may want to check a number of different emails (marketing emails, everyday work emails, sales emails, and so on) to ensure they’re all using DKIM authentication.
We also recommend reading Google’s documentation on these changes. Not only do they outline the new requirements, but they also have resources, code snippets and definitions that you can use should your CRM or ESP not supply any of the required features like one-click unsubscribe, DKIM or SPF. Also, these changes are subject to evolve as wider adoption of these standards is rolled out, so bookmarking the relevant pages will be worthwhile to help stay abreast of any changes.
How to set up DMARC, DKIM and SPF
If you’re unsure on what needs to happen at this point, either your IT team or the team at Innovation Visual can help guide you through the process.
DKIM and SPF
The good news is that many of the major ESP and CRM platforms will provide you with DKIM and SPF records that are either configured as part of the setup process (this is the case with DKIM in HubSpot) or can be simply added as a DNS text record. To do this, you will need to log in to your domain hosting platform and copy in the values provided by your email client, email service provider, or CRM.
Again, if you’re unsure about modifying DNS records, then you need to talk to your IT team as changing DNS records can lead to issues with website hosting and email deliverability if you don’t know what you’re doing. Domain hosting tools are often not the most user-friendly interfaces, so tread carefully!
DMARC
DMARC is also added as a DNS record, however, this will not be provided by your ESP or CRM, and you will need to make decisions on what this policy should be.
At a minimum, your DMARC record needs to contain:
v=DMARC1;p=none;rua=mailto:***@yorudomain.com; ruf=mailto:***@yorudomain.com
v = the version, this should always be DMARC1.
p = the policy. This is the part of the record that tells the recipient server how to treat failed emails. This should be set to ‘none’, ‘quarantine’ or ‘reject’. In simple terms, this means the server will do nothing for none, send an email to spam for quarantine, or reject the email entirely for reject.
Whilst dmarcian will flag an error when your policy is set to none, this is a good policy to have in place whilst you are monitoring the reports from your DMARC policy to ensure that all your genuine tools, platforms and processes are being delivered.
rua = the URL that you want to email XML feedback files to – these will typically be daily reports provided in XML format – not the easiest thing to read for a human. There are plenty of services available that for a fee can provide you with reports that are designed to be consumed by humans, so if you’re keen to read these reports we would recommend looking into this.
ruf = the URL to email forensic reports to. This is the same concept as above; however, this will trigger when specific emails fail the authentication checks. This will help you better understand which tools, platforms and processes need to be reviewed for DKIM and SPF authentication.
Pro tip
We would also recommend setting up a dedicated mailbox for this as you won’t want daily reports going into a shared or personal inbox.
There are several other optional tags that can be added to your DMARC record which you can read more about on dmarcian’s website.
Other Requirements from Google
Beyond these technical elements, Google are also looking for senders to include easy one-click unsubscribe functionality. Check with your specific CRM or ESP, but this is generally handled by and included as part of your marketing platform and not something you need to add yourself. If you’re unsure, reach out to Innovation Visual and we can help you investigate this.
Google are also asking senders to ensure they’re sending wanted emails only, in other words abiding by best practices when it comes to sending to opted-in contacts only and focusing on sending highly relevant emails to well thought-out segments of your audience. We already follow these best practices for all clients by sending personalised, targeted emails that convert.
Summary of actions
Once your IT team have updated your DNS records, remember to revisit the checker tool to verify that these elements are now in place and performing as expected.
You will need to ensure that every tool or system you use that sends emails has DKIM and SPF configured, and you may find that you need additional DNS records for each tool you use. This will include your CRM and ESP for marketing emails but will also include tools like your Outlook or Gmail emails, Sales tools, Finance, and Invoicing tools and so on.
This is where setting your DMARC policy to none will allow you a grace period where you can check the reports that are coming in and get your IT team to update the DNS records as required for each tool as and when they trigger an authentication failure.
If you got to the first subheading and elected to skip the technical jargon, then you’re probably not alone! We realised that these changes seem a little daunting and aren’t something most of us want to be dealing with. However, as marketers, we should see these changes as a positive step to making email a safer, more trustworthy channel, so please don’t hesitate to reach out to your client lead or contact Innovation Visual for more guidance on email authentication.
For further reading, check Google’s documentation around these changes.
