Repairing a decayed setup

The repair runbook in dependency order: inventory every sender, one SPF record, DKIM per sender, alignment, and only then DMARC. Then keep it fixed.

Last updated 19 July 2026

Repairing a decayed email setup is a dependency problem, and the order is the lesson: inventory your senders, then SPF, then DKIM, then Return-Path alignment, and DMARC last. The order exists because DMARC is a policy enforced on top of the other records. Tighten it before every legitimate sender authenticates and aligns, and receivers will quarantine your own newsletter on your instructions. People who repair in the wrong order create the very incident they were trying to prevent.

Step 1: find everything that sends as you

Before touching a single record, list every tool that sends email with your domain in the From address. The ESP, obviously. Also the CRM, the billing system that emails receipts, the support desk, the survey tool, the calendar scheduler, the hiring platform, and whatever the sales team signed up for in 2023 and forgot. In every cleanup I've watched, the inventory turns up at least one sender nobody remembered, and the forgotten one is exactly the one that breaks when DMARC tightens.

Your memory is not the only source. Your existing SPF record is a fossil record of past decisions: every include: names a service someone once authorized, so read it and ask "do we still use this". Your DMARC aggregate reports, if you have any history of collecting them, list every source actually sending as your domain, including the ones you didn't authorize. And the free health check reads your DNS and identifies which sending tools are configured on the domain right now, which regularly surprises people.

Write the list down. Every following step is "for each sender on the list".

Step 2: exactly one SPF record, inside the budget

SPF repair has two failure modes to clear, and both were covered in how SPF records rot. First, the record count: your domain must publish exactly one TXT record starting v=spf1. Two is a permanent error (RFC 7208 calls it permerror) and every SPF evaluation fails from then on. This is not a rare mistake; the most common MailerLite setup failure we see is the SPF include pasted in as a second record instead of merged into the existing one. Merge all mechanisms into one record:

v=spf1 include:mlsend.com include:_spf.google.com ~all

Second, the lookup budget. SPF allows 10 DNS lookups per evaluation; past that, permerror again and the record might as well not exist. Every include: costs at least one lookup, and includes nest. So while you merge, prune: any include: for a tool that isn't on your Step 1 inventory gets deleted. This is where the inventory pays off, because deleting an include is only safe once you know nothing live depends on it.

Keep the qualifier at ~all (soft fail) or -all (fail). Never +all, which authorizes the entire internet.

One scope note before moving on: SPF evaluates the Return-Path domain, and for many ESPs that domain is theirs, which means your root SPF record does nothing for those sends. That's expected. It's also why the next two steps matter more than this one.

Step 3: DKIM signing with your domain, per sender

For each sender on the inventory, turn on domain authentication in that tool's settings so it signs with a d= of your domain instead of the tool's shared domain. This is the step that makes alignment possible, because DKIM's d= domain is what DMARC compares against your visible From.

Prefer the delegated CNAME form wherever the provider offers it: you publish a CNAME like k1._domainkey.yourdomain.com pointing at the provider's key host (Mailchimp's points at dkim.mcsv.net), and the provider manages and rotates the actual key behind it. Delegation means key rotation happens without you touching DNS again, which removes an entire future decay mode. A pasted TXT key works too; it just becomes one more thing that can silently go stale, as how DKIM breaks over time laid out.

Expect friction here. Some tools bury the setting or charge for it on higher plans, and one or two on your list may not support custom-domain signing at all. For that last group you have a real decision: replace the tool, retire it, move its mail to a subdomain with its own policy, or accept that its mail will fail DMARC. Decide now, on purpose, rather than discovering it in Step 5.

Step 4: Return-Path alignment where it's offered

Many ESPs offer a custom bounce domain (sometimes called a custom Return-Path): a CNAME like ckespa.yourdomain.com on Kit that makes the envelope domain yours instead of the provider's. Where it's offered, set it up. It gives you SPF alignment on top of DKIM alignment, and since DMARC passes if either aligned check passes, two aligned legs mean one can break (forwarding regularly breaks SPF) and the message still passes.

