What to Know for Google’s 2024 Email Authentication Updates

Email is one of the most popular communication tools available today, especially for businesses. Because of this, spammers and other malicious individuals are continuously searching for new ways to take advantage. To protect recipients, email senders can — and should — take steps to protect their messages from interference.

In fact, email services may require it. You may have heard that Gmail and Yahoo created new email policies starting in early 2024. One of these is related to DMARC authentication, an email security protocol.

Let’s explore what DMARC is, how it works, and what Gmail and Yahoo’s updated email policies mean for your email security practices.

Table of contents

• What is DMARC?
• What is SPF?
• What is DKIM?
• How DMARC works
• DMARC reports
• DMARC DNS record explained
• Why use DMARC authentication?
• Google and Yahoo email policies in 2024
• Frequently asked questions

Terms to know

• Domain-based Message Authentication Reporting & Conformance (DMARC)
• DomainKeys Identified Mail (DKIM)
• Sender Policy Framework (SPF)
• Domain Name System (DNS)
• Email Service Provider (ESP)

What is DMARC?

DMARC is an email authentication protocol designed to protect email recipients from a type of cyber attack called domain spoofing. In an email address, the word or phrase following the @ symbol signifies the domain. In example@janedoe.com, janedoe is the email domain.

Cyber criminals can impersonate legitimate email senders, often by tweaking the domain slightly, like example@jandoe.com. Recipients may not notice the difference, especially if hackers also mimic the sender’s branding.

These scams are used to gain access to personal information. For example, a spoof email posing as your bank might say your account has been flagged for suspicious activity. They’ll give you a link to log in, but just like the spoof email, the login page is an impersonation designed to capture your online banking credentials.

DMARC offers effective protection against domain spoofing. How? By verifying other email security protocols: SPF and DKIM.

What is SPF?

SPF is an email authentication protocol that allows you to specify who can send email from your domain. When you publish SPF records on your DNS (the database that holds your domain information), it lists the IP addresses and hosts authorized to send your mail — including third-party email services like SendWP.

When an ESP receives an email, it cross-checks the domain against your published SPF records to see if they’re an approved sender.

But this is only part of the verification process. DKIM is also a vital tool.

What is DKIM?

DKIM is another email authentication protocol that works like a secret password. It adds an encrypted code to emails. When an ESP receives your email, it compares the digital signature against the one in your DNS records to verify a match.

DKIM prevents emails from being tampered with, blocking hackers who attempt to modify legitimate messages in transit. It’s a more comprehensive form of protection than SPF. When these protocols are used together, they’re highly effective at preventing spoofing and other forms of spam. They also pave the way for DMARC authentication.

How DMARC works

DMARC prevents domain spoofing by verifying that a message has passed the SPF and DKIM checkpoints. Thus, you’ll need to set up and publish your SPF and DKIM records in the DNS before you can enable DMARC.

The DMARC check automatically fails if an email doesn’t pass the SPF and DKIM verifications. But what happens next? That depends. With DMARC, domain owners can specify what happens to a flagged email. These options are called DMARC policies, and there are three options:

None

This policy doesn’t give the ESP any specific instructions about how to handle a failed DMARC. This leaves the deliverability decision up to the email service. Unless the email is obviously spam, many services choose to deliver the message so recipients don’t miss out on legitimate communications.

Quarantine

This policy tells the server to quarantine the message, which usually means sending it to the spam folder. If the email is clearly spam, it may be blocked completely.

Reject

This policy is the most stringent, telling the server to reject any unverified messages. The recipients will never receive emails that fail DMARC, but the sender will receive a rejection notice.

Which DMARC policy is best?

Google recommends starting with a none policy first, for at least one week. During this period, you should review your DMARC records daily to understand which domains pass the authentication and which fail. Remember, every third-party company that sends emails on your behalf — from email marketing services to CRMs to HR platforms — should be included in your DNS records as a legitimate sender.

