What Is A DMARC Record? Gmail’s New DMARC Policy Explained

What is a DMARC record? And what’s Gmail’s new policy on it?

If you’re an email marketer, you’re likely aware of a new policy Gmail’s enforcing for bulk senders, which states they must implement DMARC records for their domains.

And if you’ve run a DMARC check on your domain and found no such record, you’re probably a little confused.

In this post, we cover what a DMARC record is as well as Google’s recommendations for setting one up.

What is a DMARC record?

DMARC stands for Domain-based Message Authentication Reporting and Conformance, which is a fancy way of saying that DMARC is a part of the process involved in authenticating emails sent from email addresses that use your domain.

Other parts of that process include Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records.

Email authentication begins with these records. If an email sent from your domain fails SPF and DKIM authentication, the receiving server uses the policy stored in your DMARC record to determine what to do with it.

To put it into simple terms, SPF and DKIM authentication prevent emails sent from your domain from ending up in the spam folder.

However, if an email sent from your domain does fail SPF and DKIM authentication, which can happen if your domain is used in phishing scams, the receiving server can use your DMARC record to quarantine or reject the email.

In short, SPF, DKIM and DMARC are necessary email authentication methods that prevent spoofing by making it possible for receiving email servers to determine if an email was actually sent from the domain in the email’s “from:” field or if it was actually sent by a spammer who used a real domain they do not own to make the email seem legitimate.

DMARC policy vs DMARC record vs DMARC report

When we talk about DMARC, we usually use one of three terms: DMARC policy, DMARC record and DMARC report.

A DMARC policy is a bit of code script that instructs a receiving email server on what to do when your email fails SPF and DKIM authentication.

You can put one of three options in your policy:

• None – Instructs the email server to take no action. Emails that do not pass authentication are sent to the recipient like normal.
• Quarantine – Sends the email to the recipient’s spam folder.
• Reject – Bounces the email back to your server, preventing it from being sent to your recipient altogether. You may even receive a message informing you that your email bounced and never made it to the recipient.

What is a DMARC record?

A DMARC record is a DNS TXT record that contains the script that makes up your DMARC policy.

You add this DNS TXT record to wherever you manage your domain. This is normally where you registered it, but you can also add DNS records to a service like Cloudflare if you want to use Cloudflare as a CDN.

Here’s what a typical DMARC record might look like:

v=DMARC1; p=quarantine; adkim=s; aspf=s;

This may seem complicated at first glance, but we can actually break it down into a few different pieces:

• v=DMARC1 – This defines the TXT record as a DMARC record since not all TXT records are DMARC records.
• p=quarantine – This sets the policy option to “quarantine,” but you can also set this to “none” or “reject.”
• adkim=s – This tag lets you set DKIM authentication to “strict,” but you can also set it to “r” for relaxed.
• aspf=s – Just like the previous tag, this one sets SPF authentication to “strict,” but you can also set it to relaxed.

What is a DMARC report?

A DMARC report is an automated report you can have sent to a specific email address that contains information on authentication attempts.

DMARC reports can let you know if legitimate emails fail SPF and DKIM authentication and can let you know when spammers are using your domain in spoofing scams.

Here are a few pieces of data you may see in a DMARC report:

• Servers or third-party domains that attempted to send emails from your domain.
• Percentage of emails sent from your domain that passed DMARC authentication.
• Servers and services that triggered failed DMARC authentication attempts.
• DMARC actions (none, quarantine or reject) receiving servers took on emails that failed authentication.

To receive DMARC reports, all you need to do is add an extra tag to the policy in your DMARC record. This is the “rua” tag, and you can use it it to specify an email address receiving servers should send reports to:

v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:example@domain.com;

It’s best to use a third-party analyzer for DMARC reports, though, as they can condense these reports into a format that’s easier to consume.

In this case, you’d list the third-party service’s email address in your DMARC record.

Why is a DMARC record important for email marketing?

Why is having a DMARC record in place for your domain important for email marketing?

We’ve already stated the biggest reason for including a DMARC record as a DNS record for your domain, and that’s to prevent your domain from being used in phishing scams.

This means you should also have SPF and DKIM records in place. A receiving server will use these authentication methods to determine if the domain in the “from” field matches the domain from the server that’s sending the email.

Basically, receiving servers use the SPF and DKIM authentication methods to determine if it’s you sending these emails or if it’s actually spammers.

If an email fails authentication, the policy in your DMARC TXT record will instruct the receiving server on what to do with the email.

This keeps your subscribers, customers, employees and colleagues safe from phishing attempts.

Policies like the ones Google and Yahoo! have put in place are also important to keep in mind.

These policies state that if you don’t have a DMARC record in place, all emails you attempt to send to Gmail and Yahoo! email addresses will be blocked.

These are some of the most widely used email clients on the web, so you don’t want your emails being blocked by their servers.

Plus, because they’re so popular, other email clients will likely follow suit by requiring you to have SPF, DKIM and DMARC records in place.

What if you don’t use your domain for email marketing?

What if you don’t have an email list? Do you still need to have SPF, DKIM and DMARC records in place?

The short answer is yes.

Even if you don’t partake in email marketing, your domain can still be used in phishing scams.

Plus, even one-on-one emails can be blocked if you don’t have these records in place.

What is Google’s DMARC policy?

Google’s DMARC policy took effect on February 1, 2024. It targets bulk senders who send 5,000 emails per day or more.

