When inbox placement slips, most teams open three tabs at once: SPF, DKIM, and DMARC. That instinct is understandable. Receivers treat authentication as the floor, and a broken floor shows up as spam folder placement, soft failures, or sudden drops that feel like they came from nowhere. The mistake is treating the three records as a single blob to rewrite under pressure. They are related, but they fail for different reasons, and the order you fix them in matters for both safety and signal quality.
Start by deciding whether authentication is actually the problem. Pull a handful of failing messages through a header inspector or a seed test and look at the Authentication-Results line. You want to know whether SPF passed, whether DKIM passed, whether either was aligned with the From domain, and what DMARC disposition the receiver applied. If SPF and DKIM both pass with alignment, rewriting DNS will not save you. Your issue is further up the stack: reputation, stream mixing, complaint rate, or content that looks like bulk mail to the filters. Stop there and work those problems. Authentication work done on a healthy auth stack is just churn.
When auth really is broken, fix DKIM first. DKIM is the signature the message carries, and it is the alignment path most production senders rely on once they leave a shared ESP or a multi-hop relay. SPF breaks easily under forwarding, mailing lists, and any path where the envelope sender no longer matches the domain that published the SPF record. DKIM survives those hops if the body and signed headers stay intact. Practically, that means confirming the signing key is present in DNS, the selector in the message matches the published record, the private key on the sender still matches that public key, and the From domain aligns with the signing domain (or with a parent that DMARC accepts). Rotate a compromised or orphaned key before you touch policy. A team that flips DMARC while DKIM is half-deployed is volunteering for quarantine on their own mail.
SPF comes second, and only after you know which hosts are supposed to send. List every system that injects mail for the domain: the transactional platform, the CRM, the support tool, the billing provider, the monitoring alerts, the odd script someone left on a jump host. Then publish an SPF record that covers those hosts and nothing else. The common failure mode is an SPF record that grew by accretion until it hit the ten-DNS-lookup limit, or a record that still authorizes a vendor you stopped using two years ago. Keep the record short. Prefer IP literals or carefully chosen includes over a chain of nested includes you do not control. If you cannot fit legitimate senders into one SPF record without blowing the lookup budget, the domain is doing too much work on one identity and you should split sending domains rather than invent a clever SPF.
DMARC is last on purpose. DMARC does not authenticate mail by itself. It tells receivers what to do when SPF and DKIM both fail alignment, and it gives you aggregate reports about who is sending as you. Publishing p=none with a rua address is the safe first move when you are unsure of your senders. Read those reports for a stretch before you tighten policy. You will usually find forgotten tools, regional subsidiaries, and the occasional forger. Clean those up, confirm DKIM alignment on the streams you care about, then move to quarantine, then to reject once the report noise is gone. Jumping straight to p=reject because a checklist said so is how password resets and invoice mail get held while you scramble.
What to check while you wait for DNS
DNS changes are not instant, and receivers do not all honor TTLs the same way. Plan for a lag measured in hours, sometimes longer on stubborn resolvers. During that window, keep sending volume steady. Do not also rotate IPs, change From domains, or launch a campaign. You want one variable in flight. Watch bounce classes and complaint rates, not vanity open rates. If placement was already bad, expect reputation recovery to lag auth repair by days or weeks. Auth makes you legible. It does not automatically make you trusted again.
A useful mid-repair check is to send the same transactional template to Gmail, Microsoft 365, and a Yahoo or consumer account you control, then compare Authentication-Results across the three. If DKIM aligns everywhere and DMARC disposition is pass, the plumbing is done. If one receiver still fails SPF while DKIM passes, that is often forwarding or an envelope quirk, not a reason to rewrite SPF again. Chase the failure that actually drives DMARC disposition for your From domain.
Where teams usually waste the week
The first waste is rewriting SPF every time a vendor support article mentions it, without checking whether DKIM already aligned. The second is publishing DMARC reject before the billing or support tool is signed. The third is treating BIMI, brand indicators, and fancy DNS add-ons as part of the outage response. Those are later. The fourth is diagnosing a mixed stream as an auth problem. If password resets and a weekly newsletter share a From domain and an IP pool, fixing DMARC will not separate their reputations. You still need stream isolation.
There is also a quieter failure: multiple selectors and half-retired keys left in DNS "just in case." Receivers do not care how many keys you publish, but your own team will eventually sign with the wrong one during an incident. Keep one active selector per signing system, document who owns the private key, and remove selectors that have not signed mail in a long time.
If you want a short operating sequence for the next bad week, use this. Confirm the failure in headers. Repair DKIM alignment on every production sender. Rebuild SPF from an inventory of real injectors. Publish or correct DMARC at none with reporting. Read reports, remove unknown senders, then tighten policy. Only after that sequence is clean should you spend time on reputation recovery, warm-up schedules, or content changes. Authentication is the floor. Build it in an order that does not drop your own mail through the boards while you work.