ईमेल डोमेन स्पूफ़िंग चेकर

SPF, DKIM और DMARC आपके डोमेन के नाम से ईमेल भेजने से कैसे रोकते हैं?

SPF (RFC 7208) बताता है कि डोमेन के नाम से कौन-से सर्वर भेज सकते हैं और DKIM (RFC 6376) DNS में रखी key से मेल पर हस्ताक्षर करता है, पर दोनों में से कोई भी वह From एड्रेस नहीं जाँचता जो लोग देखते हैं। DMARC (RFC 7489) यह करता है: मेल तभी पास होता है जब From से aligned डोमेन के लिए SPF या DKIM पास हो, और डोमेन की p= नीति रिसीवर को बाक़ी मेल पहुँचाने (none), अलग रखने (quarantine) या ठुकराने (reject) को कहती है — इसलिए डोमेन सीधी स्पूफ़िंग से तभी बचता है जब वह p=quarantine या p=reject प्रकाशित करे।

सुरक्षा नोट: DMARC सिर्फ़ ठीक उसी डोमेन की रक्षा करता है। नक़ली दिखने वाले डोमेन और जाली display name हर जाँच पार कर लेते हैं, इसलिए ईमेल से आए भुगतान बदलने या लॉग-इन जानकारी माँगने वाले अनुरोधों की पुष्टि किसी दूसरे माध्यम से करनी ही चाहिए।

ईमेल डोमेन स्पूफ़िंग चेकर कैसे इस्तेमाल करें

1. From एड्रेस का डोमेन डालें (example.com); ईमेल एड्रेस या URL डोमेन में बदल दिया जाता है।
2. चाहें तो किसी संदिग्ध मेल के हेडर पेस्ट करें (Gmail: Show original; Outlook: View message source); डोमेन फ़ील्ड ख़ाली हो तो From डोमेन उन्हीं से लिया जाता है।
3. "डोमेन जाँचें" दबाएँ, स्पूफ़िंग जोखिम और उसकी वजहें पढ़ें, फिर SPF और DMARC का विवरण।
4. "आगे क्या करें" ऊपर से शुरू करें, और हर DNS बदलाव के बाद उसका TTL बीतने पर जाँच दोहराएँ।

ईमेल डोमेन स्पूफ़िंग चेकर की खूबियाँ

• सार्वजनिक DNS-over-HTTPS रिज़ॉल्वर से डोमेन के MX, SPF, DMARC, MTA-STS, TLS-RPT और BIMI रिकॉर्ड एक ही जाँच में पढ़ता है
• प्रकाशित SPF और DMARC नीतियों से आँकता है कि डोमेन के नाम से मेल जाली बनाना कितना आसान है — Low, Medium, High या अज्ञात — और स्तर तय करने वाला हर नियम बताता है
• DMARC को organizational डोमेन तक ऊपर खोजता है, ताकि बिना अपने रिकॉर्ड वाले सबडोमेन को उसी नीति से परखा जाए जो उस पर सच में लागू होती है (sp= या p=)
• SPF का अंत (-all, ~all, ?all, +all या redirect), DNS-lookup terms और दोहराए रिकॉर्ड, और DMARC की नीति, प्रतिशत, alignment मोड और रिपोर्ट एड्रेस दिखाता है
• चाहें तो पेस्ट किए मेल के हेडर आपके ब्राउज़र में पढ़ता है: रिसीव करने वाले सर्वर के दर्ज SPF, DKIM और DMARC नतीजे, From डोमेन से उनका alignment, और किसी दूसरे डोमेन का Reply-To
• अगले क़दम क्रम से बताता है: SPF प्रकाशित करें, DMARC प्रकाशित करें, p=none से quarantine और फिर reject पर जाएँ, और मेल न भेजने वाले डोमेन बंद करें

इनपुट और आउटपुट

इनपुट

