DNS records version-controlled

DNS records for email authentication — SPF, DKIM, DMARC, MX, BIMI — are the foundation of your deliverability infrastructure, and incorrect changes to any of them can cause immediate authentication failure or domain spoofing exposure. When DNS is managed exclusively through a web UI, there is no change history, no peer review, no rollback, and no audit trail. A DKIM selector changed in the provider console without a corresponding key update in the secrets manager, or an SPF record that inadvertently drops an authorized sender, will cause delivery failures across your entire subscriber base. RFC1035 records defined as infrastructure-as-code follow the same review process as code changes, providing the same safety guarantees.

Define all email authentication DNS records as Terraform (or equivalent IaC) resources so changes go through version control and code review. Store DKIM public keys as Terraform variables, not as inline string literals:

# Terraform: DNS records for mail.company.com

resource "cloudflare_record" "spf" {
  zone_id = var.cloudflare_zone_id
  name    = "mail"
  type    = "TXT"
  value   = "v=spf1 include:sendgrid.net ~all"
  ttl     = 3600
}

resource "cloudflare_record" "dkim" {
  zone_id = var.cloudflare_zone_id
  name    = "k1._domainkey.mail"
  type    = "TXT"
  value   = var.dkim_public_key  # Injected from secrets, not hardcoded
  ttl     = 3600
}

resource "cloudflare_record" "dmarc" {
  zone_id = var.cloudflare_zone_id
  name    = "_dmarc.mail"
  type    = "TXT"
  value   = "v=DMARC1; p=quarantine; rua=mailto:dmarc@company.com; pct=100"
  ttl     = 3600
}

Commit the Terraform state backend configuration and lock file. Any DNS change now requires a terraform plan review and an apply with CI approval — the same bar as a code deployment.