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

Original Article ↗ Hacker News Discussion ↗

Incident: Viva.com emails rejected by Google Workspace

  • Viva.com verification emails lack a Message-ID header.
  • Google Workspace rejects these messages with a clear policy error; the author confirmed this via Workspace email logs.
  • Switching the Viva account email to a personal @gmail.com address works; consumer Gmail accepts the same messages.
  • Viva support responded that the account was already “verified” and therefore there was “no issue,” ignoring the protocol-level problem.

Who’s at fault: Viva vs Google vs the RFCs

  • RFC 5322 marks Message-ID as “SHOULD,” not “MUST”; several commenters stress this means it’s not a formal requirement.
  • Others argue that per RFC 2119, “SHOULD” is a “weak must”: you ignore it only with well-understood, justified reasons.
  • Many note that in practice large providers treat Message-ID as de‑facto required for automated mail, because its absence strongly correlates with spam.
  • One camp: Google is technically non‑compliant by rejecting valid-but-odd messages.
  • Other camp: the sender is at fault; if you want to reach Workspace (or any big provider), you must follow their de‑facto rules regardless of the RFC wording.

Support quality, monitoring, and operational maturity

  • Multiple people highlight the real issue as lack of monitoring and poor handling of bounces: a major payment provider should notice that a big chunk of verification emails to a major host are being rejected.
  • Several describe similar experiences with front‑line support that follows scripts, closes tickets once a workaround exists, and never escalates protocol bugs to engineers.
  • A particularly heated subthread revolves around one commenter misreading the blog/logs, asserting defamation and legal liability; others rebut by pointing to the Workspace logs and basic email semantics.

Email deliverability pain and de‑facto standards

  • Many recount how modern email deliverability depends on SPF/DKIM/DMARC, IP/domain reputation, template quirks, and opaque heuristics at Google/Microsoft/Apple.
  • Common advice: don’t DIY transactional email—use ESPs (Sendgrid, Mailgun, Postmark, etc.) whose infrastructure already complies with the major providers’ expectations.
  • Some argue Postel’s Law (“be liberal in what you accept”) is obsolete in an adversarial, spam-heavy environment.
  • Several note that big providers routinely go beyond RFCs and effectively function as the real standards bodies; specs lag “what Gmail/Outlook will actually accept.”

European fintech / API quality and wider competence themes

  • The post’s claim that European business APIs are “always a bit broken” resonates with some: incomplete docs, PDF specs, brittle edge cases, non-technical support.
  • Others say this is more about organizational size and priorities than about Europe per se; small and mid‑size orgs everywhere underinvest in robust APIs and email.
  • Separate threads lament widespread incompetence in financial IT and enterprise tech, but also note that society is surprisingly fault‑tolerant of such failures.