DNS Connections

A DNS connection lets Palisade publish email-authentication records itself, through the account that hosts your DNS. You authorise the account once, choose which zones it may look after, and from then on every SPF, DKIM, DMARC and MTA-STS record Palisade wants for those domains can be written for you, after you have seen the exact change.

note

If you do not see DNS connectors on your Integrations page, your role in the organization does not include it. See Who can do what.

How this differs from the setup flow you already have

Each domain's setup page already offers to publish records through a one-time browser flow: you sign in to your DNS provider in a popup, approve a set of records, and the popup closes. That flow still works, and nothing about it changes.

A connection is different in three ways:

	One-time browser flow	DNS connection
Who signs in	You, in a popup, every time	Nobody. The authorisation is standing
Scope	One domain, one set of records	Every domain in the zones you chose
Preview	The provider's own screen	Palisade shows the current value and the new one side by side

Where a connection covers a domain's zone, Palisade prefers it. The button on a task changes from Set up automatically to Publish with Cloudflare (or whichever provider holds the zone), and the sentence above it names the account the record will go through. Domains in no connected account keep the browser flow.

What Palisade can and cannot do with a connection

• It reads your zones. Listing zones and reading their records is how Palisade works out which domains a connection covers and what is already published. Reading spends your provider's API quota, so Palisade asks once and remembers the answer for a few minutes.
• It writes only what you approved. Every publish starts from a preview. Palisade re-reads the zone at the moment of writing and, if a record changed in between, leaves it alone and tells you rather than overwriting something it never showed you.
• It never chooses between records it did not publish. Two SPF records at a name, or a CNAME sitting beside a TXT, is a conflict. Palisade reports it and stops. You clear it at the provider, then preview again.
• It never deletes on its own. The one case where publishing removes a record, because the record in the way cannot share the name, is shown as Will delete N records and starts unticked. A deletion is opted into, never out of.
• It never publishes through a zone you switched off. See choosing which zones a connection looks after.

Connecting a provider

Open Integrations and find your DNS provider under DNS connectors. Choose Connect on its card, or Add another account if you already have one there. You can connect more than one provider, and more than one account at the same provider; naming each connection is worth doing when you do.

Palisade checks every credential with the provider before saving it, so a token that is refused is never stored. The provider's own error is shown as it arrived, because "Invalid API Token" says more than anything Palisade could add.

Cloudflare

Palisade asks for a scoped API token, never a Global API Key. A Global Key carries your whole Cloudflare account; a token carries only what you gave it.

1. In Cloudflare, open the profile icon in the top right, then API Tokens, then Create Token.
2. Start from the Edit zone DNS template. It grants Zone:DNS:Edit only, so add Zone:Zone:Read as a second permission. Without it Palisade can write records but cannot list your zones, which is the first thing it does.
3. Under Zone Resources, limit the token to the zones you want Palisade to manage. Palisade cannot reach a zone the token cannot see, so this is the strongest limit you can set.
4. Create the token, copy it, and paste it into Palisade.

GoDaddy

Palisade asks for a Personal Access Token from the GoDaddy developer dashboard.

1. Sign in at developer.godaddy.com, then open API Keys from the account menu.
2. Create a token for the Production environment, not OTE.
3. GoDaddy shows the secret once. Copy it before you leave the page, then paste it into Palisade.

A GoDaddy token covers every domain in the account, so choose which ones this connection looks after from its zones page once it is connected.

warning

GoDaddy grants API access only to accounts above its own size threshold. A token from a smaller account authenticates and is still refused. Palisade tells you when you connect, so you find out in a minute rather than a week.

Amazon Route 53

There is no token. You create an IAM role in your own AWS account that Palisade assumes, and Palisade stores no AWS keys at all.

1. In AWS IAM, open Roles, choose Create role, then Custom trust policy, and paste the trust policy Palisade shows you. It names Palisade's role as the only principal allowed to assume yours, and carries an external ID Palisade generated for this connection. The external ID is what stops anyone else who learns your role's ARN from having Palisade assume it on their behalf, which is why Palisade chooses it rather than asking you to.

