New Domain पर Email Set Up: 20-Minute SPF, DKIM और DMARC Checklist (2026)

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

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

नए domain को अपना पहला email भेजने से पहले चार चीजें चाहिए: baseline scan, आपका real provider name करने वाला एक SPF record, custom-domain DKIM signing, और day one से reporting के साथ DMARC record। अधिकांश domains वहां कभी नहीं पहुंचते — Defaults.Exposed जनगणना (2026-06-29 तक) के अनुसार 46.4% (121,145,609 of 261,086,232 ग्रेडेड domains) में बिल्कुल कोई SPF नहीं है।

सब कुछ publish करने में लगभग 20 मिनट लगते हैं: baseline के लिए scan करें, एक SPF record add करें, अपने provider का custom-domain DKIM चालू करें, reporting address के साथ DMARC p=none publish करें, optionally MTA-STS add करें, फिर re-scan करें और report रखें। जो longer time लेता है वह है जो कोई checklist जल्दी नहीं कर सकती — DNS propagation और sending reputation — और यह guide दोनों के बारे में honest है।

क्या 20 मिनट वाकई काफी हैं?

Records publish करने के लिए, हां — नीचे हर step आपके provider के admin console में एक DNS entry plus कुछ clicks है। दो चीजें longer लेती हैं, और otherwise pretending करना नए domains के spam में end up होने का तरीका है:

Propagation। नए records usually मिनटों में resolve होते हैं, लेकिन resolvers TTL के अनुसार cache करते हैं और freshly delegated domain consistently answer करने में घंटे ले सकता है। dig से verify करें; caches catch up होते समय panic-edit न करें।
Warm-up। नए domain की zero sending reputation है, और authentication reputation की precondition है, substitute नहीं। Low, human-scale volume से शुरू करें और weeks में gradually ramp करें।

Honest claim: 20 मिनट correctly published authentication खरीदते हैं। Sensible sending के अगले कुछ weeks deliverability खरीदते हैं।

20-minute checklist

पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। DNS छूने से पहले new domain scan करें। Graded “nothing configured” baseline seconds में capture होती है और after-report meaningful बनाती है — आप before-and-after pair (step 6) चाहेंगे।
अपने actual provider के लिए एक SPF record publish करें। Exactly एक TXT record जो v=spf1 से शुरू हो, जिसमें आपके provider का include हो — उदाहरण के लिए v=spf1 include:_spf.google.com ~all Google Workspace के लिए, या include:spf.protection.outlook.com Microsoft 365 के लिए; यदि आपका DNS registrar panel पर है, GoDaddy walkthrough UI quirks cover करता है। केवल एक record: दो v=spf1 records permanent error हैं जो SPF entirely void करती है — वह state 1,013,416 domains stuck हैं, SPF attempt करने वाले domains में से roughly one in 138 (census 2026-06-29 तक), usually migration leftover। “Just in case” includes add न करें: SPF DNS lookups को 10 पर cap करती है, और कम से कम 797,263 domains ने वह cap blow करके अपना record void कर दिया। और जानें SPF actually क्या check करती है: receivers इसे Return-Path (RFC5321.MailFrom) domain के विरुद्ध evaluate करते हैं — bounce address — न कि From header जो आपके recipients देखते हैं।
Custom-domain DKIM signing चालू करें। आपका provider किसी भी तरह mail sign करता है; सवाल यह है कि signature कौन सा domain name करती है। जब तक आप यह step complete नहीं करते, Google Workspace अपने gappssmtp.com default से sign करता है और Microsoft 365 onmicrosoft.com से — signatures जो DKIM pass करती हैं लेकिन आपके domain के साथ align नहीं करतीं, इसलिए DMARC अभी भी fail। Admin console में key generate करें और provider जो देता है publish करें: Google के लिए 2048-bit TXT record, Microsoft 365 के लिए दो CNAMEs (selector1/selector2)। यदि record आपके DNS panel में fit नहीं होता, DKIM fix करें देखें — UIs द्वारा mangled long keys classic हैं।
Day one से DMARC publish करें — reporting address के साथ p=none। _dmarc.yourdomain.com पर एक TXT record: v=DMARC1; p=none; rua=mailto:[email protected]। इस बारे में clear रहें कि यह क्या करता है: p=none अभी कुछ protect नहीं करता — यह monitoring mode है। लेकिन इसकी कोई cost नहीं, और aggregate reports तब से आपके domain के sending history को cover करती हैं पहले message से। Established domains रिपोर्टिंग के weeks सिर्फ उन senders discover करने में spend करते हैं जो भूल गए थे; आप वह visibility free में buy कर रहे हैं, day zero से। Record anatomy के लिए DMARC fix करें देखें।
Optional लेकिन new domain पर cheap: MTA-STS और TLS-RPT। MTA-STS sending servers को बताता है कि आपका domain inbound mail के लिए TLS require करता है (एक DNS record plus एक small hosted policy file); TLS-RPT delivery-encryption failures report करता है। Established domain पर इन्हें care चाहिए; one mail provider के साथ new domain पर तोड़ने को कुछ नहीं है, और mode: testing essentially risk-free है। अभी set up करें या skip करें — लेकिन decide करें, drift न करें।
Re-scan करें और report रखें। Scan फिर से चलाएं — SPF, DKIM और DMARC सभी green दिखने चाहिए। Graded report save करें: launch पर domain की state का dated evidence, और exactly वह जो insurer या client questionnaire ask करेगा।

