Defaults.Exposed › सुधार › Guides

SPF PermError: आपकी Include Chain की DNS Lookup Limit Exceed हो गई — Fix Guide (2026)

प्रकाशित 2026-07-08

आंकड़े 2026-06-29 तक के · methodology v7. 261 मिलियन ग्रेडेड डोमेन में कुल जनगणना डेटा। देखें हम ग्रेड कैसे करते हैं।

SPF PermError का मतलब है आपकी include chain SPF की 10-resolved-lookup limit — RFC 7208 §4.6.4 — exceed करती है, और SPF entirely void हो जाती है: old record नहीं, new record नहीं, कोई SPF नहीं। Defaults.Exposed जनगणना के 261,086,232 domains में से कम से कम 797,263 already over हैं, और 2,119,539 9–10 पर बैठे हैं — एक SaaS include दूर।

Limit इसलिए exist करती है क्योंकि SPF resolvers unlimited recursion के पीछे crash नहीं कर सकते: RFC 7208 §4.6.4 standard ने arbitrarily नहीं, deliberately 10 set किया। यदि आपका record over है, fix order है: scan करें → dead includes delete करें → remaining unfurl करें → यदि अभी भी over है, sending subdomains पर split करें → केवल last resort के रूप में automated flattening। नीचे details।

SPF PermError actually क्या है?

जब receiver आपका SPF record evaluate करता है, यह recursively हर include:, redirect=, a, mx, और exists resolve करता है। यदि उस chain में total resolved DNS lookups 10 cross करती है — यहां तक कि एक से — receiver permerror return करना चाहिए, और most do। वह PermError एक permanent, domain-level failure है:

• SPF fail नहीं करती — यह void है। include: mechanisms के किसी chain से कोई authorize, कोई deny नहीं।
• DMARC SPF leg को fail करता है। यदि DMARC enforcing है (p=quarantine या p=reject), mail impact होती है।
• Authenticating कुछ receivers bounces के बजाय spam folder routing use करते हैं: आप नहीं देख सकते यह कहां जाती है।

Lookup cost table — save करने से पहले count करने के लिए:

include: chains recursively count होती हैं। include:_spf.google.com add करना सिर्फ 1 lookup नहीं है — Google’s _spf.google.com में शायद include:_netblocks.google.com, include:_netblocks2.google.com और include:_netblocks3.google.com हैं, 3 और lookups add करते हुए। एक include: जो 4–5 lookups cost करता है common है।

Void lookup limit: अलग से, void lookups (वे जो NXDOMAIN या empty return करते हैं) केवल दो allowed हैं। यह generally trigger होता है जब कोई deleted provider अभी भी referenced हो।

मुझे PermError क्यों हो रहा है?

तीन root causes लगभग हर case explain करते हैं:

Root cause जो आप assume नहीं कर सकते: record में जो includes हैं वे accurate हैं जो actually send करता है। Defaults.Exposed जनगणना में, domains ने years में tools और providers accumulate किए बिना old entries clean करे — और वे entry अब SPF void कर रहे हैं।

Fix order: क्या करूं?

Step 1 — पहले मुफ़्त स्कैन चलाएं। यह confirm करता है कि issue PermError है, कितने lookups resolve हो रहे हैं, और कहां chain over जाती है। DNS checker tools blindly count करते हैं; यह grade with diagnosis देता है।

Step 2 — Dead includes delete करें। अपना current SPF record dig +short TXT yourdomain.com से pull करें। Record में हर include: के लिए:

• क्या आप अभी भी उस tool/service को use करते हैं?
• क्या आपने उस provider से switch किया?
• क्या वह account cancelled हो चुका है?

यदि हां: delete करें। ये void lookups या real lookups budget waste कर रहे हैं। एक भी deleted-tool include PermError resolve कर सकता है।

Step 3 — Remaining includes recursively unfurl करें। हर surviving include के लिए, dig +short TXT <include-domain> और देखें कि उसमें क्या है। Chain follow करें जब तक ip4: या ip6: blocks हों। Total count करें। आप surprised होंगे कि एक single include: कितने lookups consume करता है।

Step 4 — यदि अभी भी over हैं, sending-only subdomains पर split करें। यदि আपके पास genuinely distinct mail streams हैं — newsletter platform, CRM, billing system, transactional alerts — उन्हें root domain से अलग subdomains से send कराएं:

mail.yourdomain.com      → v=spf1 include:mailchimp-spf.com -all  (1–2 lookups)
crm.yourdomain.com       → v=spf1 include:_spf.salesforce.com -all (2–3 lookups)
yourdomain.com           → v=spf1 include:spf.protection.outlook.com -all (1–2 lookups)

