Signing email with DKIM is becoming increasing mandatory in practice

June 22, 2022

For our sins, we forward a certain amount of email to GMail (which is to say that it's sent to addresses here and then we send it onward to GMail). These days, GMail rejects a certain amount of that email at SMTP time with a message that some people will find very familiar:

550-5.7.26 This message does not have authentication information or fails to pass authentication checks (SPF or DKIM). [...]

(They helpfully include a link to their help section on "Make sure your messages are authenticated".)

As far as we can see from outside, there are two ways to pass this authentication requirement. First, the sending IP can be covered by actively positive SPF authorization, such as a '+a' clause. GMail actively ignores '~all', so I suspect that they also ignore '+all'. Second, you can DKIM sign your messages.

There are people who don't like email forwarding, but I can assure them that it definitely happens, possibly still a lot. Unless you want your email not to be accepted by GMail when forwarded, this means you need to DKIM sign it, because forwarded email won't pass SPF (and no, the world won't implement SRS).

GMail is not the only large email provider, but they are one of the influential ones. Where GMail goes today, others are likely to follow soon enough, if they haven't already. And even if other providers (or GMail) accept the message at SMTP time, they might use something similar to these requirements as part of deciding whether or not to file the new message away as spam.

I'm not really fond of the modern mail environment and how complex it's become. But it is what it is, so we get to live with it. If your mail system is capable of DKIM signing messages but you're not doing so yet, you should probably start. If your mailer can't DKIM sign messages, you probably need to look into fixing that in one way or another.

(We're lucky in that we're DKIM signing locally generated messages, and unlucky in that we do forward messages and so we're trying to figure out what we can do to help when the message isn't DKIM signed.)

Appending: The uncertainty of SRS and GMail

SPF's usual answer to how it breaks forwarding messages is SRS. However, it's not clear that SRS or any other scheme of rewriting just the envelope sender will pass GMail's SMTP authentication checks, because GMail's help specifically says (with emphasis mine):

For SPF and DKIM to authenticate a message, the message From: header must match the sending domain. Messages must pass either the SPF or the DKIM check to be authenticated.

SRS and similar schemes normally rewrite the envelope sender but not the message From:, and so would not pass what GMail says is their check (whether it actually is, who knows). Effectively GMail is insisting on DMARC alignment even without DMARC in the picture.


Comments on this page:

I ended up hitting a similar brick wall when I moved to a dedicated box which didn’t block SMTP, so I was able to start sending out emails directly. Cue me testing in GMail (of course, you have to) and I kept getting my emails rejected, until I properly set up DKIM and SPF as stated in the article. I really wish there was a “checklist” for all of these modern email shenanigans, because I wonder how many people stopped hosting mail due to these barriers being erected.

Also, I wonder if GMail only recently changed their rejection messages - a couple of months ago I got a generic email rejection instead of “dkim cerification failed”. If I got that message, I would imagine I would’ve fixed my issues a lot sooner!

By daniel at 2022-06-23 00:09:28:

I think that comment on the Help Center article is just about DMARC authentication. In my experience SPF alignment hasn't been required and SRS has worked fine.

By Albert at 2022-06-23 05:14:07:

FWIW, things are even worse with hotmail/live recipients. I've personally seen them reject messages with correct DKIM signature and correctly configured SPF and DMARC, only because it was coming from a private/residential IP. Go figure.

Which is just cuddly and adorable of Google, since the SPF spec is clear that it's to be used to evaluate the envelope-From, not the header-From (see eg RFC7208 s1).

Google, in their infinite wisdom, having decided to apply it to the header-From, even though a well-set-up SPF record is not intended to be applied to any such thing, then just shrug and say it's everyone else's problem when our email is junked.

This leads completely-professional mail admins (ie, not me) to say things like "GMail is a walled-garden messaging platform with a very lossy SMTP gateway to the outside world. Only Google's admins can fix this, and they choose not to. If you want reliable email to the rest of the world, don't use GMail.". And they're right.

- Tom Yates

By Etienne Dechamps at 2022-06-29 18:52:17:

I really wish there was a “checklist” for all of these modern email shenanigans

https://www.mail-tester.com/ is pretty good at finding potential problems with the emails you're sending.

By Legooolas at 2022-07-08 08:45:20:

First, the sending IP can be covered by actively positive SPF authorization, such as a '+a' clause.

I honestly hadn't looked at the gmail requirements, but this is what I've been doing for a long time and had good success with Google, without setting up any of the other things (DKIM, etc), although I probably should set those up as well anyway.

Very occasionally Gmail starts marking everything I forward from my domains to my gmail account as spam, but after marking a bunch of stuff as ham it becomes happy again. No idea what causes those wobbles, as it's all very opaque...

Written on 22 June 2022.
« Some network speeds and network related speeds we see in mid 2022
A mystery with Fedora 36, fontconfig, and xterm (and urxvt) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 22 21:01:24 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.