• भेजने वाले का डोमेन — From एड्रेस का डोमेन; billing@example.com जैसा एड्रेस या URL डोमेन में बदल दिया जाता है। IP एड्रेस ठुकराए जाते हैं।
• मेल हेडर (वैकल्पिक) — एक मेल का पूरा हेडर ब्लॉक, सिर्फ़ आपके ब्राउज़र में पढ़ा जाता है। डोमेन फ़ील्ड ख़ाली हो तो From डोमेन जाँचा जाता है।

आउटपुट

• सारांश और इस स्तर की वजह — स्पूफ़िंग जोखिम, SPF का अंत, लागू DMARC नीति, MX होस्ट, और स्तर तय करने वाला हर नियम।
• SPF और DMARC — प्रकाशित रिकॉर्ड, DMARC कहाँ मिला, नीति, सबडोमेन नीति, प्रतिशत, alignment मोड और रिपोर्ट एड्रेस।
• मेल सर्वर (MX) और दूसरी मेल नीतियाँ — प्राथमिकता के क्रम में MX होस्ट, और MTA-STS, TLS-RPT और BIMI प्रकाशित हैं या नहीं।
• रिसीव करने वाले सर्वर ने क्या दर्ज किया (हेडर के साथ) और आगे क्या करें — दर्ज SPF, DKIM और DMARC नतीजे और उनका alignment, और क्रम से ज़रूरी बदलाव।

ईमेल डोमेन स्पूफ़िंग चेकर का उदाहरण

example.com

स्पूफ़िंग जोखिम: Low (सिर्फ़ प्रकाशित नीतियों से) · SPF -all · DMARC नीति reject · MX होस्ट: Null MX
इस स्तर की वजह: Null MX (RFC 7505): डोमेन घोषित करता है कि वह कभी मेल नहीं लेता। · SPF "-all" और 100% पर DMARC p=reject: रिसीव करने वाले नक़ली मेल ठुकराते हैं।
DMARC: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s, _dmarc.example.com पर · Alignment (adkim / aspf) s / s · Aggregate रिपोर्ट (rua) —
MTA-STS: प्रकाशित नहीं · TLS-RPT: प्रकाशित नहीं · BIMI: प्रकाशित नहीं
आगे क्या करें: rua= एड्रेस जोड़ें, ताकि वे aggregate रिपोर्ट मिलें जो बताती हैं कि डोमेन के नाम से कौन मेल भेजता है।

ईमेल डोमेन स्पूफ़िंग चेकर के नतीजे कैसे पढ़ें

High का मतलब है कि जालसाज़ ऐसा मेल भेज सकता है जिसे ज़्यादातर रिसीवर डोमेन का मानकर पहुँचा देंगे: कोई लागू DMARC नीति नहीं, या SPF ग़ायब या सबके लिए खुला। Medium का मतलब है कि नक़ली मेल आम तौर पर फ़िल्टर होता है पर हमेशा ठुकराया नहीं जाता। Low का मतलब है कि DMARC लागू करने वाले रिसीवर alignment में फ़ेल होने वाला मेल ठुकराते हैं।

स्तर डोमेन की नीतियों के बारे में है, किसी मेल के बारे में नहीं। Low जोखिम वाले डोमेन का मेल भी DMARC अनदेखा करने वाले रिसीवर पर नक़ली बनाया जा सकता है, और नक़ली दिखने वाले डोमेन को आपके डोमेन तक किसी पहुँच की ज़रूरत ही नहीं।

p=none निगरानी मोड है: यह रिपोर्ट जुटाता है पर रिसीवर से कुछ करने को नहीं कहता, इसलिए p=none वाला डोमेन High आँका जाता है, चाहे SPF और DKIM बिल्कुल सही हों।

