अपने DNS का अनुमान लगाना बंद करें: MX, SPF, DKIM और DMARC का डेवलपर-हितैषी परिचय

अब email DNS records क्यों मायने रखते हैं

Email authentication पहले optional हुआ करता था। 2026 में, यह बुनियादी आवश्यकता है। Gmail और Outlook दोनों bulk senders के लिए SPF और DKIM enforce करते हैं, और DMARC किसी भी ऐसे domain के लिए तेजी से अनिवार्य हो रहा है जो transactional email भेजता है। अगर आपके DNS records गलत हैं, तो आपके emails पहुंचते नहीं—कोई bounce नहीं, कोई warning नहीं, बस सन्नाटा।

समस्या यह है कि ये records tools की तरह नहीं, RFCs की तरह documented हैं। ज़्यादातर developers अपने email provider की setup guide से examples copy-paste करते हैं और उम्मीद करते हैं कि सब ठीक रहेगा। यह तब तक चलता है जब तक आपको troubleshoot करना हो, कोई दूसरी sending service जोड़नी हो, या किसी client को समझाना हो कि उनके contact form emails spam में क्यों जा रहे हैं।

यह guide MX, SPF, DKIM और DMARC को उसी क्रम में समझाती है जिसमें आप वास्तव में उनसे मिलेंगे, इतनी detail के साथ कि आप उन्हें सही ढंग से configure कर सकें और इतना context भी कि टूटने पर debug कर सकें।

MX records: inbound email कहां जाता है

MX records internet को बताते हैं कि आपके domain के लिए कौन से mail servers email accept करते हैं। ये चारों में सबसे सरल हैं, लेकिन गलत configure करना भी सबसे आसान है।

एक MX record के दो हिस्से होते हैं: priority number और hostname। कम priority numbers पहले try किए जाते हैं। अगर आप Google Workspace इस्तेमाल करते हैं, तो आपके MX records कुछ ऐसे दिख सकते हैं:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

अंत में लगे dots महत्वपूर्ण हैं—वे संकेत देते हैं कि hostname fully qualified है। ज़्यादातर DNS providers उन्हें अपने-आप जोड़ देते हैं, लेकिन सभी नहीं।

आम गलतियां: MX records को hostname के बजाय A record की ओर point करना, सभी priorities को समान number पर set करना (जिससे backups रखने का उद्देश्य खत्म हो जाता है), या providers migrate करते समय पुराने MX records हटाना भूल जाना। Stale MX records यूं ही harmless नहीं पड़े रहते—वे mail loops या दो inboxes में split delivery का कारण बन सकते हैं।

अगर आप अपना contact form चला रहे हैं और third-party services पर निर्भर हुए बिना spam से बचना चाहते हैं, तो forms spam vectors कैसे बनते हैं, यह समझना एक उपयोगी शुरुआत है।

SPF: कौन से servers आपकी ओर से send कर सकते हैं

SPF (Sender Policy Framework) एक TXT record है जो उन IP addresses और domains को list करता है जिन्हें आपके domain की ओर से email भेजने की अनुमति है। यह पहला check है जो अधिकतर mail servers तब करते हैं जब उन्हें आपके नाम से आया हुआ message मिलता है।

एक basic SPF record ऐसा दिखता है:

v=spf1 include:_spf.google.com ~all

इसे तोड़कर देखें:

• v=spf1 SPF version declare करता है
• include:_spf.google.com Google's SPF record को delegate करता है
• ~all soft fail है—unlisted sources से mail reject करें, लेकिन बहुत strict न हों

आप specific addresses को whitelist करने के लिए ip4: या ip6: भी इस्तेमाल कर सकते हैं, या अपने domain के A और MX records को reference करने के लिए a और mx। अंत में all mechanism control करता है कि उन sources से आए mail के साथ क्या हो जिन्हें आपने list नहीं किया: -all hard fail है (reject), ~all soft fail है (suspicious mark करें), ?all neutral है (कोई opinion नहीं), और +all free-for-all है (इसे इस्तेमाल न करें)।