2. Attach a permissions policy. Paste the JSON Palisade shows, or switch the policy to Visual and grant exactly what it lists. It is three actions and nothing more:

   Action	Resource	Why
   route53:ListHostedZones	All resources	List the zones in your account, so you can choose which ones Palisade manages. AWS only lets this action be granted on *, which is why the policy has two statements.
   route53:ListResourceRecordSets	arn:aws:route53:::hostedzone/*	Read what is published, so every change can be previewed.
   route53:ChangeResourceRecordSets	arn:aws:route53:::hostedzone/*	Publish the records you approve.

3. Copy the new role's ARN and paste it into Palisade.

The role has to live in your AWS account. Palisade refuses to assume a role in its own account, however the policy reads.

Choosing which zones a connection looks after

View zones on a connection lists every zone the credential can see. Each row has a switch, and the switch does one of two jobs depending on whether Palisade already monitors the zone:

• Beside a domain Palisade monitors, the switch decides whether this connection may publish that domain's records. Switching it off leaves the domain in Palisade, still monitored; it only stops this connection touching its DNS. Changes take effect when you Save, and can be undone until then.
• Beside a zone Palisade does not monitor, the switch adds the zone as a domain straight away. That is a real addition to an account priced per domain, so the page says so before you do it.

A connection that can see no zones is usually a token scoped to particular zones with none of them included, rather than an empty account.

Managing a connection

Manage on a connection opens everything else:

• Name the connection, which matters when you hold several accounts at one provider.
• Replace the credential. A replacement is checked with the provider before it is saved, so a token that is refused leaves the working one in place. For Route 53, Palisade keeps the external ID the connection already uses, so the trust policy on your role stays valid.
• Re-check asks the provider whether the stored credential still works and updates the status.
• Disconnect makes Palisade forget the credential and stop publishing through the account. Records already published stay exactly where they are; nothing is removed from your DNS.

Status

Status	Meaning
Connected	The provider accepted the stored credential the last time Palisade checked.
Needs attention	The provider refused it. The reason is shown under the connection, and it is usually a revoked token or a permission that was narrowed. Re-check or replace the credential from Manage. Nothing publishes through the account until then.

Publishing through a connection

Once a connection covers a domain, three places use it:

• A domain's tasks. A task that publishes a record, such as setting up SPF or moving DMARC to reject, offers Publish with (provider) and names the account it will go through.
• A domain's hosted-record pages. Turning on hosted SPF, DKIM, MTA-STS or BIMI publishes the records Palisade wants through the connection instead of asking you to copy them.
• Many domains at once, from the bulk add flow or the domain list. See Publishing DNS records in bulk.

Who can do what

A connection is a standing authorisation at your DNS provider, so who may create and change one follows the same admin / editor / viewer split as the rest of Palisade.

	Admin	Editor	Viewer
See the connections, their status and the zones each looks after	Yes	Yes	Yes
Connect a provider account	Yes	Yes	No
Rename, re-check, replace the credential, disconnect	Yes	Yes	No
Choose which zones a connection looks after	Yes	Yes	No
Publish records through a connection	Yes	Yes	No

A viewer sees the DNS connectors section and can open a connection to see which of your domains it looks after. The controls that would change something are not offered, and the buttons that publish through a connection are not either.

Security notes

• Tokens are stored encrypted and never shown again. Route 53 stores no key at all, only the role ARN and the external ID.
• Every credential is limited by what you granted at the provider. Palisade cannot reach a zone a Cloudflare token was not scoped to, or take an action a Route 53 policy does not list.
• You can narrow or revoke a credential at the provider at any time. The next check turns the connection to Needs attention, and nothing else changes.
• Connections are created, changed and disconnected from the Palisade dashboard only. The MCP server can list your connections and check whether one covers a domain, and nothing more: it cannot add a credential or publish through one.