होम › गाइड

SPF, DKIM और DMARC सेटअप: रिकॉर्ड, आम गलतियाँ और जाँच

प्रकाशित 2026-11-03 ／ अपडेट 2026-11-03 ／ लेखक Yuki Nakazawa

अगर आप अपने डोमेन से ईमेल भेजते हैं, तो SPF, DKIM और DMARC सेटअप अब वैकल्पिक नहीं रहा। इसे इस क्रम में करें: एक SPF रिकॉर्ड प्रकाशित करें, 2048-बिट key के साथ DKIM साइनिंग चालू करें, फिर ऐसा DMARC रिकॉर्ड प्रकाशित करें जो रिपोर्टिंग के साथ p=none से शुरू हो। साथ ही यह भी सुनिश्चित करें कि आपका मेल भेजने वाले IP पते का reverse DNS (PTR) मेल खाता हो।

यह गाइड हर स्थिति में काम आती है, चाहे आप शेयर्ड होस्टिंग, अपने VPS, Google Workspace, Microsoft 365 या किसी बल्क ईमेल सेवा से भेजते हों। इसमें ऐसे रिकॉर्ड हैं जिन्हें आप अपने हिसाब से बदल सकते हैं, वे गलतियाँ हैं जो सबसे ज़्यादा ऑथेंटिकेशन बिगाड़ती हैं, और यह भी कि किसी असली संदेश के हेडर से कैसे पुष्टि करें कि सब कुछ काम कर रहा है।

नीचे दिए गए तथ्य नवंबर 2026 की स्थिति में RFC और Google, Yahoo व Microsoft के आधिकारिक पेजों से मिलाए गए हैं। मेलबॉक्स प्रोवाइडरों की आवश्यकताएँ बदलती रहती हैं, इसलिए अंतिम जानकारी के लिए उनके पेजों को ही आधार मानें।

SPF, DKIM और DMARC क्या साबित करते हैं, और उन्हें किस क्रम में सेट करें

SPF (Sender Policy Framework) से कोई डोमेन DNS में यह सूची दे सकता है कि कौन-से सर्वर उसका मेल भेजने के लिए अधिकृत हैं। प्राप्त करने वाला सर्वर envelope sender (SMTP MAIL FROM पता, जो बाद में Return-Path के रूप में दिखता है) देखता है, उस डोमेन का SPF रिकॉर्ड लेता है और जाँचता है कि कनेक्ट करने वाला IP पता सूची में है या नहीं। अकेला SPF पाठक को दिखने वाले From पते के बारे में कुछ नहीं कहता।

DKIM (DomainKeys Identified Mail) हर संदेश में एक क्रिप्टोग्राफ़िक सिग्नेचर जोड़ता है। भेजने वाला सिस्टम private key से साइन करता है, और प्राप्तकर्ता DNS में प्रकाशित public key से सिग्नेचर को सत्यापित करते हैं। मान्य सिग्नेचर यह साबित करता है कि साइन करने वाले डोमेन (d= मान) ने संदेश की ज़िम्मेदारी ली है और साइन किए गए हेडर व मुख्य भाग रास्ते में बदले नहीं गए।

DMARC (Domain-based Message Authentication, Reporting and Conformance) इन दोनों को दिखाई देने वाले From डोमेन से जोड़ता है। कोई संदेश DMARC में तभी पास होता है जब SPF या DKIM पास हो और ऑथेंटिकेटेड डोमेन From डोमेन के साथ aligned हो। DMARC रिकॉर्ड प्राप्तकर्ताओं को यह भी बताता है कि विफल संदेशों के साथ आप क्या करवाना चाहते हैं (कुछ नहीं, quarantine या reject) और aggregate रिपोर्ट कहाँ भेजनी हैं; इन्हीं रिपोर्टों से आपको वे सेंडिंग स्रोत पता चलते हैं जिन्हें आप भूल गए थे।

सेटअप का क्रम

1. आपके डोमेन के नाम से मेल भेजने वाले हर सिस्टम की सूची बनाएँ: आपका अपना सर्वर, Google Workspace या Microsoft 365, न्यूज़लेटर और transactional ईमेल सेवाएँ, वेब फ़ॉर्म, इनवॉइस और हेल्प डेस्क टूल।
2. एक ही SPF रिकॉर्ड प्रकाशित करें जो इन सभी को कवर करे।
3. हर सेंडिंग सिस्टम पर DKIM चालू करें और उसकी public key प्रकाशित करें।
4. p=none और एक rua रिपोर्टिंग पते के साथ DMARC प्रकाशित करें। Google सुझाव देता है कि SPF और DKIM सेट करने के बाद DMARC जोड़ने से पहले 48 घंटे प्रतीक्षा करें।
5. रिपोर्ट पढ़ें, विफल होने वाले स्रोतों को ठीक करें, फिर p=quarantine पर और अंत में p=reject पर जाएँ।

