Email is tough: Major European Payment Processor's Emails rejected by GWorkspace

Source: Hacker News

TL;DR: 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 a detailed bug report: “your account has a verified email, so there’s no problem.”

The verification email that never arrived

The signup flow is standard: enter your email, receive a verification link, click it, move on. Except the verification email never showed up — not in inbox, not in spam. After a couple of days of retrying, I examined Google Workspace’s Email Log Search.

Status: Bounced.

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 earlier in RFC 2822). Google’s mail servers reject the message outright, so it never reaches spam.

The workaround

To unblock myself, I switched to a personal @gmail.com address for the account. Gmail’s receiving infrastructure is apparently more lenient, and the verification email arrived.

The support experience

I reported the issue to Viva.com’s customer support, including a screenshot from Google Workspace’s email logs and an explanation of the Message-ID problem. Their response, within a few hours, was:

“We can see your account now has a verified email address, so there doesn’t appear to be an issue.”

No acknowledgment of the technical problem, no escalation to engineering—just a confirmation that I had worked around their bug.

Why this matters

Message-ID is one of the most basic headers in email. Every email library, framework, and transactional email service generates it by default. Omitting it requires a misconfigured mail pipeline.

Note: RFC 5322 uses “SHOULD” rather than “MUST” for the Message-ID header, meaning it is strongly recommended but not strictly required. Technically, Viva.com’s emails are non‑compliant with a recommendation, not a mandate. Google treats it as a hard requirement, so the verification email ends up in neither inbox.

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? As a business in Greece needing a reliable payments processor, I’m forced to rely on infrastructure that can’t pass basic RFC compliance checks.

The broader pattern

This experience fits a pattern I encounter with European business‑facing APIs and services: documentation is incomplete or locked in PDFs, edge cases are unhandled, error messages are misleading, and support often lacks the technical depth to understand the issue. It’s less about engineering capability and more about prioritization. When a provider is one of the few options in a market, competitive pressure to polish the developer experience is low. Stripe raised the bar globally, but in markets it doesn’t fully serve, the bar remains low.

The fix

For Viva.com’s engineering team, in case this reaches you: add a Message-ID header to outgoing transactional emails. It should look something like:

Message-ID: 

Most email libraries generate this automatically. If yours doesn’t, it’s a one‑line fix. Your Google Workspace users (and many others) will thank you.