How to roll back a DNS change that broke a client's email

Evidence to collect

Open one incident record per affected client domain. Keep the observed failure separate from the suspected DNS cause. A user report that mail stopped arriving identifies impact, but it does not identify the responsible record.

Palisade DNS History is available from the Domain Overview gear menu. It shows a timeline of DNS-record snapshots and supports filters for SPF, DMARC, BIMI, MX, DKIM, and NS records, with date windows from 14 to 60 days. Consecutive snapshots can be compared in a diff view to identify the changed record type, value, and snapshot time.

Use this portable record in a ticket, PSA, or client incident log:

client: example-client
domain: yourdomain.com
evidence: "DNS History diff and redacted delivered-message result"
owner: "MSP incident lead"
next_action: "Client approves restoration of prior SPF TXT value"
review_on: "2026-11-06"

Also retain:

• The full current record value and the prior known-good value.
• The record name and type.
• The time the change appeared and the time the email symptom began.
• The affected sender, recipient, and business process, without copying private message content into a shared portfolio record.
• The DNS-provider account owner and client approval status.
• The rollback trigger and the same-path retest required after restoration.

How to run the workflow

1. Contain and classify the incident

Owner: MSP incident lead. Input: client report, ticket, or observed message symptom. Output: a scoped incident record.

Record the affected domain, sender path, first-known failure time, and business impact. Ask whether a DNS change was made near that time, but do not call it causal yet. If the issue is limited to one sender, retain that sender's ownership and request a redacted delivered-message result after the DNS record is checked.

2. Compare the DNS history

Owner: MSP incident lead. Input: affected domain and incident time window. Output: a specific rollback candidate or an unresolved DNS hypothesis.

In Palisade DNS History, filter to the relevant record type and compare consecutive snapshots. The documented view shows the snapshot date and time, record type, record value, and diff. Identify the smallest change that could reasonably be reversed.

For example, an SPF rollback candidate is a complete prior TXT value, not a manually reconstructed subset:

Illustrative only. Do not publish this as a production record.

yourdomain.com. IN TXT "v=spf1 include:spf.example.net -all"

DNS History identifies an earlier value. It does not document a one-click restoration of that value, so perform the actual mutation through the DNS provider's approved process.

3. Obtain client authorization and prepare the change

Owner: client approver and DNS administrator. Input: rollback candidate, impact record, and validation plan. Output: approved provider-side change.

Present the current and proposed values, exact record name, reason for restoration, expected test, rollback owner, and time of approval. If the domain has an active DNS connection, Palisade DNS Connections shows current and proposed values side by side before publishing an email-authentication record.

Do not merge records to make a rollback fit. Palisade stops on conflicts such as “Two SPF records at a name, or a CNAME sitting beside a TXT, is a conflict. Palisade reports it and stops.” A publish requiring removal displays “Will delete N records” and starts unticked, so record deletion needs explicit review.

4. Restore the last known-good value

Owner: authorized DNS administrator. Input: approved prior record value. Output: provider-side confirmation that the record was changed.

Restore only the approved record at the affected name. Save the provider confirmation and the prior value in the incident ticket. Do not claim the client is recovered at this stage. The available documentation does not establish a universal propagation duration or provider-specific restore procedure.

5. Verify the live DNS answer

Owner: MSP incident lead. Input: restored value and provider confirmation. Output: recorded live-DNS verification.

Use Palisade DNS Records to inspect the raw DMARC, SPF, DKIM, MX, BIMI, MTA-STS, and NS values Palisade currently sees. It is accessed from the Domain Overview gear menu and supports a post-change propagation check. Independently, use the DNS lookup tool to inspect the public result.

A public DNS result does not prove that the production sender uses the expected configuration, that every resolver has updated, or that a mailbox provider will deliver future mail.

6. Retest the affected mail path and close deliberately

Owner: sender owner with MSP incident lead. Input: a new message sent through the same production path. Output: recovery evidence or escalation.

Send a new test through the sender and recipient path that exposed the incident. Compare the new result with the original symptom where available. If the original issue involved a changed SPF authorization, verify the sender path rather than treating a visible TXT record as a complete delivery test.

Close the rollback only when the record is visible, the affected path has been retested, the client has received the result, and any remaining uncertainty is recorded.

Investigate this with your coding agent

Use this when the client's DNS records or infrastructure-as-code definitions are version controlled and you need a read-only comparison before proposing a rollback. Prepare redacted record names, record values, commit references, and approved verification queries.

Exceptions and escalation

Escalate instead of restoring a record when the evidence does not isolate one safe candidate.

• No known-good value: ask the DNS owner for change records or provider history. Do not reconstruct a record from memory.
• Multiple records changed: prepare separate candidates and require client approval for each mutation.
• DNS is correct but the same message path still fails: hand off to the sender owner or mailbox-provider evidence path. DNS evidence alone has reached its limit.
• A record conflict appears: stop and investigate. Do not remove TXT or CNAME records merely to make a proposed value publish.
• Client approval is unavailable during a business-critical incident: follow the contracted incident authority. If no delegated authority exists, preserve evidence and escalate to the client approver.
• The incident affects several tenants: keep evidence, approvals, and proposed changes isolated by client domain.

Reporting and success measures

Report rollbacks in the monthly service review as controlled incidents, not as proof of universal email health. Include the client domain, suspected record type, time discovered, approved change, evidence used, validation status, and any unresolved sender or receiver dependency.

Useful portfolio measures include:

• Incidents with a complete before-and-after DNS record.
• Rollbacks that had documented client approval.
• Incidents with a same-path message retest after DNS verification.
• Open incidents where ownership or a known-good value is missing.
• Repeated changes to the same record name.

Standardize DNS rollback control across clients

A DNS-history view and a consistent incident record help an MSP identify changes without mixing client evidence or granting blanket change authority. Explore Palisade for managed service providers to assess whether its domain monitoring, DNS history, and DNS connection workflow fit your portfolio process.

Palisade can show DNS history and current records, and it can present proposed values before an approved publish. It does not restore arbitrary historical snapshots automatically, authorize client changes, prove every sending path, or control a receiving mailbox provider's final decision.