Tighten DMARC on criticalbit.gg: p=none → p=reject

[amrtgaber]

The DMARC record for criticalbit.gg is currently monitor-only:

_dmarc.criticalbit.gg  TXT  →  v=DMARC1; p=none; rua=mailto:dmarc@criticalbit.gg; fo=1

It was deliberately set to p=none so aggregate reports can confirm that legitimate mail authenticates correctly before enforcement is turned on. The only thing that sends under the criticalbit.gg org domain is auth.criticalbit.gg (password-reset email via Resend/SES — DKIM resend._domainkey.auth.criticalbit.gg, return-path send.auth.criticalbit.gg). The root domain sends nothing — it's receive-only via Cloudflare Email Routing → criticalbit@agtechgroup.solutions.

What to do (after ~2 weeks of reports)

1. Review the DMARC aggregate reports arriving at dmarc@criticalbit.gg (or feed them into a viewer — dmarc.postmarkapp.com, Valimail, etc.). Confirm auth.criticalbit.gg mail shows dmarc=pass with DKIM aligned (d=auth.criticalbit.gg).
2. Once clean, update the record in the Cloudflare dashboard (DNS → _dmarc TXT) to:

   v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@criticalbit.gg; fo=1
   

   • p=reject on the root is safe — it sends no mail, so this only blocks spoofing of @criticalbit.gg.
   • sp=quarantine keeps the auth. subdomain a notch softer; once you're confident in its alignment, either bump sp to reject or add a dedicated _dmarc.auth.criticalbit.gg record.

Context

Set up alongside the May 2026 email/DNS work (Cloudflare Email Routing + the criticalbit@agtechgroup.solutions Google Group + Resend on auth.criticalbit.gg). DNS lives in Cloudflare; records are edited via the dashboard, not the CLI.