पेस्ट किए हेडर के साथ "DMARC नतीजा (दर्ज): फ़ेल" का मतलब है कि रिसीव करने वाले सर्वर ने मेल को उसके From डोमेन के लिए प्रमाणित नहीं किया — अगर वह डोमेन quarantine या reject प्रकाशित करता है तो यह जालसाज़ी का मज़बूत संकेत है। "none — कोई DMARC नीति प्रकाशित नहीं" का मतलब है कि लागू करने को कोई नीति थी ही नहीं, और "जाँच अधूरी" (temperror या permerror) का मतलब है कि रिसीवर जाँच पूरी नहीं कर पाया; इन दोनों में से कोई भी जालसाज़ी का सबूत नहीं है।

ईमेल डोमेन स्पूफ़िंग चेकर कब इस्तेमाल करें

• जाँचना कि आपके डोमेन से आपके नाम पर फ़िशिंग भेजी जा सकती है या नहीं, और उसे रोकने के लिए क्या प्रकाशित करना है।
• किसी सप्लायर या पार्टनर के डोमेन से बैंक विवरण बदलने वाले ईमेल पर भरोसा करने से पहले उसका डोमेन जाँचना।
• संदिग्ध मेल की जाँच: क्या वह अपने From डोमेन के लिए प्रमाणित हुआ, और क्या वह डोमेन DMARC लागू करता है?
• पार्क किए या बंद किए गए डोमेन को लॉक करना जिनसे कभी मेल नहीं जाना चाहिए।

समस्या निवारण

• "The resolver answered SERVFAIL for …": डोमेन का DNS फ़ेल हो रहा है, अक्सर टूटे DNSSEC की वजह से। पहले उसे ठीक करें — रिसीवर भी नीतियाँ नहीं पढ़ पाते।
• DMARC p=reject होने पर भी स्तर Medium है: SPF ~all या ?all पर ख़त्म होता है, pct 100 से कम है, sp= कमज़ोर है, या SPF redirect= से सौंपा गया है। वजहों की सूची बताती है कि कौन-सा।
• अभी प्रकाशित किया रिकॉर्ड नहीं दिख रहा: रिज़ॉल्वर DNS जवाब रिकॉर्ड के TTL तक रखते हैं। TTL बीतने दें और फिर जाँचें।
• "पेस्ट किए हेडर में कोई From एड्रेस नहीं मिला": From: लाइन समेत पूरा हेडर ब्लॉक पेस्ट करें, या डोमेन ख़ुद लिखें।

ईमेल डोमेन स्पूफ़िंग चेकर के बारे में अक्सर पूछे जाने वाले सवाल

तकनीकी नोट्स

SPF (RFC 7208) बताता है कि लिफ़ाफ़े (MAIL FROM) में डोमेन के नाम से कौन-से सर्वर भेज सकते हैं, DKIM (RFC 6376) DNS में प्रकाशित key से मेल पर हस्ताक्षर करता है, और DMARC (RFC 7489) दोनों को दिखने वाले From डोमेन से जोड़ता है: मेल DMARC तभी पास करता है जब From से aligned डोमेन के लिए SPF या DKIM पास हो, और p= रिसीवर को बाक़ी के साथ क्या करना है बताता है — none (निगरानी), quarantine (स्पैम फ़ोल्डर) या reject।

स्तर तय नियमों से निकलता है: SPF नहीं, "+all", टूटा SPF, DMARC नहीं, अमान्य DMARC या लागू नीति none → High; SPF "-all" के साथ pct=100 पर p=reject और कोई कमज़ोर sp= नहीं → Low; बीच का सब — ~all या ?all, quarantine, 100 से कम pct, कमज़ोर सबडोमेन नीति, redirect= से सौंपा SPF जिसे यह सारांश नहीं पढ़ता → Medium; lookup फ़ेल → अज्ञात।

