Fix DMARC with Claude: a Salesforce SPF walkthrough

This walkthrough shows how to fix DMARC with Claude: diagnose Salesforce SPF failures on crunchybagels.com using Palisade, review the proposed record, approve its publication through a separate Cloudflare connector, then verify the result and close the ticket. The prompts and tool calls below follow that worked example; Palisade MCP setup covers connecting a supported client.

The domain is crunchybagels.com, a test domain we send real mail from. Its DMARC policy is p=none, it sees about 13,000 messages in a two week window, and at the start of this run it had an open ticket: mail sent through Salesforce was failing SPF.

Connect Claude to Palisade

Follow the Claude connection instructions on Palisade's MCP setup page before starting. The setup uses Palisade's registered public OAuth client; a URL alone is not sufficient. Sign in and select the organization whose domain you want to troubleshoot.

Private account data stays within that organization. Public DNS tools can inspect other domains without accessing another account's private data. This walkthrough uses reports and tasks for a domain already in the selected account.

Ask the question you would ask a person

The first prompt is the one an operator actually types:

Who is failing DMARC on crunchybagels.com?

Claude resolves the domain with list_domains, then calls two tools that read the DMARC aggregate reports Palisade has been collecting:

get_dmarc_summary returns the reporting window's message volume, DMARC, SPF, and DKIM pass rates, the change against the window before it, and the domain's open tickets.
list_dmarc_senders returns every source seen sending as the domain, ordered by volume, each with its own pass rates and compliance breakdown.

The distinction that matters: these numbers come from what receiving servers reported, not from a record lookup. That is why the list includes senders nobody configured and senders Palisade cannot identify. Those unknowns are usually the interesting rows.

For crunchybagels.com the answer came back specific. Overall SPF pass sat around 85 percent while DKIM passed in the high nineties, and the sender dragging SPF down was Salesforce. The entry for Salesforce carried is_failing: true and one more field that shapes everything after it: open_task_id.

The finding is already a ticket

Palisade's monitoring had noticed the failing source before anyone asked, and had opened a remediation task for it. So the agent does not go off and design a fix. It follows the pointer:

Open that task and show me the fix.

get_task returns the ticket type (source_failing_spf) and its description. Use that context to identify the affected sender, then check the sender's current SPF guidance before proposing a record change. The optional expand: ["instructions"] currently supplies expanded instructions for failing DKIM tasks; it does not return an SPF remediation payload.

In this Salesforce example, the proposed change was to add include:_spf.salesforce.com to the domain's existing SPF record. Confirm the include against the sender's documentation and check the complete record and lookup budget before approving it.

The agent applies the fix with its own DNS access

Here is the part we want to be precise about. Palisade has no tool that writes DNS at your provider, and it never holds your registrar or DNS credentials. The MCP server hands the agent the exact record; the write happens through whatever DNS access the agent already has.

In this run, crunchybagels.com is on Cloudflare, and Claude has a Cloudflare connector of its own. So the same conversation continues:

Apply it with the Cloudflare connector.

Claude reads the current SPF TXT record, adds the include, and writes it back through Cloudflare's API, using credentials that belong to us, granted to our agent, revocable by us. Palisade is not in that exchange at all.

If you work in the Palisade app instead of an agent, the publish step lives there too: Smart DNS Deployment writes the records you approve into your own zone, after you authorize the connection in your DNS provider's own window. The rule is the same in both places. Your DNS stays yours.

Verify, then close

Trust nothing, including the agent. The next prompt:

Verify the domain and close the ticket if it checks out.

verify_domain re-reads live DNS and confirms the published record is what Palisade expects. Then complete_task closes the ticket.

Closing is honest by construction. complete_task records that the work is done; it does not make anything true. If an agent closes a ticket over a domain that still fails, the next monitoring sweep reopens it. The loop ends when DNS says so, not when someone says so.

Why a ticket, and not a wizard

Most tools in this space run a setup wizard. You hand over a registrar or DNS provider API key, the wizard writes your records, and the product's active involvement ends there. Two things follow from that design. A third party now holds standing write access to your DNS, and the help stops at the moment setup finishes, which is exactly when the real work starts: reports keep arriving, senders get added by someone in marketing, records drift.

Palisade is built the other way around. Monitoring is the product. It keeps reading your aggregate reports, notices drift and new senders, and turns each finding into a ticket that already carries its fix. The MCP server is the interface that lets the agent you already use pick those tickets up and finish them, with your own DNS access, under your own approval rules.

Run it on your domain

Connect Palisade's MCP server to Claude, using the supported client instructions.
Ask "who is failing DMARC on my domain?" and let get_dmarc_summary and list_dmarc_senders answer from your reports.
For any failing sender, open the attached task with get_task and read the fix.
Review and approve the exact change before applying it through your own DNS tooling, verify with verify_domain, and approve closing the task with complete_task.

If your agent is already connected, this prompt starts the loop:

Agent handoff

Copy the prepared prompt

Give this to a coding agent that can inspect the relevant repository or configuration source of truth.

Who is failing DMARC on my domain? Use Palisade's get_dmarc_summary and list_dmarc_senders on the last 7 days. For each failing sender with an open task, open the task, check the sender's current instructions, show me the proposed fix and evidence, and wait for my approval before changing any DNS.

Human approval required: Review the proposed diff and verification plan before allowing changes. Do not paste secrets, private keys, API tokens, unredacted headers, or customer data.

MCP access is available on every plan, including Free. The reports, history, and remediation features available through it still follow the selected account's plan limits.