TL;DR: Viva.com, one of Europe's largest payment processors, sends verification emails without a Message-ID header — a 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."
Updated with clarifications based on the HackerNews discussion.
A few days ago, I tried to create an account on viva.com, one of Europe's largest payment processors. It should have taken five minutes. Instead, it turned into a small investigation — and left me with some bigger questions about the state of European fintech infrastructure.
The verification email that never arrived
The signup flow is standard: enter your email, receive a verification link, click it, move on with your life. Except the verification email never showed up. Not in my inbox, not in spam, not anywhere. I waited. I retried. I waited some more.
My email is hosted on Google Workspace — a corporate email on a custom domain. Not exactly an exotic setup. After a couple of days of retrying, I decided to dig into Google Workspace's Email Log Search to see what was happening on the receiving end.
Here's what I found:
Status: Bounced.
The bounce reason:
550 5.7.1 [209.85.220.69] Messages missing a valid Message-ID header are not
550-5.7.1 accepted. For more information, go to
550-5.7.1 https://support.google.com/mail/?p=RfcMessageNonCompliant and review
550 5.7.1 RFC 5322 specifications.
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, and was already suggested by its predecessor RFC 2822 back in 2001.
Google's mail servers reject the message outright. It doesn't even get a chance to land in spam.
The workaround
To unblock myself, I switched to a personal @gmail.com address for the account. Gmail's own receiving infrastructure is apparently more lenient with messages, or perhaps routes them differently. The verification email came through.
But the fact that I had to abandon my preferred business email to sign up for a business payments platform is... not great.
The support experience
Of course, I reported the issue to viva.com's customer support, including the screenshot from Google Workspace's email logs and a clear explanation of the Message-ID header problem — enough detail for any engineer to immediately reproduce and fix it.
They responded within a few hours. Their answer:
"We can see your account now has a verified email address, so there doesn't appear to be an issue."
That was it. No acknowledgment of the technical problem. No escalation to engineering. Just a confirmation that I had worked around their bug, repackaged as evidence that nothing was wrong.
Why this matters
This isn't a cosmetic bug. Message-ID is one of the most basic headers in email. Every email library, every framework, every transactional email service generates it by default. You have to go out of your way to not include it — or be running a seriously misconfigured mail pipeline.
(In fairness: RFC 5322 technically says "SHOULD" rather than "MUST" for the Message-ID header — a distinction debated on HackerNews. So viva.com is violating a recommendation, not a mandate. Google, however, treats it as a hard requirement. Who's right? I don't know. But I'm the one without a verification email.)
For a company that processes payments across Europe, this raises a question: if they can't get email headers right, what does the rest of the stack look like?
I'm not asking rhetorically. As someone building a business in Greece, I need a reliable payments processor. Viva.com is one of the few that natively supports the the Greek instant-payment system. Stripe, which I'd use in a heartbeat, doesn't support it yet. So here I am, forced to depend on infrastructure that can't pass basic RFC compliance checks.
The broader pattern
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 don't think this is because European engineers are less capable. I think it's a prioritization problem. When you're the only option in a market (or one of very few), there's less competitive pressure to polish the developer experience. Stripe raised the bar globally, but in markets it doesn't fully serve, the bar remains remarkably low.
I miss Stripe. I miss the feeling of integrating with an API that someone clearly cared about. Until Stripe or a Stripe-caliber alternative covers the full European payments landscape, including local payment rails like IRIS, stories like this one will keep happening.
The fix
For viva.com's engineering team, in case this reaches you: add a Message-ID header to your outgoing transactional emails. It should look something like:
Message-ID: <unique-id@viva.com>
Most email libraries generate this automatically. If yours doesn't, it's a one-line fix. Your Google Workspace users (and I suspect there is a number of us) will thank you.
Update 1: Google Workspace Email Log
Some commenters questioned whether I could reliably determine why Google rejected the email. Here's the screenshot from Google Workspace's admin email log search, showing the exact bounce reason:
Update 2: MUST vs. SHOULD vs. MAY
The HN discussion clarified the nuances of RFC terminology. RFC 2119 defines three levels of requirement:
- MUST — absolute requirement, no exceptions
- SHOULD — you can skip it, but only if "the full implications [are] understood and carefully weighed"
- MAY — truly optional; implementations that include or omit it must interoperate with those that don't
The reason Message-ID is SHOULD rather than MUST? Mail clients sometimes send messages without one to their submission server, which adds it on their behalf. As for why Google enforces it anyway: spam. Messages with minor RFC violations are far more likely to be spam, so rejecting them is a reasonable heuristic. In practice, Google and Microsoft have become the de-facto standards bodies for email — what the RFCs say matters less than what their servers accept.
That said: if viva.com has indeed considered the full implications and decided omitting the Message-ID header is best for them (my bet is it's just an oversight), then at the very least I'd expect a warning somewhere saying "our email verification system isn't compatible with mail servers that require a Message-ID header, such as Google Workspace." Silence isn't a valid implementation of SHOULD.