After using none for at least a week, you can slowly ramp up to quarantine and, eventually, reject. Starting with reject immediately is risky, as many of your messages may be blocked or marked as spam. Beginning with a more lenient policy allows you to work out the kinks without harming your domain reputation.

DMARC reports

Besides selecting your send policy, you can also receive DMARC reports about all the messages sent from your domain. These reports help you troubleshoot your DNS settings, like ensuring all legitimate domains and subdomains are whitelisted to send on your brand’s behalf. DMARC reports also allow you to catch spoofers, avoid spammy language, and more.

There are two types of DMARC reports available.

Aggregate reports

Aggregate reports are generated daily, and they include stats about the emails sent from your domain. The reports contain data, such as the originating IP address, SPF and DKIM authentication status, and other relevant information.

Aggregates are written in machine-friendly XML (Extensible Markup Language), so it can be hard for human beings to decipher them. It’s helpful to use tools like dmarcian’s XML to Human Converter to understand the data.

Forensic reports

The other helpful DMARC report is called a forensic report. While aggregate reports include data about all emails sent in a 24-hour period, forensic reports cover individual emails — the ones that fail SPF or DKIM authentication. You’ll receive details about the flagged message, including the “to” and “from” addresses, the subject line, the IP address of the sender, and more.

DMARC DNS record explained

DMARC is a text record you’ll add to your DNS. It’s a line of code that includes your DMARC policy choice, where to send DMARC reports and more. Here’s an example of a DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@exampledomain.com; ruf=mailto:dmarc-forensic@exampledomain.com; pct=50

As you can see, the record is made up of value-tag pairs. The text before the = is the tag, while the text after is the value. For example, in the case of v=DMARC1, “v” is the tag, while “DMARC1” is the value.

Always list the “v=” and “p=” pairs first. The rest of the value-tag pairs can appear in any order.

Let’s break down the individual value-tag pairs.

Required value-tag pairs

v=DMARC1

This is a required tag-value pair in any DMARC record. It tells ESPs that this is a DMARC record. The “DMARC1” value refers to the industry-wide DMARC protocol version everyone uses at this time, and it won’t change unless an updated protocol is released.

p=quarantine

The “p” tag tells ESPs which DMARC policy you’ve chosen. This value pair can read “p=none,” “p=quarantine,” or “p=reject.” This is the only other required value-tag pair for your DMARC record.

Recommended value-tag pairs

rua=mailto:

The “rua” tag is where you’ll add the email address(es) you’d like to receive DMARC aggregate reports. In the example record above, only one email address is included, but you can add multiple recipients for aggregate reports. In that case, the “rua” portion of your DMARC record looks similar to this:

rua=mailto:dmarc-aggregate@exampledomain.com,mailto:dmarc-aggregate2@exampledomain.com

Always remember to add the “mailto:” prefix before each email address.

ruf=mailto:

The “ruf” tag tells email services where to send your DMARC forensic reports. Just like with “rua,” you can add additional email addresses to this portion of the record, with the “mailto:” prefix before each address.

pct=50

The “pct” tag refers to the percent value, which notates the percentage of emails you’d like your DMARC policy applied to. For example, an “=100” value means 100% of flagged emails are subject to your quarantine or reject policies, while “=50” or “=25” means only 50% or 25% of emails are subject to your policy.

We’ve already discussed how starting with a more lenient policy is helpful. Percentages are another way to gradually deploy your DMARC policy without affecting all messages immediately. When you’re starting out, it’s helpful to choose a lower percentage.

Other optional value-tag pairs for your DMARC record

There are some other value-tag pairs you can include in your DMARC record, depending on how detailed you want to get. These include:

If you include all value-tag pairs in your DMARC report, it would look like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@exampledomain.com; ruf=mailto:dmarc-forensic@exampledomain.com; pct=50; sp=quarantine; adkim=s; aspf=r; fo=1,d,s; rf=afrf; ri=86400