If this describes you, here’s every requirement you must follow in order to successfully send marketing emails to Gmail inboxes (some are for all senders):

• Set up SPF authentication for your email domain.*
• Set up DKIM authentication for your email domain.*
• Set up valid forward and reverse DNS records, also known as PTR (pointer) records, for sending domains.*
• Use a TLS connection for email transmission.*
• Maintain a spam rate below 0.10% in Postmaster Tools and never reach 0.30%.*
• Format emails according to the Internet Message Format standard.*
• Do not impersonate Gmail From: headers.*
• Add ARC headers to outgoing messages if you forward mail often.*
• Set up DMARC authentication for your domain.
• For direct email messages, the domain in your From: header must be aligned with your SPF or DKIM domain.
• Marketing emails and emails recipients have subscribed to receive must include a clearly visible, one-click unsubscribe link.

*This requirement is for all senders, not just bulk senders.

To comply with Google’s new policy, you must have a DMARC record set up for your domain in order to send emails to Gmail inboxes if you’re a bulk sender sending more than 5,000 emails per day.

What DMARC policy does Google recommend?

There are several tags you can add to a DMARC record. We already covered a couple of them, including your primary policy option (none, quarantine or reject).

But what does Google, the owner of one of the most popular email clients in the world, recommend?

Officially, Google recommends setting your policy to “reject.”

However, Google also recommends setting your policy to “none” to start with, which looks like this:

v=DMARC1; p=none;

This means if your domain fails SPF and DKIM authentication, your emails will still be sent to the recipient. This allows you to test how your emails are being perceived by receiving servers.

Google recommends gradually changing your policy from “none” to “quarantine:”

v=DMARC1; p=quarantine;

And then finally “reject:”

v=DMARC1; p=reject;

This gives you time to collect DMARC reports and analyze them while you monitor your domain’s spam score in Postmaster Tools so you can optimize your sending setup before you instruct receiving servers to reject emails that do not pass authentication.

What alignment policies does Google recommend?

You can choose between a “strict” alignment option and a “relaxed” alignment option for SPF and DKIM authentication. Google recommends choosing the option that makes the most sense for the way you send emails.

For starters, here’s what your DMARC record will look like with “strict” alignment and a “reject” policy:

v=DMARC1; p=reject; adkim=s; aspf=s;

And here’s that same record with a “relaxed” alignment:

v=DMARC1; p=reject; adkim=r; aspf=r;

SPF authentication tests the domain in your return path address against the domain in the address in your From: header.

Your return path address is the email address you receive bounced message notifications from. In other words, when an email you send cannot be delivered, the return path address is the email address that gets the notice.

Google uses this table to help you identify when SPF authentication might fail based on the alignment option you choose:

Return Path Address	From: Header Address	Strict Alignment	Relaxed Alignment
jon@solarmora.com	jon@solarmora.com	Pass	Pass
jon@mail.solarmora.com	jon@solarmora.com	Fail	Pass
jon@solarmora.org	jon@solarmora.com	Fail	Fail

In short, if your return path address and From: header address use the same domain, use strict alignment, though relaxed alignment will also pass.

If you use a subdomain to send emails or receive bounced message notifications, use relaxed alignment.

If the top level domain (TLD) in the domain of your return path address does not match the TLD in the domain of your From: Header address (like in Google’s example solarmora.org vs solarmora.com), authentication will fail.

DKIM authentication checks that the domain in the DKIM-signature domain field matches the domain in your From: header address.

For this level of authentication, Google uses this table to help you identify when DKIM authentication may fail based on the alignment option you choose:

From: Header	DKIM d=domain	Strict Alignment	Relaxed Alignment
jon@solarmora.com	solarmora.com	Pass	Pass
jon@mail.solarmora.com	solarmora.com	Fail	Pass
jon@solarmora.org	solarmora.com	Fail	Fail

As you can see, this is pretty identical to the alignment options for SPF authentication.

If your domains match, you can use strict or relaxed alignment.

If you use a subdomain for one, use relaxed alignment.

If your TLDs do not match, authentication will fail.

How to determine your return path address

Send an email from your email marketing email address to your personal email address.

Open the email from a browser, and use these simple steps to identify the email address that’s assigned as your return path address:

For Gmail:

1. Press the hamburger button next to the Reply button.
2. Click Show Original.
3. Use your browser’s Find tool (Ctrl/Cmd+F) to search for “return-path”.

For Microsoft Outlook:

1. Right click inside the email.
2. Click View Source.
3. Use your browser’s Find tool (Ctrl/Cmd+F) to search for “return-path” or “envelope-from”.

For Yahoo!:

1. Click the hamburger button in the top bar.
2. Click View Raw Message.
3. Use your browser’s Find tool (Ctrl/Cmd+F) to search for “return-path”.

For Apple Mail:

1. Go to View → Message → All Headers.
2. Find Return-Path in the right reading panel.

Final thoughts

That’s everything you need to know about DMARC records and Google’s policy on them, which states that you must have one in place for your domain if you’re a bulk sender.

Use a tool like MxToolbox if you need help generating a DMARC policy.

This tool can even test for email deliverability and aggregate reports for you.

They also offer forensic reports, but keep in mind that Gmail does not support these types of reports.

You should also check with your DNS host’s knowledge base to see how to set up SPF, DKIM and DMARC records with them.