कितने domains actually यह checklist complete करते हैं?

बहुत कम — और अधिकांश पहली hurdle पर fall करते हैं। Defaults.Exposed जनगणना में graded 261,086,232 domains में से (2026-06-29 तक):

Checklist milestone	Census reality (261,086,232 ग्रेडेड domains में से, 2026-06-29 तक)
Step 2 — कोई भी SPF record publish करें	46.4% कभी नहीं करते: 121,145,609 domains में बिल्कुल कोई SPF नहीं
Step 4+ — enforcing policy पर DMARC	10.59% (27,640,987 domains); 89.41% में कोई enforced policy नहीं
Full triad — SPF + DKIM + enforced DMARC	3.87% (10,092,481 domains)

यह page जो 20 मिनट describe करती है वह brand-new domain को full triad पर internet के roughly 96% से आगे रखती है। SPF adoption maturity model उस ladder के हर rung को breakdown करता है।

New domain कितनी जल्दी p=reject तक पहुंच सकता है?

Weeks, months नहीं — fresh शुरू करने का genuine advantage। Established domains पर DMARC enforcement को slow बनाता है legacy: forgotten CRM connector, invoicing tool जो किसी ने 2019 में wire up किया, newsletter platform जिसे किसी ने document नहीं किया। Policy tighten होने से पहले हर एक को reports में खोजना और fix करना होता है — इसलिए standard months-long rollout।

New domain में कोई legacy senders नहीं: आपने हर sending source इस week खुद configure किया, और step 4 की reports confirm करेंगी। दो से चार weeks के real sending के लिए p=none run करें, check करें कि reports सब कुछ cover करती हैं जो आप actually use करते हैं (mailboxes, invoices, receipts, website का contact form), फिर p=quarantine पर जाएं और p=reject पर एक बार जब वे clean run हो जाएं। Staged mechanics — pct ramps, subdomain policy, क्या देखना है — p=none से p=reject में हैं; new domain पर आप उनसे speed पर move करेंगे, उस place पर जहां केवल 10.59% ग्रेडेड domains पहुंचे हैं।

उस old domain के बारे में क्या जिसे आप replace कर रहे हैं?

यदि यह new domain rebrand का हिस्सा है, वह domain जिसे आप पीछे छोड़ रहे हैं अब आपका biggest email risk है: अभी भी आपका, counterparties द्वारा अभी भी trusted, अब watched नहीं। इसे abandon न करें — explicitly lock down करें। यह अपना short job है: आपके rebrand का वह old domain एक door है जो आपने खुली छोड़ी।

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

क्या मैं mail provider चुनने से पहले ये records publish कर सकता हूं? DMARC, हां — rua के साथ p=none provider-independent है, इसलिए register करने के day publish करें। SPF को आपके provider का include चाहिए; जब तक आपने एक नहीं चुना, v=spf1 -all publish करें (कुछ भी send करने के लिए authorized नहीं है) और इसे step 2 में replace करें। यह strictly better है no-record state से जिसमें 121,145,609 domains बैठे हैं (46.4% of 261,086,232 graded, 2026-06-29 तक)।

क्या मुझे DKIM चाहिए यदि SPF already pass करती है? हां। SPF design से forwarding के तहत टूट जाती है, और यह Return-Path domain validate करती है, जो कई tools के लिए आपका नहीं — aligned DKIM वह leg है जो दोनों से बचती है। केवल 3.87% ग्रेडेड domains full SPF+DKIM+enforced-DMARC triad complete करते हैं (census 2026-06-29 तक); DKIM वह step है जो अधिकांश quitters skip करते हैं। यदि scan इसे flag करे तो DKIM fix करें से शुरू करें।

क्या new domain को ~all या -all use करना चाहिए? Established domain पर, ~all cautious choice है जबकि आप forgotten senders खोजते हैं। New domain में खोजने के लिए कोई नहीं: एक बार आपके provider का include in और DKIM signing हो, -all जल्द ही safe है। Belt and braces चाहते हैं? पहले DMARC reports के दो clean weeks के साथ confirm करें।

तीनों records pass करते हैं — मेरी mail अभी भी spam में क्यों जा रही है? क्योंकि authentication और reputation अलग-अलग चीजें हैं: passing records का मतलब है receivers verify कर सकते हैं कि mail आपकी है, यह नहीं कि वे अभी आप पर trust करते हैं। New domains consistent, wanted, low-volume mail भेजकर और gradually ramp करके trust earn करते हैं। यदि mail केवल spam में landing के बजाय checks fail कर रही है, SPF fix करें से शुरू करें और scan results के नीचे काम करें।

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

यदि आप किसी client के लिए यह domain set up कर रहे हैं, job को evidence के साथ close करें। Step 6 के बाद मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: SPF, DKIM और DMARC passing, plain language में, launch पर dated। यह वह artifact है जो उन्हें cyber-insurance renewal और अगली supplier security questionnaire के लिए चाहिए — और यह prove करता है कि domain उस तरह से life शुरू हुआ जो internet का 96% कभी manage नहीं करता।

अपना डोमेन जांचें → · Legitimate email खोए बिना p=none से p=reject → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।