Email Provider Switch करने के बाद SPF काम करना बंद हो गया — Migration Fix (2026)

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

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

Email-provider switch के बाद SPF usually इसलिए टूट जाती है क्योंकि new provider का record old record के बगल में add हुआ। दो v=spf1 records permanent error हैं — SPF entirely void हो जाती है। Defaults.Exposed जनगणना के 261 मिलियन domains के अनुसार 1,013,416 domains — SPF attempt करने वालों में से roughly one in 138 — उस state में हैं। उन्हें एक में merge करें।

Fix लगभग दस मिनट लेती है: domain scan करें देखें कि migration ने exactly क्या पीछे छोड़ा, अपने authoritative nameservers पर हर SPF record list करें, उन्हें एक single record में merge करें जिसमें केवल आपका new provider हो, और dig से re-verify करें। यह guide हर step walk करती है, plus वे DKIM और nameserver checks जो अधिकांश migrations भूल जाती हैं।

Migration के तुरंत बाद SPF क्यों टूटी?

क्योंकि new provider के setup guide ने कहा “यह TXT record add करें” — और आपने किया, old record के बगल में। SPF standard इसे allow नहीं करता। RFC 7208 (§3.2, error result prescribed in §4.5) per domain exactly एक v=spf1 record permit करता है; receiver जो दो या अधिक find करे PermError return करना होगा guess करने की बजाय कि कौन सा authoritative है। PermError का मतलब है SPF void है: old record नहीं, new record नहीं, बिल्कुल कोई SPF नहीं।

और यह यहीं नहीं रुकता। DMARC PermError को SPF leg पर fail के रूप में treat करता है, इसलिए आपकी mail अब entirely DKIM पर depend करती है। यदि new provider का DKIM भी अभी तक set up नहीं है — mid-migration में common — आप exactly उस moment पर unauthenticated send कर रहे हैं जब आपने infrastructure बदला, जब receivers आपको hardest scrutinise करते हैं।

यह copy-paste है जो provider switch करने पर protection void करती है, और यह rare नहीं है: 1,013,416 domains अभी दो या अधिक SPF records publish करते हैं — Defaults.Exposed जनगणना के 261 मिलियन domains (data 2026-06-29 तक) में SPF attempt करने वाले 139 million-strong population में से roughly one in 138। Two-records trap के full numbers का अपना report है; यह page procedural fix है।

Migration ने क्या पीछे छोड़ा?

पांच leftovers almost हर post-migration SPF failure cause करते हैं। इस क्रम में check करें:

क्या पीछे रह गया	आप क्या देखते हैं	Fix
Old SPF record, अभी भी DNS में new record के बगल में (दो `v=spf1` records)	Checkers “multiple SPF records” या PermError report करते हैं; SPF पूरी तरह काम करना बंद करती है	एक record में merge करें, बाकी delete करें — नीचे steps
आपके एक record में old provider का `include:`	SPF काम करती है, लेकिन आप DNS lookups waste कर रहे हैं और old provider के servers अभी भी आपके रूप में send कर सकते हैं	इसे remove करें एक बार mail fully old system से drain हो जाने के बाद
New provider का `include:` कभी add नहीं किया	New provider की mail receivers पर SPF fail करती है	इसे existing single record में add करें — कभी new record के रूप में नहीं
New provider के लिए DKIM selectors create नहीं किए	`dkim=fail` या provider के default domain से signatures; DMARC में कोई second leg नहीं	New selectors publish करें — step 6 नीचे
Record केवल old nameservers पर updated	आप किसे query करते हैं इस पर different answers; intermittent failures	Authoritative nameservers पर zone fix करें; cutover के दौरान दोनों sets verify करें

इसे कैसे fix करूं? Migration checklist

पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। यह आपका live DNS पढ़ता है और बताता है कि आपके पास multiple SPF records, missing include, या DKIM gap है — कुछ भी छूने से पहले diagnose करें।
Authoritative nameservers पर हर SPF record list करें। dig +short NS yourdomain.com, फिर dig +short TXT yourdomain.com @<nameserver> उनमें से एक के विरुद्ध। v=spf1 से शुरू होने वाली strings count करें। केवल safe count 1 है।
Single record में merge करें। एक record, v=spf1 से शुरू होता हुआ, आपके new provider का include और आप अभी भी use करने वाले किसी अन्य sender (invoicing tool, CRM, newsletter platform) के साथ, एक terminal -all या ~all। Example — old Google Workspace, new Microsoft 365, mid-drain:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Provider values और DNS-panel quirks Google Workspace और Microsoft 365 के setup guides में हैं।
Extra records delete करें। Delete किए बिना merging कुछ fix नहीं करती — PermError count से आती है।
Old provider का include केवल तब रखें जब old system अभी भी send करे — scheduled reports, old CRM connector, forgotten mailbox। Drain हो जाने के बाद इसे remove करें: stale include old infrastructure को आपके रूप में send करने के लिए permitted छोड़ता है, और हर include SPF के hard cap of 10 के विरुद्ध DNS lookups cost करता है — कम से कम 797,263 domains ने वह cap blow करके SPF void कर दिया है (census, 2026-06-29)।
New provider का DKIM set up करें — और old selectors अभी delete न करें। New selectors new mail sign करते हैं; old selectors तब तक published रहने चाहिए जब तक उनसे sign की गई हर message deliver न हो जाए और कोई forwards settle न हो जाए। Full walkthrough email tools switch करने के बाद DKIM failing में।
यदि आपने nameservers भी बदले, दोनों check करें। DNS migrations often email migrations के साथ ride करती हैं। Old और new NS set को directly query करें (dig TXT yourdomain.com @old-ns और @new-ns) — जब तक registrar delegation fully propagate नहीं होती, कुछ receivers अभी भी old servers query करते हैं, इसलिए fixed record उस whichever set पर exist करना चाहिए जो answer करे।
Scan फिर से चलाएं और confirm करें SPF pass के साथ single valid record दिखाता है।

SPF actually कौन सा domain check करती है?

Receivers SPF को Return-Path (RFC5321.MailFrom) domain — bounce address — के विरुद्ध evaluate करते हैं, आपके recipients जो From header देखते हैं नहीं। Migration के बाद यह दो बार मायने रखता है: आपका new provider अपना own bounce domain use कर सकता है जब तक आप custom one configure नहीं करते, और SPF “passing” उस domain पर जो आपका नहीं है DMARC के लिए align नहीं करेगा। इसके लिए fix है new provider का DKIM, आपके domain के साथ signed।

Same time पर migrate और rebrand कर रहे हैं?

Domain और provider दोनों बदले? उन्हें दो jobs treat करें। New domain को day one से full stack चाहिए — SPF, DKIM, DMARC; new-domain email checklist use करें। Old domain authenticated रहता है जब तक forwarding या reply traffic इसके जरिए run करती है, और explicitly locked down (बस abandoned नहीं) होता है एक बार parked होने पर। Leftover, half-broken SPF के साथ old domain आपके former name पहने spoofing target है।

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

क्या मैं migrate करते समय दो SPF records रख सकता हूं? नहीं। Standard में कोई grace period नहीं है — दो v=spf1 records उस moment से PermError हैं जब second one exist करता है, और 1,013,416 domains उस state में बैठे हैं census (2026-06-29) तक। Migration-safe pattern overlap के दौरान दोनों providers’ includes carry करने वाला एक record है।

Old provider का include कब तक रखूं? जब तक कुछ भी old provider के जरिए send नहीं करता — typically आपके overlap window की length, days से कुछ weeks। Old system के जरिए अभी भी arrive हो रही किसी भी चीज का Return-Path देखें; जब वह traffic रुके, include remove करें और अपना lookup count re-check करें।

Checker fix करने के बाद भी मेरा old record क्यों दिखाता है? DNS caching record का TTL honor करती है, और यदि आपके nameservers बदले, कुछ resolvers अभी भी old set query करते हैं। Authoritative nameservers पर directly dig TXT yourdomain.com @<ns> से verify करें — यदि answer वहां सही है, fix हो गई और caches catch up करेंगे। यदि एक NS set पर wrong है, ‘SPF record not found’ — real causes देखें।

क्या provider switch करने पर DMARC change करना होगा? Usually record itself नहीं — यह आपकी report mailbox और policy name करता है, आपके provider नहीं। लेकिन आपके DMARC results SPF और DKIM पर depend करते हैं जो आपने अभी migrate किया: cutover के दौरान reports में dip expect करें, और policy tighten करने से पहले दोनों legs pass confirm करें। SPF fix करें से शुरू करें यदि scan SPF leg अभी भी fail दिखाए।

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

यदि आप किसी client के लिए यह migration कर रहे हैं, evidence के साथ finish करें। Merge live होने के बाद मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: new provider पर SPF, DKIM और DMARC passing, plain language में, dated। वह वह artifact है जो वे cyber-insurance renewal और अगली supplier security questionnaire के लिए file करते हैं — proof कि migration ने domain को शुरू से better authenticated छोड़ा।

अपना डोमेन जांचें → · Email tools switch करने के बाद DKIM failing → · ‘SPF record not found’ — real causes → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।