Where it isn't offered, don't agonize. Aligned DKIM alone satisfies DMARC. This step is belt and suspenders, which is why it comes after DKIM and not before.

Step 5: DMARC, last and slowly

Only now, with senders inventoried, SPF consolidated, DKIM aligned per sender and Return-Path set where offered, do you touch policy. Publish at _dmarc.yourdomain.com, starting in monitoring mode with reporting on:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none changes nothing about delivery; it makes receivers start sending you aggregate reports. Read them, the way reading DMARC reports taught, and hold at p=none until every source you recognize as legitimate shows as aligned. What we see in practice is that the reports catch the straggler: the sender that claimed to be configured but isn't signing, or the tool that never made the inventory at all.

Then tighten in stages: p=quarantine, optionally ramped with pct= so only a fraction of failing mail is affected at first, and finally p=reject when the reports have been clean for long enough that you trust them. How long is "long enough" depends on your sending calendar; the honest rule is that the reports, and nothing else, tell you when you're ready. The staged path is the standard guidance at dmarc.org for exactly this reason.

Verify from outside, every step

After every DNS change, verify the way a receiver would, and be patient about it. DNS answers are cached for their TTL (time to live), so the old value keeps being served for minutes or hours after your edit. Query public DNS after the TTL has expired, then send a real email through the affected tool to a mailbox you control and read the Authentication-Results header for the verdict.

Do not accept the sending tool's own dashboard as proof. The monitoring lesson covered why the green checkmark is a memory, and repair is where that bites hardest: entering records by hand is exactly when the appended-domain CNAME trap from how DKIM breaks over time strikes. The panel is satisfied. The network is not. If a record you added won't validate, this guide walks the usual causes in order.

Keeping it fixed

You already know from why one-time fixes fail that this repaired state is a high-water mark, not a permanent condition. A few habits protect it.

Change discipline: every DNS edit on this domain gets looked at by someone who knows what the email records are, before it ships. Most decay we see traces back to a well-intentioned edit by someone who had no idea email lived in that zone.

A standing watchlist: keep the record inventory and known-good values from this cleanup written down. The repaired records are now your baseline.

Monitoring: someone, or something, re-checks that baseline on a real cadence and alerts with specifics when it drifts. The monitoring lesson is the spec; Inbox Decay is that spec running as a service, with the re-checking, the real-email grading, the change detection and the break alerts handled for you.

What you know now

Plainly: you now know how email travels, how SPF, DKIM and DMARC actually work and align, how reputation and filtering decide placement, how to read headers and DMARC reports like evidence, how setups decay, and how to repair one in an order that won't backfire. That is working deliverability knowledge. You can hold your own in any deliverability conversation, including the ones where an agency is quoting you four figures for the contents of Step 2.

Two things remain. Run the health check on your own domain and do the runbook for real. And decide who watches it afterwards, because the one guarantee this course can make is that the fix will not stay fixed on its own. If the answer isn't you with a cron job, that's the product. Next, verification grows into its own discipline: proving fixes from the outside.

Terms from this lesson

sender inventory - the written list of every tool sending email as your domain; the required first step because every later repair is performed per sender.
lookup budget - SPF's limit of 10 DNS lookups per evaluation; exceeding it is a permerror and effectively deletes your record.
delegated DKIM - publishing a CNAME that points at the provider's key host so the provider rotates keys without you editing DNS again.
custom Return-Path - an ESP feature putting your domain in the envelope address, which earns SPF alignment alongside DKIM alignment.
staged rollout - tightening DMARC stepwise (p=none, then p=quarantine, then p=reject); you advance only when aggregate reports show all legitimate mail aligned.
TTL (time to live) - how long DNS answers are cached; until it expires, resolvers keep serving the old value, so verification must wait it out.
change discipline - the practice of having an email-aware reviewer look at every DNS edit before it ships.

Check yourself

1. Why does DMARC come last in the repair order?

2. You need to add an SPF include for a new tool and your domain already has an SPF record. What do you do?

3. What is the correct first DMARC record for a domain mid-repair?

4. After editing a DNS record, what counts as verification that the fix worked?