DMARC, DKIM, SPF Oh My! - The what and why of email sender authentication

Email is the common denominator for communication on the internet and even predates it by a few years, but even today it can still be the wild west out there when sending and receiving email.

The Why and History of Email Authentication

The SMTP standard was introduced in 1982 so different email servers could communicate with each other over the network and for the next 20 years everything was fine…ish. Everyone could email each other no problem, but there was no way to verify the from: address was actually who it claimed to be. So anyone could spoof their address and pretend to be your bank, doctor, or grandma and you had no way of knowing if it was really them.

Fast forward to 2003 and Meng Weng Wong proposed the SPF standard. Which uses DNS TXT records in a way where people who own a given domain can announce exactly what mail servers they use for sending email and receiving mail servers are then able to check that against an email’s from: address to determine if an email could have been sent from their servers. So you’ll know if it’s really your grandma emailing you asking what her bank password was again. SPF was first proposed in 2003, but didn’t become a fully accepted standard until 2014 so it’s fairly recent, at least for email standards that is.

Around that same time in 2004 Yahoo and Cisco joined forces to propose the DKIM standard which wanted to build off of SPF to not only determine who might’ve sent a given email, but that it wasn’t tampered with along the way. DKIM manages this with a private key that your email server signs every message with and a public key that is announced as a formatted DNS TXT record that a receiving mail server can use to verify the message was not tampered with in transit to your inbox. So then you’d not only know the email came from your grandma, but she really did, in fact, ask you for her bank password again. DKIM was first standardized in 2007 and updated in 2011, so it’s also a newer development in the email space, again by email standards that is.

To round out the email sending authentication trifecta we come to DMARC. Introduced in 2011 by PayPal, Google, Microsoft, and others to address a logical next step. So you got an email from your grandma about her banking password, but either SPF or DKIM checks fail. What do you do with the email? DMARC gives senders a way to publish a policy of what receiving mail servers should do with an invalid message that’s pretending to come from them or is tampered with in some way and those break down into:

None: Email receivers process this as any other message, but also are logged for reporting to domain owners.

Quarantine: Receivers treat the message as suspicious and usually send it to an inbox’s spam or junk folder.

Reject: Receivers flat out reject the incoming message so it never gets delivered in the first place.

Along with these policies, domain owners are also able to receive reports about how their messages are being handled by different email receivers and can adjust or respond accordingly. This is just a crash course on DMARC; there are other policy options, but we can get into those deep dives next time.

What This Means For Email Senders

So now that we’ve got a rough idea of what these standards are and how they came about. You’re probably asking what does that have to do with you? Being someone who sends email you obviously want it to land in a person’s inbox and not spam, or worse, bounced entirely.

These authentication mechanisms have a huge impact on deliverability, meaning compliance and not just content affects how likely you are to land in someone’s inbox. Since 2024 Gmail, Yahoo, and other major email providers have been requiring all three of these to be implemented and properly configured for bulk senders with more than 5,000 emails a day. Even if you aren’t hitting that 5,000 email threshold, having SPF and DKIM enabled and a properly configured DMARC policy can greatly improve the deliverability of the emails you do send.

Set up is one thing, but these authentication mechanisms have to be updated as your email sending changes. SPF records need to accurately reflect where you’re sending email from, your DMARC policy needs to be adjusted as your sending patterns change, and those DMARC reports need to be analyzed to inform you on how best to adjust your sending and authentication.

It can be convoluted and frustrating to stay on top of email authentication, especially when you have a million other things you need to do. So at CleanMarc we’re building a tool that handles the heavy lifting of setup, monitoring, and maintenance of your email authentication for you, while keeping you notified of any important changes or issues that might come up. If you’re interested in giving CleanMarc a shot, join the email list below and we’ll let you know as soon as it’s ready to try out!