Here’s a question that a friend asked me lately: What does the SpamAssassin "HEADER_FROM_DIFFERENT_DOMAIN" rule ("From and EnvelopeFrom 2nd level mail domains are different") mean?
First, we need to understand what they mean by From and Envelope From. In this case, the from address is your visible from address - aka the 5322.From address, and the "EnvelopeFrom" is the 5321.MailFrom, aka the return-path or bounce address. The from address you are probably most familiar with. If you're not familiar with the return path, I've blogged about that recently here.
What SpamAssassin is warning about here is that these two email address fields have different domain names; they do not match. This lack of domain matching is called a "lack of alignment" and in this instance, the mismatch between these two domains is called a "lack of SPF alignment" -- potentially affecting Sender Policy Framework authentication success in the context of DMARC. If your email messages lack a DKIM signature, and also do not properly pass SPF alignment, they could end up failing DMARC checks, and this could negatively impact your chances at deliverability success.
Because DMARC in theory passes if either SPF or DKIM passes -- meaning you don't necessarily need perfect alignment for both SPF and DKIM, just one or the other, lack of SPF alignment alone isn't supposed to cause a DMARC failure. But, message forwarding and funky filters can cause strange things to happen, so I always suggest that you ensure you can comply with as many authentication checks as possible -- making sure that messages pass both SPF and DKIM auth checks, and making sure that messages have both SPF and DKIM alignment in place.
Some ESPs, CRMs or email automation tools are configured in a way that doesn't allow for proper SPF alignment, usually for various technical reasons. You'll still get OK deliverability without perfect alignment most of the time -- but we're starting to get to the point in the evolution of deliverability and authentication where it's really better to have everything aligning properly. Not being able to customize the return-path domain to allow for SPF alignment was fine in 2010. It's barely OK today, and I think it's going to slowly become more of a problem in the future.
TL;DR? This rule calls out lack of SPF alignment, which is not the end of the world, but is kind of an outdated configuration in 2022. Nudge your sending platform to help you fix it (or nudge them to update their functionality to allow it to be addressed).
To look up more info about SpamAssassin rules in general, check out Nicola Selenu's very cool, detailed, "SpamAssassin Rules, all in one place, explained" page over on his Top Deliverability website.
Here’s a question that a friend asked me lately: What does the SpamAssassin "HEADER_FROM_DIFFERENT_DOMAIN" rule ("From and EnvelopeFrom 2nd level mail domains are different") mean?
First, we need to understand what they mean by From and Envelope From. In this case, the from address is your visible from address - aka the 5322.From address, and the "EnvelopeFrom" is the 5321.MailFrom, aka the return-path or bounce address. The from address you are probably most familiar with. If you're not familiar with the return path, I've blogged about that recently here.
What SpamAssassin is warning about here is that these two email address fields have different domain names; they do not match. This lack of domain matching is called a "lack of alignment" and in this instance, the mismatch between these two domains is called a "lack of SPF alignment" -- potentially affecting Sender Policy Framework authentication success in the context of DMARC. If your email messages lack a DKIM signature, and also do not properly pass SPF alignment, they could end up failing DMARC checks, and this could negatively impact your chances at deliverability success.
Because DMARC in theory passes if either SPF or DKIM passes -- meaning you don't necessarily need perfect alignment for both SPF and DKIM, just one or the other, lack of SPF alignment alone isn't supposed to cause a DMARC failure. But, message forwarding and funky filters can cause strange things to happen, so I always suggest that you ensure you can comply with as many authentication checks as possible -- making sure that messages pass both SPF and DKIM auth checks, and making sure that messages have both SPF and DKIM alignment in place.
If you want to dig deeper into that, I've blogged more about SPF and DKIM alignment here.
Some ESPs, CRMs or email automation tools are configured in a way that doesn't allow for proper SPF alignment, usually for various technical reasons. You'll still get OK deliverability without perfect alignment most of the time -- but we're starting to get to the point in the evolution of deliverability and authentication where it's really better to have everything aligning properly. Not being able to customize the return-path domain to allow for SPF alignment was fine in 2010. It's barely OK today, and I think it's going to slowly become more of a problem in the future.
TL;DR? This rule calls out lack of SPF alignment, which is not the end of the world, but is kind of an outdated configuration in 2022. Nudge your sending platform to help you fix it (or nudge them to update their functionality to allow it to be addressed).
To look up more info about SpamAssassin rules in general, check out Nicola Selenu's very cool, detailed, "SpamAssassin Rules, all in one place, explained" page over on his Top Deliverability website.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.