> 1. Email didn’t arrive in his inbox of his Google workspace
> 2. He checked workspace email logs (with admin you can do this on gsuite)
But it didn't arrive, so how was it in his email logs!?!?!?! Are you tech literate? Isn't this the second time you've been asked or was I rate limited at that point?
> Their support team's response to my detailed bug report: "your account has a verified email, so there's no problem."
Sadly I doubt their system is xkcd806 compatible ether.
This isn't an engineering problem, it's an ITIL problem. To be fair 99% of these complaints will be dealt with by the flow chart. Sadly people on the front line are either not knowledgable enough or not empowered enough to bust out of that straightjacket.
> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008
> ...
> `Message-ID` is one of the most basic required headers in email.
+----------------+--------+------------+----------------------------+
| Field | Min | Max number | Notes |
| | number | | |
+----------------+--------+------------+----------------------------+
| | | | |
|/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
... bla bla bla ...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
| message-id | 0* | 1 | SHOULD be present - see |
| | | | 3.6.4 |
|/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
... more bla bla ...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
| optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+
and in section 3.6.4:
... every message SHOULD have a "Message-ID:" field.
That says SHOULD, not MUST, so how is it a requirement?
The reason it’s recommended is that it’s useful for detecting when an email you receive is already in your mailbox, so that you don’t accumulate duplicates. Otherwise one would have to compare the complete email, which probably no MUA does. Another reason is that replies can include a reference to the original message, so that it can be properly threaded by MUAs.
So these are mostly quality-of-life reasons, it’s not a reason to reject an email.
SHOULD is a requirement. It means that you have to do it unless you know some specific reason that the requirement doesn't apply in your case. "I don't want to" is not a valid excuse, "I don't see a reason to" isn't either.
IIRC this particular rule is a SHOULD because MUAs often send messages without a Message-ID to their submission server, and the submission server adds one if necessary. https://www.rfc-editor.org/rfc/rfc6409.html#section-8.3 The SHOULD lets those messages be valid. Low-entropy devices that can't generate a good random ID are rare these days, but old devices remain in service, so the workaround is IMO justified.
My take, as a postmaster for hosting company, who don't have any sympathy to gmail (that should be visible from my comments history):
Message-ID is absolutely MUST in production e-mails. You can send your test stuff without it, but real messages always have it. Not having Message-ID's causes lot of fun things. All somewhat competent software is capable to add Message-ID's, so lack of it is good indication of poorly made custom (usually spamming) solution.
Rspamd and spamassassin have missing MID check in their default rules, I am sure that most antispam software is same.
I know you're looking for "pedant points" but the specification generally take a backseat to implementation. If Message-ID is expected out here where the rubber meets the road, then you are the squeaky wheel in this scenario for not including it.
And the definition of "SHOULD" (from RFC 2119) is "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
Having said that, I regret my original characterization of the Message-ID header as a "requirement" and have updated the blogpost to be fair to all sides.
As indicated in the RFC, it uses another RFC[0] to define those words. Here's the relevant excerpt from that one:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
> That says SHOULD, not MUST, so how is it a requirement?
Battle with spam has been for long part just trying to algorithmically fingerprint the scam bots and reject the message if it looks like it wasn't sent by "real" mail server/client.
So a lot of things that are optional like SPF/DKIM are basically "implement this else your mail have good chance of being put into spam automatically".
1. SHOULD means, do it if you can/you have to have a really good reason if you don't do it. The only reason it's SHOULD and not MUST is backward compatibility. Mostly in context of "personal send mails", i.e. not automated mails. (For automated mail sending the expectations of you running somewhat up to date software is much higher).
2. You can't really implement mail stuff just based on RFCs:
- There docent overlapping RFCs which can sometimes influence each other and many of them obsolete older versions why others still relevant RFCs reference this older versions. This makes it hard to even know what actually is required/recommendation.
- Then you have a lot of "irrelevant" parts, which where standardized but are hardly supported/if at all. You probably should somewhat support them as recipient but should never produce them as sender today (mostly stuff related to pro-"everything is utf8" days). Like in general the ideas of "how mail should probably work" in old RFCs and "how it is done IRL today" are in some aspects _very_ far away.
- Lastly RFCs are not sufficient by themself. They don't cover large parts of the system for "spam detection/suspicious mail rejection". So it's a must have to go to the support pages of all large mail providers and read through what they expect of mails. And "automated mails need a message id" is a pretty common requirement. In addition you have to e.g. make sure the domain you use isn't black listed (e.g. due to behavior of a previous user), and that your servers IP addresses aren't black listed (they never should be black listed long term, but happens anyway, and e.g. MS has based on very questionable excuses "conveniently" black listed smaller local data center competition while also being one of the most widely used providers for commercial mail in that area).
With fintech that surprises me not the slightest bit. Financial institutions are filled to the brim with unbelievably incompetent people. A large part of it is probably willful ignorance, too. It's often truly staggering that a financial company I interact with in day to day live is even able to exist. That's until I remember that all the others are just as incompetent.
"Major European Payment Processor" really just translates to "Major European Incompetence Center".
I mean, since 2008 finance has been officially privatised profits, socialised losses. It's inevitable that an industry people are forced to use and cannot fail becomes this way.
My pet peeve are services that go out of their way to include a text/plain alternative message part but send something useless, such as the message without the key link. One time I seriously ran into a service just send a short one-sentence note along the lines of "this is a plain text email" as the plain text part. If you don't want to support plain text, maybe just don't send the alternative part?
I had one who sent me the booking details of another client in the plaintext part. I reported it to them nearly a year ago and they didn't reply, so screw anonymity, it was Avis.
This might be me being old, but I still don't understand why html emails aren't the exception. If you want to do a fancy newsletter, trying to sell me crap, I can see why you'd need the images, the css and html. In most other cases, I don't really get the point.
- You are sending a receipt and want table alignment for items
- You want to put a logo of your company so that readers can recognize who's the email from
- You want to make unsubscribe link smaller and the "open the thing I'm notifying you about" link bigger, so that people would know which one is which without reading the url
Epic Games tells me I don't support HTML formatted email.
Many emails are just the HTML version with HTML tags removed, leaving behind a bunch of ridiculously long image and link urls and little to no text telling you what they are. You might have better luck with a partial HTML implementation (pull out the title, alt, src, href attributes) than disabling it entirely.
Gripe only related to email in general: what annoys me to no end is that if my boss forwards me an email and asks me to reply to it (to everybody in the original email) then I have to type in or copy+paste all the addresses from the Fwd attachment (using Fastmail, but this problem exists everywhere). Instead, there should be a button to make that easy.
Sudden realization that one of my American banks must be having email problems with this too because I use a Google custom email and recently got an in-app notification from my bank saying "we're unable to email you" (and a letter) yet my email works perfectly fine... switching to consumer gmail worked.
Do you actually not receive their emails? Fidelity uses tracker dots to check email receipt, which drives me nuts, because like any sane person I don't allow emails to load images without damn good reason. My brokerage should not be sending me cute dog photos, thus I have no need of their images.
So they send me an email, send me another email saying they can't reach me by email, then mail me a letter with the same content as the original letter, and mail me an additional letter saying they can't reach me by email.
Email deliverability is the reason I gave up on email entirely for my side project and built on Telegram instead. Setting up SPF, DKIM, DMARC, warming up a domain, monitoring reputation, dealing with bounces and complaints... all of that just to maybe land in someone's inbox.
With Telegram you send a message via the Bot API and it arrives. 100% deliverability. No spam filters. No authentication chain. The message just shows up with a notification on their phone.
Obviously Telegram has its own limitations (smaller user base in the US, less formal). But for anything where you need reliable message delivery to people who opted in, messaging platforms have a massive advantage over email in 2026.
They are testing it, every time someone signs up and it fails. We don't know that this wasn't something that changed on Google's side, so IMO it's a bigger indictment that no one is monitoring their live email deliverability
The bigger issue here is that Europe depends way too much on the USA in so many areas. This is not good - you can be constantly blackmailed when you have people such as Trump in charge. I don't think the EU can be fixed, but at the same time I also think the less Europeans depend on outside factors (in particular the USA) the better. Canada kind of showed how to do it. Granted, Canada is also dependent on the USA in numerous ways and most of this is hard to fix (most Canadians live in the south aka close to the USA and trade is primarily done via the USA; security has also been largely outsourced onto the USA and so forth). The sooner people in Canada and Europe get moving away towards more independence from the USA, the better. And more cooperation would not harm either.
Typically I'm a DIY type who loves tinkering and building...
HOWEVER, I have learned the hard way to never apply that spirit to email.
In Europe you see this stuff all the time with old school "IT" (what old industrial companies call tech) people balking at the prices of commercial API-based senders and email marketing ESPs.
"Money to send emails in the cloud? HAH! Back at Siemens in 90s we were running millions of emails out of our servers just fine!"
Nobody understands that deliverability has gotten immensely harder these days, and trying to DIY it if its not your core business is just plain stupid. I would never in a million years try to roll my own email, it's nightmarish legacy cruft and footguns all the way down, in everything from IP/Domain Rep to something as simple as the HTML in the email templates themselves.
Microsoft Outlook and Gmail have the last word on everything in email, and their defacto duopoly (over B2B and consumer email respectively) means you play by the rules they set in 2008 and are too lazy to change or you don't get delivered. The protocol of email exists separately from the world of the actual inbox providers, which are locked down to insane degree given the security/spam concerns with email.
I have some level of sympathy with Google here, which isn’t something I often say.
I recently switched from Gmail to Fastmail and by and large I’m happy with it. But I’ve been surprised by the amount of spam and (particularly) phishing emails I get in a regular basis. Google might be too strict in its filtering but it does serve a legitimate purpose.
Interesting that you mention this, as I also switched to Fastmail recently and got more spam than before, but after marking it as spam for some time it now died down I think. This may also be a symptom of changing providers, where the previous provider knew the kind of spam I tended to get from past years, while Fastmail needed some time to get up to speed.
Fingers crossed that the experience will be the same for you.
I don't think a single spam email has ever crossed into my Fastmail inbox. Granted, every service I sign up for gets it's own masked email. But while the @fastmail.nl email that I chuck on my website gets a fair amount of spam, it always gets categorized correctly.
Long time Fastmail customer. Let it learn a bit about your inbox. I barely see any spam these days that’s not been caught. Except LinkedIn, that somehow goes through
Message-Id being basically required for _automated_ mails (very similar mail send to a lot of people) requiring Message-Id is a de-facto industry standard. Sure some providers don't care and some might make it just more likely that your mail ends up in spam. But this could have happened with pretty much any mail provider widely used by companies.
much more funny (/s) is if you start out in a startup and still use the default template for password reset/on-baording links of a widely used system (e.g. Keycloak) and it turns out multiple larger but "cheap" phishing campaigns did the same and now MS/Google and other suspect you are running a phishing operation
or when you use a local data center and can't send mails to MS/Outlook anymore because it turns out someone did some legal questionable things on them and MS wanted the personal information to be handed over _without court order or any ongoing legal proceeding against this people_ and they didn't hand it over (partially because they legally aren't allowed to...) and MS decided to retaliate by permanently blacklist the IPv4 range of that data center(s) which just happen to locally compete with Azure while self hosted mails competes with Outlooks...
Just to add another data point - I recently switched as well and have seen no uptick in spam at all. Could just be my emailing habits though? Not sure.
> For viva.com's engineering team, in case this reaches you: add a Message-ID header to your outgoing transactional emails.
Don't know what they're using for sending emails, but that's something that should be handled by their email service provider, unless they're hosting their own email servers.
10 percent of the effort in building software compatibility with open source file specifications is dealing with knowing the specifications. 90 percent of the effort is dealing with errors in generated files by less worthy software programs.
The RSS spec is one way. RSS readers do a fine job of interpreting files done the right way. Publishers don’t always do a good job with publishing error free RSS files. So RSS readers devs have to anticipate all sorts of errors and conduct error handling to ensure RSS items are properly handled.
This is why companies want to keep their file format proprietary. Other devs can really do damage to the ecosystem and ruin the experience
Worked on an ESP. We had a couple of server software we used on low-level for sending. None of them would accept the message without a Message-ID. But even if you have a super-custom, SMTP-injecting service built, how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to? Unthinkable. I would not like to have business with such a payment provider.
> how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to?
This is the major issue that most of the discussion is missing. It doesn't matter how you want to interpret the word SHOULD, if you want to send to google workspace, you MUST include a message-id. It's not like this is some fly-by-night server with 12 clients.
If you absolutely and completely don't want to include the message-id, then you need to have a warning that your service can't be used by Google Workspace customers. This used to be common practice, blocking communication to servers that behaved badly, and I sort of wish we'd bring it back.
> I would not like to have business with such a payment provider.
Chances are that the decision-makers in most companies don't care about the technicalities (i.e. which email you used for registration) - they want to get up and running.
The reason that Viva doesn't care, I assume, is the reason Google workspace doesn't care: they're both too big to care for 5% of their clients won't do the extra work. They know that their, usually much smaller clients, will "figure it out" by i.e. using another setup that works™. So why bother?
Since workspaces are probably tied to custom domains all they see if only cursorly looking are "random" businesses with bounces (as TFA mentions, Gmail addresses seem to work fine), sure if you look closer you'll notice the MX might be a google one but going from the cursory look to a closer one takes a bit of time.
something the RFC standard recommend but doesn't require
but it being required is a de-facto industry standard for sending automated mails
and is clearly documented by support sides of large mail providers (like Google)
the mail standards only defines what parts you can put together, but widely fail to define how this parts can be interpreted, what are sensible combinations, etc.
and they don't cover spam/suspicious mail detection at all
so you can't just go by RFC, you need to read up on what all larger mail providers have as additional requirements (which mostly are the same, and Message-Id being the most common dominator) and then hope that another provider you didn't read up one doesn't have some other surprising rule (which doesn't tent to be the case if you don't do anything surprising, but it sucks anyway).
Postel’s Law would put the onus on Google to be forgiving in what it receives. Unsure how you could safely use a sender-created Message-Id for anything anyway.
Following Postel's law results in the normalisation and proliferation of defective implementations. The actual standard becomes irrelevant, and new implementations have to be coded against the defective ones.
My opinion is that Postel's law should be approached in the same way that Linus Torvalds did CVS when designing Git. If in doubt about an implementation decision, consider what Postel's law would recommend, and then do the exact opposite.
I vaguely remember hitting this message id issue in Google Workspace, and being able to work around it in mail routing configuration.
Saidly I don't remember the specifics, it was something along the lines of not all, but only specific routing features requiring it. Workspace settings are a moving target anyway, so the behavior probably changed more than once since.
I'm not saying it's a good idea to send emails without message id, but i'd also double-check that workspace configuration.
116 comments
[ 3.1 ms ] story [ 83.5 ms ] thread2. He checked workspace email logs (with admin you can do this on gsuite)
3. It showed the intentional non-accept
4. Comprehending the problem, he switched to personal Gmail
5. The email arrived
6. He informed the sender of the original problem which he worked around
7. Sender is tech-illiterate and did not realize what the problem is. This is common with first line customer support so that happens.
The question to ask is whether you are literate in English or you skimmed too fast. Because I did a 30 s read of the article and got that.
> 2. He checked workspace email logs (with admin you can do this on gsuite)
But it didn't arrive, so how was it in his email logs!?!?!?! Are you tech literate? Isn't this the second time you've been asked or was I rate limited at that point?
Sadly I doubt their system is xkcd806 compatible ether.
This isn't an engineering problem, it's an ITIL problem. To be fair 99% of these complaints will be dealt with by the flow chart. Sadly people on the front line are either not knowledgable enough or not empowered enough to bust out of that straightjacket.
> ...
> `Message-ID` is one of the most basic required headers in email.
Section 3.6. of the RFC in question (https://www.rfc-editor.org/rfc/rfc5322.html) says:
and in section 3.6.4: That says SHOULD, not MUST, so how is it a requirement?That is the difference.
So these are mostly quality-of-life reasons, it’s not a reason to reject an email.
IIRC this particular rule is a SHOULD because MUAs often send messages without a Message-ID to their submission server, and the submission server adds one if necessary. https://www.rfc-editor.org/rfc/rfc6409.html#section-8.3 The SHOULD lets those messages be valid. Low-entropy devices that can't generate a good random ID are rare these days, but old devices remain in service, so the workaround is IMO justified.
But that means a valid reason could exist and Google would block those mails too.
Rspamd and spamassassin have missing MID check in their default rules, I am sure that most antispam software is same.
Having said that, I regret my original characterization of the Message-ID header as a "requirement" and have updated the blogpost to be fair to all sides.
Thank you for bringing this up.
Battle with spam has been for long part just trying to algorithmically fingerprint the scam bots and reject the message if it looks like it wasn't sent by "real" mail server/client.
So a lot of things that are optional like SPF/DKIM are basically "implement this else your mail have good chance of being put into spam automatically".
- In most cases, you are expected to follow it.
- You can choose not to follow it, but you must have a very good reason.
For example, RFC 7231 say that there should be DATE header but some embedded devices have no real-time clock so it ok not to implement.
2. You can't really implement mail stuff just based on RFCs:
- There docent overlapping RFCs which can sometimes influence each other and many of them obsolete older versions why others still relevant RFCs reference this older versions. This makes it hard to even know what actually is required/recommendation.
- Then you have a lot of "irrelevant" parts, which where standardized but are hardly supported/if at all. You probably should somewhat support them as recipient but should never produce them as sender today (mostly stuff related to pro-"everything is utf8" days). Like in general the ideas of "how mail should probably work" in old RFCs and "how it is done IRL today" are in some aspects _very_ far away.
- Lastly RFCs are not sufficient by themself. They don't cover large parts of the system for "spam detection/suspicious mail rejection". So it's a must have to go to the support pages of all large mail providers and read through what they expect of mails. And "automated mails need a message id" is a pretty common requirement. In addition you have to e.g. make sure the domain you use isn't black listed (e.g. due to behavior of a previous user), and that your servers IP addresses aren't black listed (they never should be black listed long term, but happens anyway, and e.g. MS has based on very questionable excuses "conveniently" black listed smaller local data center competition while also being one of the most widely used providers for commercial mail in that area).
"Major European Payment Processor" really just translates to "Major European Incompetence Center".
This is about media types, not encryption.
- You are sending a receipt and want table alignment for items
- You want to put a logo of your company so that readers can recognize who's the email from
- You want to make unsubscribe link smaller and the "open the thing I'm notifying you about" link bigger, so that people would know which one is which without reading the url
- You want to add a header
So they send me an email, send me another email saying they can't reach me by email, then mail me a letter with the same content as the original letter, and mail me an additional letter saying they can't reach me by email.
With Telegram you send a message via the Bot API and it arrives. 100% deliverability. No spam filters. No authentication chain. The message just shows up with a notification on their phone.
Obviously Telegram has its own limitations (smaller user base in the US, less formal). But for anything where you need reliable message delivery to people who opted in, messaging platforms have a massive advantage over email in 2026.
I have had random emails from Google Workspaces to Microsoft 365 be rejected because of a rule that blocked whole IP blocks.
HOWEVER, I have learned the hard way to never apply that spirit to email.
In Europe you see this stuff all the time with old school "IT" (what old industrial companies call tech) people balking at the prices of commercial API-based senders and email marketing ESPs.
"Money to send emails in the cloud? HAH! Back at Siemens in 90s we were running millions of emails out of our servers just fine!"
Nobody understands that deliverability has gotten immensely harder these days, and trying to DIY it if its not your core business is just plain stupid. I would never in a million years try to roll my own email, it's nightmarish legacy cruft and footguns all the way down, in everything from IP/Domain Rep to something as simple as the HTML in the email templates themselves.
Microsoft Outlook and Gmail have the last word on everything in email, and their defacto duopoly (over B2B and consumer email respectively) means you play by the rules they set in 2008 and are too lazy to change or you don't get delivered. The protocol of email exists separately from the world of the actual inbox providers, which are locked down to insane degree given the security/spam concerns with email.
I recently switched from Gmail to Fastmail and by and large I’m happy with it. But I’ve been surprised by the amount of spam and (particularly) phishing emails I get in a regular basis. Google might be too strict in its filtering but it does serve a legitimate purpose.
Fingers crossed that the experience will be the same for you.
they are, but not in this case
Message-Id being basically required for _automated_ mails (very similar mail send to a lot of people) requiring Message-Id is a de-facto industry standard. Sure some providers don't care and some might make it just more likely that your mail ends up in spam. But this could have happened with pretty much any mail provider widely used by companies.
much more funny (/s) is if you start out in a startup and still use the default template for password reset/on-baording links of a widely used system (e.g. Keycloak) and it turns out multiple larger but "cheap" phishing campaigns did the same and now MS/Google and other suspect you are running a phishing operation
or when you use a local data center and can't send mails to MS/Outlook anymore because it turns out someone did some legal questionable things on them and MS wanted the personal information to be handed over _without court order or any ongoing legal proceeding against this people_ and they didn't hand it over (partially because they legally aren't allowed to...) and MS decided to retaliate by permanently blacklist the IPv4 range of that data center(s) which just happen to locally compete with Azure while self hosted mails competes with Outlooks...
doesn't sound like a hard requirement
Don't know what they're using for sending emails, but that's something that should be handled by their email service provider, unless they're hosting their own email servers.
The RSS spec is one way. RSS readers do a fine job of interpreting files done the right way. Publishers don’t always do a good job with publishing error free RSS files. So RSS readers devs have to anticipate all sorts of errors and conduct error handling to ensure RSS items are properly handled.
This is why companies want to keep their file format proprietary. Other devs can really do damage to the ecosystem and ruin the experience
This is the major issue that most of the discussion is missing. It doesn't matter how you want to interpret the word SHOULD, if you want to send to google workspace, you MUST include a message-id. It's not like this is some fly-by-night server with 12 clients.
If you absolutely and completely don't want to include the message-id, then you need to have a warning that your service can't be used by Google Workspace customers. This used to be common practice, blocking communication to servers that behaved badly, and I sort of wish we'd bring it back.
Chances are that the decision-makers in most companies don't care about the technicalities (i.e. which email you used for registration) - they want to get up and running.
The reason that Viva doesn't care, I assume, is the reason Google workspace doesn't care: they're both too big to care for 5% of their clients won't do the extra work. They know that their, usually much smaller clients, will "figure it out" by i.e. using another setup that works™. So why bother?
They even have a Whistleblowing link at the bottom of their website: https://www.bankingsupervision.europa.eu/about/esfs/html/ind...
they forgot to include a message-id
something the RFC standard recommend but doesn't require
but it being required is a de-facto industry standard for sending automated mails
and is clearly documented by support sides of large mail providers (like Google)
the mail standards only defines what parts you can put together, but widely fail to define how this parts can be interpreted, what are sensible combinations, etc.
and they don't cover spam/suspicious mail detection at all
so you can't just go by RFC, you need to read up on what all larger mail providers have as additional requirements (which mostly are the same, and Message-Id being the most common dominator) and then hope that another provider you didn't read up one doesn't have some other surprising rule (which doesn't tent to be the case if you don't do anything surprising, but it sucks anyway).
Hello AI (Claude?)
My opinion is that Postel's law should be approached in the same way that Linus Torvalds did CVS when designing Git. If in doubt about an implementation decision, consider what Postel's law would recommend, and then do the exact opposite.
Saidly I don't remember the specifics, it was something along the lines of not all, but only specific routing features requiring it. Workspace settings are a moving target anyway, so the behavior probably changed more than once since.
I'm not saying it's a good idea to send emails without message id, but i'd also double-check that workspace configuration.