DMARC Analyzer

TL;DR

• The SPF 10-lookup limit is defined in RFC 7208 section 4.6.4: an SPF evaluation MUST NOT perform more than 10 DNS lookups, counting include, a, mx, ptr, exists, and the redirect= modifier. Exceeding the cap returns permerror.
• ip4, ip6, and all cost zero lookups - they are evaluated against the connecting IP without DNS.
• The 10 lookups counter is the SUM across the ENTIRE evaluation - top-level mechanisms PLUS every mechanism inside every nested include and redirect=. A top-level record with 4 includes whose underlying records each contain 3 more includes consumes 4 + 12 = 16 lookups even though the published record only shows 4.
• RFC 7208 section 4.6.4 paragraph 3 adds a secondary cap of 2 void lookups: an SPF evaluation that encounters two or more DNS queries returning NXDOMAIN or NODATA MAY return permerror.
• A permerror result fails SPF for every recipient and cascades into a DMARC fail on every DMARC-honouring receiver - a single misconfigured include can produce a global mail-delivery outage.
• The four standard remediations, in order of preference: (1) audit and remove unused includes, (2) split senders across subdomains, (3) consolidate to fewer ESPs, (4) flatten with a monitored pipeline. Macros (RFC 7208 section 7) are a distant fifth.
• SPF flattening is the practice of resolving include chains down to their underlying ip4 / ip6 ranges and republishing the flattened record. It trades one operational cost (a daily / hourly cron to re-resolve includes) for one architectural risk (the flattened record diverges from the upstream sender's truth between refreshes).

1. Overview: what the limit is and why every operator hits it

Sender Policy Framework (SPF) works by publishing a list of authorised sending sources in a TXT record on the sending domain. A receiver fetches the SPF record and walks the mechanisms one by one to decide whether the connecting IP is on the authorised list. Some mechanisms - ip4, ip6, all - test the connecting IP directly against a hard-coded value and require no DNS. Other mechanisms - include, a, mx, ptr, exists - require the receiver to issue a DNS query to resolve them.

RFC 7208 section 4.6.4 caps the total number of those DNS queries at 10 per SPF evaluation. Exceeding the cap returns permerror, which fails SPF authentication for every recipient on the message. Because DMARC treats SPF permerror as SPF fail, a record that overshoots the cap cascades into a DMARC fail on every receiver that honours DMARC - which today means every major mailbox provider and every enterprise mailbox running a modern security gateway.

The 10-lookup limit is the single most common cause of SPF failure in production. Operators routinely hit it by adding one more include: for one more SaaS sender (a new survey tool, a new help-desk product, a new marketing automation platform) without realising that the new include's UNDERLYING record already contains several more includes that count against the parent domain's budget. The published record shows 5 includes; the actual lookup cost is 14.

This guide walks the rules behind the limit, the per-mechanism cost, the recursive cost accounting that catches operators by surprise, the void-lookup secondary cap, a per-provider lookup-cost reference, the symptoms and cascading effects of permerror, and the four canonical remediation paths.

2. Why the limit exists: RFC 7208 section 4.6.4 historical context

The cap is not arbitrary. SPF was originally designed in RFC 4408 (2006) with a 10-lookup cap and inherited unchanged into RFC 7208 (2014) section 4.6.4. The cap exists because without it, SPF would be weaponisable into a DNS amplification denial-of-service vector against arbitrary third-party DNS infrastructure.

The attack works as follows. An attacker registers evil.example and publishes an SPF record consisting of nested includes that eventually point at a victim domain's DNS infrastructure. Each time a mail receiver evaluates SPF for a message claiming to be from evil.example, that receiver issues a cascading flood of DNS queries against the victim's authoritative nameservers. The attacker only has to send one message to each of N mail receivers; the receivers do all the work. Without a cap on the number of DNS queries per evaluation, a single attacker with access to a few hundred open relays could trivially exhaust the victim's DNS infrastructure.

The 10-lookup cap exists to bound this attack surface. It is a deliberate trade-off: SPF cannot represent arbitrarily complex sender topologies, and operators with many senders MUST use subdomain delegation or flattening to stay under cap. RFC 7208 section 4.6.4 paragraph 1 is explicit:

Some mechanisms and modifiers (collectively, "terms") cause DNS queries
at the time of evaluation, and some do not.  The following terms cause
DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms,
and the "redirect" modifier.  SPF implementations MUST limit the total
number of those terms to 10 during SPF evaluation, to avoid unreasonable
load on the DNS.  If this limit is exceeded, the implementation MUST
return "permerror".

"Unreasonable load on the DNS" is the operative phrase. The cap is not about SPF semantic complexity; it is about protecting third-party DNS infrastructure from being weaponised by SPF evaluators on behalf of attackers.

3. Per-mechanism lookup cost

Every SPF mechanism falls into one of three cost classes: zero-cost, one-cost, or recursive. The table below summarises the cost of each:

The two cost classes that catch operators by surprise are mx with many MX hosts and include: with deeply nested underlying records. An mx mechanism against a domain with 5 MX hosts costs 6 lookups (1 for the MX query, 5 for the A/AAAA queries on each host). An include: against a SaaS sender whose record contains 4 more includes costs at least 5 lookups (1 for the top-level include, 4 for the nested includes, more if those nested includes themselves contain more).

4. Recursive include resolution: the hidden cost

Consider a record that looks innocent:

example.com.   IN   TXT   "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.sendgrid.net include:mailgun.org include:_spf.salesforce.com -all"

Five includes. The published record's mechanism count is 5. The ACTUAL DNS-lookup cost is significantly higher because each include: causes the receiver to fetch the underlying record and recursively count every mechanism inside it.

Walk it through, one include at a time:

1. include:_spf.google.com costs 1 (the top-level include) + the recursive cost of _spf.google.com's record, which is v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all - that is 3 more includes, each of which is a leaf ip4:/ip6: list. Subtotal: 1 + 3 = 4 lookups.
2. include:spf.protection.outlook.com costs 1 (the top-level include) + the recursive cost of spf.protection.outlook.com, which is currently a single ip4: / ip6: list with no further includes. Subtotal: 1 + 0 = 1 lookup.
3. include:spf.sendgrid.net costs 1 + 1 (the underlying record uses include:sendgrid.net). Subtotal: 2 lookups.
4. include:mailgun.org costs 1 + 1 (the underlying record uses include:_spf.eu.mailgun.org or similar). Subtotal: 2 lookups.
5. include:_spf.salesforce.com costs 1 + ~3 (Salesforce's record contains ~3 more includes for various regions). Subtotal: 4 lookups.

Total: 4 + 1 + 2 + 2 + 4 = 13 lookups. The published record shows 5 mechanisms; the receiver pays for 13. The record is in permerror on every receiver that walks it.

This is the canonical operator surprise: the visible mechanism count understates the actual cost by 2x to 4x. The only way to know the real cost is to walk every nested include yourself or use a tool that does. DMARC Analyzer's Domain Security Checker reports the live recursive lookup count for any domain.

Worse, the cost can change without the operator touching anything: when a SaaS sender adds a new region (Google adds _netblocks4.google.com, Salesforce adds a new geography), every customer record that includes them pays the extra lookup. Records that were comfortably at 8 lookups on a Tuesday can hit 11 on a Wednesday because of a supplier-side change the operator never saw. This is why monitoring the live lookup count (not just the static record text) matters.

5. The secondary cap: 2 void lookups

RFC 7208 section 4.6.4 paragraph 3 specifies a secondary, less-known cap:

SPF implementations SHOULD limit "void lookups" to two.  Should this
limit be exceeded, the implementation MAY return "permerror".

The purpose of this limit is to prevent attackers from creating SPF
records that cause excessive DNS lookups for nonexistent domains.

A void lookup is any DNS query that returns either NXDOMAIN (the domain does not exist) or NODATA (the domain exists but has no records of the requested type). The void-lookup cap is independent of the 10-lookup cap and is typically tripped by SPF records that include or reference domains that have been retired.

Common void-lookup sources:

• Retired SaaS senders. An operator switches from MailChimp to Klaviyo but forgets to remove include:servers.mcsv.net from their SPF record. MailChimp keeps the underlying record alive for years but eventually retires it - and every SPF evaluation thereafter trips a void lookup.
• Typo-squatted includes. An operator typed include:_spf.googl.com instead of include:_spf.google.com. The record was published, no one noticed because the operator had OTHER passing mechanisms, and the typo trips a void lookup on every evaluation.
• Discontinued ptr mechanisms. Operators who inherited old SPF records with ptr mechanisms targeting a previous hosting provider's IP space whose reverse-DNS no longer resolves.
• Bare a mechanisms with no A/AAAA record. A bare a:mail.example.com trips a void lookup if mail.example.com exists but only has AAAA, or only A, or neither.

Two void lookups MAY cause permerror under RFC 7208. Major receivers (Google, Microsoft, Yahoo) are increasingly strict about enforcing the cap - what was a SHOULD in 2014 is now a de-facto MUST in 2026. The remediation is always to audit the record and remove the broken references.

6. Per-provider lookup cost reference (approximate, 2026)

Lookup costs are not stable over time - SaaS providers add and remove netblock subqueries as their infrastructure evolves. The figures below are approximate as of mid-2026 and should be re-verified against the live record before relying on them for capacity planning:

A naive operator who combines Google Workspace + Microsoft 365 + SendGrid + Mailgun + Salesforce + HubSpot pays approximately 4 + 1 + 2 + 2 + 4 + 2 = 15 lookups - already over cap before any of their own transactional senders, marketing senders, or on-prem MTA. This combination is extremely common in mid-market SaaS companies, and the resulting permerror is one of the most common root causes cited in DMARC monitoring reports.

7. Symptoms of exceeding the limit

The canonical symptoms of an over-budget SPF record are:

• Authentication-Results header shows spf=permerror at every receiver. The header typically reads spf=permerror (sender SPF authorization permerror) smtp.helo=...; ... reason="too many DNS lookups" on Google receivers and analogous text on Microsoft, Yahoo, etc.
• DMARC aggregate (RUA) reports show spf=permerror in the per-row auth_results block, with the DMARC policy_evaluated disposition degraded to whatever the published p= tag demands.
• Receiver-specific NDRs. Bounces vary widely: Google often issues 550 5.7.26 This mail has been blocked because the sender is unauthenticated; Microsoft uses 5.7.1 Unfortunately, messages from [IP] weren't sent; Yahoo uses 553 5.7.1 [BL21] Messages from this sender did not pass DMARC.
• Sudden, mass delivery failure for ONE specific sending source while other sources continue working. The permerror cascade affects EVERY recipient of every message from the affected From: domain, but it only surfaces when SPF was the load-bearing identifier - mail that was also DKIM-aligned will still pass DMARC.
• Sender reputation degradation. Receivers track per-domain authentication pass rates over time. A domain with sustained permerror gets demoted in deliverability ranking even at receivers that do not strictly enforce DMARC.

The diagnostic is straightforward: pull the Authentication-Results header from a failing message and look for the literal string spf=permerror. If present, investigate the SPF record's live lookup count; if it is over 10 or has more than one void lookup, that is the root cause.

8. The four remediation paths (in order of preference)

8.1 Audit and remove unused includes

The cheapest, lowest-risk remediation is to delete includes for senders the organisation no longer uses. Operators routinely retain includes for SaaS senders that were sunset years ago because removing them feels risky. The procedure is:

1. Pull 30 days of DMARC aggregate (RUA) data from DMARC Analyzer's dashboard.
2. For each included sender (Salesforce, SendGrid, etc.), check whether ANY messages in the 30-day window claim that sender's IP space. If none, the include is dead and can be removed.
3. Stage the change in a test domain first. Publish the slimmer record on test-spf.example.com and send test traffic through each remaining sender. Verify every sender still passes.
4. Publish to production. Monitor the next 24-48h of RUA reports for any unexpected SPF fails.

Typical impact: removing 2-4 dead includes reclaims 4-12 lookups depending on the recursive cost of the removed includes.

8.2 Subdomain delegation

Split sending sources across different subdomains. Each subdomain has its own 10-lookup budget. This is the canonical scaling pattern for organisations with many sending sources:

example.com.       IN TXT "v=spf1 include:_spf.google.com -all"
news.example.com.  IN TXT "v=spf1 include:sendgrid.net -all"
mail.example.com.  IN TXT "v=spf1 include:mailgun.org -all"
crm.example.com.   IN TXT "v=spf1 include:_spf.salesforce.com -all"

Each sender's mail uses the From: header matching its subdomain (marketing@news.example.com, transactional@mail.example.com, crm@crm.example.com), and each subdomain's SPF record stays well under the 10-lookup cap. The parent example.com only carries staff mail via Google Workspace.

Subdomain delegation also improves DMARC reporting clarity: the rua= reports identify the sub-domain that produced each message, so an auth failure spike is immediately attributable to a specific sender.

Costs of this approach: every sender has to be reconfigured to send from its subdomain (not always possible if the marketing team insists on sending from the bare example.com); DKIM records must be published for each subdomain; DMARC records can either be inherited (the parent's p= applies via the organisational-domain rule) or published per-subdomain for finer control.

8.3 Sender consolidation

If an organisation has duplicate-purpose senders (two transactional ESPs, three marketing platforms), consolidating to fewer senders reclaims lookups AND reduces vendor sprawl. A company that uses SendGrid, Mailgun, AND Postmark for transactional mail is almost certainly not getting differentiated value from each; picking one and migrating the others typically reclaims 2-4 lookups and simplifies operations.

8.4 Flattening

The fourth remediation path - and the one most commonly reached for by tools - is SPF flattening. See the dedicated section below.

8.5 (Distant fifth) Macros

SPF macros (RFC 7208 section 7) let an SPF record substitute runtime variables (the connecting IP, the HELO name, the sender domain) into mechanism arguments, which CAN reduce lookups by replacing N includes with one exists: check against a macro-built lookup name (e.g. exists:%{i}.spf.example.com resolves the connecting IP into a per-IP lookup that consumes 1 lookup regardless of how many authorised IPs the operator publishes). In practice macros are rare in production because they are hard to reason about, hard to debug, and have inconsistent support across legacy SPF evaluators. Reach for them only after the first four remediation paths have been exhausted.

9. SPF flattening in depth

9.1 What flattening is

SPF flattening is the practice of periodically resolving every include, a, and mx mechanism in an SPF record down to its underlying ip4 and ip6 ranges, then republishing the record as a list of ip4: and ip6: mechanisms that cost zero lookups. A 13-lookup record becomes a 0-lookup record at the cost of a much longer DNS payload.

Before flattening:

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

After flattening:

example.com. IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 -all"

The flattened record costs 0 DNS lookups (all mechanisms are ip4: / ip6: literals) but the operator now owns the responsibility of keeping the ip4: list in sync with Google's and Microsoft's actual netblocks.

9.2 When to use flattening

Flattening is appropriate when:

• The organisation has exhausted the first three remediation paths (audit, subdomain delegation, consolidation) and is STILL over cap.
• The senders being flattened are stable - Microsoft 365's netblocks change rarely; SendGrid's regional shards change more often. Flattening volatile senders means more frequent refresh cycles.
• The operator has the operational capacity to run, monitor, and alert on the refresh pipeline. Flattening without monitoring is a silent time bomb.

9.3 When NOT to use flattening

Flattening is INAPPROPRIATE when:

• The organisation has not yet audited unused includes. Flattening 14 includes when 4 are dead is paying operational cost for value the audit could deliver for free.
• The senders being flattened are highly volatile (a sender that rotates IPs hourly cannot be safely flattened on a daily cron).
• The operator does not have the operational capacity to monitor the refresh pipeline. A flattened record that goes stale silently fails SPF for whichever sender's IPs rotated out of the cached list.

9.4 Manual flattening procedure

The minimal viable manual flattening procedure using standard Unix tooling:

# Resolve every nested include down to ip4/ip6 mechanisms.
# Requires the python3-dnspython package.
python3 -c "
import dns.resolver
def walk(domain, depth=0):
    if depth > 5: return []
    try:
        ans = dns.resolver.resolve(domain, 'TXT')
    except Exception: return []
    out = []
    for r in ans:
        txt = b''.join(r.strings).decode()
        if not txt.startswith('v=spf1'): continue
        for term in txt.split()[1:]:
            if term.startswith('ip4:') or term.startswith('ip6:'):
                out.append(term)
            elif term.startswith('include:'):
                out.extend(walk(term.split(':',1)[1], depth+1))
    return out
print(' '.join(walk('_spf.google.com')))
"

Wrap this in a cron job that runs every 24 hours, computes a hash of the new flattened record, compares it to the published record, and either republishes via your DNS provider's API or alerts on divergence.

9.5 Commercial flattening services

Several vendors offer SPF flattening as a service:

• Valimail Authenticate - managed SPF + DKIM + DMARC service with automatic flattening.
• PowerDMARC - SPF flattening service with hosted records and automatic refresh.
• EasyDMARC EasySPF - hosted SPF flattening with a managed record endpoint.
• dmarcian SPF Magic - flattening service tied to the dmarcian DMARC platform.
• Red Sift OnDMARC - includes an SPF flattening / Dynamic SPF feature.

These services typically work by having the operator publish an include: to a vendor-hosted record (e.g. include:_spf.vendor.com) that the vendor keeps continuously updated. The operator delegates the refresh problem to the vendor at the cost of one inbound dependency and one vendor lock-in vector.

9.6 Self-hosted flattening

Open-source flattening implementations exist for operators who prefer self-hosting:

• SPFlat - reference Python implementation, well-suited to a cron-driven pipeline.
• Custom scripts using dnspython (Python), miekg/dns (Go), or Net::DNS (Perl). The walk algorithm is straightforward; the operational complexity is in the publish-and-monitor pipeline, not the resolver code.

9.7 Flattening pitfalls

The five canonical pitfalls of flattening:

• Stale flattened record. The cron job failed three weeks ago, the operator never noticed, and a SaaS sender rotated their IP range last Tuesday. Mail from that sender silently fails SPF until someone debugs it.
• TXT record length limits. A single TXT record is capped at 255 bytes per string; the total record (concatenated strings) is capped by the DNS UDP/TCP message size. Flattened records of 15+ mechanisms approach the limit. Splitting into multiple TXT records with include: chains DEFEATS the flattening because the includes count against the lookup budget.
• Refresh interval too long. A daily refresh interval is too slow for senders that rotate IPs hourly. The canonical examples are CDN-fronted ESPs that elastically expand and contract their sending infrastructure.
• Divergent upstream truth. The flattened record represents what the operator's pipeline saw at the last refresh. It is NOT the upstream sender's authoritative list. If the upstream sender adds an IP to an ip4 mechanism IN its source record and the receiver evaluates the live record (because the operator is NOT flattening but a friend is), the operator's flattened record will lag.
• Vendor lock-in via hosted flattening. Switching from Vendor A's hosted flattening to Vendor B's requires changing the production SPF record - a high-blast-radius operation. Pick carefully and confirm the vendor has a documented data-export path.

10. Best practices

• Audit before flattening. Remove dead includes first. Flattening pays operational cost; an audit is free.
• Monitor the live lookup count. The static record text underreports the cost by 2x to 4x. Set up a daily check that recursively counts lookups and alerts on >= 9 (one below cap, so you have headroom before permerror hits production).
• Never publish bare ptr mechanisms. RFC 7208 section 5.5 deprecates them; receivers treat them with suspicion; and they trip void lookups whenever reverse-DNS is stale.
• Always terminate with -all in production. ~all (softfail) is acceptable only during the first 2-4 weeks of an initial rollout while shadow senders are being discovered.
• Stage SPF changes in a test domain first. Publish on test-spf.example.com, route test traffic through each sender, verify every authorised source still passes, only then promote to production.
• Document the senders. Maintain a list of every include and what it is for. When someone leaves and a replacement is hired, the list answers the "can I delete this?" question without archaeology.
• Prefer subdomain delegation over flattening when adding new senders. Delegation scales cleanly with sender count; flattening accumulates operational debt.
• If flattening, monitor the pipeline. A failed cron job that does not alert on-call is a silent ticking bomb. Alert on cron failure AND on stale record age (e.g. "flattened record has not been refreshed in 48 hours").

11. Common mistakes

• Counting mechanisms instead of lookups. The published record's visible mechanism count is not the same as the lookup cost. A record with 5 includes can easily consume 15 lookups.
• Adding one more SaaS include without checking the cost. Every new SaaS sender's include should be cost-checked against the current budget BEFORE it goes into production.
• Splitting a long flattened record into chained includes. Splitting a single 800-byte flattened TXT into two TXT records via include: defeats the flattening - the include itself consumes 1 lookup and so does the chained record.
• Using +all as a terminator. +all authorises every IP on the internet to send mail as your domain - it is functionally equivalent to having no SPF record at all and is exploited by spammers within hours of publication.
• Leaving retired senders' includes in place. Every retired sender's include continues to cost lookups (and risks void lookups when the upstream record finally goes away). Audit and remove them aggressively.
• Treating SPF as the only authentication mechanism. SPF breaks during forwarding. DKIM does not. Every sender should be DKIM-signed with custom-domain DKIM enabled so DMARC alignment survives the forwarding hop.
• Trusting MX flattening tools to be correct forever. A vendor-hosted flattening service still requires the operator to monitor the vendor's status - vendor outages cascade into the operator's mail flow.

12. Troubleshooting

12.1 "spf=permerror" appearing in Authentication-Results

The Authentication-Results header reads spf=permerror. Confirm the cause by walking the SPF record recursively and counting lookups. If the count is over 10, that is the cause. If the count is at or below 10, check the void-lookup count - any single mechanism whose underlying domain returns NXDOMAIN or NODATA counts. Two or more void lookups MAY trip permerror.

DMARC Analyzer's Domain Security Checker reports both counts. The Email Header Analyzer parses Authentication-Results headers and surfaces the permerror reason text from the receiver.

12.2 SPF passes but DMARC fails

SPF passed for the envelope domain but the envelope domain does not align with the From: header domain. This is the DMARC alignment problem, not the SPF lookup-limit problem. See DMARC alignment explained for the alignment rules. The fix is usually enabling custom-domain DKIM at the SaaS sender so DKIM alignment carries the message.

12.3 Permerror at some receivers, no error at others

Different SPF evaluators differ in how strictly they enforce the 10-lookup cap. Older implementations may silently continue past 10; newer implementations reject. The published record is the same; the operator only saw permerror reports from the strict receivers. The remediation is the same regardless of which receiver reported it - the record IS over budget and needs to be fixed.

12.4 The lookup count changed without my touching the record

A SaaS sender added or removed an internal include subquery in their canonical record. Your include's recursive cost changed without any change to your published record. This is one of the strongest arguments for monitoring the live lookup count rather than the static record text.

13. Frequently asked questions

What is the SPF 10 DNS lookup limit?

RFC 7208 section 4.6.4 caps the number of DNS lookups an SPF evaluation may perform at 10. Each include, a, mx, ptr, exists, and the redirect= modifier consumes 1 lookup; ip4, ip6, and all cost zero. Exceeding the cap returns permerror, which fails SPF for every recipient and cascades into a DMARC fail on every DMARC-honouring receiver.

How do I check how many SPF lookups my record uses?

Use a recursive SPF resolver that walks every include, redirect=, a, mx, ptr, and exists mechanism and counts each DNS query against the 10-lookup budget. DMARC Analyzer's Domain Security Checker reports the live lookup count and per-include attribution. Manual counting is unreliable because nested includes inflate the total in ways that do not appear in the raw record text.

What is SPF flattening?

SPF flattening is the practice of periodically resolving every include, a, and mx mechanism in an SPF record down to its underlying ip4 and ip6 ranges, then republishing the flattened record as a list of ip4/ip6 mechanisms that cost zero lookups. Flattening trades operational cost (a recurring cron job) for architectural risk (the flattened record diverges from the upstream sender's real IP set between refreshes).

What is the void lookup limit?

RFC 7208 section 4.6.4 paragraph 3 specifies a secondary cap of 2 void lookups: an SPF evaluation that encounters two or more DNS queries returning NXDOMAIN or NODATA MAY return permerror. The cap is independent of the 10-lookup cap.

Is SPF flattening safe?

Flattening is safe IF the operator commits to two operational practices: (1) re-resolve and republish the flattened record at least daily, and (2) monitor the flattening pipeline so a failed cron job alerts on-call before the flattened record goes stale. Flattening published once and forgotten is a silent time bomb.

What happens when SPF returns permerror?

A permerror result fails SPF authentication for every recipient processed by every receiver that respects RFC 7208. The DMARC evaluation then sees SPF=fail and combines it with the DKIM result: if DKIM also fails or is not aligned, DMARC fails and the receiver applies the published policy.

How does subdomain delegation reduce SPF lookup count?

Subdomain delegation splits sending sources across different subdomains, each of which publishes its own SPF record with only the includes that subdomain actually uses. Each subdomain has its own 10-lookup budget, so 30 underlying lookups split 3 ways stay comfortably under cap.

Should I use SPF macros to reduce lookups?

SPF macros (RFC 7208 section 7) CAN reduce lookups but are rare in production because they are hard to reason about and debug. Reach for them only after the four other remediation paths have been exhausted.

14. Related guides

• SPF explained - the SPF pillar covering DNS syntax, mechanisms, qualifiers, and the broader deployment context. Start here if SPF is new to you.
• DMARC for cPanel - the SHARED-HOSTING-CONTROL-PANEL- SPF-LOOKUP-BUDGET-EXHAUSTION-AT-MULTI- TENANT-INCLUDE-CASCADE-BOUNDARY companion to this SPF 10-DNS-lookup-budget pillar. Where THIS page documents the RFC 7208 §4.6.4 ten-DNS-lookup budget mechanics (the void-lookup counter, the include: / a: / mx: / ptr: / exists: per-mechanism budget cost, the permerror outcome on overflow, and the SPF- flattening / ip4:- literalization workarounds), the DMARC-for-cPanel spoke is the SHARED- HOSTING-CONTROL-PANEL-OPERATOR companion documenting the STRUCTURALLY-AMPLIFIED budget-pressure the cPanel-shared-hosting deployment surface induces on every customer- domain SPF record: (i) the cPanel-shared-hosting provider's outbound-Exim egress IP pool is typically published as a provider- managed _spf.<provider>. com include token that the customer's v=spf1 record MUST cite via include: to authorise the shared-IP envelope for the customer's domain — this consumes ONE include-budget hit before the customer's own vendor includes (Mailchimp, SendGrid, Constant Contact, etc.) are added, leaving 9 budget slots for the customer's own SaaS-sender delegation; (ii) the cPanel provider's include: token itself typically recursively expands to 2-4 sub-includes (one for each provider data-centre's egress pool, plus DKIM-signer hosts) — counting another 2-4 budget hits transitively — leaving 5-7 slots for the customer's vendor delegation, well below the headroom a single-tenant operator enjoys; (iii) the cPanel customer's WHM/cPanel UI does NOT surface the budget-consumption cost of the provider's include: token (the UI typically auto-publishes the provider include but does not warn "you have N include slots remaining before permerror"), so a customer who adds three or four SaaS-sender includes WITHOUT knowing the provider's transitive cost will silently overflow into permerror and lose all SPF-based DMARC-pass evidence; (iv) the budget-overflow remedy on cPanel is structurally different from a single-tenant operator's remedy — the cPanel customer typically CANNOT flatten the provider's include: chain (the provider's IPs may renumber without notice, breaking any flattened-CIDR record the customer maintains), so the budget-reclamation playbook for cPanel customers reduces to REMOVING redundant vendor includes / consolidating multiple ESPs onto a single-bridge include / requesting the provider issue a per-customer narrowed-CIDR include token. Read the DMARC- for-cPanel spoke alongside this budget-mechanics pillar when the operator is investigating SPF permerror at a cPanel- hosted customer domain, when the customer reports "Gmail says envelope-MAIL-FROM auth failed but I have an SPF record published", or when planning the SaaS-sender delegation strategy for a customer portfolio that includes cPanel- hosted brands alongside non- cPanel brands.
• SPF DNS record syntax explained - the focused DNS-record-level SYNTAX reference (RFC 7208 section 3): the 255-octet character-string limit + multi- string concatenation rule (a frequent companion to the 10-lookup limit on this page when flattening produces records beyond 255 octets), the v=spf1 prefix, the single- record rule, and per-subdomain publication. The syntactic constraints on this page's flattening playbook.
• SPF qualifiers explained - the per-prefix semantic deep dive on the four qualifier tokens (+ = Pass, - = Fail, ~ = SoftFail, ? = Neutral) that determine what receivers do when the 10-lookup budget is exhausted by an all fall-through. The qualifier on the tail all token is the operator knob that determines whether a post-lookup-budget mail flow lands in production reject (-all), soft-fail / reputation-penalised (~all), or accepted with neutral disposition (?all). Pair with this page when designing a flattening migration: the lookup-limit constraint forces a tighter SPF record but the policy-strength choice (-all for production, ~all for staged rollout, ?all for testing) is the orthogonal qualifier-layer decision that determines what happens to IPs missing from the slimmed record. Also covers the implicit-+ default rule and the canonical receiver mapping in detail.
• SPF mechanisms explained - the per-mechanism deep dive on every directive type the lookup-budget counter on this page tracks. Each mechanism has a different lookup signature documented in this page's flattening playbook — include:<domain> consumes 1 lookup plus the recursive cost of the included SPF tree (the dominant contributor to the 10-cap overrun), a / a:<domain> consumes 1 lookup plus the A/AAAA RRset returned, mx / mx:<domain> consumes 1 lookup for the MX RRset PLUS one A/AAAA lookup per MX target (the second most common overrun source after deeply- nested includes), ptr / ptr:<domain> consumes N lookups where N is the number of PTR records resolved (RFC 7208 §5.5 deprecates this mechanism for performance reasons — it is now a regression-flag for any modern SPF audit), exists:<domain> consumes 1 lookup with no nested contribution, and redirect=<domain> consumes 1 lookup PLUS the full recursive cost of the redirected record. Use the mechanisms reference when diagnosing WHICH specific directive in your record is the lookup-budget bottleneck before designing the flattening migration this page's playbook walks through.
• MX records explained - the SPF-MX-MECHANISM-DNS-LOOKUP-BUDGET- CONSUMER companion to this SPF lookup-budget reference. Where THIS page documents the RFC 7208 §4.6.4 ten-DNS-lookup ceiling + the §4.6.4 void-lookup-cap (max 2) + the operator-side flattening migration playbook, the MX-records spoke documents the underlying MX RRset whose expansion the mx mechanism evaluates against: (i) per-MX-host A/AAAA expansion cost — the mx mechanism consumes 1 lookup for the MX RRset PLUS one A/AAAA lookup per MX target (the second-most- common overrun source after deeply-nested include: chains the flattening playbook this page documents is designed to refactor); (ii) per- MX-target rDNS-validation chain — the receiver-side rDNS-validation process consumes ADDITIONAL DNS lookups per MX target during the SMTP receiving path's per-connecting-IP FCrDNS check that operates outside the SPF lookup budget but co-amplifies the DNS-fetch cost the connecting-IP attribution imposes; (iii) backup-MX per-record expansion — operators publishing 3-4 backup MXs encounter the cumulative mx-mechanism cost in their authoring discipline, often producing the unintentional 10-DNS-lookup cap overrun even before counting the include: chain; (iv) MX-record-vs-mx-mechanism substitution decision — the flattening migration this page's playbook walks through commonly replaces the mx mechanism with ip4: / ip6: literals derived from the MX RRset, but the operator must remember the MX RRset is the publishing-domain authoritative ground truth — flattened ip4: literals require manual re-flattening every time the MX RRset changes. SPF authors landing here for the lookup-budget reference need the MX-records spoke's apex-MX byte-syntax to understand the per-mechanism MX-RRset contribution the lookup-budget counter on this page tracks.
• include vs ip4 vs a vs mx: the four IP-providing mechanisms compared - the focused four-way operator-decision tree on the mechanism-choice layer that determines the dominant DNS-lookup cost documented on this page. Each of the four IP-providing mechanisms has a different lookup signature: include: consumes 1 lookup plus the recursive cost of the included SPF tree (often the dominant contributor to the 10-cap overrun); ip4: and ip6: consume ZERO lookups (the flattening target of choice); a: consumes 1 lookup; and mx: consumes 1 lookup PLUS 1 per MX target (often a hidden cost on domains with redundant inbound MX records). The include-vs page is the canonical reference for the flattening playbook on this page: when an SPF record breaches the 10-lookup cap, the remediation is almost always to replace a high-cost include: with either a precomputed ip4:/ip6: set (full flattening) or a tighter include: chain (partial flattening). Includes a side-by-side comparison table, a five-question decision matrix, three worked deployment examples (single on-prem Postfix, Microsoft 365 + Mailchimp, Google Workspace hybrid), and the seven most common mechanism-choice mistakes that compound into 10-cap overruns. Pair with this page when the lookup-count audit on this guide flags an over-budget record: this page documents WHY the limit exists, the include-vs page documents WHICH mechanism to swap in for the slimmed record.
• DMARC alignment explained - the alignment rules that determine whether a passing SPF result also satisfies DMARC. A permerror cascade is one common cause of "SPF passed but DMARC failed".
• Reverse DNS / PTR records for mail servers — the SPF-PTR-MECHANISM-AS-RFC-7208-§5.5- DEPRECATED-DNS-LOOKUP-BUDGET-CONSUMER companion to this RFC 7208 §4.6.4 ten- DNS-lookup budget reference. Where THIS page documents the canonical DNS-lookup budget exhaustion failure-modes (the include: chain depth cost, the a: and mx: per-RR resolution cost, the exists: macro-expansion resolution cost), the reverse-DNS-PTR spoke documents the FIVE structurally-distinct angles on which the RFC 7208 §5.5 SPF ptr mechanism evaluation interacts with this page's 10-DNS-lookup budget discipline: (i) THE ptr MECHANISM IS RFC 7208 §5.5 EXPLICITLY DEPRECATED ("ptr mechanism SHOULD NOT be published") precisely because its evaluation is the SINGLE MOST EXPENSIVE per-mechanism DNS-lookup-budget consumer — the receiver MUST perform a PTR lookup on the connecting IP, then forward-resolve EACH returned PTR FQDN, then check whether ANY of those resolved IPs matches the connecting IP (potentially many lookups for a single mechanism evaluation); (ii) the ptr mechanism is the SINGLE MOST-LIKELY MECHANISM to trigger the void-lookup limit RFC 7208 §4.6.4 imposes (2 void lookups maximum before permerror) because the connecting IP frequently has NO PTR record or a PTR record whose forward-resolution returns no IPs; (iii) the ptr mechanism is the ONLY SPF mechanism whose evaluation depends on the receiver-side IP-identity-validation layer that reverse-DNS-PTR documents (FCrDNS verification) — the SPF ptr mechanism is structurally a SPF-LEVERAGE of the FCrDNS verification protocol at the envelope-layer; (iv) for publishers attempting to AVOID the ptr mechanism (per RFC 7208 §5.5 deprecation), the per- mechanism comparative evaluation with a: (forward-resolves the FQDN's A/AAAA records and matches connecting IP) and mx: (forward-resolves the MX hosts' A/AAAA records and matches connecting IP) shows the same intent (match connecting IP via DNS lookups) at a smaller per-mechanism lookup cost (1 lookup for a:, ≤10 MX host lookups for mx:); (v) the operator-side budget-recovery playbook when an SPF record HISTORICALLY published ptr mechanisms is to migrate to ip4: / ip6: explicit IP literals whose evaluation cost is ZERO lookups — the receiver-side FCrDNS verification the ptr mechanism formerly leveraged is still performed by every major mailbox-provider receiver independent of SPF, so the publisher's switch from ptr to ip4: / ip6: does NOT remove the receiver-side IP-identity-validation gate, only the SPF-budget-expensive way of consuming it. Read the reverse-DNS-PTR spoke when an SPF lookup-budget audit reveals an active ptr mechanism in a legacy SPF record — the spoke documents the receiver-side FCrDNS verification protocol that operates IN PARALLEL with SPF and that the publisher's SPF migration away from ptr does NOT disable.
• DKIM best practices - the SPF-10-LOOKUP-DISCIPLINE-AS-ENVELOPE- LAYER-OPERATOR-DISCIPLINE-PARITY-WITH-DKIM- 13-RULE-APPLICATION-LAYER-OPERATOR- DISCIPLINE companion documenting the platform-agnostic 13-rule DKIM operator- discipline synthesis that is the structurally-analogous APPLICATION-LAYER operator-discipline companion to this SPF-lookup-limit ENVELOPE-LAYER pillar. Where THIS page documents the SPF ENVELOPE-LAYER operator-discipline (the RFC 7208 §4.6.4 10-DNS-lookup budget ceiling, the per-mechanism lookup-cost accounting for include: / a: / mx: / ptr: / exists: / redirect=, the void-lookup secondary cap, the flattening + ip4/ip6 materialisation remediations, the pre-publication record-lookup-count verification workflow, the post-publication recursive-resolver cache-aging discipline), the DKIM-best-practices spoke is the STRUCTURALLY-ANALOGOUS APPLICATION-LAYER operator-discipline companion documenting the 13 rules EVERY DKIM-publishing operator must internalise as the message- content authentication-layer counterpart to this page's envelope-layer SPF operator-discipline: the 2048-bit RSA / Ed25519 algorithm floor, the per-selector key-isolation rule, the 6-to-12-month rotation cadence, the relaxed-relaxed canonicalisation default, the x= expiration discipline for replay-mitigation, the post-DMARC alignment-with-DMARC discipline, the DKIM-failure-monitoring discipline via RUA aggregate reports, and the seven-additional-rules covering selector hygiene, public-key retirement, signing-algorithm migration, and the platform-portability discipline. The two operator-discipline checklists are STRUCTURALLY ANALOGOUS at distinct OSI layers — SPF publishes a TXT record + a receiver-side recursive-lookup engine + a 10-lookup budget enforcement at the envelope-MAIL-FROM authentication- boundary, DKIM publishes a TXT signature-verification key + signs message-content + receiver-side body-hash + header-hash verification at the message-content authentication- boundary — and operators running the SPF envelope-layer 10-lookup operator- discipline this page documents SHOULD also run the 13-rule DKIM APPLICATION-LAYER operator-discipline to close the SPF + DKIM + DMARC authentication posture that NEITHER protocol achieves alone. Read the DKIM-best-practices spoke when scoping the application-layer operator- discipline that runs at the orthogonal- protocol-layer sibling to this page's SPF envelope-layer operator-discipline — the 13-rule checklist is the rubric against which the operator's DKIM-publishing posture is evaluated for parity with the SPF envelope-layer operator-discipline documented here.
• DMARC record tags explained - every tag in the DMARC DNS record. The p= tag determines what happens to mail that fails DMARC because of an SPF permerror.
• DMARC troubleshooting - the operational diagnostic guide for DMARC failures including the SPF permerror cascade.
• DMARC myths and misconceptions - the SPF-10-DNS-LOOKUP-LIMIT-AS-PER- MISCONCEPTION-CANONICAL-REFERENCE companion to this RFC 7208 §4.6.4 ten-DNS-lookup budget deep dive. Where THIS page documents the receiver-side §4.6.4 lookup-counting contract (include:, a:, mx:, ptr:, exists:, redirect= each cost 1 lookup; ip4: and ip6: cost 0; nested includes recurse with each level counting) and the §4.6.4 void- lookup cap (max 2 lookups returning NXDOMAIN or empty), the myths-and-misconceptions spoke is the STAKEHOLDER-EDUCATION-AGAINST- SPF-LOOKUP-BUDGET-FALSE-MENTAL-MODELS reference that debunks the operator-side misconceptions about lookup-budget accounting that drive incorrect SPF-record authoring decisions. The SPF-LOOKUP-BUDGET- MISCONCEPTION-DEBUNKING cross-reference establishes FOUR structurally-distinct dimensions where the myths spoke debunks operator-side misconceptions about the budget-accounting discipline THIS page's RFC 7208 §4.6.4 byte-counting catalogue is the canonical reference for: (i) "include: cascades are functionally unlimited as long as the record validates" misconception → debunked by the RFC-7208-§4-6-4-HARD-CEILING-AT-10- TERMINATES-WITH-PERMERROR class — operators new to SPF authoring frequently treat the receiver-side include-cascade recursion as a depth-unbounded mechanism as long as the published record SYNTACTICALLY validates against the SPF grammar; the myths spoke documents the RFC 7208 §4.6.4 receiver-side hard 10-DNS- lookup ceiling — when the receiver hits the 11th lookup during evaluation it STOPS and emits spf=permerror, which DMARC then EVALUATES as a hard authentication failure under aspf= alignment-mode semantics — debunking the operator's "syntactic-validation ≡ runtime-evaluation-success" mental model with the per-receiver-DNS-budget- accounting operational truth this page's §4.6.4 catalogue documents in byte-level detail; (ii) "spf=permerror is a receiver-side noise verdict that doesn't affect my deliverability" misconception → debunked by the SPF-PERMERROR-CASCADES- INTO-DMARC-VERDICT-AT-aspf-EVALUATION- AND-INTO-POLICY-MODE-ENFORCEMENT class — operators reading the periodic spf=permerror verdicts in their aggregate-report data frequently dismiss them as receiver-side noise that affects only "diagnostic visibility" without runtime consequence; the myths spoke documents the per-RFC-7489-§4-2 cascade where spf=permerror propagates into the DMARC aspf= alignment evaluator as a HARD AUTH FAILURE, then into the publisher's p= policy-mode enforcement contract — at p=quarantine or p=reject the consequence is per-message inbox-routing-to-spam or outright-rejection — debunking the operator's "permerror is diagnostic noise" mental model with the cascades-into-publisher-policy-mode- enforcement architectural truth THIS page's §4.6.4 ten-lookup-ceiling catalogue is the publisher-side prevention reference for; (iii) "ip4: / ip6: don't count against the budget so flattening is the universal solution" misconception → debunked by the FLATTENING-CREATES-STALE-IP-AND- CIDR-MAINTENANCE-DEBT class — operators at the 10-lookup ceiling frequently reach for the "flatten the cascade by inlining every IP block directly as ip4:/ip6: terms" remediation as a one-shot fix because ip4:/ip6: don't count against the budget; the myths spoke documents the per-third- party-sender ROTATION discipline (Mailchimp / SendGrid / Amazon SES / Mailgun all rotate IP egress allocations on quarterly+ cadences) where the flattened record becomes STALE on the first IP allocation change, silently dropping legitimate sender traffic that was previously include:-cascade- authorized — debunking the operator's "flatten and done" mental model with the requires-CI-job-to-re-flatten-on- per-sender-rotation-cadence maintenance-debt architectural truth that frames flattening as a per- sender-rotation OPS-cost decision not a one-shot remediation; (iv) "PermError happens only at receivers, my publishing posture can't trigger it" misconception → debunked by the PUBLISHER-SIDE-VOID- LOOKUP-CAP-AT-2-MAX-ALSO-COUNTS-AS- PUBLISHER-AUTHORING-DEFECT class — operators authoring SPF records frequently believe that PermError is purely a receiver-side decision they cannot prevent without flattening; the myths spoke documents the RFC 7208 §4.6.4 void-lookup cap (≤2 lookups returning NXDOMAIN or empty across the entire evaluation) — a publisher authoring an include: chain where a sub-include's downstream sender has decommissioned a sub-domain producing 3+ void lookups in the cascade triggers spf=permerror regardless of whether the 10-lookup ceiling is reached — debunking the operator's "void lookups are external/receiver- side problems" mental model with the per-publisher-void-lookup-monitoring- is-publisher-responsibility operational truth this page's §4.6.4 deep-dive documents alongside the primary 10-lookup ceiling. Read the myths-and-misconceptions spoke alongside this SPF-10-DNS-lookup- limit RFC 7208 §4.6.4 reference when onboarding new SPF authors, when escalating budget-exhaustion remediation decisions to non-technical stakeholders, or when correcting operator-side false-mental-models that drive incorrect include-cascade / flatten / void-lookup decisions — the spoke is the canonical stakeholder- education reference whose four myth- debunking dimensions directly map to the SPF-budget-authoring decisions THIS page's §4.6.4 ten-lookup-ceiling catalogue is the publisher-discipline instrument for.
• DMARC for Microsoft 365 - the M365 deployment guide where include:spf.protection.outlook.com is one of the lookup costs.
• SPF for Microsoft 365 - the M365-specific SPF deep dive with the exact lookup accounting for spf.protection.outlook.com (it expands into a multi-level tree that consumes 3 of the 10 budget slots before you add anything else) and the canonical third-party-sender catalogue (Mailchimp, SendGrid, Mailgun, Salesforce, HubSpot, Amazon SES, Marketo, Zendesk) so you can precompute the total lookup count for any Exchange Online tenant's SPF record before publishing.
• DMARC for Google Workspace - the Workspace deployment guide where include:_spf.google.com is one of the lookup costs.
• SPF for Google Workspace - the Workspace-specific SPF deep dive with the exact lookup accounting for _spf.google.com (it expands to _netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com - 2 lookups for the include plus the recursive descents) and the canonical third-party-sender catalogue (Mailchimp, SendGrid, Mailgun, HubSpot, Salesforce, Amazon SES, Marketo, Zendesk) so you can precompute the total lookup count for any Workspace tenant's SPF record before publishing.
• DMARC for SaaS senders - the multi-ESP deployment guide where the 10-lookup limit becomes a binding constraint.
• DMARC for transactional email - the third-party-ESP deployment guide where each transactional sender's include consumes lookups.
• Email deliverability fundamentals — the SPF-PERMERROR-AS-DMARC-FAIL-ROOT- CAUSE-DELIVERABILITY-KPI-DEGRADATION companion to this SPF 10-DNS-lookup budget reference. The deliverability spoke is the business-outcome quantification layer that connects the SPF-permerror failure-mode THIS page documents as the publisher's operational ceiling (10-DNS-query budget breach) to the downstream deliverability-KPI degradation cascade at FOUR deliverability-KPI- vs-SPF-permerror causal-driver dimensions: (i) SPF permerror → DMARC fails → publisher's receiver-side positive-sender- reputation signal collapses at Gmail / Outlook / Yahoo / Apple iCloud / corporate-Exchange routing engines → inbox-placement-rate drops to spam-folder-routing baseline for the publisher's novel-sender / first-time-receipt population — the deliverability spoke documents how the SPF-permerror verdict THIS page documents as the publisher's structural-failure mode for an over-budget include- cascade causes the receiver-side DMARC evaluation to emit dmarc=fail (because BOTH the SPF half is structurally broken AND alignment cannot be evaluated in the absence of a definitive SPF verdict), which the receiver- side inbox-placement engines consume as a load-bearing NEGATIVE sender-reputation signal — the publisher's first-time- receipt-from-novel-sender mail to any of those receivers' user populations is routed to the spam folder rather than the inbox folder for the duration of the SPF-permerror window; (ii) SPF permerror at p=quarantine → quarantine-folder delivery → user-visible delivery-delay-and-recovery-cycle → complaint-rate spike from user-reported-as-junk events upstream from the operator's intent — the deliverability spoke documents the consequence chain when the publisher's policy is p=quarantine and the SPF budget is breached: receivers treat the dmarc=fail verdict as the publisher's enforcement- committed-quarantine intent, and route legitimate mail to the quarantine folder; users observe the legitimate mail in their junk folder and report-as-junk, which produces an upstream complaint-rate spike (counted against the publisher's IP-pool / domain- reputation), which produces a secondary downstream deliverability-KPI degradation independent of the original SPF-permerror trigger; (iii) SPF permerror at p=reject → outbound mail bounces with 5.7.1 rejection codes → bounce-rate spike to 100% for the affected sender stream → publisher's transactional-email pipeline delivery-failure for the SPF-permerror window — the deliverability spoke documents the catastrophic consequence chain when the publisher's policy is p=reject and the SPF budget is breached: receivers reject the legitimate mail with 5.7.1 DMARC-policy-rejection NDRs; the publisher's bounce-rate for the affected sender stream rises to 100% for the SPF-permerror window; the publisher's transactional- email pipeline (password resets, 2FA codes, order confirmations, invoices, receipts, calendar invitations) enters a complete delivery-failure state until the SPF permerror is remediated via one of the four remediation paths THIS page documents (audit, subdomain delegation, sender consolidation, monitored SPF flattening); (iv) SPF permerror post- remediation → reputation- recovery latency → inbox- placement-rate recovery does NOT happen the instant the SPF record is fixed because the receiver-side reputation engine carries an N-day decay window — the deliverability spoke documents how the inbox- placement-rate KPI does NOT snap back to the pre- permerror baseline the instant the publisher fixes the SPF record, because the receiver-side reputation engines (Gmail's per- sender reputation score, SmartScreen, M3AAWG- published heuristics) decay observed negative signal over an N-day rolling window (typically 14-30 days at Gmail / Outlook); the deliverability spoke provides the REMEDIATION-LATENCY playbook for restoring inbox-placement-rate to pre-permerror baseline, which is the BUSINESS- OUTCOME complement to the TECHNICAL-FIX runbook THIS page documents. Read the deliverability spoke WITH this page when designing the SPF- permerror incident- response playbook OR when building the executive case for proactive SPF budget hygiene — THIS page is the protocol-level budget-and-remediation reference; the deliverability spoke is the business-outcome consequence-chain reference that justifies the investment in proactive remediation BEFORE the budget is breached.
• DMARC for shared hosting (cPanel / Plesk / DirectAdmin / ISPConfig) - the SHARED-HOSTING-PROVIDER-INCLUDE-CHAIN-CONSUMPTION-OF-SPF-10-LOOKUP-BUDGET-AT-CPANEL-PLESK-DIRECTADMIN-ISPCONFIG-TENANT-CUSTOMER-EGRESS companion documenting the shared-hosting deployment whose provider-published SPF-include (e.g. include:spf.cpanel.net, include:_spf.spamexperts.com, include:spf.directadmin.com, include:_spf.ispconfig.org) consumes ~2 to 3 of the 10 SPF lookup slots before the tenant customer adds any SaaS-sender includes - making lookup-budget exhaustion the single most common SPF=permerror root cause for shared-hosting tenants, and the provider-include's nested A / MX sub-mechanisms expanding under recursive lookup descent makes the per-tenant budget visibility opaque without an explicit flattening audit. The page documents the cPanel-side SPF authoring UI quirks (the "Email Routing" panel's auto-generated SPF record, the per-account SPF-include vs WHM-tenant- wide-SPF-include layering pattern, the "use server-wide SPF record" toggle's implications for per-tenant lookup accounting), the Plesk-side SPF authoring UI quirks (the "Mail Settings → DNS Settings → SPF" panel's nested-include layering, the per-subscription SPF-record scoping), the DirectAdmin-side SPF authoring UI quirks (the "DNS Management → SPF Record" wizard's mechanism-chain builder), the ISPConfig-side SPF authoring UI quirks (the "DNS → Records → TXT" panel's manual SPF authoring), and the canonical SaaS-sender catalogue (Mailchimp, SendGrid, Mailgun, HubSpot, Salesforce, Amazon SES, Marketo, Zendesk) the shared-hosting tenant must reconcile with the provider-include's pre-consumed lookup slots so the total SPF lookup count for the tenant's published record does not exceed 10.
• DMARC multi-domain strategy - the PER-DOMAIN-SPF-LOOKUP-BUDGET- CONSUMPTION-AT-PORTFOLIO-SCALE companion documenting the structurally-distinct portfolio-level SPF authoring challenge that emerges when a single org publishes SPF records across many portfolio domains (primary brand, secondary brands, parked domains, legacy-acquisition domains, redirector domains, sub-brand SaaS domains) and EACH portfolio domain inherits its own independent 10-DNS-lookup budget but the org's portfolio-shared SaaS-sender catalogue (Mailchimp, SendGrid, Mailgun, HubSpot, Salesforce, Amazon SES, Marketo, Zendesk, Postmark, SparkPost, plus the org's own transactional and marketing infrastructure) must be allocated to each portfolio domain's SPF record without budget exhaustion. Where THIS page documents the per-record 10-lookup ceiling mechanics from RFC 7208 section 4.6.4 and the SPF flattening / macro-factoring techniques to stay under it for a SINGLE record, the multi-domain- strategy spoke is the PORTFOLIO-LEVEL-SPF-AUTHORING-ARCHITECTURE companion documenting how the operator structures the org-wide SPF authoring posture across N portfolio domains: (i) ORG-SHARED-INCLUDE-MACRO factoring (publish a single _spf-shared.example.com macro-include record consumed by all portfolio domains, so a vendor-onboarding change in the org-shared SaaS catalogue propagates atomically across every portfolio sibling's published SPF without per-domain republication), (ii) PER-BRAND-SAAS-INCLUDE allocation (when only ONE portfolio brand uses a given SaaS vendor — e.g. only the marketing-primary brand uses Mailchimp, only the support-secondary brand uses Zendesk, only the transactional-domain uses Postmark — the per-brand SaaS-include should NOT be promoted into the org-shared macro to avoid burning lookup budget on all portfolio siblings for one brand's usage), (iii) PORTFOLIO-WIDE-LOOKUP-AUDIT cadence (the operator must run a periodic portfolio-wide SPF-lookup-count audit across ALL N portfolio domains because the per-domain budget exhaustion failure modes are STRUCTURALLY-DIFFERENT — a single primary-brand domain over-budget is immediately visible at the p=reject brand-trust-tier, but a parked-domain or legacy-acquisition-domain over-budget can sit at p=none for months producing silent SPF-permerror RUA rows that the operator never triages until an attacker exploits the brand-portfolio weakest-link), (iv) PARKED-DOMAIN-NULL-MX-PLUS-NULL-SPF portfolio-default-posture (RFC 7505 Null-MX 0 . plus v=spf1 -all is the canonical parked-domain SPF posture that consumes ZERO lookup budget while still publishing an authoritative refusal, and the multi- domain strategy spoke documents the portfolio-default-posture pattern for every brand-portfolio sibling that does not legitimately send mail). Read the multi-domain-strategy spoke alongside this SPF-lookup-limit page when scoping the portfolio-level SPF authoring posture — the per-record lookup-limit mechanics documented here become the BUILDING-BLOCK repeated across every portfolio sibling, and the multi-domain-strategy spoke provides the PORTFOLIO-COMPOSITION-AND-AUDIT-CADENCE meta-discipline preventing the weakest-link portfolio sibling from becoming the silent SPF-permerror failure mode the attacker pivots to.
• DMARC monitoring - the operational monitoring guide. Tracking the live SPF lookup count is one of the standard health checks.
• Email authentication glossary - definitions of permerror, void lookup, flattening, and the other vocabulary used on this page.
• Email security glossary — the SPF-LOOKUP-LIMIT-VOCABULARY- RESOLVES-TO-EMAIL-SECURITY-VOCABULARY- DICTIONARY companion to this RFC 7208 §4.6.4 SPF-lookup-budget operator reference. Where THIS page introduces the per-mechanism DNS-lookup-budget accounting (the 10-lookup ceiling across include:, a, mx, exists:, redirect=, and ptr mechanisms; the void- lookup cap at 2 per RFC 7208 §4.6.4; the flattening operator-tool ecosystem for budget-exhausted publishers; the nested-include cascade depth at SaaS relay platforms), the Email security glossary spoke is the canonical email- security term-dictionary whose entries resolve THIS page's SPF-lookup-budget vocabulary into cross-cluster terminology. The SPF-LOOKUP-BUDGET- VOCABULARY-RESOLVES-TO-GLOSSARY cross- reference establishes FOUR structurally- distinct lookup-budget-vs-protocol- artifact resolution dimensions: (i) per-mechanism lookup-budget cost vocabulary resolves to glossary SPF-mechanism dictionary entries — the per-mechanism cost accounting (include: = 1 + downstream-recursive lookups, a = 1, mx = 1 + N-MX-record-A-lookups, exists: = 1, redirect= = 1 + downstream-recursive lookups, ptr = 1 + N-PTR-target- A-record-verification-lookups) that THIS page documents have glossary entries documenting the canonical cross-cluster vocabulary used uniformly across SPF-mechanisms-explained / include-vs-ip4-vs-a-vs-mx / SPF- forwarding-issues pages; (ii) void-lookup vocabulary resolves to glossary DNS-NXDOMAIN / DNS-rcode-3-resolver-attribution dictionary entries — the per- class attribution (NXDOMAIN on decommissioned vendor's include:-target domain, DNS-zone-misconfiguration with empty TXT record, anycast-resolver inconsistent NXDOMAIN attribution under the RFC 7208 §4.6.4 void-lookup cap of 2) that THIS page documents have glossary entries resolving the cross-protocol parallels (parallel DNS-failure-mode handling at MX-records / DMARC-record-lookup / DKIM-key-lookup / DANE-TLSA-lookup); (iii) flattening operator-tool vocabulary resolves to glossary lookup-budget- recovery / publisher-side-pre-resolution dictionary entries — the per- class flattening-operator vocabulary (publisher-side recursive pre- resolution of all include: chains into a single layer of ip4:/ip6: mechanisms; tools like spf-tools, DMARCLY, EasyDMARC, Mailhardener; tradeoffs between upstream-vendor-IP-rotation-tracking cost vs lookup-budget-recovery benefit) that THIS page documents have glossary entries documenting cross-cluster vocabulary used uniformly across SaaS- senders / multi-domain-strategy / shared-hosting / hybrid-topology operator-tool catalogues; (iv) nested-include cascade vocabulary resolves to glossary SaaS- relay-platform-aggregated-budget / per-vendor-include-cost dictionary entries — the per-class nested-cascade vocabulary (SendGrid's include:sendgrid.net = 4-lookup cost, Mailgun's include:mailgun.org = 2-lookup cost, SES's include:amazonses.com = 2-lookup cost, Salesforce's include:_spf.salesforce.com = 5-lookup cost, Microsoft 365's include:spf.protection.outlook.com = 1-direct-lookup) that THIS page documents have glossary entries documenting the cross-cluster vocabulary used uniformly across SaaS- senders / Microsoft-365-deployment / Google-Workspace-deployment / multi- domain-strategy pages. Pair this page (the SPF-lookup-budget operator reference) with the Email security glossary spoke (the canonical email- security vocabulary dictionary) when introducing the 10-DNS-lookup-budget concept to operators new to SPF — the glossary's term-dictionary provides the cross-cluster vocabulary that THIS page's per-mechanism budget- accounting composes into the broader SaaS-deployment / DNS-publication / DMARC-troubleshooting terminology landscape.
• SPF permerror vs temperror - the SPF-LOOKUP-LIMIT-OVERLIMIT- PERMERROR-PRIMARY-CAUSE companion to this SPF-lookup-limit-and-flattening page. Where THIS page documents the RFC 7208 §4.6.4 10-DNS-lookup budget, the per-mechanism lookup-cost accounting, the include-flattening + ip4/ip6 materialisation remediations, and the SPF-record-budget pre-publication verification workflow, the permerror-vs-temperror spoke is the RECEIVER-SIDE-EVALUATION companion documenting the FOUR distinct receiver-side SPF outcome classes the over-budget condition surfaces as: (i) permerror — the canonical and permanent over-budget outcome the lookup-limit produces ("permanent error" because additional retries cannot recover from a record that exceeds the static 10-lookup cap; the receiver MUST treat the SPF check as "permanently fail-to-evaluate" per RFC 7208 §2.6.7); (ii) temperror — the TRANSIENT-DNS-FAILURE outcome the receiver returns when an authoritative nameserver in the lookup chain times out or returns SERVFAIL during the evaluation (per RFC 7208 §2.6.6 — different from permerror because retries CAN succeed and DMARC engines treat temperror as non-fatal vs permerror's fatal-no-alignment treatment); (iii) none — the receiver-side outcome when no SPF record exists at all (distinct from permerror because it indicates absence rather than malformed-or-overbudget configuration); (iv) neutral — the receiver-side outcome when the SPF record evaluates to ?all or the sending IP matches a ?-qualified mechanism (per RFC 7208 §4.7 — distinct from permerror because it indicates the policy author EXPLICITLY DEFERRED the IP-authorisation decision rather than failing to evaluate). Read the permerror-vs-temperror spoke alongside this page when an operator's SPF record is approaching the 10-lookup budget and they need the receiver-side diagnostic catalogue to distinguish permerror (over-budget structural failure — requires record-side remediation) from temperror (transient DNS-infrastructure failure — typically resolves on retry without record-side intervention) when interpreting RUA report rows showing spf=permerror vs spf=temperror.
• Email spoofing - the SPF-PERMERROR-COLLAPSE-AS-STRUCTURAL- SPOOFING-BYPASS companion to this SPF-lookup- budget deep dive. Where THIS page documents the 10-DNS-lookup recursion cap (RFC 7208 §4.6.4 — the receiver's SPF evaluator MUST track every include:, a:, mx:, exists:, ptr:, redirect=, and recursive expansion thereof against a hard cap of 10 — exceeded → permerror) and the secondary void-lookup cap (≤2 RCODE 0 empty-answer responses — exceeded → permerror) and the per-include recursion-overflow pathology where adding a single include: to a marginally-under-budget record pushes it permanently over the cap, the email- spoofing spoke is the ATTACKER-PERSPECTIVE companion documenting WHY the permerror collapse creates a STRUCTURAL spoofing window the publisher cannot defend against without remediating the lookup-budget exceedance: (i) RFC 7489 §4.2 DMARC alignment evaluation treats spf=permerror as "no SPF policy applicable" for purposes of the SPF-aligned-pass test — the receiver cannot establish that the message originated from a publisher-authorized IP because the publisher's SPF record itself cannot be evaluated, and the receiver MAY (per implementation choice) fall back to DKIM-only alignment OR may apply the publisher's p= policy as if SPF were missing entirely; (ii) at receivers that fall back to DKIM-only evaluation, an attacker forging the From: as the publisher's domain from an arbitrary IP succeeds at SPF-permerror-collapse bypass IF the receiver's DKIM verification cannot complete (the attacker omits any DKIM signature, sending an unsigned message — DKIM evaluates as none, alignment evaluates as no aligned mechanism, and the receiver applies the publisher's p=quarantine or p=reject policy — but at p=none publishers, the message is delivered to the recipient inbox); (iii) at receivers running asymmetric SPF / DKIM evaluation under operationally- common DMARC implementations, an attacker forging the From: from a residential proxy / freshly-rented VPS / botnet IP can bypass SPF entirely if the publisher's SPF record is in permerror state — the SPF rejection that should have fired the moment the attacker connected from a non-authorized IP simply does not fire because the receiver cannot evaluate the SPF record at all; (iv) the OPERATIONAL signal in RUA aggregate reports that this spoofing window is active is a sudden increase in spf=permerror / dkim=none rows for the publisher's domain — the email-spoofing spoke documents the per-spoofing-variant RUA-row detection signatures alongside the per-variant remediation playbooks. Read the email-spoofing catalogue when authoring the SPF-lookup-budget operational urgency rationale — a marginally-under-budget SPF record is one third-party SaaS-vendor onboarding away from collapsing the publisher's entire SPF-based spoofing defense at receivers, and the SPF-lookup- budget remediation is therefore a STRUCTURAL anti-spoofing control rather than merely a DNS-hygiene matter.
• Phishing protection (defense-in-depth catalogue) — the SPF-10-DNS-LOOKUP-LIMIT-OVERLIMIT- PERMERROR-AS-PHISHING-PROTECTION- DEGRADATION-VECTOR companion to this RFC 7208 §4.6.4 10-DNS-lookup-budget reference. Where THIS page documents the receiver-side SPF evaluator's hard 10- DNS-lookup cap (every include:, a:, mx:, exists:, ptr:, redirect= mechanism + recursive expansion counts; exceeded → permerror) and the secondary void-lookup ≤2 cap, the phishing-protection spoke documents the LAYERED DEFENSE-IN- DEPTH CONTROL CATALOGUE in which the per- message envelope-MAIL-FROM-layer SPF pass- rate is one of TWO authentication-layer load-bearing controls (SPF + DKIM) whose joint pass-rate determines whether DMARC alignment fires at receivers. FIVE structurally-distinct SPF-LOOKUP-LIMIT- OVERLIMIT-VS-PHISHING-CONTROL operational classes the spoke catalogues that THIS DNS-budget reference intentionally elides: (i) per-publisher SPF-lookup- overlimit collapses the envelope-layer phishing-defense control at every receiving organisation worldwide — the publisher's SPF record entering permerror state because a third-party SaaS-vendor onboarding pushed the include: cascade over the 10-DNS- lookup ceiling produces a STRUCTURAL phishing window where the receiver-side SPF evaluator cannot establish IP authorisation, so cousin-domain impersonation phishing from arbitrary attacker-controlled IPs bypasses the envelope-layer authentication control entirely; (ii) per-publisher SPF-permerror collapses the BIMI display- eligibility prerequisite at receivers — the publisher's BIMI logo display requires DMARC-at-enforce-PASS for the message, which requires either SPF- aligned-pass OR DKIM-aligned-pass, so a permerror collapse degrades the user- awareness-layer phishing-protection control (the user no longer sees the brand logo their training teaches them to look for); (iii) per-publisher SPF-lookup-overlimit forces sole reliance on DKIM-only alignment, multiplying the DKIM-replay-attack and DKIM-key-rotation- gap exposure surface — the phishing-protection spoke catalogues the DKIM-only-fallback failure modes that an SPF-permerror publisher inherits when DKIM-signing infrastructure has key- rotation gaps, third-party-signer mis- configuration, or signed-header-list under-coverage; (iv) per- publisher SPF-permerror creates an observable RUA-aggregate-report signal the receiver-side defense-in-depth monitoring layer can detect — the phishing-protection spoke documents how a sudden spike in spf=permerror aggregate- report rows for the publisher's domain is a high-priority alarm-fire signal for the security team's phishing- defense-degradation monitoring workflow, because the spike marks the moment the envelope-layer control was lost; (v) SPF-lookup-budget-discipline as STRUCTURAL anti-phishing operator- discipline rather than DNS-hygiene matter — the phishing- protection spoke positions SPF-lookup- budget remediation as a security- critical operator-discipline whose absence creates STRUCTURAL phishing windows attackers exploit. Read the phishing-protection spoke alongside this SPF-lookup-budget reference when authoring the security-team's phishing- defense threat-model — the spoke maps the SPF-permerror collapse onto the concrete phishing-TTP class (T1566 phishing, T1583.001 acquire- infrastructure cousin-domain registration, T1071.003 application- layer-protocol-mail-protocols) the envelope-layer authentication-control loss enables.
• Why SPF alone is insufficient — the SPF-10-DNS-LOOKUP-LIMIT-AS- OPERATIONAL-LOAD-BEARING-EVIDENCE-OF-THE- SPF-ALONE-INSUFFICIENT-THESIS companion to this RFC 7208 §4.6.4 ten-DNS-lookup budget reference. Where THIS page documents the per-mechanism lookup-cost accounting + the permerror cascade + the flattening playbook, the SPF-alone-insufficient thesis page is the STRUCTURAL-PROTOCOL-LEVEL companion that synthesises the operator-facing argument WHY SPF was never designed to carry the email- authentication posture alone — and the 10-DNS-lookup ceiling THIS page is the reference for is one of the canonical concrete load-bearing pieces of evidence at FOUR structural-protocol-constraint dimensions: (i) the 10-DNS-lookup ceiling itself proves SPF cannot scale to enterprise sender catalogues — any non-trivial multi- vendor publisher (M365 + Mailchimp + SendGrid + Salesforce + Amazon SES + Marketo + Zendesk + the org's own transactional infrastructure) cannot express their full authorised-sender catalogue within the 10-lookup budget the RFC 7208 §4.6.4 ceiling enforces, structurally forcing the publisher to ADOPT DKIM as the per-message companion-mechanism for senders excluded from the lookup-budget; (ii) multi-vendor deployment is the canonical forcing function that demonstrates the SPF-alone-insufficient thesis in production — operators arriving at the 10-cap permerror cascade discover by operational necessity that SPF cannot carry the authentication posture alone for their sender-catalogue, prompting the same DKIM- adoption + DMARC-alignment posture the SPF-alone-insufficient thesis page argues from first principles; (iii) forwarder- independence failure is the second structural evidence-class — even when within the 10-lookup budget, SPF fails on forwarding paths (mailing-list rewrites of MAIL FROM, ARC-sealed forwards, alias-redirects, simple forwarding services) because SPF's envelope- layer binding to authorised IPs cannot survive the forwarder's source-IP substitution, the SECOND structural reason SPF alone is insufficient that the thesis page catalogues alongside the lookup-budget cap; (iv) receiver-fallback path to DKIM-only alignment is the operational footprint of the SPF-alone-insufficient thesis at the receiver- side DMARC evaluation algorithm — when SPF permerrors (whether via lookup-budget exhaustion or forwarder collapse), the DMARC RFC 7489 §4.2 evaluation algorithm depends entirely on DKIM-pass + DKIM-aligned to produce a DMARC-pass disposition, structurally proving DKIM is the load-bearing authentication-evidence channel at every message where SPF alone would have failed. Read the SPF-alone-insufficient thesis page alongside this lookup-budget reference when authoring the operator's email-authentication deployment strategy — the thesis page documents the first-principles argument WHY the operator must publish SPF + DKIM + DMARC together rather than SPF alone, and THIS page documents the operationally-load-bearing 10-DNS-lookup ceiling that is one of four canonical structural reasons the SPF-alone posture cannot scale to enterprise sender catalogues.
• DKIM selectors explained - the DKIM-PER-SELECTOR-PUBLICATION-AS- ZERO-SPF-LOOKUP-BUDGET-IMPACT-RESCUE- PATH-FOR-EVERY-PERMERROR-PRONE-MULTI- TENANT-SENDER-WHOSE-SPF-INCLUDE-CASCADE- EXCEEDS-THE-10-LOOKUP-CEILING companion to this SPF 10-DNS-lookup-budget reference. Where THIS page documents the operationally- load-bearing RFC 7208 §4.6.4 10-DNS-lookup ceiling whose breach causes receiver-side SPF permerror and the per- publisher mitigation strategies (SPF flattening, per-tenant include:-cascade restructuring, per-source-IP / per-ESP attribution triage), the DKIM-selectors-explained spoke is the MESSAGE-LAYER per-publisher per- selector authentication-record publication- discipline reference documenting how the DKIM-side authentication path provides a ZERO-SPF-LOOKUP-BUDGET-IMPACT rescue path for every multi-tenant sender whose SPF include:-cascade exceeds the 10-DNS-lookup ceiling, at FOUR per-DKIM- selector-to-SPF-lookup-budget-impact dimensions: (i) per-publisher per- selector DKIM lookup-cost DOES NOT count against the RFC 7208 §4.6.4 10-DNS-lookup ceiling — DKIM verification produces ONE per-message per-signature DNS lookup at <selector>._domainkey.<d-tag> which is the receiver-side message-layer signature-verification operation, NOT the receiver-side envelope-MAIL-FROM SPF evaluation operation; the DKIM- selectors-explained spoke documents the per-selector forward-DNS publication discipline AND the receiver-side validator operation that produces the DKIM lookup, confirming that the 10-DNS-lookup ceiling THIS page architects against is exclusively the SPF receiver-side recursive-evaluation budget, not a generic per-message DNS- lookup budget; (ii) per-tenant selector partitioning as the DKIM-side per-tenant-ESP-attribution rescue path for SPF-include:-cascade partitioning the 10-DNS-lookup ceiling forces a publisher to collapse — the DKIM-selectors-explained spoke documents per-tenant selector partitioning (one selector per signing tenant / per-ESP / per-marketing-platform / per- transactional-pipeline) which gives the publisher per-tenant DMARC-alignment- verdict attribution and per-source-IP DKIM-pass-row attribution WITHOUT the per- tenant include:-cascade DNS lookup cost the SPF 10-lookup ceiling forces collapse on; (iii) per- DKIM-selector publication-discipline survives the canonical SPF mitigation strategies (SPF flattening, include:-cascade restructuring, per-ESP delegation collapse) without regression — the DKIM-side message-layer per-tenant attribution remains intact EVEN WHEN the SPF-side envelope-MAIL-FROM attribution is collapsed by the mitigation strategies THIS page architects; the DKIM-selectors-explained spoke documents per-selector publication- discipline as the message-layer auth path that survives every SPF-side mitigation the 10-lookup ceiling forces; (iv) per-DKIM-selector publication- discipline provides the message-layer DMARC-alignment input that does NOT depend on a successful SPF evaluation — DMARC alignment passes if EITHER SPF From-aligned-pass OR DKIM d=-aligned-pass succeeds per RFC 7489 §3; the DKIM-selectors- explained spoke documents per-selector publication as the message-layer DMARC- alignment input the publisher relies on when the SPF-side path is in permerror from a 10-DNS- lookup breach this page architects against. Read the DKIM-selectors-explained spoke alongside this SPF 10-DNS-lookup- budget reference when designing the per- publisher mitigation runbook — the spoke documents the per-tenant selector partitioning publication-discipline whose zero-SPF-lookup-budget-impact message- layer authentication path provides the load-bearing rescue path for every multi- tenant sender whose SPF cascade exceeds the 10-lookup ceiling THIS page architects against.
• Business Email Compromise (BEC) - the SPF-LOOKUP-LIMIT-PERMERROR-AS- LOAD-BEARING-BEC-DMARC-BYPASS-EXPLOITATION- VECTOR companion to this SPF lookup-cap reference. Where THIS page documents the RFC 7208 §4.6.4 10-DNS-lookup cap, the recursive include: cascade evaluation, the void-lookup secondary cap, the SPF-permerror emission discipline at overflow, and the per-publisher per-domain SPF-flattening + SPF-record-partitioning publication disciplines, the business-email-compromise spoke documents the canonical BEC financial- fraud-attack-category catalogue (six canonical variants per FBI IC3 USD 2.9B reported 2023 loss + USD 55B+ cumulative since 2013) and the per-variant defense-in-depth control stack whose SPF-PUBLICATION-LAYER FOUNDATION is the SPF-lookup-budget discipline THIS page documents — at four SPF-permerror-to-BEC- exploitation coupling dimensions: (i) SPF-permerror-emission-causes- receiver-side-SPF-aligned-pass-path- elimination as BEC-DMARC-bypass exploitation opportunity — when a publisher's SPF cascade overflows the 10-lookup budget and emits SPF-permerror at the receiver-side, the per-message DMARC evaluation loses the SPF-aligned-pass evaluation path (only the DKIM-aligned-pass path remains); the BEC attacker who can exploit DKIM-publication- discipline-gaps (selector-not-yet-published, rotation-mid-flight cutover, weak-key- cryptography) gains a per-message DMARC- verdict bypass opportunity that would NOT exist absent the SPF-permerror; (ii) per-publisher SPF-overflow observability gap as BEC-campaign-evasion window — the per-publisher SPF cascade depth is OPAQUE to publisher-side operator-monitoring absent the domain_checker reference THIS page directs the operator to consult; the BEC attacker who can detect a publisher's SPF-permerror- emission state (via the publisher's own rua aggregate-XML stream the attacker may not have, or via a separate per-receiver Authentication-Results header observation) gains a per-publisher BEC-campaign-launch- window before the publisher fixes the SPF cascade; (iii) BEC vendor-invoice- fraud per-supplier-domain SPF-permerror- exploitation pattern — the BEC vendor / supplier-invoice fraud variant the spoke documents (attacker-controlled supplier-impersonation requesting wire- transfer-rerouting to an attacker-controlled IBAN) is structurally easier when the impersonated supplier-domain publishes an SPF-permerror-prone cascade — the SPF- aligned-pass elimination removes ONE of the TWO DMARC-evaluation paths and the BEC attacker's downstream-spoofing succeeds absent the SPF-aligned-pass evaluation gate; (iv) per-publisher SPF-flattening + SPF-record-partitioning publication- discipline as per-publisher BEC-defense outbound-cascade-hygiene primitive — the per-publisher SPF-cascade-flattening + per-subdomain SPF-record-partitioning publication disciplines THIS page documents are the load-bearing per-publisher BEC- defense outbound-SPF-cascade-hygiene primitives that prevent the per-publisher per-domain SPF-permerror emission state from becoming a BEC-attacker-exploitable DMARC-bypass window. Read the BEC spoke ALONGSIDE this SPF-lookup-cap reference whenever the per-publisher per-domain SPF- publication-discipline-posture is being scoped for BEC-financial-fraud-campaign- defense coverage — the SPF-lookup-budget discipline THIS page documents IS the SPF- PUBLICATION-LAYER primitive the BEC defense- in-depth-control-stack the BEC spoke documents structurally consumes at every per-receiver per-message DMARC-evaluation boundary that includes the SPF-aligned-pass path as one of the two DMARC-verdict evaluation paths.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC. Reports the recursive SPF lookup count and flags records over budget.
• Email Header Analyzer - paste a message's headers and see the Authentication-Results decoding, including the SPF permerror reason text.
• DNS Record Generator - model a slim SPF record before publishing it.
• DMARC attacker-bypass techniques (defender's red-team catalogue) — the SPF-10-DNS-LOOKUP-LIMIT-PERMERROR-AS- LOAD-BEARING-DMARC-BYPASS-VECTOR-COLLAPSING- THE-SPF-LEG-OF-THE-RFC-7489-OR-CONJUNCTION companion to this SPF lookup-limit reference. Where THIS page documents the RFC 7208 §4.6.4 10-DNS-lookup cap + the void-lookup secondary cap + the permerror result class the cap breach produces, the DMARC-attacker-bypass spoke is the OPERATOR-SIDE 22-technique attacker-bypass classification framework whose SPF-PERMERROR-INDUCTION technique class consumes the lookup-limit-permerror SPF-half-collapse primitive at FOUR permerror-induction-and-exploitation- dimensions: (i) attacker-induced SPF-include-cascade-permerror via supply- chain-poisoning of a downstream ESP's SPF record — the attacker compromises or manipulates a transitively-included third- party SPF record (an ESP, a CRM platform, a transactional mail platform) to inflate its include-cascade past the receiver-side 10-DNS-lookup cap, producing per-message spf=permerror at every downstream-publisher receiver evaluation, collapsing the SPF leg of the RFC 7489 §6.6.2 DMARC OR-conjunction and leaving the DKIM leg as the sole load-bearing DMARC-pass path — the attacker-bypass spoke documents this as the canonical supply-chain SPF-half-collapse attacker-bypass class; (ii) per- receiver per-source-IP per-day aggregate- report row/auth_results/spf/result=permerror distribution as the SOC-side attacker- bypass-detection signal the attacker-bypass spoke documents as the canonical detection- layer evidence-row pattern — the spoke documents how SOC analysts cross- correlate per-receiver per-source-IP per- day spf=permerror surge evidence with upstream ESP-or-transitive-SPF-publisher configuration-change events to attribute the permerror surge to upstream-supply-chain compromise vs publisher-side legitimate configuration-change; (iii) per- publisher per-domain SPF-flattening mitigation discipline as the canonical attacker-bypass-defense control the attacker-bypass spoke documents as protective control class — the spoke documents per-publisher per-domain SPF- flattening deployment discipline (using third-party flattening services that materialise the transitive include-cascade into a flat ip4/ip6 list bounded by the budget) as the LOAD-BEARING per-publisher defense against supply-chain SPF-permerror- induction attacker-bypass attempts — the spoke is the canonical defender-side deployment-discipline reference; (iv) per-publisher per-domain bounded- include-cascade publication discipline as the canonical attacker-bypass-defense prerequisite the attacker-bypass spoke documents — the spoke documents per- publisher per-domain include-cascade publication discipline (capping the cumulative include-cascade at 5-7 DNS queries to leave headroom for downstream ESP-side cascade-expansion) as the LOAD- BEARING per-publisher pre-attacker-bypass publication-discipline prerequisite this page's lookup-limit reference quantifies — the spoke is the canonical defender-side publication-discipline reference for the per-publisher per-domain SPF-permerror- attacker-bypass-defense posture. Read the DMARC-attacker-bypass spoke ALONGSIDE this lookup-limit reference when designing the per-publisher per-domain SPF-permerror- attacker-bypass-defense posture and when investigating per-receiver per-source-IP per-day spf=permerror surge evidence — the spoke is the canonical 22-technique attacker-bypass classification framework whose SPF-permerror-induction technique class consumes the lookup-limit-permerror primitive this page documents.
• DMARC aggregate (RUA) reports — the RFC-7489-§7.2 XML-AGGREGATE- EVIDENCE-STREAM companion to this SPF-lookup-limit reference. Where THIS page documents the RFC-7208- §4.6.4 10-DNS-lookup budget ceiling, the void-lookup secondary cap, the per-mechanism token DNS-cost accounting catalogue, and the per- publisher per-domain SPF-record flattening + include-pruning remediation playbook, the aggregate- reports spoke is the receiver-side daily per-publisher per-domain feedback evidence-stream documenting the THREE per-day per-receiver per- source-IP row-level evidence channels that surface per-publisher per-domain SPF-permerror surge events the lookup-budget-overflow remediation discipline must detect and triage: (i) the per-row <auth_results> <spf> <result> sub- element whose permerror verdict across per-source-IP per-day rows is the canonical per-publisher per- domain SPF-budget-overflow detection primitive — every per-receiver per- day per-source-IP message whose EHLO/MAIL FROM domain triggered an SPF evaluation that overran the 10-lookup ceiling surfaces here as a permerror row that the per-publisher per-domain operator aggregates daily across receivers to quantify the surge magnitude; (ii) the per-row <policy_evaluated> <spf> alignment verdict whose fail result on rows where the per- publisher per-domain dispositioning equals quarantine / reject is the per- publisher per-domain SPF-permerror- induced enforcement-disposition surface — every per-source-IP per- day legitimate-sender message whose SPF evaluation produced permerror and whose DKIM-side rescue did NOT fire surfaces here as a per-row DMARC failure that the per-publisher per-domain operator MUST resolve before progressing the policy-ramp progression; (iii) the per-row <source_ip> + <count> elements whose per-day per-source-IP aggregation across the per-publisher per-domain RUA dataset surfaces the WHICH-INCLUDE-CHAIN-EXPANSION-IS- THE-CULPRIT diagnostic surface — per-publisher per-domain operators cross-reference the per-source-IP permerror clusters against the per- ESP authoritative SPF-record publication catalogue to isolate which per-include-token expansion is consuming the lookup budget. Read THIS page when AUTHORING the per-publisher per-domain SPF record-flattening + include-pruning remediation discipline; read the aggregate-reports spoke when DETECTING, QUANTIFYING, and TRIAGING per-publisher per-domain SPF-permerror surge events surfaced in the daily per-receiver RFC-7489- §7.2-XML evidence stream the per- publisher per-domain RUA mailbox accumulates.
• TLS-RPT record syntax explained — the RFC 8460 §3 _smtp._tls.<domain> TXT-record byte-grammar reference covering the v=TLSRPTv1 version-token prefix, the rua=mailto: / rua=https:// per-publisher per-domain reporting-endpoint-token publication, and the per-publisher per-domain transport-layer observability reporting- channel registration discipline. THIS page documents the RFC 7208 §4.6.4 ten-DNS-query budget at the per-publisher per-domain SPF evaluation resolution-discipline layer (the cumulative include: / a / mx / exists / ptr / redirect= mechanism-DNS-query accounting at the receiver-side per-evaluation budget, the secondary void-lookup cap, and the SPF-flattening + subdomain-delegation + per-receiver consolidation remediation playbook the per-publisher operator must run to keep cumulative DNS query count below the ten-query budget); the TLS-RPT-record-syntax spoke is the cross-protocol byte-grammar publication peer at the transport-layer observability boundary documenting the per- publisher per-domain TLS-RPT record byte- grammar token catalogue (v=TLSRPTv1; rua=mailto: terminal-mailbox-endpoint token, rua=https:// JSON-POST-endpoint token, the ; per-token delimiter discipline) at the per-publisher per-domain DNS-zone-editor publication boundary. Both the SPF ten-DNS-query budget resolution-discipline and the TLS-RPT-record byte-grammar publication share the per-publisher per-domain RFC-published TXT-record-publication substrate and the per-publisher per-domain operator- side authoring discipline — the SPF ten-DNS- query budget GOVERNS the per-receiver evaluation-budget consumed when retrieving the per-publisher per-domain SPF include-graph at envelope-MAIL-FROM resolution time, and the TLS-RPT-record byte-grammar GOVERNS the per- publisher per-domain transport-layer observability reporting-channel-endpoint publication that the receiver-side STARTTLS- chain-validation evidence pipeline consumes. Read the TLS-RPT-record-syntax spoke alongside this SPF-lookup-limit reference when authoring the per-publisher per-domain DNS-zone-file commit batch that flattens the SPF include- graph to stay below the ten-DNS-query budget AND publishes the per-publisher per-domain TLS-RPT record as the unified per-publisher per-domain envelope-layer-resolution- discipline + transport-layer-observability dual-publication discipline at the per-domain zone-editor commit cadence.
• DKIM troubleshooting — the PER-MESSAGE-DKIM-FAILURE-MODE- DIAGNOSTIC-LADDER-AS-LOAD-BEARING- AUTHENTICATION-LEG-EVIDENCE-FOR-PER-MESSAGE- SPF-PERMERROR-CASCADE-DOWNGRADED-DMARC- ALIGNMENT companion to this SPF-lookup-limit reference. Where THIS page documents the per- publisher per-domain SPF DNS record's 10-DNS- lookup budget (RFC 7208 §4.6.4) + void-lookup secondary cap + per-publisher per-domain include: chain depth-counting discipline + per-publisher per-domain spf=permerror cascade-into-DKIM-only DMARC alignment symptom-class, the DKIM-troubleshooting spoke is the per-message DKIM-failure-mode diagnostic- ladder reference that DKIM-side load-bearing triage operators consult at FOUR per-failure- mode DKIM-load-bearing-coverage dimensions: (i) per-publisher per-domain SPF permerror cascade as per-message DKIM-load- bearing alignment-leg promotion making per- message DKIM-failure-mode diagnostic-discipline the per-publisher per-domain deliverability floor — when the per-publisher per- domain SPF DNS record's 10-DNS-lookup limit produces per-receiver per-message spf=permerror verdicts at the per-receiver application- layer email-auth evaluation step, per-message DMARC alignment downgrades to DKIM-only making per-message DKIM verification the load-bearing AND ONLY authentication leg the per-publisher per-domain has remaining — per- publisher operators in this state MUST have rock-solid per-message DKIM verification discipline because per-message DKIM-failure- mode-class issues directly cascade into per-message DMARC-fail dispositions; (ii) per-publisher per-domain SPF include: chain audit cycle coordination with per- publisher per-domain DKIM-failure-mode diagnostic-cadence — per-publisher operators auditing per-publisher per-domain SPF include: chains for the 10-DNS-lookup cap simultaneously audit per-publisher per- domain DKIM-signing posture (per-selector publication + per-key-rotation cadence + per-canonicalization discipline) because per-publisher per-domain mail flow that relies on per-message DKIM-only DMARC alignment cannot tolerate per-message DKIM- failure-mode-class drift on top of the per-publisher per-domain SPF permerror cascade — the DKIM-troubleshooting spoke is the per-publisher per-domain per-failure- mode-class diagnostic-discipline reference the per-publisher operator consults during per-domain SPF-vs-DKIM mail-flow audit coordination; (iii) per-publisher per-domain per-source-IP per-tenant-SaaS- platform DKIM-troubleshooting alongside per-tenant-SaaS-platform include: chain per-tenant-SaaS-platform per-source-IP authorisation publication discipline — per-publisher per-domain per-source-IP per- tenant-SaaS-platform mail-flow scenarios (Salesforce + Mailchimp + SendGrid + HubSpot + Mailgun + per-tenant SaaS-platform N) each require BOTH per-source-IP SPF include: chain authorisation AND per-tenant- SaaS-platform-DKIM-signed per-message signature publication — when per-publisher per-domain SPF include: chain breaches the 10-DNS-lookup cap THIS page documents, the per-publisher per-domain per-tenant-SaaS- platform DKIM-signing posture becomes the per-publisher per-domain per-source-IP- attribution-cum-authentication SOLE publication-leg — making per-tenant-SaaS- platform DKIM-troubleshooting per-publisher per-domain mission-critical; (iv) per-publisher per-domain DKIM-troubleshooting as canonical per-message-rescue discipline when per-publisher per-domain operators migrate from SPF-overflow remediation (flattening + restructuring) to per- publisher per-domain DKIM-only alignment commitment — when per-publisher per-domain operators commit to per-publisher per-domain DKIM-only DMARC alignment as a deliberate strategy (rather than as the accidental consequence of per-publisher per-domain SPF permerror cascade), per- publisher per-domain DKIM-troubleshooting becomes the canonical per-message-rescue discipline whose per-failure-mode diagnostic ladder catalogues the per-message rescue path for every per-message DKIM verification anomaly — the DKIM-troubleshooting spoke is the per-publisher per-domain operational reference for per-message DKIM-failure- rescue discipline complementing the per- publisher per-domain SPF-overflow remediation discipline THIS page documents. Read the DKIM-troubleshooting spoke alongside this SPF-lookup-limit reference when per-publisher per-domain operators diagnose per-message DMARC-fail dispositions whose root cause traces to a per-publisher per-domain SPF permerror cascade downgrading per-message DMARC alignment to DKIM-only, when AUTHORING per-publisher per-domain SPF-vs-DKIM mail-flow audit coordination runbooks that integrate per- publisher per-domain SPF include: chain cap-discipline with per-publisher per- domain DKIM-signing posture diagnostic- discipline, when EXECUTING per-publisher per-domain per-tenant-SaaS-platform mail- flow audits that hold per-publisher per- domain DKIM-signing posture as the per- tenant-SaaS-platform authentication SOLE- publication-leg, or when ESTABLISHING per- publisher per-domain DKIM-only DMARC alignment strategy as a deliberate per- publisher per-domain deliverability- discipline commitment.
• RFC 7208 section 4.6.4 - the canonical specification of the 10-lookup cap and the void-lookup secondary cap.
• RFC 7208 section 5.5 - ptr deprecation - why you should never publish bare ptr mechanisms.
• RFC 7208 section 7 - SPF macros - the macro substitution mechanism for the rare cases where it makes sense.
• SPF forwarding issues — the canonical operator-side SPF-forwarding-issue remediation reference whose per-forwarder envelope-rewrite + SRS + ARC-rescue remediation playbook is the load- bearing downstream producer of RFC 7208 §4.6.4 ten-DNS-lookup- ceiling overflow THIS page documents at four lookup-budget-to- forwarder-remediation coupling dimensions: (i) the per-forwarder include:srs.forwarder.example token-addition discipline is the canonical load-bearing downstream producer of incremental DNS-lookup budget consumption — every include:-cascaded forwarder-rewrite-provider's nested SPF tree (typically 2-4 lookups per SRS provider including the per- provider a: / mx: mechanism cascade) compounds the per-publisher RFC 7208 §4.6.4 ten-DNS-lookup-ceiling consumption the SPF-lookup-limit reference budgets at the apex; (ii) the per-mailing-list-forwarder include:bounces.list-provider.example + include:dkim.list-provider.example dual-include token-addition pattern is a load-bearing dual-lookup-budget consumer that compounds RFC 7208 §4.6.4 ceiling consumption — many list-server forwarders publish separate VERP-bounce and DKIM- signing-domain SPF includes, each consuming 2-4 nested lookups respectively, that the SPF-lookup-limit budget reference IS the canonical resolution framework for; (iii) the per- ARC-rescuing-forwarder include:arc.forwarder.example token-addition discipline is a load-bearing per-forwarder-network downstream lookup-budget consumer — ARC-rescuing forwarders that re-sign forwarded mail under their own arc-message-signature header sometimes also require the publisher to authorise per-source- IP egress paths via an apex SPF include, compounding the per- publisher RFC 7208 §4.6.4 budget the lookup-limit reference documents; and (iv) the per- publisher SPF-record bounce-tree- decomposition mitigation pattern (split apex SPF into spf1.example.com + spf2.example.com delegation subdomains, each containing a forwarder-include subset) is the canonical downstream-of-overflow remediation the SPF-lookup-limit reference IS the load-bearing root-cause analysis surface for — the forwarder-include-driven overflow is the trigger, the bounce-tree decomposition is the per-zone mitigation, the spf=permerror-on-the- DMARC-aligned-pass-rate is the downstream consequence. Read the SPF-forwarding-issues spoke ALONGSIDE this SPF-lookup-limit reference whenever the publisher scopes a forwarder-include-token- addition cutover that risks crossing the RFC 7208 §4.6.4 ten-lookup ceiling — the per- forwarder remediation playbook THIS lookup-limit reference is the canonical apex-budget framework for IS the load-bearing downstream consumer the forwarder-include-addition upstream-publication discipline the SPF-forwarding-issues spoke documents structurally produces.
• BIMI Verified Mark Certificates (VMCs) explained — the RFC-7208-§4.6.4-LOOKUP-CEILING-AS- UPSTREAM-INPUT-TO-PER-PUBLISHER-BIMI-VMC- RENDER-ELIGIBILITY companion to this SPF lookup-limit reference. Where THIS page documents the RFC 7208 §4.6.4 ten-DNS- lookup ceiling (the per-publisher per- include-cascade DNS-lookup budget, the per-publisher cascade-depth flattening discipline, the per-publisher permerror result-code overflow-class, the per- publisher include:-cascade-to- ip4:-literal-CIDR substitution remediation pattern), the BIMI-VMC-explained spoke is the per-publisher X.509-certificate Web-PKI trust-chain reference documenting the per-publisher VMC / CMC issuance gate whose per-publisher BIMI-render-eligibility pre-condition IS the per-publisher per- receiver per-day DMARC-aligned-pass-rate floor whose per-message SPF-aligned-pass component is upstream-gated by the per- publisher RFC 7208 §4.6.4 ten-DNS-lookup ceiling discipline THIS page documents. The PER-PUBLISHER-LOOKUP-CEILING-VS- PER-PUBLISHER-BIMI-VMC-RENDER-ELIGIBILITY cross-reference establishes FOUR structurally-distinct lookup-budget-vs- BIMI-deployment-gate dimensions: (i) per-publisher ten-DNS-lookup- overflow spf=permerror AS LOAD-BEARING per-publisher per-message DMARC-aligned-pass-rate erosion mechanism directly impacting per-publisher BIMI- deployment-readiness gate — every per- publisher per-message SPF-evaluation producing spf=permerror contributes to a per-publisher per-receiver per-day DMARC-aligned-pass-rate erosion directly degrading per-publisher BIMI- render-eligibility — the per- publisher per-day permerror burst attributable to include:- cascade overflow is the canonical per- publisher BIMI-deployment-readiness regression-class; the BIMI-VMC spoke documents the per-publisher BIMI-render- eligibility gate whose per-publisher SPF- aligned-pass-rate component IS upstream- gated by the per-publisher RFC 7208 §4.6.4 lookup-budget discipline THIS page documents; (ii) per-publisher include:-cascade flattening discipline AS LOAD-BEARING per-publisher BIMI-deployment-prep operational pattern — the per-publisher BIMI VMC-issuance pre- condition flatten campaign typically coincides with per-publisher include:-cascade flattening campaign — a per-publisher BIMI- deployment-prep typically begins with a per-publisher per-portfolio-member include:-cascade audit and flattening campaign to lift the per- publisher per-day SPF-aligned-pass-rate above the per-publisher BIMI-deployment- readiness floor; the BIMI-VMC spoke documents the per-publisher BIMI-deployment- prep operational discipline whose per- publisher include:-cascade flattening pattern IS the cascade-budget- management discipline THIS page documents; (iii) per-publisher per-portfolio- member SPF-publication-budget partitioning discipline AS LOAD-BEARING per-publisher per-portfolio-member BIMI-render-eligibility coordination — the per-publisher BIMI VMC is per-publisher-domain-scoped, requiring per-portfolio-member SPF-aligned-pass-rate floor at each portfolio-member envelope- domain — the per-publisher per- portfolio-member SPF-publication-budget partitioning discipline (per-portfolio- member include:-cascade-OR- ip4:-literal-CIDR substitution discipline) IS the per-portfolio-member BIMI-render-eligibility coordination discipline; the BIMI-VMC spoke documents the per-portfolio-member BIMI-deployment- coordination discipline whose per-portfolio- member SPF-publication-budget partitioning IS the per-publisher per-portfolio-member ten-DNS-lookup ceiling-budget partitioning discipline THIS page documents; (iv) per-publisher per-day permerror rate as per-publisher BIMI-deployment- drift detection primitive — a per-publisher per-day spf=permerror rate spike post-BIMI-deployment is the canonical per-publisher BIMI-deployment-drift signature — the per-publisher per-day spf=permerror rate post-BIMI-deployment is observable in the per-publisher per-receiver per-day rua- aggregate evidence stream; the BIMI-VMC spoke documents the per-publisher BIMI- deployment-drift detection-AND-emergency- rollback discipline whose per-publisher per-day-permerror-rate baseline-shift detection IS the per-publisher RFC 7208 §4.6.4 lookup-budget-overflow detection primitive THIS page documents the operational discipline of. Read the BIMI- VMC-explained spoke alongside this SPF lookup-limit reference whenever the operator scopes a per-publisher BIMI- deployment-prep plan — the per-publisher RFC 7208 §4.6.4 ten-DNS-lookup ceiling IS the canonical UPSTREAM per-publisher SPF- aligned-pass-rate constraint the per- publisher BIMI VMC render-eligibility gate directly depends on at the per-publisher per-receiver per-day DMARC-aligned-pass- rate floor boundary.
• ARC (Authenticated Received Chain) — the PER-FORWARDER-HOP-CRYPTOGRAPHIC- CHAIN-OF-CUSTODY-MECHANISM companion to this SPF lookup-limit reference. Where THIS page documents the RFC 7208 §4.6.4 ten-DNS-lookup budget ceiling whose overflow produces the spf=permerror mechanism- evaluation result and structurally BLOCKS the SPF leg of the RFC 7489 §6.6.2 OR-conjunction from producing a passing aligned-SPF leg, the ARC- explained spoke is the per-forwarder- hop cryptographic-chain-of-custody companion documenting FOUR ARC-vs- SPF-lookup-budget coordination dimensions whose per-publisher per- domain ARC-signer trust-anchor posture determines whether forwarder- path traffic can survive the per- publisher per-domain SPF-permerror- induced loss of the SPF-aligned-pass leg: (i) per-publisher per- domain SPF-permerror-vs-ARC-DKIM- rescue cross-protocol coordination at the per-receiver per-message RFC 7489 §6.6.2 OR-conjunction evaluation boundary determines whether per-publisher per-domain forwarder-path traffic can produce a passing aligned identifier leg in the SPF-permerror condition — when the per-publisher per-domain SPF-record's lookup-budget overflows producing spf=permerror, the SPF leg of the OR-conjunction structurally CANNOT contribute a passing leg, making the per-message DKIM-alignment leg (possibly via per-forwarder-hop ARC-rescued DKIM validation) the SOLE LOAD-BEARING DMARC-pass path; the ARC spoke documents the per-forwarder-hop cryptographic chain-of-custody mechanism that preserves the per- message DKIM-Signature evaluation through forwarder hops, providing the cross-protocol recovery path the per-publisher per-domain SPF- permerror condition this page documents materially relies on; (ii) per-receiver ARC-validator trust-posture variance under SPF- permerror conditions at the per- publisher per-domain enforcement boundary determines the per-receiver per-message disposition baseline — Gmail's, M365's, Yahoo's, iCloud's, and Apple Mail's per-receiver ARC- validator trust-posture under the per-publisher per-domain SPF- permerror condition materially varies — some receivers (Gmail, M365) consume the ARC-validated DKIM-pass verdict as the SOLE aligned-identifier leg, while others (Yahoo, iCloud) require BOTH SPF-aligned-pass AND DKIM- aligned-pass for high-confidence delivery; the ARC spoke documents the per-receiver per-ARC-validator trust-posture variance under SPF- permerror conditions; (iii) per- publisher per-domain ARC-signer trust-anchor publication as load- bearing recovery path when SPF lookup budget overflows — the per-publisher per-domain ARC- signer trust-anchor catalogue determines which forwarders' per-message ARC-Sets are validated at receiver-side, providing the per-publisher per-domain forwarder- path-survival baseline when the per-publisher per-domain SPF lookup-budget overflow structurally eliminates the SPF-aligned leg; the ARC spoke documents the per- publisher per-domain ARC-signer trust-anchor publication discipline operationally consumed at the per- receiver per-message ARC-chain- validation boundary; (iv) per- publisher policy-mode-ramp ARC- rescue baseline under SPF-permerror conditions at the per-publisher per-domain per-day per-receiver per-forwarder-path RUA aggregate- XML evidence stream determines the per-publisher per-domain ramp progression confidence under SPF- permerror condition — the per-day per-receiver per-forwarder- path per-policy-mode ARC-rescued-row rate baseline under the per-publisher per-domain SPF-permerror condition surfaces in the aggregate-XML evidence stream as the per-publisher per-domain forwarder-path-survival rate baseline; the ARC spoke documents the per-publisher per- domain ARC-rescue-rate diagnostic visibility operationally consumed at each per-publisher per-domain policy-mode ramp-progression decision point under SPF-permerror conditions. Read the ARC spoke ALONGSIDE this SPF lookup-limit reference whenever the per- publisher per-domain operator scopes a per-publisher per-domain SPF-permerror-tolerance plan — the per-publisher per-domain SPF lookup-budget ceiling THIS page documents IS the per-mechanism evaluation resource-budget primitive whose overflow-condition recovery path the per-forwarder-hop ARC- Set chain-of-custody mechanism the ARC spoke documents encodes the per-message cryptographic- provenance preservation defence for.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-SPF- 10-DNS-LOOKUP-LIMIT-COMPLIANCE-AS-LOAD- BEARING-PREREQUISITE-OF-PER-PUBLISHER- DMARC-RAMP-STEP-TIGHTENING companion to this RFC 7208 §4.6.4 10-DNS-lookup-limit reference. Where THIS page documents the per-publisher per-domain SPF 10-DNS- lookup-limit ceiling and the per-message per-receiver permerror verdict the ceiling produces at the per- receiver per-message SPF-evaluation boundary (the RFC 7208 §4.6.4 normative-cap on SPF DNS resource consumption), the policy-rollout spoke is the per-publisher per-domain DMARC enforcement-progression discipline whose every p=none → p=quarantine → p=reject ramp-step tightening commit is gated by the per-publisher per- domain SPF 10-DNS-lookup-limit compliance THIS page documents at FOUR per-RFC-7208- §4.6.4-permerror-vs-DMARC-policy-ramp- step coupling dimensions: (i) per- publisher per-domain SPF 10-DNS-lookup- limit compliance is the per-publisher per-domain operational prerequisite of the p=none observation-window opening — the policy-rollout spoke documents how the p=none observation-window opening is preceded by a per-publisher per-domain SPF-publication green-state baseline whose per-RFC-7208-§4.6.4 10- DNS-lookup-limit compliance THIS page documents is the load-bearing per- publisher per-domain prerequisite — a per-publisher per-domain SPF record evaluating to permerror at the per-receiver per-message SPF- evaluation boundary collapses the per- publisher per-message SPF-aligned-pass rate to zero across the per-publisher per-domain receiver topology, making the per-publisher p=none observation-window measurements operationally meaningless for the per- publisher per-domain SPF-side leg; (ii) per-publisher per-domain SPF 10- DNS-lookup-limit compliance is the load- bearing gating input of the p=none → p=quarantine ramp-step commit — the policy-rollout spoke documents how the p=none → p=quarantine ramp-step commit decision reads the per-publisher per-domain per-receiver per-message SPF- aligned-pass rate as the load-bearing per-publisher per-domain authentication- leg-health indicator — every per- publisher per-domain SPF record evaluating to permerror per RFC 7208 §4.6.4 across the per-receiver per-message SPF-evaluation boundary forces the per-publisher per-domain SPF- aligned-pass rate to a structural floor of zero, BLOCKING the p=quarantine tightening commit until per-publisher per-domain SPF record optimization restores per-message SPF-aligned-pass to operational range; (iii) per-publisher per-domain SPF 10-DNS-lookup-limit compliance is the load-bearing per-publisher per-domain SPF-side authentication-leg-availability precondition of the p=quarantine → p=reject ramp-step commit — the policy-rollout spoke documents how the p=quarantine → p=reject ramp-step commit decision reads the per-publisher per- domain SPF-side authentication-leg- availability THIS page documents as the load-bearing precondition — the per- publisher per-domain SPF record must evaluate to a non-permerror verdict (pass, fail, softfail, or neutral) at the per- receiver per-message SPF-evaluation boundary BEFORE the per-publisher operator can commit the p=reject tightening; (iv) per-publisher per-domain SPF 10- DNS-lookup-limit compliance is the load- bearing per-publisher per-domain SPF- record-publication-discipline-regression- resilience indicator the policy-rollout discipline reads post-commit — the policy-rollout spoke documents how every per-publisher per-domain p=reject commit is followed by a per-publisher per-domain rolling- window per-message SPF-verdict- distribution observation whose per- publisher per-domain per-RFC-7208-§4.6.4 10-DNS-lookup-limit compliance THIS page documents is the load-bearing per- publisher per-domain regression- resilience indicator — a per-publisher per-domain SPF-record include-mechanism upstream change pushing the per-publisher SPF record over the 10-DNS-lookup ceiling produces a per-message permerror regression that collapses the per-publisher per-message SPF-aligned-pass rate and forces a per- publisher per-domain p=reject → p= quarantine ramp-step rollback until the per-publisher per-domain SPF record is brought back below the per-RFC- 7208-§4.6.4 10-DNS-lookup ceiling.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-RECEIVER-DMARC-DISPOSITION-ACTION downstream-consumer companion to this RFC 7208 §4.6.4 10-DNS-lookup limit reference. Where THIS page documents the receiver-side 10-DNS-lookup budget enforcement contract whose saturation produces per-message spf=permerror that collapses the per-message SPF leg of the RFC 7489 §6.6.2 DMARC OR-conjunction and structurally forces the per-message DKIM-alignment leg to be the SOLE load-bearing DMARC-pass path, the policy- modes spoke is the per-receiver DMARC- disposition-action reference documenting what each p=-tag value instructs the per-receiver to do with the per-message DMARC-failed mail when the SPF leg is broken by over-budget DNS- lookup count and the per-publisher per- message DKIM-alignment leg ALSO does not produce a passing aligned identifier: p=none defers the per- receiver disposition to monitor-only per-row RUA aggregate-report emission while the operator re-budgets the per- publisher per-domain SPF record below the 10-DNS-lookup ceiling, p=quarantine routes the per- message SPF-permerror-affected stream to per-receiver Junk-folders until the per-publisher SPF record is brought back below the 10-DNS-lookup ceiling, and p=reject escalates to per-receiver SMTP-time 550 rejection of the entire per-publisher per-message SPF-permerror-affected population — which is why operators typically de- escalate from p=reject back to p=quarantine (or even back to p=none for the duration of the regression window) once a per-publisher per-domain SPF- lookup-budget saturation regression is detected via the per-receiver per-row RUA aggregate-report spf=permerror row inspection discipline. Read THIS page when AUDITING the per-publisher per-domain SPF record's recursive lookup-cost budget against the RFC 7208 §4.6.4 10-DNS-lookup ceiling; read the policy-modes spoke when DECIDING which p=-tag value to publish (or temporarily roll back to) during the per-publisher per- domain SPF-permerror regression recovery window.
• DMARC reporting pipeline (RUA aggregate-report end-to-end flow) — the PER-PUBLISHER-PER-SOURCE-IP-SPF- PERMERROR-ROW-OBSERVABILITY-CHANNEL companion to this RFC 7208 §4.6.4 10- DNS-lookup limit reference. Where THIS page documents the receiver-side 10- DNS-lookup budget enforcement contract whose saturation produces per-message spf=permerror and the per-publisher per-domain SPF-record budget-management discipline (per-ESP- vendor measured-cost table, per-mechanism sub-resolution accounting, per-void- lookup cap of 2, canonical ip4: literal-block migration pattern), the reporting-pipeline spoke is the per-publisher per-source-IP per- disposition row observability channel through which per-publisher per-domain SPF-permerror conditions become visible: the per-receiver per-message spf=permerror verdict captured at Stage 1 of the pipeline is batched into the per-receiver per-RUA- mailbox daily aggregate-XML at Stage 2, delivered to the per-publisher rua= mailbox at Stage 3, ingested by the per-publisher RUA- aggregate-XML parser at Stage 4, and surfaced as auth_results.spf.result=permerror rows at Stage 5 — which is precisely the per-publisher per-source-IP per- disposition row inspection discipline THIS page recommends for detecting per-publisher per-domain SPF 10-DNS- lookup budget saturation regressions and per-publisher per-domain void-lookup cap saturation regressions. Read THIS page when AUDITING the per-publisher per-domain SPF record's recursive lookup-cost budget; read the reporting- pipeline spoke when INGESTING the per- publisher per-source-IP per-disposition row evidence stream that surfaces SPF- permerror regressions.
• DMARC for Office 365 hybrid — the LOAD-BEARING per-hybrid-Exchange- tenant HYBRID-EXCHANGE-DUAL-EGRESS-SPF- INCLUDE-CASCADE-AGAINST-RFC-7208-§4.6.4- 10-DNS-LOOKUP-LIMIT-BUDGET-PRESSURE- DISCIPLINE companion documenting the per- hybrid-Exchange-tenant DMARC + SPF + DKIM publication tutorial. The hybrid Exchange SPF publication confronts a SPECIFIC and SEVERE per-domain lookup-budget pressure BECAUSE the apex record MUST authorise BOTH cloud-egress AND on-prem-egress topology legs: the canonical include:spf.protection.outlook.com directive alone resolves into a 3–5-lookup sub-include cascade (the EOP-published spf-a.outlook.com / spf-b.outlook.com / further regional sub-includes), and the per-tenant operator's required addition of third-party ESP includes (e.g. include:_spf.salesforce.com for transactional mail, include:sendgrid.net for marketing mail) plus the on-prem-egress operator-managed include:_spf.<org>.com token quickly pressures the per-domain record against the 10-lookup cap THIS page documents. Where THIS page documents the per-publisher per-domain RFC 7208 §4.6.4 recursive DNS-lookup budget cap (the 10-mechanism-evaluating-lookup per- evaluation hard limit across the entire SPF record's recursive include-traversal cone, the per-evaluation 2-void-lookup soft limit, the per-receiver per-evaluation permerror verdict the cap saturates into, the per-publisher per- domain operator-side flattening or SPF-include-tree pruning playbook), the DMARC-for-O365-hybrid spoke documents the per-hybrid-tenant SPF-INCLUDE- CASCADE-BUDGET-PRESSURE DISCIPLINE — the per-tenant operator-side strategies for keeping the hybrid apex SPF record's cumulative recursive lookup cost BELOW the 10-lookup ceiling this page documents. Read THIS page when AUDITING the per- publisher per-domain SPF record's cumulative recursive-lookup budget; read the DMARC-for-O365-hybrid spoke when AUTHORING the per-hybrid-tenant per- org-domain SPF record whose dual-egress composition consumes a higher-than- typical fraction of the 10-lookup budget this page enforces.
• DMARC deployment checklist — the 4-PHASE-ROLLOUT-DISCIPLINE companion to this SPF 10-DNS-lookup- budget pillar. Where THIS page documents the RFC 7208 §4.6.4 ten-DNS-lookup budget mechanics (the per-mechanism budget cost for include: / a: / mx: / ptr: / exists:, the void- lookup counter, the permerror outcome on overflow, and the SPF-flattening / ip4:-literalization workarounds), the DMARC-deployment- checklist spoke is the PHASE-2- TRIAGE-PERMERROR-REMEDIATION- BLOCKING-OBSTACLE companion documenting how budget-overflow permerror verdicts surfaced during Phase 1 (Discovery) aggregate-report inspection BLOCK the per-domain Phase 2 (Triage) alignment-fixing workstream until remedied: Phase 1 publishes p=none with rua= and surfaces every per-domain SPF verdict in the receiver-side aggregate-report stream — when a Phase-1 report contains spf=permerror rows for an operator-controlled sender, the per-sender Phase 2 triage workstream CANNOT advance to DMARC-aligned posture until the per-sender SPF record's budget overflow is reclaimed via the playbook THIS page documents (consolidate ESP includes, flatten provider sub-includes, replace a: / mx: recursion with ip4: literals where the IP cone is stable, etc.); Phase 3 (Quarantine) advances to p=quarantine only after every Phase-2 per-sender permerror has been reclaimed below the 10-lookup ceiling THIS page documents — a residual permerror at Phase 3 promotion would force-quarantine operator-controlled mail that fails SPF alignment because of the envelope-evaluation budget overflow rather than because of legitimate spoofing; Phase 4 (Enforcement) advances to p=reject only after Phase 3 confirms zero permerror regression on the per-sender SPF inventory. The 4-phase progression is the operational sequencing discipline the 10-DNS-lookup budget THIS page documents BLOCKS at Phase 2 until each per-sender overflow is remediated. Read THIS page when EXECUTING Phase 2's per-sender SPF-budget-reclamation action items; read the DMARC-deployment-checklist spoke when AUTHORING the overall 4-phase rollout plan that gates Phase-3 quarantine-promotion and Phase-4 enforcement-promotion on the completion of every Phase-2 permerror-reclamation action item THIS page's budget mechanics drive.
• DNS propagation — the per-publisher per-domain DNS-PROPAGATION-TIMING companion to this per-publisher per-domain RFC 7208 §4.6.4 10-DNS-lookup SPF-budget reference. Where THIS page documents the per-publisher per- domain SPF mechanism-expansion accounting — the 10-DNS-lookup budget governed by RFC 7208 §4.6.4, the per-include / per-mx / per-a / per-exists / per-ptr / per-redirect mechanism-cost ledger, the permerror failure mode when per-publisher per-domain expansion overflows the 10-lookup ceiling, the per-sender SPF-record consolidation / flattening / sub-record-delegation remediation patterns the per-publisher per-domain operator deploys to reclaim budget — the DNS-propagation spoke documents the per-resolver per-TTL operational-timing layer whose propagation-delay determinism gates every per-receiver per-resolver per-include / per-mx / per-a / per-exists / per-ptr chained-record lookup the SPF mechanism- expansion performs. The composition operates through three per-publisher per- domain SPF-budget-and-DNS-propagation dependencies the per-receiver per-message SPF-verdict materially relies on: (i) per-publisher per-domain SPF root-record TTL determines the per-receiver per- resolver propagation-delay between the per-publisher per-domain operator's per-budget-reclamation SPF-record edit (consolidation, flattening, sub-record delegation) and the per-receiver per- resolver per-message SPF-verdict recomputation that observes the new budget-compliant expansion; (ii) per- publisher per-domain include:-target SPF-record TTL determines whether per-receiver per- resolver SPF expansion observes the per-include-target operator's per-record edit (per-include-target adding / removing mechanisms) within the per- publisher per-domain operator's per- budget reclamation window — a slow per- include-target TTL cliff can cause per- receiver per-resolver per-message SPF- verdict permerror recurrence AFTER the per-publisher per-domain operator has remediated the per-record budget; (iii) per-publisher per-domain mx / a mechanism-target record TTL determines the per-receiver per-resolver propagation-delay budget the per- publisher per-domain operator must respect when migrating per-MX-host / per-A-record infrastructure during SPF- budget reclamation — an MX migration completed before per-receiver per- resolver per-MX-record TTL expires causes per-message SPF-verdict fail regression for the per-receiver per-resolver cohort still observing the stale MX answer. Read THIS page when EXECUTING the per- publisher per-domain Phase-2 SPF-budget-reclamation action items; read the DNS-propagation spoke when SEQUENCING the per-publisher per-domain SPF-record-edit rollout against per- receiver per-resolver per-include / per-mx / per-a chained-record TTL cache-lifetime windows whose propagation-delay determinism gates the per-receiver per-message SPF-verdict observability of the per-publisher per- domain budget reclamation completion.
• MTA-STS policy file byte-grammar — the structurally parallel transport-layer per-receiver-side resource-budget-enforcement publication-discipline companion to this SPF envelope-MAIL-FROM-layer 10-DNS-lookup ceiling reference. Where THIS page documents the per- publisher per-domain RFC 7208 §4.6.4 ten-DNS- lookup ceiling whose per-receiver-side overflow produces spf=permerror, the MTA-STS- policy-syntax spoke documents the per-publisher per-domain MTA-STS policy-fetch HTTPS-request- budget at the transport-layer per-receiver-side resource-budget-enforcement boundary whose per-receiver-side overflow produces fall-back- to-opportunistic STARTTLS. Four per-protocol- layer per-receiver-side resource-budget- enforcement coupling dimensions matter: (i) per- publisher per-domain DUAL publication-budget primitive — per-publisher SPF envelope-MAIL- FROM-layer ten-DNS-lookup ceiling at the per- receiver-side recursive-DNS-resolver budget boundary, per-publisher MTA-STS transport-layer policy-fetch HTTPS-request budget at the per- receiver-side recursive-HTTPS-fetch budget boundary; (ii) per-publisher per-domain DUAL per-receiver-side overflow degraded-verdict — per-publisher SPF ten-lookup overflow produces per-message spf=permerror verdict cascading to DMARC-fail, per-publisher MTA-STS policy-fetch overflow produces per-MX-host fall- back-to-opportunistic STARTTLS degraded enforcement; (iii) per-publisher per-domain DUAL publication discipline operational cadence — per-publisher SPF record audit cadence (every third-party-sender add/remove operation), per- publisher MTA-STS policy-id rotation cadence (whenever the per-publisher per-MX-host set changes); (iv) per-publisher per-domain DUAL cross-protocol resource-budget portfolio — per- publisher SPF lookup-budget audit + per-publisher MTA-STS policy-byte-budget audit + per-publisher TLS-RPT per-failure-class observability form the composite per-publisher per-domain cross-protocol resource-budget-enforcement publication- discipline-floor portfolio every per-publisher per-domain envelope-and-transport-layer deployment THIS page documents materially coordinates publication discipline against.
• DKIM for Google Workspace
• DKIM alignment with DMARC
• TLS-RPT explained — the per-publisher per-domain transport-layer aggregate-observability primer companion at four per-publisher per-domain SPF-lookup-budget-vs-TLS-RPT-transport-layer-observability coupling dimensions: (i) per-publisher per-domain SPF RFC 7208 §4.6.4 10-DNS-lookup-cap budget THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer publication-discipline of IS structurally parallel envelope-MAIL-FROM-layer DNS-publication-budget primitive to per-publisher per-domain TLS-RPT JSON-aggregate-report per-day per-MX-host per-failure-class attribution publication-and-collection budget per RFC 8460 §3 — both per-publisher per-domain per-day publication-discipline budget references coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-day publication-discipline budget coordination boundary; (ii) per-publisher per-domain SPF permerror on lookup-budget exhaustion produces per-receiver per-day DMARC RUA auth_results/spf/result=permerror + policy_evaluated/spf aligned-pass-rate erosion per RFC 7489 §7.2 IS structurally parallel application-layer publication-discipline-permerror failure-class to per-publisher per-policy-domain TLS-RPT sts-policy-fetch-error/sts-policy-invalid transport-layer publication-discipline-permerror failure-class per RFC 8460 §4.3 — both per-publisher per-domain per-leg permerror failure-class references coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-leg permerror failure-class coordination boundary; (iii) per-publisher per-domain SPF lookup-budget-flattening operations (replacement of nested include:-cascade with consolidated ip4:/ip6: CIDR enumeration) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline operational-mitigation to per-publisher per-domain MTA-STS HTTPS-served-policy mx:-allow-list consolidation operational-mitigation surfacing in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report transport-layer per-day per-MX-host per-failure-class attribution stream the per-publisher per-domain transport-layer aggregate-observability primer THIS TLS-RPT spoke documents the per-publisher per-domain transport-layer per-failure-class catalogue of materially surfaces; (iv) per-publisher per-domain SPF lookup-budget management decision-matrix THIS page documents (per-publisher per-domain include:-cascade-delegation-vs-flattening trade-off matrix; per-publisher per-domain ip4:-CIDR-consolidation choice; per-publisher per-domain include:-target-trimming) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline operational-decision-matrix to per-publisher per-domain MTA-STS mode: testing/mode: enforce + DANE TLSA-RR rollover operational-decision-matrix surfacing in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report per-day per-MX-host per-failure-class attribution stream the per-publisher per-domain transport-layer aggregate-observability primer THIS TLS-RPT spoke documents the per-publisher per-domain transport-layer publication-discipline catalogue of materially surfaces against the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer publication-discipline coordination floor.
• TLS-RPT JSON aggregate-report format — the per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format companion at four per-publisher per-domain SPF-10-DNS-lookup-cap-budget-vs-TLS-RPT-aggregate-report-payload coupling dimensions: (i) per-publisher per-domain SPF RFC 7208 §4.6.4 10-DNS-lookup-cap budget exhaustion-to-permerror produces per-receiver per-day DMARC RUA auth_results/spf/result=permerror + policy_evaluated/spf aligned-pass-rate erosion per RFC 7489 §7.2 IS structurally parallel envelope-MAIL-FROM-layer per-day per-source-IP per-record permerror evidence-stream to per-publisher per-policy-domain TLS-RPT JSON aggregate-report failure-details[]/result-type=sts-policy-fetch-error/sts-policy-invalid per-day per-MX-host per-failure-class transport-layer evidence-stream per RFC 8460 §4.3 — both per-publisher per-domain per-leg per-day publication-discipline-evidence-stream references coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-day publication-discipline-evidence-stream coordination boundary; (ii) per-publisher per-domain SPF lookup-budget exhaustion-to-permerror policy-evaluation-disposition-softening BYPASS-effect at per-receiver per-mailbox-provider DMARC-enforcement boundary IS structurally parallel envelope-MAIL-FROM-layer per-receiver per-message receiver-side disposition-softening to per-publisher per-policy-domain TLS-RPT JSON aggregate-report summary/total-failure-session-count per-day per-policy-domain transport-layer per-receiver receiver-side disposition-attribution evidence-stream the per-publisher per-policy-domain TLS-RPT-report-format spoke documents the per-publisher per-policy-domain transport-layer per-day per-MX-host per-failure-class aggregate-attribution publication-discipline of materially surfaces; (iii) per-publisher per-domain SPF lookup-budget management operational-decision-matrix THIS page documents (per-publisher per-domain include:-cascade-delegation-vs-flattening trade-off; per-publisher per-domain ip4:-CIDR-consolidation choice; per-publisher per-domain include:-target-trimming + void-lookup-cap 2 maximum) IS structurally parallel envelope-MAIL-FROM-layer operational-decision-matrix to per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format policies[]/policy-type/policy-string per-policy per-day attribution decision-matrix the per-publisher per-policy-domain TLS-RPT-report-format spoke documents the per-publisher per-policy-domain transport-layer per-policy attribution publication-discipline of; (iv) per-publisher per-domain SPF lookup-budget publication-discipline drift (10-DNS-lookup-cap exhaustion / void-lookup-cap 2 maximum exhaustion / nested-include cycle / dangling-include subdomain-takeover) directly opens per-publisher per-domain envelope-MAIL-FROM-layer authorization-discipline-floor regression structurally parallel to per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline drift (malformed JSON / missing failure-details[] attribution / oversized aggregate-payload / non-conformant result-type vocabulary) the per-publisher per-policy-domain TLS-RPT-report-format spoke documents the per-publisher per-policy-domain transport-layer aggregate-attribution publication-discipline-floor of catalogues against — together the per-publisher per-domain SPF 10-DNS-lookup-cap budget THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer publication-discipline of AND the per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline compose the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-day per-leg aggregate-evidence-stream-floor coordination boundary.
• BIMI logo SVG requirements — the SPF lookup budget this page protects is upstream of BIMI display. When the 10-DNS-lookup cap exhausts to permerror, the SPF leg of DMARC drops out and the aligned-pass rate erodes, which keeps the domain below the p=quarantine/p=reject enforcement BIMI requires. Flatten the lookup count first; only then does publishing a conformant SVG Tiny PS logo actually surface a mark in the inbox.
• Email authentication explained — the umbrella overview of the SPF + DKIM + DMARC stack the 10-DNS-lookup cap this page documents is a failure mode of. When the SPF leg overruns the §4.6.4 budget to permerror, one of the three authentication mechanisms drops out; the email-authentication primer shows how SPF, DKIM, and DMARC alignment compose so you can see exactly which leg a lookup-budget overrun knocks out of the composite. Read it for the stack-level picture this lookup-limit guide tunes a single mechanism of.
• DKIM canonicalization (relaxed vs simple c=) — the 10-DNS-lookup cap THIS page documents is the failure mode of the SPF leg; DKIM canonicalization is the parallel integrity discipline on the DKIM leg, where the c= choice (relaxed vs simple header/body) decides whether an in-transit whitespace, line-wrap, or MIME re-encoding silently breaks the signature. Both legs feed the DMARC aligned-pass disjunction (RFC 7489 §3.1.1) — an SPF permerror from a lookup overrun and a body-canonicalization mismatch are the two parallel ways a domain loses a leg of that composite. Read it to keep the DKIM leg as robust as the SPF budget discipline this guide enforces.
• Microsoft SNDS + JMRP monitoring — SPF PASS does not clear Microsoft's IP-reputation gate: SNDS shows the per-IP GREEN/YELLOW/RED filter verdict Outlook.com assigned to each authorized address and JMRP reports the Junk clicks behind a degraded one.

15. Audit your SPF lookup count now

DMARC Analyzer's Domain Security Checker performs a live recursive walk of any published SPF record (via includes/DnsChecker.php), reports the total lookup count, attributes each lookup to its source mechanism, and flags any record that is at or over the 10-lookup cap. The Email Header Analyzer parses Authentication-Results headers from any message (via includes/EmailHeaderParser.php) and surfaces the spf=permerror reason text emitted by the receiving mail server.

Check my SPF lookup count Sign up — Free plan