SPF glossary
What does the exists mechanism do in an SPF record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The exists: mechanism matches when an A lookup of a constructed domain name returns any result. Alone that's useless — its power comes from SPF macros, like exists:%{i}.spf.example.com, which turns each check into a per-IP query against a DNS zone you control. Powerful, rare, and easy to get wrong.
exists: at a glance | |
|---|---|
| Tag | exists (mechanism) |
| Valid values | exists:<domain>, almost always with macros, e.g. exists:%{i}.spf.example.com |
| Default | No match if the A lookup returns nothing — but the lookup still counts against the budget. |
| Where it goes | Between v=spf1 and the final all; usually the record's only piece of custom logic. |
How exists: works
exists: asks one question: does an A record exist at this name? The addresses returned don't matter — any answer at all is a match. With a fixed name that's meaningless, because it gives the same verdict for every sender.
Macros are what make it useful. %{i} expands to the sending IP, so exists:%{i}.spf.example.com turns every SPF check into a lookup like 192.0.2.10.spf.example.com — and your DNS zone becomes the decision engine. Publish an A record for each authorized IP and nothing else, and you have per-IP authorization that scales past anything you could write into a TXT string. Large senders and some anti-spam services run exactly this pattern.
For a typical domain, it's the wrong tool: the macro syntax is dense, mistakes are silent, each evaluation costs one of the 10 DNS lookups, and the whole policy now depends on a backend zone staying alive. If your scale doesn't demand it, ip4: and include: do the job legibly.
Correct record vs common mistake
Correct
v=spf1 exists:%{i}.spf.example.com -allEach sending IP becomes a DNS query against a zone you control — authorized IPs get an A record, everything else fails.
Common mistake
v=spf1 exists:spf.example.com -allNo macro, so this checks one fixed name for every sender — it matches everyone or no one. Almost never what you meant.
Generate your SPF record
Build a correct SPF record for your domain — add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider's docs, e.g. spf.example-esp.com — commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include — check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 DNS lookupsPublish as a TXT record at the domain root. One SPF record per domain — if one exists, merge into it instead of adding another.
yourdomain.com (or @)
v=spf1 ~all
Record type: TXT · ip4/ip6 mechanisms don't count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn't stop spoofing — pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting exists:
| Issue | Likely cause | Fix |
|---|---|---|
| All mail suddenly failing on an exists-based record | The backend DNS zone stopped resolving — expired, migrated, or deleted | That zone IS the policy: restore it, and monitor it like production infrastructure from now on |
| exists matches senders it shouldn't | A wildcard record in the backend zone answers for every name | Remove wildcards; publish A records only for explicitly authorized IPs |
| Nobody on the team understands the record | Macro syntax is dense and the original author is gone | Document what the zone does — or replace with ip4/include if your scale doesn't actually need exists |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
An exists: term in a client record is usually something a long-gone consultant built: dense macro syntax, no internal documentation, and a DNS backend nobody on the current team knows exists. Across a fleet, that's an untouchable record — and if the backend zone lapses, authorization silently stops for every domain wired to it. Document it or replace it before it pages you.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
Whatever the mechanism — exotic or plain — the test is the same: do the domain's real senders pass and align? Palisade reads each client domain's DMARC reports and verifies exactly that, so even a macro-driven record advances to `p=reject` on evidence rather than faith.
Free 15-day trial · No credit card · Your own domain free forever (NFR)