It’s a law of nature: Before one year ends, you’re stressed about the year ahead. Y2k, am I right? No, none of us were right. 

Anyway, as if the holiday sending season wasn’t chaotic enough, the email community is abuzz with the looming deadline of Google and Yahoo’s new sender requirements. We have a more extensive write-up about the situation here, and you can read Google’s announcement outlining their requirements as well as Yahoo’s version of the same. 

In a nutshell: One of the new requirements is that you must be ready to have a DMARC record published for your sending domain by February 2024.  

While DMARC isn’t a new concept, it is something not entirely well-adopted even today. In 2022, more than 5.5 million DMARC records were in use. Sounds like a lot, right? In the grand scheme, adoption is much lower than our more well-known security measures like SPF and DKIM. 

We’ll walk you through the basics of DMARC here, and in the next weeks, we’ll provide more in-depth exploration of the DMARC protocol, including what a record looks like, how to install it into your DNS, how to read the reports, and so on. The works.  

The clock is ticking, so let’s be on our way. 

What is DMARC? 

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a standard created to protect both senders and recipients alike from dangers leading to data theft, which could result in monetary loss for both parties. 

It’s the end of 2023 and no one really needs to be reminded of why additional security is always a smart choice, but to make sure the point is made, data breaches can be devastating. Data breaches via email are ever-increasing in frequency, too, so DMARC provides a quick way to prove to a mailbox provider the mail is either safe (total policy alignment) or needs to have some kind of intervention (levels of action). 

DMARC acts as an extra layer of protection for recipients, can improve certain circumstances affecting deliverability (like being less vulnerable to deliverability-harming attacks), and can alert and protect businesses from bad actors attempting to hijack or spoof brands. It shows you how your domain is being used, and you should only see mail sent by you – if there’s abuse, you’ll see it in a DMARC report. 

It tells receiving servers, like a mailbox provider (MBP), what to do with mail using your domain when the DKIM or SPF (or both) records don’t align with the email’s “From” header. This is a key indicator the email is compromised or simply not from you, so the DMARC record instructs them to handle the mail one of three ways (stick with us.) 

Google and Yahoo require DMARC as a ticket to entry 

Before we get into how it works, we want to stress something.  

Right now, it’s not as important to mailbox and internet service providers as SPF or DKIM, but the security benefit is significant and with pressure to adopt DMARC policies coming from two of the largest mailbox providers, having DMARC will be key in maintaining delivery to those inboxes as their sender expectations increase. 

To be very clear, DMARC is not a catch-all security protocol. There are limits to what it can detect and prevent. For instance, it cannot catch or prevent instances where a domain is slightly changed from your own. Think “@socketlabz” versus “@socketlabs” as a sending domain. As such, DMARC is a (now mandatory) supplement to your DKIM or SPF policy

How DMARC works 

Let’s understand how DMARC operates before we start to worry about actually using it. 

There are three policies you can set to tell mailbox providers how to treat your mail when it doesn’t pass the test. You need to start at the lowest level before graduating to more stringent policies, but at the end of the day, any DMARC is helpful no matter the policy, because you’ll receive DMARC reports to analyze… As long as you add an email address to receive them! Unfortunately, Google and Yahoo aren’t requiring an email address attached to the DMARC record, but if you’re going to the trouble of setting up DMARC, this is not a corner to cut. Put the dang email address in.

p=none to Watch 

This policy is the intro to DMARC. Monitoring mode. You start here, at p=none. Google and Yahoo will require p=none policies, so this is the one to know, know well, and implement ASAP. 

With p=none, your DMARC record is telling the mailbox provider to take NO action when something fails authentication. There is no rerouting of mail, just a report sent to the email address you specified in the DMARC record to highlight there was an authentication failure.  

Why have a p=none if it doesn’t take any tangible action? Great question. A monitoring policy allows a sender to understand the state of their domain security. It also can reveal weaknesses or deliverability issues they may not know they have.  

When analyzing reports, the sender can see where there are issues. Is someone trying to spoof your domain? Is someone in your organization sending unauthorized email? By seeing where authentication methods are failing, you can determine if there are issues to be addressed and exactly where to turn your attention. 

Warning: Don’t be the person who gets reports and doesn’t look at them, ultimately leading you to believe there is no issue. When you’re setting up your DMARC record, specify an email address where someone is expecting reports and will analyze them accordingly.  

p=quarantine to Separate 

You’ll be ready to move to p=quarantine after you’ve seen your reports for a while, gotten a grasp on the email operations within your organization, and resolved any identified issues.  

When you’re using p=quarantine, you’re asking the MBP to send unauthenticated mail to the time out corner rather than just tattling on them. This doesn’t mean you’re asking them to reject the mail outright, but it does mean you’d like them to move the mail elsewhere while you investigate. “Elsewhere” is typically the spam folder, which might feel painful, but it’s better than allowing dangerous mail to arrive in an inbox just to create the data breach of your nightmares. 

Without p=quarantine, you run the risk of a spike in spam complaints, which can negatively affect your sender reputation even after you resolve the problem. Ultimately, you decrease the gamble you take at only a p=none policy. 

From a user perspective, you should keep monitoring your DMARC reports, but now, you should keep an even keener eye on your engagement metrics. Any negative fluctuation in open rates could be attributable to more mail landing in spam than the inbox, and if your practices haven’t changed, you could be looking at a security issue handled well by your quarantine policy.  

p=reject to Decline 

Are you ready to catch ‘em all? It’s time to become a DMARC master. 

Once you’re confident in reading reports, understanding the signals of malicious and spoofed mail, and you’ve implemented every safeguard you can to protect your domains and IPs from hijacking, you can move to a p=reject. 

Yes, this means you are instructing mailbox providers to reject or decline the mail outright if authentication fails. It will not be separated from the inbox; it won’t land anywhere, not even spam. Scary, we know, but it will keep your email audience safer and better ensure you don’t get spam complaints from people who accidentally get unauthorized mail from your domains in their inbox. 

On the whole, when it comes to perceptions of your sending reputation, using a p=reject policy is a huge signal to MBPs and your recipients alike (even if they don’t actually know it.) First, they are less likely to get spoofed or dangerous mail from your brand, and they won’t lose any trust you’ve built with them over something preventable like spoofing. And, of course, you’re protecting them from the consequences of opening a phishing email. For mailbox providers, they can see you take security seriously and, hopefully, the positive engagement signals from your recipients and lower spam rates makes your sender reputation impeccable. 

So, you’re at p=reject. Now what? 

Even though you’re at the highest level of safeguarding, your responsibility to your recipients doesn’t lessen. Keep reading the DMARC reports you get from providers because they can let you know what mail is failing authentication, if any. Then, again, you can do investigating to figure out what is happening, why, and how to both fix and prevent it from happening again. 

Final notes 

Get ahead of the curve. Large MBPs are no longer taking email security as a nice-to-have. You don’t want to get caught at only the bare minimum when they upgrade their requirements again (and again, and again). It’s not enough.  

By using DMARC on top of your SPF and DKIM records, you better ensure they’re working properly to better secure your mail, and it will alert you and providers to authentication failures to resolve. Without it, you’re hoping for the best. Preparing for the best rather than worst is usually…a bad idea. 

Now you’re ready to enter DMARC territory, so we’ll let you in on the process in our next DMARC blog.   

In the meantime, why don’t you give sending with SocketLabs a try? From great reporting to strict security protocols, you can try it all out for free with just a simple plug-and-send set up. What’s there to lose?