SPF सेटअप: एक रिकॉर्ड, दस lookup

SPF डोमेन पर ही एक TXT रिकॉर्ड होता है। यह एक ऐसे डोमेन का उदाहरण है जो अपने सर्वर से IPv4 और IPv6 पर भेजता है और Google Workspace का भी उपयोग करता है:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

ज़्यादातर DNS कंट्रोल पैनल में होस्ट फ़ील्ड खाली छोड़ी जाती है (या @ डाला जाता है), TXT चुना जाता है, और v=spf1 से शुरू होने वाला मान पेस्ट किया जाता है। आम घटक:

SPF की आम गलतियाँ

• हर नाम पर केवल एक SPF रिकॉर्ड। RFC 7208 एक ही डोमेन के लिए कई SPF रिकॉर्ड की अनुमति नहीं देता; प्राप्तकर्ता permerror लौटाते हैं और हर संदेश के लिए SPF विफल हो जाता है। कोई सेवा जोड़ते समय दूसरा v=spf1 रिकॉर्ड बनाने के बजाय मौजूदा रिकॉर्ड को एडिट करें और उसमें उसका include: जोड़ें।
• 10-lookup की सीमा। include, a, mx, ptr और exists mechanism तथा redirect modifier, सभी DNS lookup करवाते हैं, और पूरे मूल्यांकन में कुल lookup, nested include के अंदर के lookup समेत, 10 से ज़्यादा नहीं होने चाहिए। सीमा पार होने पर permerror आता है। ip4:, ip6: और all से कोई lookup नहीं होता। RFC 7208 यह भी कहता है कि बिना जवाब वाले दो lookup के बाद प्राप्तकर्ताओं को रुक जाना चाहिए, इसलिए जिन सेवाओं का अब उपयोग नहीं करते उनके include हटा दें।
• ~all बनाम -all। -all का मतलब है कि सूची में न दिए गए स्रोत अधिकृत नहीं हैं (fail); ~all का मतलब है कि वे संभवतः अधिकृत नहीं हैं (softfail)। Google, Workspace डोमेन के लिए ~all की सलाह देता है; Microsoft उन Microsoft 365 डोमेन के लिए -all की सलाह देता है जो DKIM और DMARC भी उपयोग करते हैं। अगर आपको अभी पक्का नहीं है कि आपने हर सेंडर ढूँढ लिया है, तो ~all से शुरू करें और लागू करने का काम DMARC पर छोड़ दें।
• सबडोमेन को अपना अलग रिकॉर्ड चाहिए। example.com का SPF रिकॉर्ड news.example.com को कवर नहीं करता। किसी बल्क ईमेल सेवा को उसके अपने सबडोमेन पर रखने से उसे 10 lookup का अलग बजट भी मिलता है और उसकी रेप्युटेशन आपके स्टाफ़ के मेल से अलग रहती है।
• सिंटैक्स की छोटी गलतियाँ। Microsoft आम गलतियाँ बताता है: include: की जगह include=, कोलन के बाद स्पेस, और शामिल किए गए डोमेन के बाद आख़िर में डॉट।

जो डोमेन कभी मेल नहीं भेजते, उनके लिए v=spf1 -all प्रकाशित करें, ताकि उनकी नकल (spoofing) करना कठिन हो।

DKIM सेटअप: 2048-बिट key और selector

DKIM के दो हिस्से होते हैं: भेजने वाला सिस्टम private key से साइन करता है, और DNS उससे मेल खाने वाली public key प्रकाशित करता है। Google Workspace, Microsoft 365, ज़्यादातर होस्टिंग कंट्रोल पैनल और ज़्यादातर ईमेल सेवाओं में आप एडमिन कंसोल में key बनाते हैं और वहाँ दिखाया गया DNS मान कॉपी करते हैं।

Key की लंबाई और selector

2048-बिट RSA key का उपयोग करें। RFC 8301 न्यूनतम 1024 बिट तय करता है और कहता है कि साइन करने वालों को कम से कम 2048 बिट का उपयोग करना चाहिए; यह rsa-sha1 पर भी रोक लगाता है। Google का मार्गदर्शन भी यही है: अगर आपका DNS होस्ट समर्थन करता है तो 2048 बिट चुनें, और केवल समर्थन न होने पर ही 1024 पर जाएँ।

