Major European payment processor can't send email to Google Workspace users

> 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.

Section 3.6. of the RFC in question (https://www.rfc-editor.org/rfc/rfc5322.html) says:

    +----------------+--------+------------+----------------------------+
    | 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?

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.

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?

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 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.

> Who's in the right

I don't think either are. The payment processor should be sending it, but, at least according to the RFC, it is incorrect to reject an email that doesn't have it. I suspect the reason it is SHOULD, and not MUST is for backwards compatibility with software that predates the RFC that adds the message-id header.

Maybe there is a correlation between missing that header and being spam, but then it should go to the spam folder, not be outright rejected.

----------------------------

The experience with support is also similar to experiences I've had with support at many companies. I provide enough details that an engineer could probably easily fix the problem, but the support representative just dismisses it, and it is doubtful an engineer even hears about it.

The most damning thing about this is they didn't test their email infra w/ Google Workspaces. Imagine what else they didn't test.

The first thing that comes to my mind is: how come viva.com is unable to send emails to google workspaces and nobody at viva.com noticed before ? For how long has this going on ?

The second thing is, what email software are they using ? If it was any relatively used software I would not expect this problem to arise (maybe it is some commond software but misconfigured).

Third, while the header is not mandatory, I usually read SHOULD as a "if you don't implement it prepare for possible problems". SHOULD is not MAY.

Fourth, they should be thankful that Google bounced the messages with some appropriate error explaining how to solve it. I have plenty of issues in the past with both Google and Microsoft where they accept the message for then sending to /dev/null

The Gmail requirement is actually slightly different: the header must be present and unique. Gmail only keeps one copy of a message per user and message ID. Combined with a mail source that uses predictable message IDs (such as Github), you can abuse this to suppress delivery of certain messages to Gmail users.

"Email is tough", software development is tough, IT is tough, walking and talking at the same time is tough, mailing a letter is tough.

When orgs frame problems like this, it erodes trust in the message they try to convey. Email isn't a tough problem, but its a problem nobody wants to really deal with. Email is simple - its a text based protocol, that started out open, but now you need to add security to ensure your email is delivered.

If that's how they handle email, I wouldn't want to see what they do with payment data.

That will teach those pesky Europeans not to start their own payment processors.

Maybe that's something to report to the "European System of Financial Supervision" or some other EU government agency.

They even have a Whistleblowing link at the bottom of their website: https://www.bankingsupervision.europa.eu/about/esfs/html/ind...

> This experience fits a pattern I keep running into with European business-facing APIs and services. Something is always a little bit broken. Documentation is incomplete, or packaged as a nasty PDF, edge cases are unhandled, error messages are misleading, and when you report issues, the support team doesn't have the technical depth to understand what you're telling them.

I can definitely confirm that this is a common thing. But I think this is a "small org"-problem more than a "European business"-problem. Apparently, the company has somewhere between 500 and 1000 employees (I couldn't find good data, sadly). With a size like this, the "support" is probably outsourced (meaning they don't know anything), there are maybe 100 engineers (probably less) and the mailing is either done via a third-party or set up by an Admin that left three years ago.

Without any basis, I will speculate that you will notice this more in Europe because there is simply no company at the size of Stripe or similar.

Huh I've lived in Europe for most of my life and I've never heard of viva except as a poor name choice for Microsoft's corporate Facebook (yammer)

Most companies here use stripe on their website.

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

Mamiride dot com email verifications are not delivered to Gmail from a self-hosted mail server and I wonder if this is the reason. We got around this by making email verification an optional step instead of mandatory.

If a business like that doesn't get its emails delivered, it will slowly go out of business. Merchants will find another processor that is able to deliver emails to every inbox. That is, Google could be less picky, but the company with a problem at hand is Viva.

> For viva.com's engineering team, in case this reaches you: [...]

That's too kind of you, but on the other hand it really doesn't solve the issue of bad priorities and lack of overall Quality. Some engineer might log a couple hours fixing a Level 3 severity bug, emails will start working better, but the poor (or at the least, dubious) backwards technical stewardship (or lack of it) will keep going on inside the company, unnoticed from outside (until something bad eventually happens to some client)

The specific bug is annoying, but that there's no way to report such a thing is an exact hallmark of our current corposphere.

> 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.

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.

Shouldn't this be "doesn't want to send..."?

To author:

The phrase:

“sends verification emails without a Message-ID header — a recommendation of RFC 5322 since 2008”

can be misread as though RFC 5322 recommends not including a Message-ID.

> Why this matters

Hello AI (Claude?)

It used to be said that the reason the Internet evolved so well was because of the basic principle of "be strict when you send, but tolerant when you receive". Clearly Google has forgotten this.

Do you want to enable receiving email for viva.com? sign up for VibeCodedSAAS for E49.99/month

Might want to consider Adyen, which should support IRIS, the Greek instant payment system.

I've never heard of them. Looks to be a company from Greece. That would explain their reply. Not exactly known for their tech.

> This experience fits a pattern I keep running into with European business-facing APIs and services. Something is always a little bit broken.

I feel like this isn't just business services though.

American engineers are used to working for either big tech or "Silicon Valley inc." European engineers are used to working for Volkswagen, Ikea or Ryanair. Very different kinds of businesses who treat tech very differently.

Over here, competing on user experience and attracting users with a slick interface that people love to use isn't really something most companies think about (and so they get their lunch eaten by the Americans).

Nowhere is the European mentality more evident than in cybersecurity, where outdated beliefs still dominate. In this mentality, everybody is out to get you (and that notably incudes your vendors, your business partners and your customers), so all infrastructure has to be on prem, open source is free and hence suspicious by definition, obscurity is the best kind of security, encryption doesn't work so data should go over custom fiber, and if you have to expose an API on the public internet, an Authorization header isn't enough, it should also require MTLS behind a layer of IpSec.

>"We can see your account now has a verified email address, so there doesn't appear to be an issue."

There are still too many edge cases like this one that can't get fixed because of ignorant support not doing it's job. In my life, every company that escalates to an engineer instead of punting the ticket with some asinine 'but it works right now, goodbye' message gets rewarded via keeping my business. The ones that don't are immediately cancelled. Sometimes I even do a chargeback as extra punishment. Maybe I'm just old, but I have near zero tolerance for immature support playing games with my time.

The problem is always e-mail itself. It is terrible standardised and hard to get "right".

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.

> Their support team's response to my detailed bug report

As you said, its not a bug.

A feature request might fare better.

literally everything is tough when comes to emails

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.

I’m sorry but in the context of a 50 year old technology like email, 2008 was yesterday. Gmail is in the wrong, you don’t get to just update the standard for email like it’s TikTok content or a Roblox update or whatever.

Email was here long before Gmail and will be here long after Google abandons it.

This is why I don’t use Gmail.

Also, get off my lawn.

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.

> 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.

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.

[dead]

> Viva.com, one of Europe's largest payment processors, sends verification emails without a Message-ID header — a basic requirement of RFC 5322 since 2008. Google Workspace rejects them outright. Their support team's response to my detailed bug report: "your account has a verified email, so there's no problem."

Their emails do arrive tho? It was your email that didn't arrive? I find it unbelievable that a payment provider ignored customer complaining about no emails being delivered since it would breach their SLAs with their customers and their customers' customers would have complained. Especially since at the top you say Google says you got the verified email.

Dude, you may be liable for damages on this. This is an extremely serious allegation to be making in my opinion. I would delete this asap.

Edit: I think Ycombinator needs to realise they're liable for spreading this too. Holy crap, it's bad. They're lying through their teeth saying an email bounced but ended up in their logs. That's not now emails bounce is it? They bounce because it wasn't found. How was he able to verify his email if he didn't get the code?

Google NOT following the spec is not surprising. SHOULD does not mean MUST and they are completely in the wrong here.

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.

This bug will not be fixed before the Environmental Impact Study is concluded on it.

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.

I offered to host a friends business email on my DO instance. Works 99% of the time but every now and then emails just disappear only to find out that MS and Apple block DO IP addresses, sometimes. Silently. There is a war on small email providers it seems.

Hilarious - German users lecturing Google on how to interpret the English RFC?

I say this lovingly, having significant German ancestry:)

But taking a step back :

did viva previously send message ids and pushed a change to prod to strip it? Was it on purpose or an accident?

And other email providers like proton or Hotmail - do they accept messages without message ids?

Have other clients of Google workspace complained about this issue?