Dns Cloudflare¶
Google Workspace MX modernized in April 2023 — single smtp.google.com record replaced legacy 5-record set¶
From legacy section: SEO NEO / Workbook
Pattern: During sandmans.net DNS migration, Cloudflare's import normalized a legacy 5-record MX set (aspmx.l.google.com priority 1 + 4 alt records) into a hybrid:
smtp.google.compriority 1 + 4 legacy alts. I incorrectly raised an alarm that priority-1 was "wrong" (claimed smtp.google.com is outbound-only and won't accept inbound mail). Jim pushed back ("i'm pretty sure google changed their mx to just smtp.google.com — can you check before i change it back?"). Verification confirmed: Google announced a simplified single-record MX setup for Workspace in April 2023. Both configs are fully supported in 2026 — the new single-record (smtp.google.com priority 1) AND the legacy 5-record set work identically. The Lexnet/Prospeo guidance is consistent: "If it ain't broke, don't fix it" — never swap a working MX setup just to modernize. Cost: ~10 minutes of session time + a near-miss on telling Jim to revert a working record. Rule: When evaluating Google Workspace MX records in 2026, accept BOTH configurations as valid: (a) modern single recordsmtp.google.compriority 1, (b) legacy 5-record setaspmx.l.google.compriority 1 + alt1/alt2 priority 5 + alt3/alt4 priority 10. Hybrid mixes (e.g., smtp.google.com priority 1 + legacy alts as backups) also work — Cloudflare and other DNS providers sometimes produce these on import. Never recommend changing MX records that are currently delivering mail successfully. If unsure whether a config is current, run a perplexity_search for "Google Workspace MX records 2024-2026" before suggesting a change. Always verify with Jim before flagging a working production record as "wrong" — his real-world deliverability beats my training data on vendor-specific defaults. Date: 2026-04-27
Cloudflare permission model: Account-scoped vs Zone-scoped DNS are different permissions¶
From legacy section: SEO NEO / Workbook
Pattern: During the sandmans.net Cloudflare setup, our existing token (
evolve-mcp) had Account-level permissions including "DNS View Write," "Account DNS Settings Write," and "DNS Firewall Write" — sounded like comprehensive DNS access. But every API call to/zones/{id}/dns_recordsreturned{"code":10000,"message":"Authentication error"}. Reason: Cloudflare's permission model has TWO separate scopes for DNS: - Account-scoped: "Account DNS Settings" (account-wide settings), "DNS Firewall" (DNS firewall service), "DNS View" (multi-zone DNS Views feature) - Zone-scoped: plain "DNS" with Read/Edit checkboxes (this is what/dns_recordsrequires) The names are confusingly similar but the resources are completely separate. Searching "dns" inside the Cloudflare permission browser ONLY returns the account-scoped variants when the policy scope is "Entire Account" — the plain "DNS" permission only appears when scope is "All zones" or "Specific zone." We burned ~30 min trying to add the right permission via the custom permission editor before pivoting to Cloudflare's pre-built "Edit zone DNS" template which configured everything correctly in 30 seconds. Rule: When creating a Cloudflare API token for managing DNS records, use the pre-built "Edit zone DNS" template instead of building a custom policy. Path: My Profile → API Tokens → Create Token → "Edit zone DNS" template → set Zone Resources to "Include — All zones from an account" → Continue → Create. The template adds exactly the right permission (#dns_records:edit) at the right scope. If you must build custom: the policy scope must be set to a Zone resource (not "Entire Account") for the plain "DNS" permission to appear in the permission search. The account-level "DNS View Write" / "Account DNS Settings Write" / "DNS Firewall Write" do NOT grant access to/zones/{id}/dns_records— those are different features entirely. Date: 2026-04-27
DNSSEC must be disabled at the registrar BEFORE switching nameservers¶
From legacy section: SEO NEO / Workbook
Pattern: Jim asked the right question during the Cloudflare cutover: "should i adjust dnssec on godaddy?" — caught a foot-gun before it triggered. If DNSSEC is enabled at the registrar with the OLD provider's DS records, switching nameservers to a new provider whose keys don't match would cause DNSSEC-validating resolvers (Google DNS, Cloudflare 1.1.1.1, many ISPs) to refuse the zone entirely. Domain becomes globally unresolvable, not just "wrong records served" — way worse than email being broken. Rule: When migrating DNS providers, ALWAYS check DNSSEC status at the registrar BEFORE updating nameservers. Quick check:
dig +short DS <domain>against a public resolver — if it returns DS records, DNSSEC is signed at the parent registry. If signed: disable DNSSEC at the registrar first, wait for DS records to propagate out (TTL-dependent, usually <24hr), THEN switch nameservers. Re-enable DNSSEC AFTER the new provider's zone is fully active using their DS records. Never enable DNSSEC during a migration window — it adds risk for zero benefit. For sandmans.net the check returned no DS records, so it was safe to flip NS without touching DNSSEC settings. Document this verification step in any future DNS migration playbook. Date: 2026-04-27