Email Authentication Impact on Inbox Placement


The messaging around inbox placement and authentication has always been nuanced, and it's easy to misunderstand. To be clear, email authentication doesn't guarantee inbox placement, but it can help. And a lack of authentication clearly makes it harder to get reliability delivered to the inbox.

Why is there any impact at all? Part of it is likely due to confidence on the part of the mailbox provider that your domain is yours; that it's a safe and accurate identifier to attach reputational metrics to; that it's safe to use the domain as a way to measure you as you. Another part of it is probably arbitrary, a choice made by the mailbox provider to increase your (positive) score in their internal systems based on finding evidence of email authentication. They want to see email authentication, so they perhaps offer a modest deliverability boost, in some cases.

Here's some fun testing I performed over the course of the past few weeks. With multiple MTAs and sending services at my disposal, I was able to test email from a domain to my inbox placement seed list multiple times, across multiple days, with different email authentication configurations.

I configured and executed a number of different email send scenarios:
  • All messages pass DKIM and SPF authentication.
  • All messages pass SPF authentication, but lack DKIM authentication.
  • All messages pass DKIM authentication checks, but fail SPF authentication.
  • All messages fail SPF authentication and lack DKIM authentication, with a DMARC policy of p=none.
  • All messages fail SPF authentication and lack DKIM authentication, with a DMARC policy of p=reject.
Overall impact: Disable email authentication and inbox placement is negatively impacted. Different mailbox providers are affected by different signals to different degrees; not every provider responded similarly.

To frame that another way, failed authentication with DMARC p=none knocked a good 50 points off of my inbox (test) placement, but with DMARC p=reject it completely prevented my failed mail from delivering to any of the big mailbox providers. No spoofing allowed! How do email authentication and DMARC affect inbox placement and delivery? That's how. In particular, the 100% missing entry reminds us of how things can go wrong.

The little bit of yellow (spam folder delivery) persistent across almost all sends reminds us that authentication is not the only ingredient in the mix when it comes to spam filtering. The domain in question is one that I don't use very often, and doesn't have a very long or deep history of email sends. Apple's iCloud, in particular, loved to send every test email message from that domain to the spam folder.

DKIM success plus SPF failure leading to reduced inbox placement was a bit of a surprise for me. Apple's iCloud, AT&T and Gmail were unkind to some or all of those messages.

SPF (only) seemed to be "good enough" in my test scenarios, matching the DKIM+SPF results. My testing here is limited, but it suggested to me that if it's possible to implement SPF aligned to your sending domain, you should do it, as it might be an acceptable backup in scenarios where DKIM is unexpectedly missing.

And with no authentication (failed SPF and no DKIM, and a p=none DMARC policy) I still managed to get inbox delivery at Google Workspace, Comcast, and Yahoo mailboxes in my various tests. But clearly, overall inbox placement success was greatly inhibited, compared with the messages that were fully authenticating successfully.

Repeating tests didn't show any sort of wobble; I found the results reproducible day after day. But do know that any testing like this is by nature imperfect; it doesn't account for overall domain reputation and variations in IP reputation.

Nonetheless: Email authentication matters for deliverability success.

Just do remember that it isn't the whole story. You could authenticate every message you send, but if those messages are unwanted and garner high complaint rates and low engagement rates, your chances at inbox success are slim-to-none. While email authentication might open up the path to the inbox, at least slightly, it does not prevent other factors from slamming that gate back down when appropriate.

Email authentication is not a substitute for permission; it's a necessary mechanism that rides along side permission.
2 Comments

Comments

  1. Do you think unaligned SPF would have a similar effect? A lot of ESPs use their own domain to handle SPF while allowing the sender to sign their DKIM. Often DKIM will be signed by both the ESP's domain and the sender's domain. Do you think this process should be updated to implement full domain alignment for both SPF and DKIM?

    ReplyDelete
  2. I work for an ESP that handles SPF for all client sends using our own domain. This checks the SPF box, but we don't have domain alignment with client sending domains. I'm wondering about the deliverability benefits of having (or at least offering) domain alignment for SPF. I know there are some large ESPs that don't offer it, yet some do. Is this something we should explore?

    ReplyDelete

Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.