Mail moved from Cloudflare forwarding to Google Workspace, and the two failures that only appeared after DNS was correct

Supersedes D-033. Cloudflare Email Routing is disabled. The apex MX now points at Google Workspace across five records — ASPMX.L.GOOGLE.COM at priority 1, ALT1 and ALT2 at 5, ALT3 and ALT4 at 10, all DNS only, never proxied. The apex carries exactly one SPF record, v=spf1 include:_spf.google.com ~all; DKIM is published at google._domainkey; _dmarc is v=DMARC1; p=none; rua=mailto:ahmad@novelsystems.ca. support@, security@, sales@ and careers@ are Workspace groups rather than forwarding targets, and eight people hold accounts on the domain.

This is the condition D-033 named, not a reversal of its reasoning. D-033 closed by predicting its own end: a real mailbox "becomes correct the moment more than one person needs to read support@, or the moment anyone needs to *reply from* one of these addresses." Both have now fired. Eight users exist, and a reply was sent from ahmadzkhan@novelsystems.ca and received externally as coming from that address, which forwarding could never have produced — 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. D-033 was right for the three days it held, and it is being retired on the trigger it wrote down rather than on a change of mind.

The single-record form stays deleted. D-033 removed an apex MX pointing at smtp.google.com at priority 1, and Google's own domain-connect flow proposes re-adding exactly that record. It was refused. The five-host ASPMX set is the form Workspace documents and the form that was verified end to end here; adding smtp.google.com alongside it would create a sixth path whose behaviour nobody in this repository has tested. The record in D-033 is written out verbatim there so the *old* decision can be reversed by retyping it — that is an escape hatch for reinstating forwarding, not an invitation to run both.

The first failure: DNS was perfect and every published address still rejected mail. With the MX, SPF, DKIM and DMARC all correct, external mail to all four group addresses was rejected. The diagnosis that matters is *where* it was rejected. mx.google.com accepted the connection and logged spf=pass dkim=pass dmarc=pass — the transport layer was doing exactly what the zone told it to. The rejection came one layer up, from each group's Who can post setting, which by default excludes senders outside the organisation. A group address that only its own members can write to is, from the outside, indistinguishable from a dead address, and /security publishes one of these asking strangers to report vulnerabilities. External posting was enabled on all four: Careers 01pxezwc2sv3qfg, Sales 01hmsyys1vix5st, Security 04k668n3115lra5, Support 03cqmetx415dk7a. The general lesson is that a green DNS check proves delivery to the provider's edge and nothing about what the provider does with the message after that — the same class of error as D-033's original bounce, where the MX was live and there was nothing behind it.

The second failure: the first four deliveries landed in Spam. A brand-new domain sending its first inbound traffic to a brand-new tenant is exactly the profile the filter is built to distrust. The fix was to open each message and mark it Not spam, which also whitelists the sender, and deliberately *not* to add an Admin-console spam bypass on the group addresses. A bypass would have cleared the symptom permanently and in one action, and it would have done so by disabling filtering on careers@ and support@ — the two addresses most likely to receive a hostile attachment from a stranger, and the two where a person is expected to open what arrives. Trading the site's most exposed inboxes against four messages of inconvenience is not a trade worth making. The reputation problem is self-correcting as legitimate volume accumulates; the bypass would not have been.

Why this is now recorded as costing money. Workspace is a recurring subscription, which D-033 correctly identified as the wrong shape for four low-volume aliases and as a payment action that was not mine to take. The owner has since taken it. What that buys beyond forwarding is storage, per-person mailboxes, sending identity on the domain, and group membership that can change without a DNS edit. The changelog carries Workspace as a service with a running cost, because a mail platform that lapses for non-payment fails in the same silent way the original never-provisioned tenant did.

What would make this wrong. If mail stops arriving, the first thing to check is not DNS — it is the group posting matrix and the spam folder, in that order, because both have already failed here once with the zone in a correct state. If the Workspace subscription lapses, the apex MX keeps pointing at Google and mail is accepted and discarded, which is the precise failure D-033 was written about; the recovery is to delete the five MX records and re-enable Email Routing, not to leave the zone as-is. And the rua address in the DMARC record is an alias on a single super-admin account, so if that account is ever renamed the reports stop with no other visible symptom.