Defaults.Exposed

Defaults.Exposed › सुधार › Guides

"SPF Record Not Found" — लेकिन आपके पास एक है? 5 असली कारण (2026)

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

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

यदि कोई checker “SPF record not found” कहता है लेकिन आप sure हैं आपने एक publish किया, record usually missing के बजाय invisible है: Defaults.Exposed census of 261 million domains के अनुसार 1,013,416 domains — SPF attempt करने वालों में से लगभग एक in 138 — दो या अधिक SPF records publish करते हैं, एक PermError (RFC 7208 §3.2) जिसे कई checkers not-found report करते हैं।

पाँच असली कारण हैं, सभी एक sitting में fixable: गलत host, duplicate record, गलत DNS type या mangled quoting, inconsistent nameservers, या length/CNAME collision। नीचे: हर एक के लिए 60-second test, check करने के order में, फिर fix steps।

क्या आप sure हैं record actually exist करता है?

Unflattering possibility से start करें, क्योंकि यह अब तक सबसे common है: Defaults.Exposed census में graded 261,086,232 domains में से 121,145,609 — 46.4% — बिल्कुल कोई SPF record publish नहीं करते। बहुत से “but I set this up” cases एक staging zone में या एक old DNS provider पर add किए गए record निकलते हैं जो अब authoritative नहीं है। DNS provider check करें जिस पर आपके nameservers actually point करते हैं (often आपका registrar नहीं) v=spf1 से शुरू होने वाले TXT record के लिए। यदि यह genuinely वहाँ नहीं है, detective work skip करें और directly fix your SPF record पर जाएं।

SPF record properly कैसे check करते हैं?

Web checkers DNS को अपने own caching resolver के जरिए query करते हैं। Truth देखने के लिए, अपने domain के authoritative nameserver को directly पूछें:

# authoritative nameservers find करें
dig NS yourdomain.com +short

# उनमें से एक से directly TXT records पूछें
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Windows पर: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com।

Interpretation के दो rules। पहला, v=spf1 से शुरू होने वाली lines count करें — count content जितनी ही matter करती है। दूसरा, check करें कि आपने right name query किया: receivers SPF को Return-Path (RFC5321.MailFrom, “envelope from”) domain के विरुद्ध evaluate करते हैं — वह From address नहीं जो recipients देखते हैं। यदि आपका newsletter tool mail bounce.yourdomain.com के जरिए bounce करता है, apex पर perfect record वह record नहीं है जिसे receivers look up करते हैं।

पाँच असली कारण क्या हैं?

#Cause60-second testFix
1गलत host पर record (subdomain vs apex)अपने Return-Path में exact domain का dig TXT करेंउस name पर publish करें जो actually send करता है
2दो या अधिक v=spf1 records = PermErrordig TXT 2+ v=spf1 lines return करता हैExactly एक record में merge करें
3Record type 99 के रूप में publish, या mangled quotingRecord type और stray quote marks check करेंएक clean TXT record के रूप में republish करें
4Stale caches / inconsistent nameserversहर NS को directly query करें; answers compare करेंLagging nameserver fix करें, old TTL out wait करें
5>255-character splitting या CNAME conflictBroken string chunks या same name पर CNAME देखेंProvider को strings correctly split करने दें; record को CNAME’d name से हटाएं

Data 2026-06-29 तक का।

1. क्या record गलत host पर है?

Classic: SPF mail.yourdomain.com पर add की जब mail yourdomain.com से आने का claim करती है, या vice versa। SPF नीचे inherit नहीं होती — apex पर record subdomains के बारे में कुछ नहीं कहता, और vice versa। Exactly उस name पर publish करें जो आपके Return-Path में है। Vendor जो अपने own bounce subdomain से send करता है उस subdomain पर record चाहिए — usually एक CNAME या TXT जो vendor supply करता है (GoDaddy SPF setup guide दिखाता है ये fields कहां रहते हैं)।

2. क्या आपके पास दो SPF records हैं?

Headline cause, और email authentication में सबसे misleading error message। RFC 7208 §3.2 blunt है: domain में exactly एक SPF record होना चाहिए। दो या अधिक PermError है — receivers आपके SPF को void treat करते हैं। कुछ checkers उस state को accurately report करते हैं (“multiple records found”); अन्य net effect report करते हैं: no valid SPF record found। आप panel में एक record देखते हैं और conclude करते हैं checker broken है। यह नहीं है — आपके पास एक record too many है।

Census ने 1,013,416 domains carrying दो या अधिक SPF records पाए — SPF attempt करने वाले domains में से लगभग एक in 138 — हर एक के साथ SPF effectively switched off। यह usually provider change के दौरान होता है: new provider का wizard एक fresh record add करता है old को edit करने के बजाय। Fix merge है, never second record: सब कुछ single v=spf1 … ~all line में combine करें और बाकी delete करें। हमारा data report two SPF records equals none breakdown करता है कि million domains यहाँ कैसे पहुंचे; यदि यह migration के बाद शुरू हुआ, देखें SPF stopped working after switching provider। Merge करते समय, blindly हर include: concatenate मत करें — हर एक SPF की 10 की hard limit के विरुद्ध DNS lookups cost करता है, not-found को PermError: too many DNS lookups से trade करते हुए।

3. क्या आपने गलत record type publish किया — या UI ने इसे mangle किया?

