How to Audit SPF, DKIM, DMARC on a Burned Email Domain
Before deciding whether to recover or replace a burned domain, you need to understand what's actually broken. Here's the complete auth audit process.
You have a domain that was previously used for cold email and developed a bad reputation. Before you decide whether to try to recover it or replace it, you need to audit its current authentication status to understand whether configuration issues are contributing to the problem or whether it's purely a reputation issue.
Why This Matters
When a domain is burned, it's tempting to assume everything is broken. But sometimes a burned domain has clean authentication and the problem is entirely reputation-based. Other times, authentication was misconfigured from the start and contributed to the burn. Knowing which situation you're in determines your recovery strategy.
SPF Audit
Use the SPF checker. Confirm exactly one record starting with "v=spf1" exists. Verify the record includes all current sending services. If you used to send through Service A but now only send through Service B, remove Service A's include.
Count DNS lookups. If you're at or above 10 lookups, you need to flatten. Check for common errors: multiple SPF records, exceeding 10 lookups, using deprecated mechanisms like "ptr", missing includes for current sending services.
DKIM Audit
Use the DKIM checker — it auto-discovers which selectors are published. Confirm at least one DKIM record exists for your current sending infrastructure. Check key length — a minimum of 1024 bits is required for Gmail, 2048 is recommended.
Verify that DKIM signing is actually enabled on your sending server, not just that the DNS record exists. Send a test email and verify DKIM: PASS in the headers. Check that the d= value in the DKIM-Signature matches your From header domain.
DMARC Audit
Use the DMARC lookup. Confirm the record exists at _dmarc.yourdomain.com and is properly formatted.
Check the policy (p= value). If it was set to p=quarantine or p=reject, verify that all legitimate mail is properly authenticated before keeping a strict policy on a recovering domain.
Verify that rua and ruf reporting addresses are set up so you receive DMARC reports. These reports show who is sending email as your domain and whether they pass or fail authentication.
Cross-Check
Run a placement test from each sending service you use and check headers for all three: SPF PASS, DKIM PASS, DMARC PASS. Every sending source must pass all three.
Run the blacklist checker on the domain and sending IP to understand the reputation situation separately from authentication. Run the burn score calculator to get an overall assessment.
The Fix Path
Fix any configuration issues found during the audit. Update SPF, publish correct DKIM keys, ensure DMARC is valid.
Once authentication is confirmed clean, the recovery question becomes purely about reputation. Clean authentication on a burned domain won't instantly fix deliverability, but it removes one set of problems and lets you focus on the reputation rebuild.
When to Replace Instead of Repair
If the audit reveals significant authentication problems alongside reputation damage, fixing authentication is the first step. Without clean authentication, no reputation recovery effort will work.
If authentication is already clean and the domain is burned purely due to reputation, the decision is whether to invest 4–8 weeks in reputation recovery or to replace with clean infrastructure. For time-sensitive campaigns, WarmInboxes provides domains that are already audited, authenticated, and warmed — eliminating the need for both the audit and the recovery process on the new infrastructure.
Mistakes That Make This Worse
- Starting a reputation recovery effort without first verifying authentication is clean
- Assuming authentication is fine because it was set up months ago
- Not checking all sending sources (your outreach tool, your email provider, any transactional email services)
- Changing DMARC policy to p=reject on a burned domain without verifying all sources pass authentication first
Run the checks first
Before replacing anything, run a free inbox placement test. You might find the issue is DNS, not the domain — and save yourself a week of unnecessary work.