अगर आप “Sender ID” search करके यहां पहुंचे हैं, तो पहले एक जरूरी correction: Sender ID, SPF नहीं है। यह 2000 के दशक के बीच का एक अलग, Microsoft-समर्थित authentication scheme था, जो Purported Responsible Address (PRA) check पर बना था। इसे कभी असली adoption नहीं मिला और IETF ने इसे काफी पहले “Historic” status दे दिया था — यानी यह practically खत्म हो चुका है। आज आपके domain को असल में जो protect करता है वह एक अलग, तीन-हिस्सों वाला system है: SPF, DKIM और DMARC, और ऊपर से इनाम के तौर पर BIMI। यह guide इन चारों को ठीक से समझाती है, क्योंकि 2026 तक ये optional extras नहीं रहे — Gmail, Yahoo और Microsoft अब non-compliant mail को सीधे reject कर देते हैं।
Email Authentication Optional क्यों नहीं रहा
Gmail और Yahoo ने फरवरी 2024 से bulk senders के लिए SPF, DKIM और DMARC enforce करना शुरू किया, और 2025 के अंत तक यह enforcement और सख्त हो गया: non-compliant messages को inbox तक पहुंचने से पहले ही permanent 5xx rejection मिल जाता है, सिर्फ spam-folder soft-fail नहीं। Microsoft ने भी 2025 के दौरान Outlook.com, Hotmail और Live.com के लिए इसी तरह की requirements लागू कर दीं। अगर आपका domain रोज personal Gmail या Yahoo accounts को 5,000+ messages भेजता है, तो अब न्यूनतम standard है: valid SPF, valid DKIM, एक published DMARC policy, bulk mail पर one-click unsubscribe (RFC 8058), और 0.3% से कम spam-complaint rate।
इस volume threshold से नीचे भी, unauthenticated mail अब डिफ़ॉल्ट रूप से spam में जाने लगा है — inbox providers sender के size से independent, authentication status को एक core trust signal की तरह इस्तेमाल करते हैं।
SPF — Sender Policy Framework
SPF (RFC 7208) एक ही सवाल का जवाब देता है: “क्या इस server को इस domain के लिए mail भेजने की permission है?” आप एक DNS TXT record publish करते हैं जिसमें उन IP addresses और third-party services (आपका email host, आपका CRM, आपका marketing platform) की list होती है जो आपके domain की तरफ से mail भेजने के लिए authorized हैं। Receiving server connecting IP को उस list से मिलाकर check करता है।
जो गलती ज्यादातर domains करते हैं: SPF में हर check के लिए ज्यादा से ज्यादा 10 DNS lookups की सीमा होती है। जब आप बहुत सारे include: statements जोड़ते जाते हैं — अपना email platform, helpdesk, marketing tool, invoicing system — तो चुपचाप यह limit पार हो जाती है, और उस पल SPF सबके लिए fail हो जाता है, legitimate mail के लिए भी। जब भी कोई नया sending tool जोड़ें, अपना SPF record audit करें — सिर्फ तब नहीं जब कुछ टूट जाए।
DKIM — DomainKeys Identified Mail
DKIM (RFC 6376) एक अलग सवाल का जवाब देता है: “क्या यह message रास्ते में बदला गया, और क्या यह असल में वहीं से आया जहां से दावा कर रहा है?” आपका mail server हर outgoing message को एक private key से sign करता है; public key एक “selector” के तहत DNS TXT record में रहती है। Receiving server signature को उस public key से मिलाकर verify करता है — अगर message रास्ते में बदला गया, या signature match नहीं करता, तो DKIM fail हो जाता है।
SPF के उलट, DKIM message के साथ खुद travel करता है, इसलिए यह simple forwarding में भी बना रहता है। सबसे आम गलती: teams अपने main mail server के लिए DKIM set up करते हैं और बाकी हर platform को भूल जाते हैं जो उनकी तरफ से mail भेजता है — DKIM को हर sending source पर अलग-अलग, अपने खुद के selector के साथ configure करना पड़ता है।
DMARC — वह policy layer जो सबको जोड़ता है
अकेले SPF और DKIM उस address को spoof होने से नहीं रोक पाते, जिसे कोई इंसान असल में देखता है। DMARC (RFC 7489) उस gap को बंद करता है: इसके लिए जरूरी है कि SPF या DKIM (आदर्श रूप से दोनों) pass करें और “aligned” हों — यानी वे उसी domain को authenticate करें जो visible From: address में दिखता है, सिर्फ किसी technical envelope address को नहीं जिसे recipient कभी देखता ही नहीं। DMARC यह भी बताता है कि receiving servers fail होने वाले mail का क्या करें: p=none (सिर्फ monitor करें), p=quarantine (spam में भेजें), या p=reject (सीधे block करें) — साथ ही aggregate reports (rua=) कहां भेजें ताकि enforce करने से पहले आप देख सकें कि क्या fail हो रहा है।
2026 का एक असहज करने वाला industry आंकड़ा: global DMARC adoption 50% से ऊपर पहुंच चुका है, लेकिन उन domains में से ज्यादातर अब भी p=none पर ही बैठे हैं — वे देख रहे हैं, protect नहीं कर रहे। एक DMARC record जो कभी monitoring से आगे नहीं बढ़ता, वह zero spoofing रोकता है।
BIMI — बाकी सब ठीक करने का इनाम
BIMI (Brand Indicators for Message Identification) वह चीज़ है जो आपके verified logo को inbox में आपके emails के बगल में दिखाती है — लेकिन यह बाकी तीनों के पूरा होने पर ही मिलता है: logo दिखने से पहले आपको DMARC को quarantine या reject पर enforce करना होगा, साथ ही SPF और DKIM दोनों properly aligned होने चाहिए। Vendor data में BIMI logos से reported open-rate lift करीब 39% तक पहुंचता है — guaranteed नहीं, लेकिन DMARC rollout को p=none पर हमेशा के लिए parked रखने के बजाय पूरा करने की एक असली वजह।
वे आम गलतियां जो चुपचाप authentication तोड़ देती हैं
- SPF का 10-lookup limit पार करना — आमतौर पर जमा होते गए third-party
include:entries की वजह से, जिन्हें कोई audit नहीं करता। - Secondary senders पर DKIM का न होना — marketing platform या support desk जो आपके domain की तरफ से mail भेजता है लेकिन उसका अपना DKIM selector नहीं है।
- DMARC alignment mismatch — SPF/DKIM technically pass तो कर जाते हैं, लेकिन उस domain के लिए जो visible From: address से अलग होता है, इसलिए DMARC फिर भी fail हो जाता है।
p=noneसे कभी आगे न बढ़ना — reports set up हो जाते हैं और फिर कोई उन्हें review नहीं करता या enforcement की तरफ नहीं बढ़ता।- Subdomains को भूल जाना — कोई spoofed
mail.yourdomain.comयाnews.yourdomain.comजिसकी अपनी कोई policy नहीं है, वह एक खुला दरवाज़ा है जिसे बंद करने के लिए ही DMARC की subdomain policy (sp=) बनी है।
इसे सही तरीके से set up करना
- वह हर service list करें जो आपके domain की तरफ से mail भेजती है — mail server, CRM, marketing tool, invoicing, helpdesk।
- इन सबको cover करता एक SPF record publish करें, 10 lookups के अंदर रहते हुए।
- हर sending source पर, सिर्फ primary mail server पर नहीं, अपने खुद के selector के साथ DKIM configure करें।
rua=reporting चालू करकेp=noneपर एक DMARC record publish करें — और reports को असल में पढ़ें।- reports में जो भी fail दिख रहा है उसे ठीक करें, फिर
p=quarantineऔर अंत मेंp=rejectपर graduate करें। - एक बार DMARC enforce हो जाए, तो अगर inbox में brand recognition matter करता है तो BIMI के लिए apply करें।
XgenPlus इसमें कैसे मदद करता है
XgenPlus SPF, DKIM और DMARC support को core administration की तरह देता है, कोई bolt-on feature नहीं — domain setup, selector management और policy enforcement उसी admin console से handle होते हैं जो user और mailbox management के लिए इस्तेमाल होता है, 25+ years की email infrastructure और 50M+ mailboxes के अनुभव के साथ। जिन organizations को transport-level authentication से एक कदम आगे जाना है, उनके लिए XgenPlus S/MIME के लिए एक in-house PKI/Certificate Authority भी चलाता है — message-level signing और encryption, जहां trust chain किसी विदेशी third party के पास नहीं, आपके अपने control में रहता है।
अक्सर पूछे जाने वाले सवाल
क्या “Sender ID” और SPF एक ही चीज़ हैं?
नहीं। Sender ID 2000 के दशक के बीच का एक अलग, Microsoft-समर्थित authentication proposal था जो Purported Responsible Address (PRA) check इस्तेमाल करता था। इसे कभी असली adoption नहीं मिला और IETF ने इसे तब से Historic classify कर दिया है। Modern email authentication SPF, DKIM और DMARC पर चलता है।
क्या मुझे SPF, DKIM और DMARC तीनों चाहिए, या एक ही काफी है?
तीनों चाहिए, क्योंकि वे अलग-अलग सवालों के जवाब देते हैं। SPF check करता है कि sending server authorized है या नहीं; DKIM check करता है कि message बदला गया या नहीं और origin को cryptographically verify करता है; DMARC check करता है कि SPF/DKIM visible From: address से align होते हैं या नहीं, और तय करता है कि न होने पर क्या हो। इनमें से अकेला कोई भी एक gap छोड़ जाता है जिसे बाकी बंद करते हैं।
SPF set up होने के बावजूद Gmail मेरा mail क्यों reject करता रहता है?
सबसे आम वजहें: SPF का 10-DNS-lookup limit पार करना (जिससे यह चुपचाप fail हो जाता है), उस specific platform पर DKIM का न होना जिसने वह message भेजा, या authenticated domain और visible From: address के बीच DMARC alignment mismatch। 2024-2025 से, Gmail और Yahoo non-compliant bulk mail को सिर्फ spam-folder में डालने के बजाय hard-reject भी करने लगे हैं।
DMARC का “p=none” असल में किससे protect करता है?
अपने आप में कुछ नहीं — p=none सिर्फ monitor-only है। यह एक जरूरी पहला कदम है (ताकि enforce करने से पहले आप देख सकें कि क्या टूटेगा), लेकिन एक DMARC record जो हमेशा के लिए p=none पर parked रहता है, वह zero spoofing रोकता है। असली protection p=quarantine या p=reject पर graduate करने से मिलती है।
BIMI (inbox में logo वाला feature) पाने से पहले मुझे क्या चाहिए?
DMARC का quarantine या reject पर enforce होना (none पर नहीं), साथ ही SPF और DKIM दोनों का आपके domain से properly aligned होना, और एक certificate — Gmail, Yahoo और Apple Mail में broad support के लिए एक Verified Mark Certificate (VMC, जिसके लिए registered trademark चाहिए), या सिर्फ Gmail support के लिए एक Common Mark Certificate (CMC, जिसके लिए trademark जरूरी नहीं)।
अंतिम बात
Email authentication करीब दो सालों में “होना अच्छा है” से “bilkul deliver होने के लिए mandatory” बन गया। अगर आपका domain अब भी सालों पहले copy-paste किए गए SPF record पर चल रहा है, DKIM सिर्फ एक sending source पर है, और DMARC जिस दिन बना था उसी दिन से p=none पर बैठा है, तो इसे अभी ठीक कर लेना बेहतर है — इससे पहले कि किसी provider का अगला enforcement update आपके mail को bounce करके इसे खुद ठीक कर दे।
- XgenPlus की email security और authentication controls देखें — SPF, DKIM, DMARC और admin-level policy management।
- S/MIME के साथ एक कदम और आगे जाएं — message-level signing और encryption के लिए in-house PKI/CA।
- हमारी team से बात करें अपने मौजूदा SPF/DKIM/DMARC setup को audit कराने के लिए।
