DNS Email Authentication Configuration Checklist Builder

Create a developer-ready checklist for configuring SPF, DKIM, DMARC, and BIMI records with testing steps, rollout policy, and monitoring.

Prompt Template

You are an email infrastructure engineer and deliverability-minded developer. Build a DNS email authentication configuration checklist for:

Domain: [primary sending domain]
Sending subdomains: [marketing.example.com, mail.example.com, transactional domain, none]
Email platforms: [ESP, CRM, transactional provider, help desk, billing system]
DNS provider: [Cloudflare, Route 53, GoDaddy, internal DNS, other]
Current authentication status: [paste SPF, DKIM, DMARC, BIMI records or say unknown]
DMARC policy goal: [none, quarantine, reject]
Reporting mailbox or service: [rua/ruf destination, monitoring tool]
Volume and sender types: [transactional, newsletter, sales outreach, support, billing]
Migration context: [new domain, ESP migration, subdomain split, remediation, audit]
Constraints: [shared domain, multiple vendors, DNS change window, compliance requirements]
Testing tools available: [dig, nslookup, MXToolbox, provider validators, Postmaster Tools]
Risk tolerance: [monitor first, move quickly, strict enforcement]

Create:
1. Current-state audit checklist for SPF, DKIM, DMARC, BIMI, MX, and return-path alignment.
2. Recommended DNS records with placeholder-safe values and notes for each provider.
3. SPF include strategy that avoids the 10-lookup limit.
4. DKIM setup plan by sending platform, including selector tracking.
5. DMARC rollout path from monitoring to enforcement with decision gates.
6. BIMI readiness checklist including logo, VMC/CMC, and DMARC prerequisites.
7. DNS change plan with TTL, sequencing, ownership, and rollback notes.
8. Validation commands and third-party checks after propagation.
9. Monitoring dashboard fields for failures, alignment, spoofing, and vendor drift.
10. A final implementation checklist a developer can execute safely.

Flag assumptions and anything that must be confirmed in the sending platform or DNS host before changes are made.

Example Output

DNS Email Authentication Plan - example.com

Record Inventory

| Control | Status | Action |

|---|---|---|

| SPF | Existing record has 8 lookups | Consolidate vendors and remove retired CRM include |

| DKIM | Missing for help desk | Add selector zendesk1._domainkey.support.example.com |

| DMARC | p=none, rua configured | Monitor 14 days, then move marketing subdomain to quarantine |

| BIMI | Not ready | Wait until DMARC reaches quarantine or reject |

Rollout

1. Lower TTL to 300 seconds one day before the change window.

2. Add DKIM records for each active sender before editing SPF.

3. Validate with provider tools and dig TXT selector._domainkey.example.com.

4. Keep DMARC at p=none until alignment failures are below 2% for two weekly reports.

Developer Checks

Run dig TXT example.com, dig TXT _dmarc.example.com, and a seed send through Gmail, Outlook, and the transactional provider validator.

Tips for Best Results

  • 💡Inventory every tool that sends email before editing SPF; hidden senders are the usual failure point.
  • 💡Move DMARC policy in stages so legitimate mail streams have time to surface in reports.
  • 💡Track selectors, vendors, and owners in a small register so future platform changes do not break authentication.