What to Do When You Inherit a Domain with a Bloated SPF Record and No DKIM Keys

You took over a domain. The SPF record has 14 includes. The DKIM selector for a vendor that went out of business three years ago still has a record in DNS. Your DMARC report address is a Gmail account that stopped receiving mail in 2022.

Welcome to domain inheritance.

This is a common situation after acquisitions, managed migrations, or when the previous IT team left without documentation. The mail is still mostly working, but you have no idea what is actually validating and what is not. Here is how to audit and fix it without taking mail offline in the process.

What you typically find

When you audit an inherited domain's email authentication, the pattern is consistent:

• SPF record with 10 or more includes, sometimes exceeding the 10 lookup DNS limit
• Multiple DKIM selectors, some for services that were decommissioned
• DMARC record pointing to a report address that stopped receiving mail years ago
• No one who can explain what half the includes actually do

The first thing to understand is why each of these is a problem.

Why bloated SPF is a real risk

SPF has a hard limit: when a receiving mail server checks your SPF record, it follows includes and mechanisms recursively. RFC 7208 specifies a maximum of 10 DNS lookups before the check must fail with a permanent error.

Large organizations routinely exceed this. When that happens, some receivers accept mail anyway, treating the softfail as a pass, and some reject it. Your deliverability becomes unpredictable, and you will not always know why.

The fix is flattening, replacing includes with IP ranges where possible, consolidating vendors, and removing dead includes. But you cannot delete everything and rebuild overnight. You need to audit first.

Why orphaned DKIM selectors cause silent failures

DKIM signs outbound mail with a private key. The receiving server looks up the public key at the selector domain and verifies the signature.

If a DKIM selector exists for a discontinued service, a vendor you stopped using, or an old internal system, and the private key is gone but the DNS record remains, you have an orphaned DKIM selector. Most receivers ignore selectors they cannot verify, so it usually does not cause direct failures. But it creates noise in your DMARC reports and means you are not getting credit for email that could be DKIM authenticated.

More problematically, if a DKIM selector exists for a key that an attacker might have, and they can generate valid signatures, that is a potential abuse vector.

Step 1: Audit before you touch anything

Before changing anything:

1. Check your DMARC aggregate reports, your rua address has been receiving data, even if no one looked at it
2. Run your SPF record through an SPF checker to count actual DNS lookups
3. List all DKIM selectors in your DNS, look for selector._domainkey.yourdomain.com records
4. Cross-reference with DMARC report data to see which selectors are actually signing mail

This gives you a real map of what is active and what is not. Do not skip it. This cross-referencing step is where raw XML reports fight back hardest, DMARCFlow parses your aggregate reports and lays out every sending source, SPF result, and DKIM selector in a readable view, so building that map of what is actually active becomes something you read rather than something you reverse-engineer.

Step 2: Clean up SPF

For each include in your SPF record:

• Still in use: keep it
• Service discontinued: remove it
• Vendor sending on your behalf: consider whether they should use a subdomain with their own SPF instead of yours

Run an SPF lookup checker after changes to confirm you are under 10 lookups.

If you are still over 10, look for includes that chain to other includes. Those count double toward your limit and are a common culprit.

Step 3: Find or rotate DKIM keys

For each DKIM selector:

• Active and working: verify the private key is still accessible
• Service gone: remove the DKIM record from DNS
• Unknown: check DMARC reports for DKIM failures tied to that selector

For selectors where you cannot confirm key security, rotate: generate a new key pair, update DNS with the new public key, verify signing works, then remove the old record.

Step 4: Fix DMARC reporting

While cleaning up:

• Is the rua address actually receiving reports?
• Is the policy still p=none? Normal during cleanup, but have a plan to move to p=quarantine

If your reports stopped, update the rua address to something you actually monitor. DMARC reports are the evidence source for the entire cleanup process.

Step 5: Validate without breaking mail

Before pushing changes live:

1. Set up a test mailbox at an external provider such as Gmail or Fastmail
2. Make your DNS changes
3. Send test messages and check headers for SPF, DKIM, and DMARC results
4. Review your DMARC reports for unexpected failures

The long-term safety net

Once SPF and DKIM are clean, p=none DMARC shows you exactly what is happening with your mail. Moving to p=quarantine becomes low-risk when you have visibility, because you see failures before they become hard rejections.

This is what DMARCFlow is built for, it parses your DMARC aggregate reports and alerts on sudden changes in pass/fail rates, so the next inheritance mess, a vendor quietly breaking, a selector going dark, mail starting to fail, surfaces as an alert instead of a deliverability incident you find out about weeks later.