电子邮件困难:主要的欧洲支付处理商的电子邮件不符合RFC标准。
Major European payment processor can't send email to Google Workspace users

原始链接: https://atha.io/blog/2026-02-12-viva

Viva.com,一家主要的欧洲支付处理公司,遭遇了一个关键的邮件投递问题:他们的验证邮件缺少自2008年以来就已成为标准的“Message-ID”头部(RFC 5322)。这导致Google Workspace自动拒绝这些邮件,阻止使用公司邮箱地址的用户注册。 作者在创建账户时遇到了这个问题,并使用Google的邮件日志搜索发现了问题。一个解决方法是使用个人Gmail地址,因为Gmail的容错性更高。然而,向Viva.com的支持团队报告此错误,得到的回复却轻描淡写——确认账户已验证,而不是承认潜在的技术缺陷。 这凸显了欧洲金融科技基础设施中令人担忧的模式:文档不完整、未处理的边缘情况以及支持团队缺乏技术理解,这可能源于竞争不足。作者强调了可靠的支付处理的必要性,特别是对于希腊的IRIS等本地系统,并希望像Stripe这样的供应商能够扩张,从而提高整体标准。 解决方案很简单:在所有传出的交易邮件中包含Message-ID头部。

一家主要的欧洲支付处理商Viva.com正在发送违反RFC 5322标准的邮件验证消息,缺少必需的“Message-ID”头部。这导致Google Workspace拒绝这些邮件,阻止用户验证他们的账户。 尽管提交了详细的错误报告,Viva.com的支持团队却驳回了这个问题,声称验证不是问题,因为用户*已经*拥有经过验证的电子邮件地址。最初的发布者通过使用Gmail地址来规避这个问题,而Gmail显然拥有更宽松的接收基础设施。 这次讨论强调了遵守电子邮件标准的重要性,大型公司对技术问题缺乏响应的令人沮丧之处,以及基于声誉的电子邮件过滤可能对可传递性产生影响。一些评论员认为Google可能过于严格,而另一些人则指出Viva.com的整体无能以及金融机构内部更广泛的ITIL问题。
相关文章

原文

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 my detailed bug report: "your account has a verified email, so there's no problem."


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

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.

联系我们 contact @ memedata.com