The world of email is in flux. Big players like Gmail and Yahoo are making bold moves to help crack down on spam, strengthen security, and clean up messy lists. Check out their official announcements here (for Google) and here (for Yahoo).

What does this mean for you as a sender?

First and foremost, don’t panic! These changes don’t formally roll out until February 2024. 

Additionally, though they may create a bit of a headache as bulk senders pivot to comply, it’s important to note that these changes ultimately mean:

• Better security
• Less spam - both in your inbox and in your complaint rates
• Enhanced trust with your clients and subscribers
• Higher deliverability and engagement

There’s a lot to unpack here; in this article we’re going to specifically focus on authentication. In the coming months, emails failing to meet essential authentication standards will face a significantly higher risk of being blocked or sent to spam.

How do you make sure your emails are secure enough for mailbox providers to accept your mail?

Over time, the email world has developed three primary authentication protocols to secure your messages: SPF, DKIM, and DMARC.

Does that sound like a bunch of nonsense to you? No worries, let’s break it down:

SPF, or Sender Policy Framework

SPF is a foundational measure to combat email spoofing and phishing. It works by allowing domain owners to specify which IP addresses are authorized to send emails on their behalf.

When receiving servers get an email, they check if it comes from one of these authorized IPs. If not, the email might be treated with suspicion or outright rejected.

TL;DR

SPF is like the guest list at an exclusive event. If your name (or IP address) isn't on it, you're probably not getting in.

DKIM, or DomainKeys Identified Mail

DKIM is a cryptographic approach to email authentication. It provides an encryption key and digital signature that validates an email message was not tampered with during transit. When an email is sent, it's signed with a private key. On the receiving end, the ESP uses a public key (published in the sender's DNS records) to verify the email's integrity.

TL;DR

DKIM is like a secret handshake. If any part is wrong, you can immediately tell something's amiss with the sender.

DMARC, or Domain-based Message Authentication, Reporting, and Conformance

Of course, there are always ways to bypass the guest list. Perhaps you try the back door or wear a disguise. Same thing goes for a secret handshake; no matter how complex it is, there’s always the possibility that someone has discovered how to mimic it well enough to avoid raising suspicion.

That’s where DMARC comes in: it builds on SPF and DKIM to ensure that legitimate emails are properly authenticated against set policies and any failing emails are blocked or moved elsewhere, instead of the recipient's inbox.

TL;DR

DMARC is akin to a security protocol at a post office. When a suspicious package comes in, there's a clear procedure to follow. If the name on the package doesn’t make sense or there’s an invalid barcode, that letter won’t be delivered. Similarly, DMARC uses SPF and DKIM to verify an email and decide the next steps for its delivery.

Getting Started with DMARC

The benefits of DMARC, especially for those in the legal industry, are substantial. It allows you to take control of the messages sent from your domain and prevent bad actors from sending fraudulent or malicious emails on your behalf. Think of it as a customizable tool in your security toolbox; an apt comparison here would be a surveillance camera.

Although it can be tricky to fully implement, I highly recommend setting up at least a rudimentary policy. That might look something like this:

v=DMARC1; p=none;

The “v” value refers to the version of DMARC being used, in this case DMARC1. The “p” value refers to the policy you have set, in this case none. If you were to hire a DMARC consultant or an IT firm to do this on your behalf, a p=none policy is often the first step they’ll have you take.

Because it’s set to none in that example, none of your outgoing mail is rejected, but – if you decide to add a reporting address to your DMARC policy – you’re able to gain insight into what mail is being sent from your domain and develop a strategy for managing it. That might look something like this:

v=DMARC1; p=none; rua=mailto:dmarc@insertyourdomainhere;

The “rua” value specifies the email address that these aggregate reports will be sent to. Be aware that if you choose to include reporting in your DMARC policy, it’s a good idea to use a dedicated email address or one that will allow you to easily filter out reports. They can generate high volume and quickly overwhelm your inbox if you’re not careful!

Working towards implementing DMARC even with a basic policy like the examples above is a great way to signal to your clients and mailbox providers that you prioritize security and trust.