SPF की दो तेज धारें हैं। पहली, email forward होने पर यह टूट जाता है, क्योंकि forwarding server आपके SPF record में नहीं होता। दूसरी, SPF records की lookup limit दस DNS queries है। अगर आप बहुत सारी third-party services include करते हैं, तो आप limit पार कर देंगे और SPF काम करना बंद कर देगा। Fix है अपने SPF record को flatten करना—include: directives को actual IP ranges से replace करना—लेकिन जब providers अपने IPs बदलते हैं तो इसके लिए maintenance चाहिए।

DKIM: sender identity का cryptographic proof

DKIM (DomainKeys Identified Mail) आपके outbound email में digital signature जोड़ता है। Receiving server आपके DNS में published public key के against signature check करता है। अगर signature valid है और message से छेड़छाड़ नहीं हुई है, तो DKIM pass हो जाता है।

SPF के विपरीत, DKIM forwarding में भी बचा रहता है, क्योंकि signature message के साथ travel करता है। यह अधिक flexible भी है—आप अलग-अलग sending services के लिए multiple DKIM keys रख सकते हैं, हर एक अपने selector के साथ।

एक DKIM DNS record ऐसा दिखता है:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selector (इस example में default) arbitrary होता है—आपका email provider इसे चुनता है। p= value public key है, आमतौर पर एक लंबी base64-encoded string। आपका email provider private key generate करता है और outgoing messages sign करने के लिए उसका इस्तेमाल करता है।

DKIM setup लगभग हमेशा आपका email provider handle करता है। आपका काम है कि वे जो TXT record दें उसे copy करके अपने DNS में paste करें। मुश्किल हिस्सा यह है कि कुछ DNS providers long TXT records को ठीक से handle नहीं करते—वे उन्हें truncate कर देते हैं या value को multiple quoted strings में split करने की आवश्यकता रखते हैं।

DKIM काम कर रहा है या नहीं verify करने के लिए, Gmail address पर एक test email भेजें और headers check करें। Authentication-Results header में dkim=pass देखें।

DMARC: policy enforcement और reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) SPF और DKIM को साथ जोड़ता है और receiving servers को बताता है कि authentication fail होने पर क्या करना है। यह reporting भी enable करता है, ताकि आप देख सकें कि आपके domain के रूप में कौन email भेज रहा है—legitimate भी और spoofed भी।

एक minimal DMARC record ऐसा दिखता है:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none का मतलब है केवल monitor—failed messages को reject या quarantine न करें
• rua=mailto:[email protected] specify करता है कि aggregate reports कहां भेजनी हैं

जब आपको भरोसा हो जाए कि SPF और DKIM काम कर रहे हैं, तो आप policy को p=quarantine (failures को spam में भेजें) या p=reject (उन्हें सीधे bounce करें) तक tighten कर सकते हैं। आप sp= के साथ subdomain policy भी set कर सकते हैं और pct= के साथ यह specify कर सकते हैं कि कितने percentage messages पर policy apply करनी है।

DMARC reports XML files होती हैं जिन्हें major receivers daily भेजते हैं। वे verbose होती हैं और raw पढ़ना कठिन होता है, लेकिन वे आपको ठीक-ठीक बताती हैं कि कौन से messages authentication में pass या fail हुए और क्यों। अगर legitimate mail reject हो रहा है, तो reports दिखाएंगी कि कौन सा SPF या DKIM check fail हो रहा है।

एक gotcha: DMARC को alignment चाहिए। SPF के लिए, Return-Path header में domain को From header में domain से match करना चाहिए (या subdomain होना चाहिए)। DKIM के लिए, DKIM signature में d= domain को From domain से match करना चाहिए। अगर आप third-party sending service इस्तेमाल कर रहे हैं, तो उन्हें custom return paths या आपके domain के साथ DKIM signing support करना होगा, अपने domain के साथ नहीं।

