Defaults.Exposed › सुधार › Guides
Forwarded Email SPF Fail करती है — आप इसे Fix क्यों नहीं कर सकते, और जो वास्तव में काम करता है (2026)
प्रकाशित 2026-07-08
आंकड़े 2026-06-29 तक के · methodology v7. 261 मिलियन ग्रेडेड डोमेन में कुल जनगणना डेटा। देखें हम ग्रेड कैसे करते हैं।
आप forwarded email के लिए SPF pass नहीं करवा सकते — forwarding SPF को design से तोड़ती है, और ईमानदार fix aligned DKIM है, जो forwarding से बचती है। Scale census-wide है: Defaults.Exposed जनगणना के 261 मिलियन domains के अनुसार 7,355,985 of 138,927,207 SPF-publishing domains Namecheap के forwarding include को authorize करते हैं, strict-SPF share <0.1% के साथ।
नीचे: क्यों कोई SPF record जो आप लिख सकते हैं forwarding से नहीं बच सकता, क्यों SRS और ARC वे tools नहीं हैं जिन्हें आप control करते हैं, और वह fix जो holds करती है — आपके domain के साथ DKIM signing आपके DMARC pass के रूप में — plus वह एक case जो DKIM भी तोड़ता है (mailing lists जो messages rewrite करती हैं) और उस residue के बारे में क्या करना है।
Forwarding SPF क्यों तोड़ती है?
Receivers SPF को Return-Path (RFC5321.MailFrom) domain, From header नहीं के विरुद्ध evaluate करते हैं। जब आप directly send करते हैं, आपके server का IP आपके SPF record में है और check pass होती है। जब आपका recipient message forward करता है — personal Gmail को, university alias के जरिए, registrar के forwarding product के जरिए — forwarder का server इसे retransmit करता है, usually आपका domain Return-Path पर रखते हुए। Final receiver अब पूछता है: क्या यह forwarding server आपके SPF record में authorized है?
यह नहीं है, और कभी नहीं होगा: आपने forwarder नहीं चुना, आपको पता नहीं यह exist करता है, और कल किसी अलग service के जरिए forward किया गया same message अलग IP से fail होगा। SPF एक प्रश्न पूछती है — “क्या यह IP ऐसे server से आया जिसे Return-Path domain ने authorize किया?” — और forwarded mail के लिए सच्चा जवाब नहीं है। Fail SPF exactly specified काम करना है, आपका record गलत नहीं।
Census दिखाता है कि यह path कितना mainstream है: 7,355,985 domains Namecheap के email-forwarding include (spf.efwd.registrar-servers.com) को authorize करते हैं — 139 मिलियन SPF publishers में से एक single provider का forwarding product — strict-SPF share <0.1% के साथ और केवल 0.2% DMARC enforce करते हुए। वह soft template carelessness नहीं है: forwarding precisely वह है जहां strict -all misfires, और वह provider जिसका product है forwarding accordingly ship करता है। Qualifier story हमारी ~all vs -all report में है, और provider-by-provider picture कौन सा email provider strongest SPF देता है में।
क्या मैं forwarder का server अपने SPF record में add नहीं कर सकता?
नहीं — और क्यों यही पूरा article है:
- आप forwarders enumerate नहीं कर सकते। कोई भी recipient, कहीं भी, आपकी mail किसी भी service के जरिए forward कर सकता है। आपके SPF record को उन servers list करने होंगे जिनके बारे में आप advance में नहीं जान सकते।
- उन्हें list करना purpose defeat करेगा। Big forwarding services लाखों customers के लिए mail relay करती हैं। उनके ranges अपने record में डालें और उनके किसी भी user द्वारा relay किया गया हर message — spoofer का भी — आपके रूप में SPF pass करेगा।
यही logic qualifier loose करने को rule out करती है “forwarding काम करने के लिए”: qualifier वह कारण नहीं है जिससे forwarded mail fail होती है, और एक बार DMARC play में हो यह अधिकांश guides claim से कम बदलती है — qualifier data देखें। Record यहां lever नहीं है। इसे खींचना बंद करें।
SRS और ARC के बारे में क्या — क्या वे forwarding fix नहीं करते?
वे इसे address करते हैं — लेकिन न तो आपका deploy करना है:
| Mechanism | जब mail forward की जाए तब क्या करता है | कौन control करता है | आपका DMARC fix करता है? |
|---|---|---|---|
| SPF | Fail: forwarder का IP आपके record में नहीं | आप इसे publish करते हैं; forwarding इसे defeat करती है | नहीं |
| SRS (Sender Rewriting Scheme) | Forwarder Return-Path को अपने domain पर rewrite करता है ताकि इसका retransmission SPF pass करे | Forwarder | नहीं — SPF pass अब forwarder के domain का है, जो आपके From के साथ align नहीं करता |
| ARC (RFC 8617) | Forwarder original authentication results seal करता है; final receiver may sealed chain trust करे | Forwarder और receiver | कभी-कभी — receiver के discretion पर, आपके नहीं |
| Aligned DKIM | Signature message के अंदर travel करती है और forwarding के बाद भी verify करती है, आपके domain के साथ | आप | हां |
Data और mechanism status 2026-06-29 तक के।
SRS forwarder की SPF problem दूर करती है, आपकी नहीं: Return-Path rewrite करना यह बदलता है कि किसका SPF checked है, जबकि आपका From header — वह domain जिसे DMARC defend करती है — untouched है। ARC infrastructure operators के बीच trust decision है। यदि कोई guide आपको “SRS implement करें” domain owner के रूप में tell करती है, इसने आपको forwarder के साथ confuse कर दिया है।
मैं अपनी email forwarding से कैसे survive करूं?
DKIM को, aligned आपके domain से, आपका DMARC pass बनाएं। DKIM signature message headers में carried cryptography है: यह जहां भी message end up होती है verify करती है, चाहे कितने servers ने relay किया हो, जब तक signed content modify नहीं हुई। DMARC को केवल एक aligned pass चाहिए — SPF या DKIM — इसलिए जब forwarding SPF leg kill करती है, aligned DKIM message authenticated रखती है।
- DNS छूने से पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। यह दिखाता है कि आपके पास DKIM है या नहीं, क्या यह आपके domain से sign करता है, और आपका DMARC कहां है — ताकि आप real gap fix करें न कि अपने SPF record से fight।
- Confirm करें कि forwarding actually आपकी problem है। Affected message के Authentication-Results header में, direct mail SPF pass करती है जबकि forwarded copy forwarding service के IP से fail करती है। यदि SPF और DKIM pass करते हैं लेकिन DMARC अभी भी fail — आपके पास alignment problem है — DMARC fails but SPF and DKIM pass देखें।
- अपने domain के साथ DKIM signing चालू करें हर sending service पर — mailbox provider पहले, फिर ESPs और transactional senders। Provider defaults अक्सर provider के domain से sign करते हैं, जो align नहीं करता; आप
d=yourdomainचाहते हैं। DKIM fix करना से शुरू करें, Google Workspace और Microsoft 365 के click-paths के साथ। - Alignment verify करें, केवल pass नहीं। Signature में
d=domain आपके From domain से match करना चाहिए; किसी और के domain परdkim=passआपके DMARC के लिए कुछ नहीं करता। - अपना SPF record alone छोड़ें। इसे अपनी direct mail के लिए accurate रखें — यह अभी भी आपकी अधिकांश traffic authenticate करती है और आपकी second DMARC leg रहती है। बस इसे forwarders cover करने की कोशिश बंद करें।
- Re-scan करें, फिर deliberately DMARC enforcement stage करें — next section, और p=none से p=reject rollout guide।
यह combination — SPF plus enforcing DMARC aligned DKIM पर riding — forwarding-proof pattern है, और यह rare है: ~all publish करने वाले 77.5 मिलियन domains में से, केवल 9.2% (7,116,774) इसे enforcing DMARC policy के साथ back करते हैं, और केवल 3.87% of 261 मिलियन ग्रेडेड domains (10,092,481) full SPF + DKIM + enforced-DMARC triad complete करते हैं, census के अनुसार (2026-06-29)।
उन mailing lists के बारे में क्या जो messages rewrite करती हैं?
वह एक forwarding path जिससे aligned DKIM नहीं बचती: mailing lists जो message modify करती हैं — एक [list-name] subject tag, unsubscribe footer, stripped attachment। Signed content बदलें और body hash अब match नहीं करता, इसलिए DKIM भी fail होती है (dkim=fail: body hash did not verify उस failure का अपना guide है)। अब दोनों DMARC legs dead हैं, और केवल list mitigate कर सकती है (From rewriting, ARC sealing)।
यह residue exactly वह है जिसके लिए staged DMARC enforcement है। pct ramp के साथ p=quarantine के जरिए move करना aggregate reports देखते हुए दिखाता है कि आपकी real mail का कितना हिस्सा rewriting lists के जरिए flow करता है पहले p=reject policy इसे bouncing शुरू करे। उन domains पर reject पर jump न करें जिनके users mailing lists पर रहते हैं; p=none पर forever stall भी न करें। Staged rollout guide ramp walk करती है।
अक्सर पूछे जाने वाले सवाल
क्या forwarding DKIM भी तोड़ती है? Plain forwarding, नहीं: signature message के साथ travel करती है और final receiver पर verify करती है। DKIM केवल तब टूटती है जब signed content transit में modify होती है — mailing-list subject tags और footers classic case हैं — यही कारण है कि list residue DNS में किसी चीज से नहीं बल्कि DMARC policy staging से handled है।
क्या मुझे forwarding fail होना बंद करने के लिए -all से ~all switch करना चाहिए? Qualifier change करने से forwarders pass नहीं होंगे — यह वह कारण नहीं है जिससे वे fail होते हैं। यह instructive है कि Namecheap का forwarding include, 7,355,985 domains और census का largest dedicated-forwarding population (2026-06-29), strict-SPF share <0.1% के साथ ship करता है: soft SPF forwarding product के लिए arguably correct template है। Qualifier actually क्या बदलता है ~all vs -all report में देखें।
जब directly send किया जाता है मेरा mail SPF pass क्यों करता है लेकिन forward होने पर fail? Receiver check करता है कि क्या last transmitting server का IP आपके Return-Path domain के SPF record द्वारा authorized है। Direct: आपका server, आपके record में, pass। Forwarded: forwarder का server, आपके record में नहीं, fail। आपका record नहीं बदला — transmitting IP बदला।
क्या मैं इसे fix करने के लिए SRS set up कर सकता हूं? केवल यदि आप forwarder हैं। SRS forwarding करने वाले server पर run होता है, और जहां यह run होता है वहां भी resulting SPF pass forwarder के domain का है और आपके From के साथ align नहीं करता — आपके DMARC को फिर भी DKIM leg चाहिए।
क्या SPF pointless है यदि forwarding इसे वैसे भी तोड़ती है? नहीं। अधिकांश mail directly deliver होती है, जहां SPF exactly intended के अनुसार काम करती है, और यह आपकी दो DMARC legs में से एक रहती है। Census में 261,086,232 domains (2026-06-29), 138,927,207 SPF publish करते हैं — अपना SPF fix page के जरिए accurate रखें, और DKIM को forwarded remainder carry करने दें।
मालिक को रिपोर्ट भेजें
यदि आप किसी client या नियोक्ता के लिए यह fix कर रहे हैं, evidence के साथ loop close करें। Custom-domain DKIM live और DMARC staged होने के बाद, मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: dated, plain-language, दिखाता है कि domain authenticated रहता है यहां तक कि जब इसकी mail forward होती है। वह cyber-insurance renewal और अगली supplier questionnaire के लिए artifact है — documented before-and-after, “मैंने कुछ चालू किया” नहीं।
अपना डोमेन जांचें → · DMARC fails but SPF and DKIM pass → · DKIM ठीक करें → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।