Selector एक लेबल है जो बताता है कि किस key ने संदेश साइन किया, ताकि एक डोमेन की एक साथ कई key हो सकें, हर सेंडिंग सेवा के लिए एक या हर rotation अवधि के लिए एक। Public key selector._domainkey.yourdomain पर होती है। Google Workspace डिफ़ॉल्ट selector के रूप में google का उपयोग करता है। Microsoft 365 दो CNAME रिकॉर्ड, selector1._domainkey और selector2._domainkey, का उपयोग करता है जो Microsoft द्वारा होस्ट की गई key की ओर इशारा करते हैं; सटीक target, Defender पोर्टल या Get-DkimSigningConfig से लें, क्योंकि उनका फ़ॉर्मेट tenant के अनुसार बदलता है।

लंबी public key प्रकाशित करना

2048-बिट public key, एक DNS character-string में अनुमत 255 अक्षरों से लंबी होती है, इसलिए zone-file के रूप में इसे एक ही TXT रिकॉर्ड में कई quoted string के रूप में लिखा जाता है:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

कोष्ठक वाले हिस्सों को अपनी असली key से बदलें। प्राप्तकर्ता इन string को बीच में बिना किसी स्पेस के जोड़ते हैं, इसलिए key के अंदर कहीं भी विभाजन किया जा सकता है। कई कंट्रोल पैनल लंबे मान को अपने-आप विभाजित कर देते हैं: पहले पूरा मान पेस्ट करें, और केवल तभी खुद विभाजित करें जब पैनल उसे स्वीकार न करे। ध्यान रखें कि कॉपी करते समय कुछ छूट न जाए; खाली p= का मतलब है कि key रद्द (revoke) कर दी गई है।

Postfix या इसी तरह का MTA चलाने वाले अपने VPS पर, OpenDKIM जैसा signing milter key pair बना सकता है, उदाहरण के लिए opendkim-genkey -b 2048 -s selector1 -d example.com। बनी हुई public key फ़ाइल की सामग्री ऊपर दिखाए गए तरीके से प्रकाशित करें।

जाँचें कि संदेश सच में साइन हो रहे हैं

अपना भेजा हुआ कोई संदेश खोलें और DKIM-Signature: हेडर देखें। उसका d= टैग आपका डोमेन होना चाहिए और s= वह selector जिसे आपने प्रकाशित किया। कई ईमेल सेवाएँ डिफ़ॉल्ट रूप से अपने डोमेन से साइन करती हैं; इससे DKIM पास होता है, लेकिन यह आपके From डोमेन के साथ aligned नहीं होता, इसलिए DMARC में मदद नहीं करता। सेवा का custom domain authentication चालू करें ताकि d= आपका डोमेन बन जाए।

DMARC सेटअप: p=none से शुरू करें, फिर लागू करें

DMARC आपके डोमेन के अंतर्गत _dmarc पर एक TXT रिकॉर्ड है। monitoring मोड से शुरू करें, जिसमें प्राप्तकर्ताओं से कहा जाता है कि वे आपके मेल को संभालने का तरीका न बदलें, और aggregate रिपोर्ट माँगें:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Aggregate रिपोर्ट मशीन से पढ़े जा सकने वाले सारांश होते हैं, जो बताते हैं कि किन IP पतों ने आपके डोमेन के नाम से मेल भेजा और वह पास हुआ या नहीं; Google इन्हें पाने के लिए एक अलग मेलबॉक्स या ग्रुप रखने का सुझाव देता है। जब रिपोर्ट दिखा दें कि हर वैध स्रोत alignment के साथ पास हो रहा है, तो दूसरा रिकॉर्ड जोड़ने के बजाय उसी रिकॉर्ड को एडिट करके नीति सख्त करें:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alignment, आसान शब्दों में

DMARC में पास होने के लिए SPF या DKIM में से कम से कम एक को ऐसे डोमेन के लिए पास होना चाहिए जो From डोमेन से मेल खाता हो। relaxed मोड में organizational डोमेन मेल खाने चाहिए, इसलिए d=example.com वाला DKIM सिग्नेचर alerts@news.example.com से आए मेल के साथ aligned होता है। strict मोड में बिल्कुल सटीक मेल ज़रूरी है। ईमेल सेवाएँ अक्सर Return-Path में अपना डोमेन इस्तेमाल करती हैं, इसलिए SPF पास होने पर भी aligned नहीं होगा; ऐसे संदेशों को DMARC से पास कराने का व्यावहारिक तरीका aligned DKIM है।

