When it comes to email authentication priorities, bounce messages generated by your company are probably not at the top of the list. But these messages should not be overlooked—they can contain critical information that has the potential to impact your business.
Why authenticate bounce messages?
When an executive leaves your company or a team alias changes, you want to be sure the original third-party sender is informed. However, if your company’s bounce messages do not authenticate when the third party recipient’s email infrastructure checks for DMARC (Domain-based Message Authentication Reporting and Conformance), such critical information may never get delivered.
Authenticating your bounce messages with DMARC helps ensure their delivery to all third-party inboxes. However, there are some authentication hurdles with bounce messages you need to overcome before DMARC will work.
How DMARC Authentication Works
As a reminder, the purpose of DMARC is to prevent spoofing of the visible 5322.Header From (a.k.a. “Friendly From”) domain listed in the visible email header.
DMARC does this by leveraging two protocols: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). To pass DMARC, the message must pass SPF and SPF alignment or DKIM and DKIM alignment. (For more on how DMARC works, check out this blog post).
DMARC.org advises companies generating bounce messages to sign with DKIM. Why? Because outgoing bounce messages act differently than outgoing regular messages. To understand this difference, let’s take a look at how a regular outbound message would authenticate via SPF.
How Regular Outbound Emails Authenticate with SPF
The SPF check is carried out against the MFrom (a.k.a. “Envelope From”) domain hidden in the technical header of the email. This check to ascertain whether or not a particular IP address is authorized to send emails on their behalf. SPF alignment (critical to DMARC) checks to see whether or not the (hidden) MFrom domain matches the (visible) Header From domain:
In the example above, the sending IP is within the range found in the SPF record for the MFrom domain, so SPF Passes.
Furthermore, the MFrom and Header From domains both match at an organizational level (domain.com), so SPF also aligns, giving one example of a DMARC pass.
The Trouble With Bounce Messages
Problems with SPF occur when your company generates a bounce message in response to an email sent from an outside source addressed to an inbox that no longer exists.
Your infrastructure will return that email (the “bounce”), usually with a Header From address of [email protected] and a Subject Line of Undeliverable: Original Subject
So far so good—the email will leave your infrastructure and make its way over to the original sender, who now becomes the recipient.
However, the recipient’s ISP, or their own enterprise email platform, (the verifier) will check the DMARC authentication of that bounce message. If this were any other email, you would have configured your SPF to authenticate accordingly, as we explored in the SPF section above.
But at this step, the bounce message will automatically leave the MFrom field in the email header blank. This is intentional and prevents “Mail Loops” from forming. What if the bounce message also triggered another bounce message? These messages would go back and forth until something, somewhere broke. By leaving out the MFrom, you leave out the “return address” on your bounce message, so you can stop this mail loop from happening:
And herein lies the authentication headache. With no MFrom, where does the verifier look for their SPF check?
The SPF check for bounce messages can be carried out against the HELO/EHLO domain (cited at the initiation of the SMTP transaction), so long as a valid SPF record exists in the DNS at the HELO/EHLO domain. The SPF check can be performed and it can pass:
However, for SPF to align, we would need at least the organizational portion of the HELO/EHLO domain to match the Header From domain—and in the case of bounce messages, it will be unlikely these domains will match to provide SPF alignment for a DMARC Pass.
Signing Bounce Messages with DKIM to Pass DMARC
To get your bounce messages delivered, you need to do precisely as DMARC.org suggests: ensure that your bounce messages are signed with DKIM and, critically, are aligning with DKIM (where the d= value matches the Header From).
While it’s recommended that both SPF and DKIM pass and align, to pass DMARC a message just needs to pass and align across one of these protocols.
Email authentication isn’t just about security—it’s also crucial to ensuring the deliverability of your legitimate messages. But understanding all the actions your company needs to take to authenticate outbound messages properly is difficult. For a step-by-step authentication guide, download our eBook, “Getting Started with DMARC.”