Deleting the Google Workspace MX, and why an unpaid mail provider is worse than none

Name:        novelsystems.ca
Type:        MX
Mail server: smtp.google.com
Priority:    1
TTL:         Auto
Proxy:       DNS only

was deleted, and Cloudflare Email Routing was enabled in its place with a single catch-all rule forwarding to `khan.ahmadz6370@gmail.com`. The record is written out verbatim above so the decision can be reversed by retyping it.

Superseded 2026-08-07 by D-103. Email Routing is off and the apex MX points at Google Workspace across the five ASPMX hosts. Everything below stands unedited, because it was correct for the three days it held and because its closing paragraph is the exact condition on which it was retired. The one thing that did *not* come back is the record quoted immediately above: the single-host smtp.google.com MX stays deleted, and D-103 says why.

What the evidence actually said. Ticket NS-60452 sent two notifications through Resend and both came back Bounced. The obvious reading — "the apex has no MX" — was wrong. The apex had an MX, and it was the modern single-record Google Workspace one. What it did not have was anything behind it: no mailbox existed at ahmad@ or support@, so mail was accepted at Google's edge and hard-rejected. Two independent signals said Workspace had never actually been live: the bounces themselves, and the total absence of an apex SPF record — the apex carried only a google-site-verification TXT, where a live Workspace sending domain would normally carry include:_spf.google.com.

This is worse than a cosmetic gap. /security tells visitors to mail security@novelsystems.ca to report a vulnerability, and that address was silently discarding mail. The dead set was support@, security@, sales@, careers@ — every address the site or the legal documents publish.

Why not simply pay for Workspace. It would work, and it is the wrong shape for this problem twice over. It is a recurring subscription whose sole purpose would be receiving four low-volume aliases; and buying it is a payment action that is not mine to take, which would leave the site's published security contact broken for as long as it took someone else to act. Cloudflare Email Routing is free, deterministic, reversible in one record, and drivable end to end from the dashboard that already holds the zone.

Why catch-all rather than four rules. Four rules cover four addresses; catch-all covers every address the site publishes now *and* every one it publishes later, including any already sitting in a legal document nobody re-reads. The failure mode of catch-all is receiving spam addressed to sdfkj@novelsystems.ca. The failure mode of per-address rules is a silently dead address that someone was told to use for security reports. Those are not symmetric.

Why the new apex SPF cannot break Resend. Email Routing adds v=spf1 include:_spf.mx.cloudflare.net ~all to the apex, which looks alarming next to a working outbound pipeline and is not. Resend's SPF lives on send.novelsystems.ca because that subdomain is the MAIL FROM / return-path domain, and SPF is evaluated against the return-path, never against the visible From. The apex record does not participate in Resend's check. DKIM alignment runs through resend._domainkey on the apex and is untouched. DMARC is p=none — monitor-only — so even a misjudgement here could not have caused a rejection.

The third failure, which the fix exposed. With routing repaired, the next two sends read Suppressed rather than Delivered. Resend adds an address to a suppression list after a hard bounce, and a suppressed send returns success to the caller while never being transmitted — an application-level failure that is invisible from inside the application. Both entries were removed by hand. This is the standing operational hazard of the Resend integration: *a repaired delivery path does not un-suppress the addresses that broke while it was broken.* Any future mail outage needs the suppression list checked as its last step, not its first.

Proof, in the order the three defects had to be cleared. NS-60452 → Bounced (mail had nowhere to land). NS-36977 → Suppressed (both addresses blacklisted by the previous bounce). `NS-64035`, Zammad #87007, filed from the live form at 11:27 a.m. EDT → Delivered on both rows, and both messages present in the destination inbox, forwarded by the Cloudflare catch-all.

What would make this wrong. A real mailbox — Workspace, Fastmail, anything with storage — becomes correct the moment more than one person needs to read support@, or the moment anyone needs to *reply from* one of these addresses. Forwarding is receive-only, and a reply sent from a Gmail account is a reply from a Gmail account no matter what it is answering. At that point the apex MX goes back to the mail provider and Email Routing is disabled, because the two cannot coexist: Email Routing refuses to install its records while any non-Cloudflare MX is present, which is exactly the conflict that produced the red inline error here.