Avoid missed emails with SPF, DKIM, and DMARC

If you aren't already aware, as of February 1, 2024, both Google and Yahoo!, arguably the two largest email providers in the world, added policies to help their users avoid spam or other unwanted email. While these policy changes mostly apply to "bulk" senders of messages to these platforms – understood as one organization (domain) sending to 5,000 or more Gmail or Yahoo! users a day – they apply to anyone and everyone, regardless of whether they're bulk senders or not. (Here is Google's email sender FAQ and here is the email sender requirements FAQ for Yahoo!)

Really, all Google and Yahoo! are doing is keeping senders honest. This includes ensuring a sending domain stays below a .3% "spam rate", and that there is a simple one-click way to unsubscribe from a mailing. The primary focus, however, is on sender authentication. How they're going about this is by implementing strict enforcement of email authentication, which focuses on three main things: SPF, DKIM, and DMARC. (For a quick review, see our blog post on Understanding SPF, DKIM and DMARC.)

What IS Email Authentication?

To quote from our own blog post:

"Put simply, SPF, DKIM and DMARC are ways to authenticate your mail server and to prove to ISPs, mail services and other receiving mail servers that senders are truly authorized to send email. When properly set up, all three prove that the sender is legitimate, that their identity has not been compromised and that they're not sending email on behalf of someone else."

So, having properly implemented SPF, DKIM, and DMARC means that receiving servers have confidence that the sender is exactly who they say they are. If you use, or manage, a server that already has these three things set up, then you're golden! If not, it's possible your messages will get sent to a recipient's junk folder or, worse, outright rejected, especially if your company sends out a lot of newsletters, sales circulars, etc. (As of now these guidelines are primarily for bulk senders of email, but logic dictates these same rules will trickle down to standard users.)

Email Authentication and SmarterMail

The good news is that SmarterMail easily integrates DKIM into a domain's settings, so domain administrators can set it up themselves from within SmarterMail, then make the DNS changes that are necessary, or get the DKIM information to whoever manages their DNS. SmarterMail also gives domain administrators the ability to create a Rollover DKIM record, making it easy for them to periodically change the public DKIM key. (Because DKIM is public, and it's a way of digitally signing messages, a good security practice is to change the key from time-to-time to prevent attacks.)

In addition, creating an SPF record is extremely simple when using sites like MXToolbox or EasyDMARC. EasyDMARC also has a DMARC Record Generator that can be used, and it provides a detailed description of each field, including the settings available for each. Of course, there are dozens of sites that offer similar tools for generating SPF and DMARC, as well as tools for validating the records once they're added to DNS. As for DKIM, that key is generated by SmarterMail directly.

Sender Verification Shield

Sender Verification Shield in webmail

As a user, SmarterMail makes it very easy to see if a sender has been properly authenticated in the webmail client with the "Sender Verification Shield". By default, SmarterMail checks a number of things to attempt to validate that the sender is who they say they are. Things like DMARC, DKIM, SPF, trusted sender status, whether the user is authenticated on the server, and whether they're listed in your Contacts are all used to verify that Tom@Business-A.org, for example, IS actually Tom from Business-A.org. Moving your mouse over the shield opens a window that tells you whether the sender is likely the sender or not, what checks were performed, and the status of these checks. All of this adds up to verifying the authenticity of the sender.

Following in the Footsteps fo Google and Yahoo!

Text of an email header

So, if these email providers are making changes to how they receive mail, can SmarterMail administrators do the same? Of course!

The first thing to do is to make sure domains administrators have the information they need to make the necessary DNS adjustments for SPF, DKIM, and DMARC, as well as tools to make sure they've validated their changes and that things are working properly. Then, it's up to them to make sure their domains are fully in compliance. We said a while ago that this is the direction email authentication was headed, and now service providers are making decisions that could impact the proper delivery of email for users.

Next, it's possible to modify spam weights for the SPF and DKIM spam checks, making them more punishing for domains that haven't implemented them – or implemented them improperly – and be more forgiving for domains that have things set up properly. By default, SmarterMail assigns weights to these checks, but those weights are fully customizable. So, it's possible to set a PASS weight to a negative number (thereby lowering an overall spam score by that amount) while setting FAIL or NONE weights higher than the defaults. This rewards domains for the proper implementation of SPF and/or DKIM and places a harsher penalty on those domains who have it set up poorly.

The problem with this, though, is that there's no way to really let the administrators of the offending domains know what the problems are. Sure, you can look at a message that has a high score for, let's say, SPF NONE, and you know the domain the message was sent from, but how does that information get back to the domain administrator? If you send a highly technical reply to the sender, what are the chances that gets forwarded to someone who can do something about the issue?

The best you can do is to manage these settings for your own domains, and adjust their spam scores to give users the best possible experience, while limiting the potential for missed emails. It's a balancing act, for sure, but fighting spam has always been this balancing act.


So, what do the recent changes that Google and Yahoo! just announced really mean?

Well, put simply, SPF, DKIM, and DMARC are now mainstream. They're no longer "recommended" settings for a domain that sends emails, they're necessary DNS entries. And while Google and Yahoo! are implementing these restrictions for "bulk" senders, it's a safe bet that they'll soon implement them for ANY domain that sends emails to users of their services, regardless of the type of email being sent.

And they're just the most recent companies who are doing this. Others will certainly follow, so it's best to make sure you and the domains you manage are ahead of this rapidly flattening curve. Thankfully, all three are supported by SmarterMail, and using them offers powerful spam protection for your servers and your users. However, until more companies adopt the use of SPF, DKIM, and DMARC, and until they get all three implemented properly, there may be some growing pains.