In October 2023, Gmail and Yahoo announced that they would start enforcing factors that should already be common practice for high-volume senders. Even though deliverability professionals have been coaching senders to follow these rules literally for years, this was still met with some surprise by many senders who were not already doing this. The good news is that both Mailbox Providers have given you some grace, and you have until early 2024 to get this into place. Do NOT wait to make these changes. Both companies have had these as casual “rules” for years, and I doubt you will get a free pass after January 2024.
So, what needs to be done to keep sending mail in 2024? They boil down to 3 important factors.
Authentication. This is the most important since lacking these will make your email end up in the bit-bucket and the rest becomes irrelevant. You absolutely must have a valid SPF, DKIM and DMARC records in DNS for your sending domain. There is extensive documentation on-line on how to create these and validate them. If you are one of the financial institutions that fall into the large group that only has SPF set, you need to fix that before the end of the year, or your Gmail and Yahoo users will not be receiving your email. If you are one of the many senders who still have not published a DMARC record, you should attend to that soon.
Easy Unsubscribe. If you make it past the SPF/DKIM/DMARC gauntlet mentioned above, your next hurdle will be to make sure you have an easy, preferably “one-click" unsubscribe. This is probably the easiest thing to do, and yet many emails are sent without this protection every day.
Only send mail to people who want it. This is easiest to manage by monitoring your spam-complaint rate, which is exactly what Gmail and Yahoo will be doing to protect their users. You need to monitor it as well to make sure you stay under the allowable threshold.
While there are other factors that will influence your ability to deliver to a real user inbox, these three items are probably the most critical and are the ones specifically mentioned in the Gmail and Yahoo announcements that can be read in their original forms below.
Gmail announcement || Yahoo announcement
How can you ensure your email is compliant?
Lucky for you, KumoMTA has built-in ways to manage these in simple ways. While SPF, DKIM and DMARC are mainly DNS configuration issues, the DKIM signing of a message is done by the MTA that delivers the message. Some under-powered MTAs will slow to a crawl if they must DKIM sign every message, so you need to ensure you have a high-performance MTA designed to DKIM sign every message without impact to speed. KumoMTA was designed with that recommendation in mind, and the configuration is dead simple. Once you have your signing keys in place, signing every message is as easy as adding the dkim_signer function to the SMTP or HTTP event handler. Every message from a configured sending domain will be signed and sent.
What about Unsubscribes?
Ideally, every message you send should have a clear one-click unsubscribe link right on the message itself, but in addition, you should add a List-Unsubscribe header that can be triggered from the Mailbox provider’s junk mail tools. This is quite simple to configure in KumoMTA if your content tools don't allow you to add one at the source. We have a function specifically for adding headers to messages in transit to make this easy.
You can add the append_header function in an event that has access to the message object. This can be done in the smtp_server_message_received event handler. The sample below is taken from a working demo system, but yours will be very similar. Feel free to copy and modify in your own KumoMTA config. When an SMTP message is received and ready for processing, the header “List-Unsubscribe” will be appended to the headers with the appropriate values. The unsubscribe header(s) include an email to post to as well as a one-click URI.
kumo.on('smtp_server_message_received', function(msg)
-- Place functions for message handling here --
local keyuserid = kumo.encode.base64_encode(string.format('%s/%s', msg:recipient().email, msg:get_meta('tenant')))
msg:append_header("List-Unsubscribe", "<mailto:unsub@demo2.kumomta.com?subject=unsub>, <https://luna.kumomta.com/unsubscribe.php?t=" .. keyuserid .. ">")
msg:append_header("List-Unsubscribe-Post", "List-Unsubscribe=One-Click")
-- rest of message handling goes here --
end)
But how can an MTA help track Spam Complaints?
This is something we were thinking about when we initially built KumoMTA. There are very few (if any) reasons not to be tracking spam complaints, so we enabled it by default. The setup is incredibly easy – it mostly just works out of the box. Let me introduce you to the trace_headers setting.
If you follow that documentation link above, you will find that we turn this on by default and give you options to alter it or turn it off. By default, we turn on a supplemental header called X-KumoRef with a base64 encoded string that includes the recipient's email address. You can alternately include additional metadata that could include other arbitrary data. Note that this is NOT encrypted, only base64 encoded.
trace_headers = {
supplemental_header = true,
header_name = 'X-KumoRef',
include_meta_names = {},
},
If you configure the listener_domain for your feedback address, KumoMTA will automatically capture the Feedback loop messages (spam complaints) and log them for you in the proper ARF/FBL format. Our instructions for the Listener Domains Helper show how easy it is to add your spam complaint address for monitoring. The X-KumoRef encoded string discussed above is captured and logged along with other information in your normal MTA logs. These logs can be shipped to many visualization tools in real-time for immediate tracking of your spam complaint rate.
So are you ready?
If your current email infrastructure cannot give you a clear and easy way to DKIM sign every message, change platforms.
If it can’t include a list-unsubscribe header on every message, change platforms.
If you can’t get a clear understanding of your relevant spam complaint rate, change platforms.
If you need help moving your email onto KumoMTA to hit all these requirements, contact us, and we will get you sorted.