DMARC की खोज डोमेन के अपने _dmarc नाम (_dmarc.mail.example.com) से organizational डोमेन की ओर ऊपर जाती है (इस जाँच में ज़्यादा से ज़्यादा तीन नाम); नीति किसी पैरेंट से आए तो सबडोमेन पर sp= लागू होता है अगर हो, वरना p=। SPF स्थिर रूप से पढ़ा जाता है: include: और redirect= गिने जाते हैं पर फ़ॉलो नहीं किए जाते, इसलिए किसी include के पीछे छिपा "+all" या lookup सीमा का पार होना सिर्फ़ SPF रिकॉर्ड चेकर में दिखता है।

Mutqan सर्वर हर जाँच में ज़्यादा से ज़्यादा 8 DNS-over-HTTPS क्वेरी भेजता है: MX, डोमेन के TXT रिकॉर्ड, DMARC की खोज, _mta-sts (MTA-STS, RFC 8461), _smtp._tls (TLS-RPT, RFC 8460) और default._bimi। null MX ("0 .", RFC 7505) घोषित करता है कि डोमेन कोई मेल नहीं लेता। पेस्ट किए हेडर ब्राउज़र में पार्स होते हैं, और हर तरीक़े पर फ़ैसला देने वाला सबसे नया Authentication-Results हेडर दर्ज नतीजा तय करता है, जो जैसा है वैसा दिखाया जाता है — pass, fail, softfail, neutral, none, temperror या permerror; जिस हेडर का authserv-id Received हेडर में बताया गया रिसीव करने वाला सर्वर नहीं है, उसे RFC 8601 के मुताबिक़ अलग रख दिया जाता है।

सीमाएँ और कार्यप्रणाली

सिर्फ़ प्रकाशित DNS नीतियाँ जाँची जाती हैं: DKIM keys नहीं (उनके लिए selector चाहिए), SPF के include: और redirect= फ़ॉलो नहीं होते, और कोई मेल न भेजा जाता है न लिया जाता है — स्तर किसी ख़ास रिसीवर के बर्ताव की जाँच नहीं है।

क्वेरी Cloudflare edge से सार्वजनिक DNS-over-HTTPS रिज़ॉल्वर के ज़रिए जाती हैं और दिखाती हैं कि उस समय उन रिज़ॉल्वर के पास क्या था।

आपके अपने मेल सर्वर की एंट्री के नीचे वाले हेडर नक़ली हो सकते हैं। टूल सबसे नए दर्ज नतीजे बताता है और यह साबित नहीं कर सकता कि आपके रिसीवर के नाम वाला हेडर सच में उसी ने लिखा।

सुरक्षा और गोपनीयता

डोमेन Mutqan सर्वर को भेजा जाता है, जो सार्वजनिक DNS रिज़ॉल्वर से उसके मेल रिकॉर्ड पूछता है; कुछ भी सेव नहीं होता। पेस्ट किए हेडर आपके ब्राउज़र में पार्स होते हैं और कभी भेजे नहीं जाते।

संदर्भ

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)IETF · 2015DMARC का पहला प्रकाशित रूप (2015): _dmarc पर रिकॉर्ड, p, sp, pct, adkim, aspf, rua और ruf टैग, SPF और DKIM के साथ identifier alignment, और Public Suffix List से तय organizational डोमेन पर लौटना। मई 2026 में RFC 9989 ने इसकी जगह ली; इसके pct, rf और ri टैग अब भी पब्लिश हुए रिकॉर्ड में मिलते हैं।
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1IETF · 2014SPF का मानक: v=spf1 रिकॉर्ड, उसके mechanism और qualifier, मूल्यांकन का क्रम, और हर जाँच में दस DNS लुकअप व दो void लुकअप की सीमा।
• RFC 6376: DomainKeys Identified Mail (DKIM) SignaturesIETF · 2011DKIM सिग्नेचर और selector._domainkey पर पब्लिक-कुंजी रिकॉर्ड: उसके टैग (v, k, p, t, s, h, n) और verifier कुंजी को कैसे ढूँढकर इस्तेमाल करता है।