How to Find and Fix Orphaned SPF Records on Abandoned Campaign Mail Subdomains

The problem nobody watches for

A marketing campaign ends. The staffer who ran it leaves the company. Their campaign subdomain, something like offers.yourdomain.com or newsletter.yourdomain.com, still has an SPF record in your DNS that points to the ESP they used. SendGrid, Mailchimp, Amazon SES - it does not matter which. What matters is that nobody is watching that subdomain anymore.

That is the problem with orphaned SPF records. The account that was sending mail through that ESP is closed, transferred, or simply abandoned. The DNS record still exists and still passes SPF checks for that ESP. If somebody gains access to that ESP account - or if the ESP reuses the sending domain for another customer - your domain can be used to send mail that SPF says is legitimate. No matter what your DMARC policy on the parent domain says.

This is not a theoretical risk. It is a specific operational gap that shows up in DMARC aggregate reports as a source IP you do not recognize, sending mail that claims to be from your subdomain.

How to find orphaned SPF records

There are three practical ways to find them. Not all are equally fast.

Method 1: DMARC aggregate report review

Your RUA reports show every source IP that has sent mail claiming to be from your domain in the reporting period. The manual version: cross-reference each IP against your known ESP list and your own mail servers. Any SPF pass from an unrecognized IP is worth investigating.

The faster version: DMARCFlow's ESP auto-detect cross-references every source IP in your RUA reports against a registry of known ESPs. When it finds an SPF pass from an ESP you have not registered - including one you decommissioned - it flags it as an esp_misconfigured alert, linked to the specific subdomain and the unexpected ESP. This fires without you having to manually compare IP lists against a spreadsheet every time a report arrives.

The specific signal to look for manually: an SPF pass from an IP that resolves to an ESP domain you no longer use, or that you have no record of ever onboarding. For example, if your reports show mail authenticated through includespf.mailchimp.com but you have no active Mailchimp account, that subdomain has an orphaned SPF record pointing to a closed account.

This method catches subdomains that are actively sending. It will not catch subdomains that have gone silent but still have live DNS records.

Method 2: DNS TXT record audit

List every TXT record on every subdomain that has ever sent mail. Look for records containing include: mechanisms that point to third-party ESPs. For each one, verify that the ESP account is still active and that the subdomain still needs to send mail.

This catches both active and silent orphaned records. It is more thorough but slower if you have many subdomains. A script that pulls all TXT records and filters for known ESP vendor domains makes this much faster.

Method 3: Staff offboarding review

Map former employees to the subdomains they created or managed. For each mapping, confirm that the subdomain still has a valid business owner and that the associated ESP account is still active and still needed. If the person who created the subdomain no longer works there and nobody handed over ownership, treat that subdomain as a likely orphan.

This method catches the root cause - subdomains created ad hoc without proper handover documentation.

All three methods together give you the cleanest picture. RUA reports tell you what is actively sending. DNS audits tell you what is still configured. Offboarding reviews tell you what nobody is watching.

How to fix orphaned SPF records

Once you have identified the orphaned subdomains, the fix depends on what you want to do with the subdomain.

If the subdomain no longer needs to send mail: remove the SPF record entirely. If the subdomain also has a DKIM record, remove that too. A subdomain that is not sending mail has no reason to have authentication records pointing to an active ESP. Leaving those records in place is pure attack surface.

If the subdomain still sends mail but through a different ESP now: update the SPF record to point to the current ESP, or to nothing if the subdomain is switching to a purely DKIM-aligned setup. Do not layer new ESP include mechanisms on top of old ones - start clean.

If the subdomain must keep sending through its current ESP but the ESP account was compromised or abandoned: the immediate fix is to update the SPF record to ~all (softfail) or -all (fail) while you investigate the exposure scope. Then close or recover the ESP account, verify no unauthorized mail was sent, and update the SPF record to the correct configuration before tightening the policy back to -all.

Regardless of the approach, document the change. Update your ESP register with the current SPF configuration for each subdomain. That register is what makes the next offboarding review faster.

How to monitor so this does not happen again

The reason orphaned SPF records accumulate is that nobody is watching the subdomains that nobody is watching. The moment a campaign ends or a staffer leaves, those subdomains fall off the operational radar. DMARC monitoring on all subdomains that send mail is the baseline control.

Beyond that, the specific monitoring that catches this class of problem automatically is detection for when a subdomain's SPF resolves to an ESP that is not registered in your account. DMARCFlow's esp_misconfigured alert type is designed exactly for this scenario. When a subdomain's SPF record points to an ESP you have not onboarded - or that you have since decommissioned - the alert fires and points you to the specific subdomain and the unexpected ESP. Without automated monitoring of your ESP registry against RUA source IPs, you are relying on the next manual DMARC report review to notice an unfamiliar source IP. Forgotten subdomains do not announce themselves. DMARCFlow's esp_misconfigured alert closes that gap by comparing current sending sources against your registered ESP list and alerting when a subdomain is sending through an ESP you have not onboarded or have since decommissioned.

Add orphaned subdomain checks to your staff offboarding checklist and your campaign end checklist. When an ESP account is closed, that is the moment to audit the DNS records for the subdomains that used it, not weeks later when the next quarterly review happens.

FAQ

Can a subdomain-level SPF record override a parent domain DMARC policy?

No. A subdomain SPF record and the parent domain DMARC policy work independently. A p=reject policy on example.com does not automatically reject mail from subdomains.example.com if that subdomain has its own SPF record that passes. Each subdomain that sends mail needs its own aligned authentication (SPF, DKIM, or both) to pass the parent DMARC check. If the subdomain SPF passes but DKIM is not aligned, the mail fails DMARC unless the policy is p=none. This is why orphaned subdomain SPF records are dangerous even when the parent domain has a strict DMARC policy.

Does removing the SPF record break mail if the subdomain is still sending?

It will. Removing an active SPF record from a subdomain that is still sending mail through an ESP will cause SPF failures for that subdomain. Always verify that the subdomain is not sending before removing its SPF record. If you are not sure, set the SPF record to ~all (softfail) first and monitor for a few days before removing it entirely.

What is the risk if the ESP account is still active but nobody is using it?

An active ESP account with no owner is a credential theft risk. If the account uses a weak password, no MFA, or an old API key that was never rotated, an attacker who discovers the account can send mail as your subdomain. The SPF record will pass because it still points to that ESP. This is why staff offboarding for ESP accounts matters as much as DNS hygiene.