Moving your SPF to SentraDMARC
Hosted SPF (Business and above) keeps your SPF record under the 10-lookup limit and updates it when a provider changes its addresses. You move to it with one edit: you replace the value of your existing SPF record with one that points at ours.
Only after Activate
The record ours points at is created when you activate your domain, so the swap is offered only after that: in step 3 of the setup wizard ("One more record: SPF") and at the top of the SPF page ("Finish SPF setup"). When you activate, we read the senders your current SPF record authorizes and carry them into ours, so nothing you send today is left out.
Edit your existing record; never add a second. A domain may publish exactly one v=spf1 record. Two is a permanent error (RFC 7208 §4.5), and receivers fail SPF for every message. If your domain already publishes more than one, the page says so: delete the extras so one remains.
The two modes
The SPF page offers two ways to point at us, under Record ownership. The page shows the exact value for the mode you pick; switching modes changes that value, and the change takes effect once you publish the new one.
| Mode | What you publish at @ | Who sets ~all / -all |
|---|---|---|
| Keep control | v=spf1 include:spf.[your-unique-link] ~all | You. The ending is part of your record, so changing it means editing your record again. |
| Set once | v=spf1 redirect=spf.[your-unique-link], with no all at the end | The dashboard. Changing your SPF policy on the SPF page changes what receivers do, with no further DNS edit. |
In "Set once" mode the record must not end in ~all or -all: a trailing all cancels the redirect=, and the policy you set in the dashboard would stop taking effect. In "Keep control" mode the all inside our record has no bearing on the result (RFC 7208 §5.2), so the dashboard reports the ending your own record carries.
Adding a sender
- On the SPF page, add the provider's include to your hosted record.
- Or, on the DMARC page, press Add to your SPF on a sender card whose mail fails SPF. If the addresses are shared by several services, pick the one you send with.
We republish your record; it is live within its TTL. A sender card clears once a new report shows the mail passing, usually the next day's. If your domain does not point at our record yet, the include is saved and takes effect when you finish the swap; until then, the card shows the include to paste into your own record.
Updates we hold back
The worker re-resolves your senders on an hourly schedule and republishes your record when their addresses change. It refuses to publish a result that looks like a DNS failure rather than a change:
- a result with no addresses at all is not published. Your live record stays as it is, and you get one alert, "SPF update held: no addresses resolved", which clears once resolution recovers;
- a result that shrinks below half of the addresses your published record authorizes is held. Your live record is unchanged, and you get one alert, "SPF update held for review". The held update is published once resolution recovers; if the shrink is intended, republish from the SPF page;
- a result that would need more than 10 DNS lookups, usually because of providers that cannot be flattened (below), is held with one alert, "SPF update held: too many DNS lookups", naming each provider and what it costs. Nothing is dropped to make it fit.
Providers that cannot be flattened
A few providers (Salesforce, SparkPost and Elastic Email among them) authorize mail with an exists: mechanism, which asks DNS about each sending address at the moment of the check. There is no list of addresses to copy. Hosted SPF keeps such a provider in your record as an include: that receivers follow, as before. Each costs its own DNS lookups, so the page counts them against your 10. See SPF flattening.