अपने current setup का audit कैसे करें

ज़्यादातर DNS issues तब तक अदृश्य रहते हैं जब तक वे समस्या पैदा न करें। कुछ टूटने से पहले अपने records check करने का तरीका यह है:

1. अपने MX records query करें: dig MX example.com आपके mail server hostnames और priorities return करना चाहिए। Verify करें कि वे आपके email provider की documentation से match करते हैं।

1. SPF syntax check करें: dig TXT example.com और v=spf1 record देखें। Syntax errors और lookup limit violations पकड़ने के लिए इसे SPF validator से run करें।

1. DKIM keys verify करें: एक test email भेजें और DKIM-Signature header inspect करें। Selector और domain extract करें, फिर public key मौजूद है यह confirm करने के लिए dig TXT selector._domainkey.example.com query करें।

1. DMARC policy validate करें: dig TXT _dmarc.example.com को आपका DMARC record return करना चाहिए। सुनिश्चित करें कि rua= ऐसे address की ओर point करता है जिसे आप सच में monitor करते हैं।

1. End-to-end test करें: mail-tester.com जैसी service इस्तेमाल करें या Gmail address पर भेजें और full headers check करें। Authentication-Results header में spf=pass, dkim=pass, और dmarc=pass देखें।

अगर आप debug कर रहे हैं कि emails क्यों नहीं पहुंच रहे, तो headers आपका सबसे अच्छा tool हैं। ज़्यादातर mail clients आपको raw headers देखने देते हैं—Gmail में, message खोलें, तीन dots पर click करें, और 'Show original' select करें। Authentication-Results header आपको ठीक-ठीक बताएगा कि कौन सा check fail हुआ और क्यों।

Subdomain policies कब इस्तेमाल करें

अगर आप multiple subdomains से email भेजते हैं—मान लें, marketing के लिए newsletter.example.com और transactional mail के लिए app.example.com—तो आप per-subdomain DMARC policies set कर सकते हैं। इससे आप जिन subdomains को control करते हैं उन पर strict policies enforce कर सकते हैं, जबकि main domain पर looser policy रख सकते हैं।

Trade-off complexity है। हर subdomain को अपने SPF, DKIM, और DMARC records चाहिए, और आपको track करना होगा कि कौन सी sending services किन subdomains के लिए authorized हैं। अधिकतर small teams के लिए, एक single well-configured domain सरल है और उतना ही secure भी।

Authentication टूटने पर क्या करें

सबसे common failure mode है DNS update किए बिना नई sending service जोड़ना। अगर आप नया transactional email provider इस्तेमाल करना शुरू करते हैं, तो आपको उनका SPF include या IP range add करना होगा, अपने domain के साथ DKIM signing configure करना होगा, और DMARC alignment verify करना होगा।

दूसरी सबसे common issue forwarding है। अगर users आपका email किसी दूसरे address पर forward करते हैं, तो SPF fail होगा क्योंकि forwarding server आपके SPF record में नहीं है। DKIM आमतौर पर forwarding में बचा रहता है, इसलिए जब तक DKIM pass है और आपकी DMARC policy partial alignment allow करती है, message फिर भी deliver होना चाहिए। अगर forwarded mail reject हो रहा है, तो अपनी DMARC policy check करें—strict alignment के साथ p=reject forwarding को तोड़ देगा।

तीसरी issue DNS propagation है। DNS records में changes propagate होने में घंटों लग सकते हैं, और अलग-अलग mail servers records को अलग-अलग समय तक cache करते हैं। अगर आपने अभी record update किया है और यह काम नहीं कर रहा, तो कुछ घंटे इंतज़ार करें और फिर test करें। आप whatsmydns.net जैसे tool से propagation check कर सकते हैं।

मुख्य बातें