Why use DMARC authentication?

Using DMARC has many benefits. It gives you greater control over the emails sent from your domain, putting the decision about potentially harmful messages in your control, instead of leaving it up to the ESP. This not only protects your customers, but it also makes your brand more reputable and trusted. Email services may blacklist your domain if they notice a pattern of spam messages.

DMARC also provides clarity through the aggregate and forensic reports.

The last reason to implement DMARC authentication lies with the 2024 email policies mentioned at the beginning of this post: Gmail and Yahoo now require DMARC authentication for certain senders.

Google and Yahoo email policies in 2024

As the most prolific email service provider in the industry, Gmail is always looking for new and better ways to protect email recipients from spam, phishing, spoofing, and other malicious messages. As of February 2024, they require all bulk email senders (those who send 5,000 or more messages to Gmail users per day) to follow three practices:

• Authenticate your emails with SPF, DKIM, and DMARC
• Enable one-click unsubscribe
• Stay below a 0.3% threshold for spam complaints

When Google announced this change in October 2023, Yahoo quickly followed suit.

DMARC authentication isn’t required for every email service, but Gmail and Yahoo are prolific. Your email list is undoubtedly filled with @gmail.com and @yahoo.com addresses. If you want to keep sending these recipients messages in bulk, setting up DMARC is non-negotiable.

Frequently asked questions

What if I’m not a bulk sender?

As mentioned, Gmail defines a “bulk sender” as anyone who sends 5,000 or more messages per day. But that doesn’t mean everyone else should ignore the new updates. Gmail’s policies are best practices for any sender, no matter how many emails you send.

Additionally, if you use an email sending service like SendWP (or MailChimp, etc.), the 5,000 message threshold applies to the sending service itself — how many messages the company sends per day — so you’ll definitely need DMARC authentication in place.

Protocols like DMARC protect your customers, build brand trust, and help your domain build a solid reputation. And, as mentioned, using DMARC is an excellent way to gain clarity about the emails sent from your domain.

DMARC authentication also future-proofs your business. You may not be a bulk sender today, but if your business grows, having DMARC already in place means you’re ready to safely email a bigger audience when the time comes.

How do these policies affect transactional email?

Gmail’s policies apply to both marketing and transactional email types. However, in most cases, bulk email sending typically falls under the marketing category. For instance, sending a Black Friday sale message to your entire email list simultaneously.

Transactional email is different. Since a specific transaction triggers these messages on your website — like a customer recovering their password or making a one-time purchase — they go out one at a time. Unless you’re a major brand like Amazon, you’re likely not sending transactional emails in bulk quantities every day.

Still, Gmail’s policies are important. As mentioned, they’re best practices — smart choices that protect recipients from spam and cyber attacks. Since transactional emails tend to deal with high-risk details like account credentials and credit card information, it’s best to follow Gmail’s guidance.

I set up DMARC — why aren’t my emails sending?

So you’ve set up DMARC authorization but realized some of your emails aren’t sending. You may have forgotten to set up your SPF and DKIM records for all services that send your emails. This has been a common stumbling block since Google and Yahoo announced their new policies.

Let’s say you use SendWP for transactional email, MailChimp for marketing email, and Google Workspace for mail inboxes. When you set up your DMARC, you must make sure you have SPF and DKIM records set up with all of your senders. Otherwise, DMARC will block those services from sending on your behalf.

Visit SendWP’s documentation to learn how to set up your SPF and DKIM records. Other third-party services should have their own published guidelines. (For example, Google Workspace’s article on setting up SPF.)

Don’t wait on DMARC

DMARC authentication, along with other best email practices like SPF and DKIM records, protect your customers and followers — and your reputation. Considering Google’s leadership position in the email space, its policies are likely to set a new standard for senders.

At SendWP, we make it fast and easy to get started with DMARC. Don’t hesitate to contact us with any questions.