हर subdomain अपने lean SPF के साथ under limit है; root domain uncrowded रहता है। DMARC alignment के लिए आपको उन subdomains से send करने वाले tools का DKIM भी align करना होगा — वह वह leg है जिसे DMARC check करता है।

Step 5 — Automated flattening केवल last resort के रूप में। “SPF flattening” का मतलब है include: references को उनके underlying IP addresses से replace करना, जिससे DNS lookups remove होती हैं। यह काम करता है, लेकिन एक serious maintenance problem introduce करता है: जब भी कोई included provider (Google, Microsoft, Mailchimp, Salesforce…) अपने mail server IPs rotate करते हैं — जो वे unannounced करते हैं — आपका flattened record stale हो जाता है। Mail fail होना शुरू हो जाती है, silently।

यदि आपको flatten करना ही है, केवल एक service use करें जो programmatically changes monitor करती है और आपके records automatically update करती है। Manual static flattening — IPs copy करना, एक बार publish करना, future में revisit न करना — rots करता है और eventually break करता है।

Step 6 — Save करने से पहले count verify करें। 10 से comfortably under रहें। 9 already cliff पर है: census में 2,119,539 domains 9–10 lookups पर बैठे हैं, और कुछ providers अपनी includes बिना notice के adjust करते हैं — जो 9 पर OK था अचानक PermError है।

क्या Include PermError Fix करने के बाद भी चाहिए?

नहीं, हमेशा नहीं। यदि tool include: add करने का reason है कि वे आपके Return-Path domain के रूप में send करते हैं — और कई tools नहीं करते, वे अपने own bounce domain use करते हैं — तो आपको उनके IP addresses को अपने record में authorize करने की जरूरत नहीं। आपको उनका DKIM CNAME setup चाहिए।

SaaS Europe guide में detail है: alignment vs PermError vs actual fail, और exactly किन tools को include की जरूरत है vs केवल DKIM। Short version: यदि include: add करना DMARC fix नहीं करता, tool Return-Path के रूप में आपका domain use नहीं कर रहा, और आपको DKIM alignment की जरूरत है।

Lookup count census data

Defaults.Exposed जनगणना (2026-06-29 तक, 261 मिलियन graded domains):

• 797,263 domains RFC 7208 की 10-lookup limit के over हैं — उनका SPF PermError return करता है और कुछ protect नहीं करता।
• 2,119,539 domains 9–10 lookups पर बैठे हैं — एक new include: PermError trigger करेगा।
• Census P99 lookup count: 9 — यही median domain 99th percentile पर carry करता है।

Full SPF PermError landscape SPF PermError report में है।

अक्सर पूछे जाने वाले सवाल

SPF checker “pass” कह रहा था, PermError कभी क्यों नहीं दिखाया? कुछ checkers जो domain check करते हैं उस resolver से query करते हैं जो caches heavily hit करता है और IP count नहीं करता। वे authoritative DNS response से count नहीं करते। dig +short TXT की आउटपुट पर trust करें और manually count करें, या checker use करें जो explicitly “resolved lookup count” report करता है।

क्या मैं ~all को -all में change करके fix कर सकता हूं? नहीं। ~all (softfail) vs -all (hardfail) lookup count को effect नहीं करता — वे terminal mechanism हैं जो evaluation के end में आते हैं, और वे free हैं। PermError includes count होने से आती है, not से all value।

ptr mechanism use करना ठीक है? नहीं। RFC 7208 §5.5 ptr को explicitly deprecate करता है: expensive, slow, unreliable। इसे ip4: या ip6: blocks से replace करें।

Static IP lists publish करना — क्या यह safer है? यह lookup-free है, हां। लेकिन vendor IPs rotate करते हैं — daily या weekly sometimes — और आपको कैसे पता चलेगा? यदि आप manually maintain करने की capacity नहीं रखते, automated flattening service (static publish नहीं) use करें, या domain split approach prefer करें।

Existing DMARC policy क्या होना चाहिए? PermError SPF leg को fail करता है। यदि DMARC p=quarantine या p=reject है और DKIM aligned fail हो रही है, यह impact करेगा। SPF fix होने तक DMARC temporarily p=none करना reasonable है, फिर वापस। DMARC policy कैसे set करें में full steps हैं।

मालिक को रिपोर्ट भेजें

Fix हो जाने और scan confirm करने के बाद, dated graded report business owner या client को forward करें — plain language में दिखाता है कि SPF PermError कहां था, आपने क्या prune किया, और domain अब कहां है। वह वह evidence है जो उन्हें insurance renewal या अगले supplier security questionnaire के लिए चाहिए।

अपना डोमेन जांचें → · SaaS tools के लिए SPF failing → · SPF कैसे fix करें → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।