From DMARC question to closed ticket, without leaving Claude

Palisade's MCP server now covers the whole remediation loop. An agent can read what DMARC aggregate reports say about a domain, name the sender that is failing, open the ticket Palisade already wrote for it, apply the fix through its own DNS access, verify the result, and close the ticket. This post walks that loop on a real domain, with the exact prompts and tool calls, so you can reproduce it on your own account.

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

Palisade runs a remote MCP server at https://api.palisade.email/mcp. In Claude, add it as a custom connector: paste the URL, and when the browser opens, sign in to your Palisade account. There is no API key to create first; the server answers the first call with an OAuth challenge and your client handles the rest. Setup for Claude Code, Cursor, and clients that only speak stdio is on the MCP page.

Every tool is scoped to the organization you signed in with. The agent sees your domains and nobody else's.

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 with expand: ["instructions"] returns the ticket in full: the task type (source_failing_spf), what is going wrong and for whom, and the remediation Palisade worked out. For Salesforce the fix is one change: add include:_spf.salesforce.com to the domain's SPF record. The task also links Salesforce's own documentation for the record, so the value is checkable against the vendor, not taken on trust.

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, or to any MCP client you use.
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.
Apply the record through your own DNS tooling, verify with verify_domain, and close 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 with expand: ["instructions"], show me the fix, 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.

The MCP server works on every plan, including the free one, so the loop above runs before any payment conversation happens.