Palisade

Check the status of any domain's email authentication from live DNS in one call: MX, SPF, DKIM, DMARC, BIMI, MTA-STS and TLS-RPT, each with a verdict and the records behind it, plus a score out of 100. Use it to answer "is DMARC set up on example.com", "how bad is this domain" or "what does this vendor publish". Unlike the rest of this server it takes a domain name rather than a domain id and works on domains that are not in the caller's Palisade account, so it also sizes up a domain before adding it. It reads public DNS only and writes nothing. For a domain already in the account prefer get_domain (by id or by url) and get_dns_records, which additionally know what Palisade is publishing and what it expects; and read list_tasks before acting on anything found here, because Palisade usually has worked-out instructions for a problem it already knows about. Results are cached for ten minutes per domain, so re-calling it will not show a DNS change published seconds ago.

audit_domain

Summarize what DMARC aggregate reports say about a domain over a recent window: message volume, DMARC/SPF/DKIM pass rates, the compliance breakdown, and the change against the immediately preceding window of the same length (so the default 7-day period is a week-over-week comparison). Also returns the domain's DMARC policy, whether Palisade currently recommends tightening it, and the open remediation tasks for the domain. Pass rates here are computed over all reported volume including forwarded and uncategorised traffic, so they read lower than the last_14_days figures get_domain returns, which count only compliant and non-compliant mail; the payload carries both so the difference is visible. When this surfaces a problem, do not design a fix: policy_readiness and every entry in open_tasks carry a task id, and get_task with expand: ["instructions"] returns the steps Palisade has already worked out for it.

get_dmarc_summary

Get the DNS records to publish for a domain: purpose (dmarc, spf, dkim, mta_sts, mta_sts_policy, tls_rpt, bimi), record type, host (absolute and relative to the apex), value, recommended TTL, required action (create, replace, or delete), whether the record is required, its live verification status, and already_published. Palisade does not create these records for you — apply each one yourself at the domain's DNS provider using your own DNS tool, connector, or that provider's API; the records are portable, so any DNS integration works. The response also includes dns_provider, resolved from the domain's live NS records: dns_provider.id names the DNS host (for example cloudflare, route53, godaddy, azure, google) and dns_provider.nameservers lists the nameservers it was derived from. If you have a DNS tool or connector for that provider, prefer it and publish the records yourself end to end; note this is the DNS host, which is often not the domain's registrar. When dns_provider.id is null (unknown, mixed, or unresolvable nameservers) do not guess a provider — check dns_provider.nameservers for a tool you do have, and otherwise hand the records to the user to publish. Skip every record where already_published is true — it is already live with exactly this value. For the rest, use the action field to reconcile (create a new record, replace an existing one of the same host/type, or delete the record) and preserve the given TTL. already_published is null when the live lookup could not be completed, in which case treat action as a best-effort hint and publishing is safe but may be redundant. Then call verify_domain; all_verified is true once every required record is verified. IMPORTANT: check the warnings array before applying anything — it is normally empty, but a warning means publishing the records as-is could break the domain's mail. Relay any warning to the user and get confirmation rather than applying silently. Note also that SPF and DKIM records only appear here when Palisade hosts them; their absence does not mean the domain needs none — get_spf reads the domain's live SPF state either way.

get_dns_records

Get the MTA-STS state for a domain: whether Palisade-hosted MTA-STS is enabled, the policy mode, MX list, and the DNS targets to publish.

get_mta_sts

Read the live SPF state of a domain: the record DNS actually serves, how many DNS lookups it costs receivers against SPF's limit of 10, a breakdown of every include/a/mx/ptr/exists/redirect lookup with what each accounts for (terms receivers never reach are not counted: anything to the right of a matching all, and a redirect= in a record that also carries an all), and the problems found — a record over the lookup limit, more than one v=spf1 record (which receivers reject outright), includes that no longer resolve, loops, and unsafe all mechanisms. Purely diagnostic: it changes nothing, and it reads the domain's live DNS rather than Palisade's stored state, so it works the same whether or not Palisade hosts the record. When a problem shows up, check list_tasks before designing a fix — Palisade usually opens a task with worked-out instructions, and an SPF change made against that guidance is how a working domain stops delivering mail. A record over the lookup limit is what Palisade-hosted SPF flattening solves: set target_spf with update_domain and Palisade flattens the record and serves it from a single include, which get_dns_records then returns for publishing.

get_spf

Get the Palisade organization (account) you are signed in to: name, contact details, and settings.

get_account

Check the status of a domain in your Palisade account, by id or by name: the managed DNS status of each record (SPF, DKIM, DMARC, BIMI, MTA-STS), monitoring status, DMARC policy, score, and 14-day pass rates. This is the tool for "what is the DMARC status of example.com" when the domain is in the account; pass url to look it up by name without calling list_domains first. The response carries the domain id every other domain tool takes. For a domain that is not in the account, use audit_domain, which reads its live DNS instead.

get_domain

Get a single task by id. Use expand: ["instructions"] to include provider-specific fix instructions when the task supports them.

get_task

Answer "what happens next on this domain" rather than "what is open right now". Returns the four stages of the DMARC journey - setup, alignment, enforcement, monitoring - with where the domain stands in them and the steps each stage is made of, and upcoming_steps as the shortlist of what Palisade works next. A step already backed by tasks carries their ids in task_ids, so pair it with list_tasks: list_tasks is what can be actioned today, this is the road it is on and what completing it is worth against the audit score. Read-only and computed from stored state plus one cached DNS read, so it changes nothing and opens nothing.

get_domain_plan

List the sources sending mail as a domain, built from DMARC aggregate reports and ordered by volume. This is what receivers actually saw, so it includes senders nobody has confirmed and senders Palisade cannot identify (is_known false) - those are usually the interesting ones, and they are the reason to use this rather than the confirmed-sources list. Each sender carries its volume and share, DMARC/SPF/DKIM pass rates, the compliance breakdown, the header-from domains it sent as, and is_failing when it has non-compliant volume. A failing sender that Palisade has opened remediation for also carries open_task_id: call get_task with expand: ["instructions"] and follow those steps rather than working out an SPF or DKIM change yourself. Returns at most 20 senders; truncated tells you whether more exist. Aggregates only - raw reports are not available through this tool.

list_dmarc_senders