Hosted SPF
The Hosted SPF page lets you manage your domain's SPF record through Palisade. Instead of editing the full SPF TXT record in your DNS provider every time something changes, your SPF record delegates to Palisade with a single include: mechanism — letting Palisade publish updates on your behalf and avoiding the risk of syntax errors.
Hosted SPF requires DMARC monitoring to be set up first. Enable it from the gear menu on the Domain Overview page.
How It Works
When Hosted SPF is active, your domain's SPF TXT record at the root delegates to Palisade through an include: mechanism (e.g. v=spf1 include:example.com._spf0.dns.palisade.email ~all). Palisade serves the included SPF record on your behalf, so changes you make in the Palisade UI no longer require you to edit your DNS provider — they propagate as the included record's DNS TTL expires (typically minutes, sometimes longer for cached resolvers).
Before You Enable
You must replicate your entire existing SPF record into Palisade before publishing the new TXT record. When the Palisade-managed record goes live, it fully replaces your current SPF TXT record. Any include: mechanisms, IP addresses, or other entries that are not carried over will stop passing SPF checks immediately.
Missing an include will cause email from that service to fail SPF — which can result in messages being sent to spam or rejected, depending on your DMARC policy.
Before enabling Hosted SPF:
- Copy your current SPF record — look up your existing
v=spf1 ...TXT record and note everyinclude:,ip4:,ip6:, anda:mechanism. - Add every entry into Palisade — use the SPF Configuration editor to add each mechanism from your existing record.
- Double-check — compare the Palisade-generated record with your original. They should authorize exactly the same senders.
- Only then publish the Palisade-managed SPF record — once you are confident the records match, replace your existing SPF TXT record at your DNS provider with the one Palisade displays.
Use the SPF Audit tool to look up your current SPF record and see the full list of includes before migrating.
SPF Configuration
The edit interface lets you manage:
- Include mechanisms — add
include:entries for your authorized sending services (e.g.,include:_spf.google.com,include:sendgrid.net) - IP addresses — add specific
ip4:orip6:entries for mail servers that send on your behalf - Senders not listed above — choose what receivers do with everyone else,
~all(softfail) or-all(hardfail)
Palisade automatically includes its own SPF include so that Palisade-routed mail passes SPF checks.
Softfail or hardfail
~all is marked Recommended and is what a new record is created with. The choice is yours, and
Palisade will publish either one. The mark does not depend on your DMARC policy: the audit warning
and the score effect below apply at every policy, and a hardfail costs you the same forwarded mail
whether DMARC is enforcing or not.
A -all hardfail is applied by the receiving server before DMARC is evaluated. That turns away
spoofed mail, but it also turns away legitimate mail that has been forwarded or relayed, through a
mailing list or a staff auto-forward for instance, where the sending IP is no longer one of yours.
DMARC would have let that mail through on its DKIM signature. With ~all, unlisted senders are
marked unauthorized and your DMARC policy decides what happens to them, which is why we suggest
pairing ~all with a DMARC policy of quarantine or reject rather than reaching for the hardfail.
See Softfail vs hardfail for the full reasoning.
If you do choose -all, Palisade's audit flags it as a delivery risk and your domain score reflects
that. That is the recommendation above being consistent, not a fault in your record. Palisade only
raises a task asking you to change it once your DMARC policy reaches quarantine at 100% or reject,
where the hardfail adds nothing DMARC is not already doing.
Importing an existing record keeps whichever mechanism it already uses, so a record that arrives as
-all stays that way until you change it here.
A parked domain is the exception to all of this. It sends no mail, so there is no legitimate traffic
for a hardfail to catch, and Palisade recommends -all there alongside a reject policy.
SPF Lookup Limit
SPF records are limited to 10 DNS lookups. Each include: and a: mechanism counts toward this limit, and nested includes count as well. Exceeding the limit causes SPF to fail for all senders.
If you are near the limit, consider:
- Removing includes for services you no longer use (Last Seen tells you which ones those are)
- Replacing
include:entries with directip4:orip6:entries where possible (this is called SPF flattening) - Consolidating sending services that use the same infrastructure
Last Seen
Every entry in the Authorized senders list shows when mail last passed SPF through it:
- Last seen 4 days ago — the most recent day mail from that sender passed an aligned SPF check.
- No mail in 90 days — a warning chip: Palisade knows this sender, and nothing has passed SPF through it anywhere in the activity window.
This is what makes trimming safe. Palisade only marks an entry as unused when it can prove it: the sender has to be one that report discovery already recognizes, and the domain has to have been monitored for the full window. A freshly added include shows nothing rather than a false "no mail" claim, and so does a sender whose mail flows but never passes SPF — that is a failing-SPF problem, and the Agent raises it as its own ticket.
An unused entry is worth reviewing, not automatically wrong. If you no longer send through the service you can remove it; if you are not sure, keep it. See the activity window for how that is measured.
Domain Status
A status badge at the top shows:
- Active — the SPF TXT record is published and Palisade is serving the included record
- Verifying — waiting for the SPF TXT record to propagate
- Error — DNS verification failed or there is a sync issue
- Inactive — Hosted SPF is not enabled
If an error occurs during SPF synchronization, a notice will appear with details about the issue.