• MX records inbound mail route करते हैं; SPF, DKIM और DMARC outbound mail authenticate करते हैं। वे अलग-अलग problems solve करते हैं और आपको चारों चाहिए।
• SPF forwarding पर टूट जाता है और इसकी ten-lookup limit है। DKIM forwarding में बचा रहता है लेकिन per-service configuration मांगता है। DMARC उन्हें साथ जोड़ता है और reporting enable करता है।
• DMARC में p=none से शुरू करें, कुछ हफ्तों तक reports monitor करें, फिर जब आपको भरोसा हो कि legitimate mail pass हो रहा है, तो p=quarantine या p=reject तक tighten करें।
• DNS errors silent होते हैं। Real email के साथ अपनी configuration test करें और headers inspect करके confirm करें कि SPF, DKIM और DMARC pass हो रहे हैं।
• अगर नई sending service जोड़ने के बाद authentication टूटता है, तो SPF includes, DKIM selectors, और DMARC alignment check करें। Headers आपको बताएंगे कि कौन सा check fail हुआ।

FAQ

Q: क्या मेरे पास multiple SPF records हो सकते हैं?

A: नहीं। Multiple SPF records की वजह से उन सभी को ignore कर दिया जाएगा। अगर आपको multiple services authorize करनी हैं, तो single SPF record के भीतर include: directives इस्तेमाल करें, या IP ranges सीधे list करें। Ten-lookup limit पर ध्यान दें।

Q: अगर मैं दिन में केवल कुछ emails भेजता हूं तो क्या मुझे DMARC चाहिए?

A: हां। DMARC volume के बारे में नहीं है—यह prove करने के बारे में है कि आप वही हैं जो आप कहते हैं। Small domains को भी DMARC से लाभ होता है क्योंकि यह spoofing रोकता है और delivery issues में visibility देता है। p=none और reporting address से शुरू करें।

Q: अगर DKIM और SPF दोनों fail हो जाएं लेकिन email legitimate दिखे तो क्या होता है?

A: यह आपकी DMARC policy पर निर्भर करता है। अगर p=none है, तो mail warning के साथ deliver होता है। अगर p=quarantine है, तो यह spam में जाता है। अगर p=reject है, तो यह bounce होता है। इसी वजह से strict policy enforce करने से पहले आपको DMARC reports monitor करनी चाहिए—हो सकता है आपके पास legitimate senders हों जिनके बारे में आपको पता न हो।

Q: क्या मैं multiple domains के लिए वही DKIM key इस्तेमाल कर सकता हूं?

A: Technically हां, लेकिन ऐसा न करें। हर domain की अपनी DKIM key pair होनी चाहिए। Keys share करने से rotation कठिन हो जाता है और private key compromise होने पर blast radius बढ़ जाता है।

Q: मुझे DKIM keys कितनी बार rotate करनी चाहिए?

A: कोई universal rule नहीं है, लेकिन अधिकतर domains के लिए साल में एक बार reasonable है। अगर आपको शक है कि कोई key compromise हुई है, तो तुरंत rotate करें। New private key से signing शुरू करने से पहले DNS में new public key publish करना सुनिश्चित करें, और delayed mail handle करने के लिए rotation के बाद कुछ दिनों तक old key DNS में रहने दें।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: DMARC Lookup के साथ किसी भी डोमेन की प्रकाशित नीति की जाँच करें, ताकि देखा जा सके कि व्यवहार में MX, SPF और DMARC रिकॉर्ड कैसे एक साथ फिट होते हैं।

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — SPF specification, जिसमें syntax rules और ten-lookup limit शामिल हैं।
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specification, जिसमें signature generation और verification शामिल हैं।
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC specification, जिसमें policy syntax और aggregate reporting format शामिल हैं।
• Google Workspace: Prevent spoofing and spam — Google Workspace domains के लिए SPF, DKIM और DMARC configuration पर practical guidance।