अगर आप सबडोमेन के लिए अलग नीति चाहते हैं, तो sp= जोड़ें। उदाहरण के लिए, p=reject; sp=quarantine मुख्य डोमेन से आए विफल मेल को reject करता है, जबकि सबडोमेन से आए विफल मेल को केवल quarantine करता है।

अपडेट हुए मानक के बारे में

मई 2026 में DMARC को RFC 9989 के रूप में दोबारा प्रकाशित किया गया, जिसने RFC 7489 का स्थान ले लिया। मौजूदा रिकॉर्ड काम करते रहेंगे और अब भी v=DMARC1 से शुरू होते हैं। नया मानक pct टैग को हटाता है, जो 0 या 100 के अलावा शायद ही कभी सही ढंग से लागू होता था, और t=y (test मोड) तथा np (मौजूद न होने वाले सबडोमेन की नीति) जैसे टैग जोड़ता है। कुछ प्रोवाइडरों के सहायता पेज अब भी pct दिखाते हैं, इसलिए नीति को लागू करने का सबसे कम भ्रम वाला तरीका p= के मानों को एक-एक करके बदलना है।

भेजने वाले IP के लिए reverse DNS (PTR)

Reverse DNS किसी IP पते को वापस एक host name से जोड़ता है। Google निजी Gmail अकाउंट पर भेजने वाले सभी सेंडर से ऐसा PTR रिकॉर्ड रखने की अपेक्षा करता है जिसका host name वापस उसी भेजने वाले IP पर resolve हो, और Yahoo भेजने वाले IP के लिए मान्य forward और reverse DNS की अपेक्षा करता है तथा अर्थपूर्ण, non-generic PTR रिकॉर्ड की सलाह देता है।

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

PTR रिकॉर्ड आपके डोमेन के zone में नहीं होता। IP पते का मालिक ही इसे नियंत्रित करता है, इसलिए VPS पर आप इसे प्रोवाइडर के कंट्रोल पैनल में सेट करते हैं (जिसे अक्सर reverse DNS या rDNS कहा जाता है), फिर अपने DNS में उससे मेल खाता A रिकॉर्ड (IPv6 के लिए AAAA) बनाते हैं। अगर आप IPv6 पर भेजते हैं, तो IPv6 पते के लिए भी यही करना होगा। Google Workspace, Microsoft 365, ईमेल सेवाओं और ज़्यादातर शेयर्ड होस्टिंग में भेजने वाले IP और उनका reverse DNS प्रोवाइडर ही आपके लिए संभालता है।

अपने सेटअप की पुष्टि कैसे करें

Authentication-Results पढ़ें

किसी बाहरी मेलबॉक्स पर एक टेस्ट संदेश भेजें और पूरे हेडर देखें। Gmail में संदेश खोलकर Show original चुनें। Google की DKIM सहायता में बताया गया है कि खुद को भेजने के बजाय किसी दूसरे उपयोगकर्ता को भेजें। इस तरह का हेडर देखें:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

सटीक लेआउट प्राप्तकर्ता के अनुसार बदलता है। मायने यह रखता है कि spf=pass, dkim=pass और dmarc=pass हों, और header.i या header.d में तथा header.from में आपका अपना डोमेन हो। अगर SPF किसी सेवा के डोमेन के लिए पास होता है लेकिन DKIM कोई दूसरा डोमेन दिखाता है, तो DMARC विफल होगा: पहले DKIM alignment ठीक करें।

DNS को सीधे क्वेरी करें

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Windows पर nslookup -type=TXT _dmarc.example.com यही काम करता है। DNS बदलावों को फैलने में समय लग सकता है; Google कहता है कि SPF और DKIM, दोनों में से हर एक को काम शुरू करने में 48 घंटे तक लग सकते हैं। मुफ़्त ऑनलाइन चेकर भी आपके रिकॉर्ड को पार्स करके SPF lookup गिन सकते हैं।

अगर ऑथेंटिकेशन पास हो रहा है और फिर भी मेल बाउंस होता है या स्पैम में जाता है, तो हमारे ब्लैकलिस्ट चेकर से जाँचें कि आपका भेजने वाला IP या डोमेन किसी DNSBL में तो नहीं है, और आगे के कदमों के लिए ब्लैकलिस्ट की वजह से ईमेल डिलीवर न होना देखें।

Gmail, Yahoo और Outlook.com की sender requirements

