Been asked to authenticate your email domain? How to respond to your provider’s update request


If you’re a website owner you may have received a request from your email service provider recently —be it Mailchimp or Campaign Monitor etc. —urging you to authenticate your email domain.

What does this mean? Why now? And, more importantly, how does it affect your ability to reach your audience? You’re not alone in your concern. In this article we’ll explain why email authentication is becoming a non-negotiable requirement, and guide you through what you need to do to comply.

The Background

When it comes to email marketing, deliverability is king. However, the landscape of email security is evolving. Phishing attacks and spam have become more sophisticated, prompting email service providers (ESPs) and receiving email servers to tighten their filters and authentication requirements.

To combat these threats and protect their users, major email platforms like Yahoo and Gmail are now insisting that all outgoing emails are authenticated. This means that emails must have specific DNS records in place—SPF, DKIM, and DMARC—to verify that the sender is legitimate and authorized to send emails on behalf of the domain. This push towards stricter authentication practices aims to improve email security, preserve sender reputation, and enhance overall deliverability.

Why Now?

The urgency around email authentication has been driven by a notable increase in email-based threats and a collective move towards more secure digital communication standards. Internet service providers (ISPs) and ESPs are responding to these challenges by implementing stricter policies to ensure that only authenticated emails reach their intended recipients. Furthermore, with regulations like GDPR in Europe and similar data protection laws worldwide, there’s a growing emphasis on accountability and security in email marketing.

What are the moving parts?

Firstly, it’s handy to understand what SPF, DKIM, and DMARC records are and how they work to authenticate your emails. These records are added to your domain’s DNS settings to prove that the email service provider sending emails on your behalf is authorized to do so.

Some definitions:

Term Definition

Sender Policy Framework

SPF records help mail servers verify that emails sent from your domain are coming from allowed servers. An SPF record lists the IP addresses authorized to send emails on behalf of your domain.

A simple SPF record might look like this:

v=spf1 ip4: -all

Here’s what it means:

  • v=spf1 indicates the version of the SPF protocol used.
  • ip4: specifies that an email is allowed to be sent from the IP address
  • -all indicates that emails sent from any IP address not listed in the record should be considered unauthorized and potentially rejected or marked as spam.

DomainKeys Identified Mail

DKIM adds an encrypted signature to your emails, allowing receiving servers to check that the email hasn’t been tampered with and is authorized by the domain’s owner.

A simple DKIM record might look like this:


Here’s what it mean:

  • v=DKIM1 specifies the version of DKIM being used.
  • k=rsa indicates the encryption algorithm (RSA in this case).
  • p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrZ2KjaZ... is a part of the public key that will be checked against the encrypted signature in the email header. This key is much longer in reality; the example is truncated for simplicity.

Domain-based Message Authentication, Reporting, and Conformance

DKIM adds a reporting function that lets senders know if their emails are passing or failing SPF and DKIM authentication checks. It also allows domain owners to specify how email receivers should treat emails that don’t pass SPF or DKIM checks.

A simple DMARC record might look like this:

v=DMARC1; p=none; rua=mailto:[email protected]

Here’s what it means:

  • v=DMARC1 indicates the version of DMARC being used.
  • p=none specifies the policy, telling receiving email servers not to take any specific action against emails that fail DMARC checks. Other options include quarantine (mark as spam) or reject (block the email).
  • rua=mailto:[email protected] specifies where to send aggregate reports of DMARC failures, providing insight into emails failing DMARC checks, sent to [email protected].

So what needs to be done?

Now that you have an understanding of the different components and what each of the acronyms stand for, it’s time to move towards implementation.

  1. Identify where your DNS records are managed: This could be with your domain registrar (where you registered your domain name) or possibly through a third-party service like Cloudflare if you’re using one for additional website services.

  2. Create the SPF, DKIM, and DMARC records: You will add these records to your DNS settings. Each record type has a specific format and serves a unique purpose in email authentication, as previously described.

  3. Test your setup: After configuring these records, it’s crucial to verify they are correctly implemented. You can use tools provided by your Email Service Provider (ESP) or third-party verification services to ensure your setup is correct. 

From here

Navigating the requirements for email authentication can seem daunting at first, especially with the acronym-heavy jargon and specific formatting requirements for the records themselves. Your service provider should have emailed you however, with easy to follow instructions to guide you through any required changes. This is something you should look to do sooner rather than later.

Need help?

We can make sure your domain is verified properly to comply with the authentication requirements, so if you haven’t done so yet and you’re looking for someone to assist, please get in contact.



    Leave a Reply

    Creative Digital Agency

    Code and Visual works with clients around Australia to create and build outstanding and accessible digital services. If you want to discus a project contact us now for an initial consultation.


    Recent Posts