Early SPF का अपना DNS record type था (type 99, literally “SPF” named)। यह deprecated हो गया: RFC 7208 TXT require करता है, और receivers type 99 query नहीं करते। कुछ DNS panels अभी भी record-type dropdown में “SPF” offer करते हैं; इसे choose करें और आपका record real, well-formed, और invisible है। Type column check करें और TXT के रूप में republish करें।

Subtler sibling quoting है। Value को quotes में paste करना ऐसे field में जो अपने own quotes add करता है ""v=spf1 …"" produce करता है — जो अब v=spf1 से start नहीं होती, इसलिए verifier को यह exist नहीं करती। आपका dig output truth दिखाता है; DNS panel often इसे cosmetically hide करता है।

4. क्या यह really “still propagating” है?

“24–48 घंटे propagate होने दो” DNS में सबसे over-prescribed advice है। Propagation बस caches expire होना है: एक बार record का TTL elapsed हो (typically 1 घंटा, rarely 24 से अधिक), हर resolver नया answer देख सकता है। 24 घंटों के बाद भी not-found? Propagation cause नहीं है।

दो real culprits: negative caching — एक resolver जिसने आपको उससे पहले look up किया जब आपने record add किया वह “no such record” answer को negative TTL expire होने तक cache करता है — और inconsistent nameservers migration के बाद, जहाँ domain अभी भी new ones के साथ old provider के nameservers list करता है और world का आधा हिस्सा एक zone read करता है जिसे आप अब edit नहीं करते। हर listed nameserver को directly query करें; यदि answers differ करते हैं, आपने यह find कर लिया। Registrar के NS delegation fix करें ताकि केवल वह provider authoritative हो जिसे आप actually edit करते हैं।

5. क्या record too long है, या CNAME से blocked है?

TXT record में एक single string 255 characters पर max out होती है। Longer SPF records legal हैं लेकिन one record के भीतर multiple quoted strings में split होनी चाहिए — और DNS provider interfaces regularly split botch करते हैं, value truncate करते हुए या mechanism के बीच break करते हुए ताकि यह अब parse न हो। यदि आपका record long है, abruptly end होने वाले value के लिए dig output check करें।

Separately, DNS एक name पर TXT record forbid करता है जिसमें already एक CNAME है। यदि mail.yourdomain.com आपके provider का CNAME है, आप वहाँ SPF भी नहीं रख सकते — कुछ panels इसे accept करते हैं फिर केवल CNAME serve करते हैं। Record को वहाँ रखें जहाँ CNAME point करता है (यदि आप इसे control करते हैं), या restructure करें ताकि sending name CNAME’d न हो। Clean TXT handling वाले providers दोनों easier बनाते हैं — देखें Cloudflare SPF setup guide।

इसे step by step कैसे fix करूं?

  1. defaults.exposed पर मुफ़्त scan run करें — यह आपका live DNS read करता है और बताता है कि आप पाँच states में से किस में हैं कुछ भी touch करने से पहले।
  2. Confirm करें कौन से nameservers authoritative हैं (dig NS) और कि वे सब agree करते हैं।
  3. Exact Return-Path domain के लिए authoritative nameserver पर TXT query करें।
  4. v=spf1 lines count करें: zero → एक publish करें; दो या अधिक → एक में merge करें।
  5. Verify करें type TXT है, value exactly v=spf1 से start होती है, और कोई stray quotes या truncation नहीं।
  6. एक TTL wait करें, फिर re-scan करें confirm करने के लिए कि यह everywhere cleanly resolve होता है।

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

Checker “not found” क्यों कहता है जब मैं panel में record देख सकता हूं? Usually cause 2 या 4: second v=spf1 record दोनों को void करता है — एक PermError जिसे कुछ tools not-found report करते हैं, वह state जिसमें 1,013,416 domains 2026-06-29 तक हैं — या आपका panel वह DNS नहीं है जो actually authoritative है।

Checkers मेरी fix कब तक देखेंगे? एक TTL — typically एक घंटा, अधिकतम 24। उससे परे, “propagation” explanation नहीं है; nameserver consistency से शुरू करके पाँच causes फिर check करें।

क्या मुझे DNS panel की offer की “SPF” record type use करनी चाहिए? नहीं। Type 99 deprecated है; RFC 7208 केवल TXT require करता है। Type-99 record modern receivers को invisible है।

Record अब found है — मेरी mail SPF क्यों fail करती है? क्योंकि SPF Return-Path domain के विरुद्ध check होती है, From header नहीं, और record को actually आपके लिए send करने वाले servers list करने चाहिए। Found step one है; fix your SPF record guide passing cover करती है।

क्या कोई SPF record न होना really उतना common है? हाँ — 121,145,609 domains, Defaults.Exposed census (2026-06-29 तक) में graded 261,086,232 में से 46.4%, बिल्कुल कोई SPF publish नहीं करते। Not-found internet की default state है।

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

एक बार record cleanly resolve होने पर, scan फिर चलाएं और graded report business owner या client को forward करें। यह plain language में दिखाता है कि क्या broken था, आपने क्या fix किया, और domain अब कहाँ है — exactly वह evidence जो उन्हें cyber-insurance renewals और supplier security questionnaires पर ask किया जाएगा। Report काम की receipt है।

अपना SPF record मुफ़्त में जांचें

देखें कि आपका domain पाँच not-found states में से किसमें है — privately और owner-only।

अपना डोमेन जांचें → · SPF fix करें → · Provider switch के बाद SPF टूट गई → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।