बड़े मेलबॉक्स प्रोवाइडर अब ऑथेंटिकेशन लागू करते हैं। नवंबर 2026 की स्थिति में उनके आधिकारिक पेज यह कहते हैं।

• Gmail (1 फ़रवरी 2024 से लागू): निजी Gmail अकाउंट पर भेजने वाले हर व्यक्ति को SPF या DKIM, आपस में मेल खाने वाले forward और reverse DNS, TLS कनेक्शन, और Postmaster Tools में 0.3% से कम स्पैम दर की ज़रूरत है। प्रतिदिन 5,000 से ज़्यादा संदेश भेजने वालों को इसके अलावा SPF और DKIM दोनों, एक DMARC रिकॉर्ड (p=none स्वीकार्य है), SPF या DKIM के साथ aligned From डोमेन, और मार्केटिंग मेल के लिए one-click unsubscribe चाहिए। DKIM key कम से कम 1024 बिट की होनी चाहिए, और 2048 की सलाह दी जाती है।
• Yahoo (फ़रवरी 2024 से लागू): सभी सेंडर को SPF या DKIM, मान्य forward और reverse DNS और 0.3% से कम स्पैम दर चाहिए। बल्क सेंडर को SPF और DKIM दोनों, पास होने वाली कम से कम p=none की DMARC नीति, From alignment (relaxed पर्याप्त है), काम करने वाला one-click unsubscribe और भेजने वाले IP के लिए मान्य forward और reverse DNS चाहिए।
• Outlook.com (outlook.com, hotmail.com और live.com के पीछे की उपभोक्ता सेवा): प्रतिदिन 5,000 से ज़्यादा ईमेल भेजने वाले डोमेन को SPF और DKIM में पास होना होगा और SPF या DKIM के साथ aligned, कम से कम p=none वाला DMARC प्रकाशित करना होगा। Microsoft ने कहा था कि 5 मई 2025 से नियमों का पालन न करने वाले संदेश 550; 5.7.515 एरर के साथ reject किए जाएँगे।

पूरा टेक्स्ट Google email sender guidelines, Yahoo sender best practices और Microsoft की Outlook.com घोषणा में पढ़ें। अगर आप इससे बहुत कम संदेश भेजते हैं, तब भी अभी तीनों सेट कर लेने से बाद में सीमा घटने पर आप अचानक मुश्किल में नहीं पड़ेंगे। Gmail से जुड़े समस्या निवारण के लिए Gmail आपका ईमेल डिलीवर नहीं कर रहा देखें।

आम गलतियाँ

• दूसरा SPF रिकॉर्ड। हर सेवा के लिए नया v=spf1 रिकॉर्ड जोड़ने से पूरे डोमेन का SPF अमान्य हो जाता है। सब कुछ एक ही रिकॉर्ड में मिला दें।
• बहुत सारे include। SPF में छोड़ी गई पुरानी सेवाएँ 10-lookup के बजट को खा जाती हैं। जो अब उपयोग नहीं करते उसे हटाएँ और बल्क मेल को किसी सबडोमेन पर ले जाएँ।
• Key प्रकाशित है, लेकिन साइनिंग चालू नहीं। Google Workspace में DNS रिकॉर्ड लाइव होने के बाद भी आपको Start authentication पर क्लिक करना होता है; दूसरे प्लेटफ़ॉर्म पर भी ऐसा ही स्विच होता है।
• सेवा अपने ही डोमेन से साइन करती है। SPF और DKIM दोनों पास होते हैं, DMARC विफल होता है। custom domain signing चालू करें।
• सीधे p=reject पर पहुँच जाना। कोई भूला हुआ वेब फ़ॉर्म या इनवॉइस सिस्टम रातों-रात डिलीवर करना बंद कर देता है। p=none से शुरू करें और रिपोर्ट पढ़ें।
• कॉपी-पेस्ट से होने वाली गड़बड़ी। मान के अंदर फ़ालतू उद्धरण चिह्न, अधूरी key, या ऐसा host name जो _dmarc.example.com.example.com बन जाता है क्योंकि पैनल आपके लिए डोमेन अपने-आप जोड़ देता है। एक छोटा-सा dig इन सबको पकड़ लेता है।

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

उपयोग किए गए आधिकारिक पेज

इस लेख के तथ्य प्रकाशन के समय नीचे दिए गए आधिकारिक पेजों से मिलाए गए थे। नीतियाँ और व्यवहार बिना सूचना के बदल सकते हैं, इसलिए किसी महत्वपूर्ण बात पर भरोसा करने से पहले आधिकारिक पेज देख लें।

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

संबंधित गाइड

सभी गाइड →