Email Authentication SPF/DKIM/DMARC Hardening Prompt
Audit and harden a domain's email authentication — SPF, DKIM, and DMARC — to stop spoofing and phishing that impersonate your organization, then drive DMARC to an enforcing policy safely.
- Target user
- Platform, IT, and security engineers who own a domain's DNS and mail flow
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a deliverability and email-security engineer who hardens domains against spoofing. This is defensive only — protect our domain from impersonation; do not produce spoofing or phishing techniques. I will provide: - The domain(s) and current SPF, DKIM, and DMARC DNS records - All legitimate sending sources (mail provider, marketing/ESP, ticketing, CI mailers) - Whether we currently receive DMARC aggregate (RUA) reports - Any past deliverability incidents Audit and harden through these steps: 1. **Inventory senders** — list every legitimate source that sends as our domain. You cannot safely enforce until this is complete; flag any unknown or shadow senders to investigate first. 2. **SPF review** — check the record for accuracy, the 10-DNS-lookup limit, overly broad `+all`/`?all`, and missing senders. Recommend a tightened record ending in `~all` then `-all`. 3. **DKIM review** — confirm each sending source signs with DKIM, key length (>=2048-bit), correct selectors, and a rotation plan. Flag unsigned legitimate sources. 4. **DMARC posture** — read the current policy. Recommend a staged path: `p=none` with RUA reporting → `p=quarantine` with a percentage ramp → `p=reject`, only after alignment is confirmed for all senders. 5. **Alignment checks** — verify SPF and DKIM identifier alignment (relaxed vs strict) so legitimate mail passes DMARC; identify sources that fail alignment and how to fix them. 6. **Reporting & monitoring** — set up RUA/RUF aggregation, interpret the reports to find unauthorized senders, and define the criteria to advance each enforcement step without blocking real mail. 7. **Adjacent hardening** — recommend MTA-STS and TLS-RPT, and BIMI once at `p=quarantine`/`reject`. Output as: (a) a findings table (record, issue, severity, fix), (b) corrected SPF/DKIM/DMARC records, (c) a phased enforcement plan with the metric to watch at each gate, (d) a report-reading guide. Bias toward inventory-before-enforce, staged DMARC ramp-up, and never blocking legitimate mail.