सेंडिंग डोमेन को ऑथेंटिकेट कैसे करें: SPF, DKIM और DMARC सेटअप गाइड

सेंडिंग डोमेन को ऑथेंटिकेट करने के लिए आप तीन DNS रिकॉर्ड पब्लिश करते हैं, जो Gmail, Yahoo, Outlook और हर अन्य रिसीविंग सर्वर को साबित करते हैं कि आपके संदेश वास्तव में आपके ही हैं: SPF उन सर्वरों की सूची देता है जिन्हें आपकी ओर से भेजने की अनुमति है, DKIM हर संदेश में क्रिप्टोग्राफ़िक सिग्नेचर जोड़ता है, और DMARC रिसीवर को बताता है कि ये जांचें विफल होने पर क्या करना है। एक ही बैठक में पूरा करने पर आमतौर पर लगभग 30 मिनट लगते हैं, और इनबॉक्स प्लेसमेंट के लिए यह सबसे बड़ा कदम है।

संक्षेप में

1. जांचें कि क्या पहले से मौजूद है। अपने मौजूदा SPF, DKIM और DMARC रिकॉर्ड देखें ताकि आप डुप्लिकेट बनाने के बजाय उन्हें संपादित करें।
2. एक SPF रिकॉर्ड पब्लिश करें। आपके डोमेन रूट पर एक अकेला TXT रिकॉर्ड, जिसमें आपकी ओर से भेजने वाली हर सेवा शामिल हो।
3. DKIM पब्लिश करें। डैशबोर्ड से मिला सेलेक्टर रिकॉर्ड, ताकि हर संदेश साइन हो।
4. DMARC को p=none पर पब्लिश करें। रिपोर्टिंग पते के साथ मॉनिटरिंग मोड में शुरू करें।
5. सत्यापित करें। dig चलाएँ, फिर टेस्ट संदेश भेजकर हेडर पढ़ें।
6. लागू करें। रिपोर्ट की समीक्षा करें, फिर p=quarantine और p=reject पर जाएँ।

सेंडिंग डोमेन को ऑथेंटिकेट करने का क्या अर्थ है?

ईमेल को इस तरह डिज़ाइन किया गया था कि संदेश भेजने वाले की पुष्टि का कोई तरीका नहीं था। कोई भी आपका पता From फ़ील्ड में लिख सकता है, इसीलिए फ़िशिंग और स्पूफ़िंग इतनी आम हैं। ऑथेंटिकेशन तीन पूरक जांचों से इस कमी को भरता है, जिनमें से हर एक रिसीविंग सर्वर के एक अलग सवाल का जवाब देती है:

• क्या इस सर्वर को इस डोमेन की ओर से भेजने की अनुमति है? यह SPF है (Sender Policy Framework, RFC 7208 में परिभाषित)।
• क्या संदेश वास्तव में इसी डोमेन से आया है और बदला नहीं गया? यह DKIM है (DomainKeys Identified Mail, RFC 6376)।
• यदि कोई जांच विफल हो तो क्या होना चाहिए, और रिपोर्ट किसे मिले? यह DMARC है (RFC 7489)।

रिसीवर इन तीनों को मिलाकर एक भरोसे का संकेत बनाते हैं। जो संदेश ऑथेंटिकेट होते हैं और आपके From डोमेन से अलाइन होते हैं, वे समय के साथ स्थिर डोमेन रेप्युटेशन बनाते हैं। जो नहीं होते, उन्हें फ़िल्टर किया जाता है, देरी से पहुँचाया जाता है या अस्वीकार कर दिया जाता है, और अधिक वॉल्यूम पर अब प्रमुख मेलबॉक्स प्रदाता उन्हें सीधे ठुकरा देते हैं।

एक नज़र में SPF, DKIM और DMARC

	SPF	DKIM	DMARC
यह क्या साबित करता है	भेजने वाला सर्वर इस डोमेन के लिए अधिकृत है	संदेश पर डोमेन ने साइन किया है और रास्ते में उसमें बदलाव नहीं हुआ	जांचें दिखाई देने वाले From डोमेन से अलाइन हैं, और यह पॉलिसी तय करता है
DNS में यह कहाँ रहता है	डोमेन रूट पर TXT रिकॉर्ड	selector._domainkey पर TXT या CNAME	_dmarc पर TXT रिकॉर्ड
क्या जांचा जाता है	Return-Path (एनवेलप सेंडर) डोमेन और भेजने वाला IP	DKIM-Signature हेडर में सिग्नेचर	SPF और DKIM परिणामों के विरुद्ध From हेडर डोमेन
क्या फ़ॉरवर्डिंग में टिकता है?	आमतौर पर नहीं	हाँ, यदि सामग्री में बदलाव न हो	DKIM पास और अलाइन होने पर पास होता है
मुख्य विफलता का कारण	कोई सेंडर छूटना या 10 से अधिक लुकअप	गलत सेलेक्टर या कुंजी गलत कॉपी होना	अलाइनमेंट का मेल न खाना

शुरू करने से पहले: आपको क्या चाहिए

• डोमेन का DNS संपादित करने का एक्सेस (रजिस्ट्रार, Cloudflare, cPanel या आपका DNS होस्ट)।
• आपके डोमेन के नाम से ईमेल भेजने वाली हर सेवा की सूची: आपका MigoSMTP खाता, आपका ऑफ़िस मेल (Google Workspace या Microsoft 365), आपका CRM, बिलिंग और सपोर्ट टूल।
• DMARC रिपोर्ट पाने के लिए एक मेलबॉक्स, बेहतर होगा कि आपके डोमेन पर dmarc-reports जैसा समर्पित पता हो।
• आपके MigoSMTP डैशबोर्ड के Domains पेज से SPF include और DKIM रिकॉर्ड के मान।

चरण 1: अपने मौजूदा रिकॉर्ड जांचें

डुप्लिकेट रिकॉर्ड ऑथेंटिकेशन विफल होने का सबसे आम कारण हैं। कुछ भी जोड़ने से पहले देखें कि पहले से क्या पब्लिश है। macOS या Linux पर dig उपयोग करें; Windows पर nslookup।

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

ऐसे किसी भी TXT रिकॉर्ड को देखें जो v=spf1 (SPF) से शुरू होता है और _dmarc पर ऐसे किसी रिकॉर्ड को जो v=DMARC1 से शुरू होता है। यदि इनमें से कोई मौजूद है, तो दूसरा जोड़ने के बजाय उसी को संपादित करें।

चरण 2: अपना SPF रिकॉर्ड जोड़ें

SPF आपके डोमेन के रूट पर एक अकेला TXT रिकॉर्ड है। यह उन सेवाओं की सूची देता है जिन्हें एनवेलप सेंडर (Return-Path) में आपके डोमेन का उपयोग करके मेल भेजने की अनुमति है।

SPF रिकॉर्ड सिंटैक्स

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

भाग	अर्थ
v=spf1	अनिवार्य। रिकॉर्ड को SPF संस्करण 1 के रूप में चिह्नित करता है।
include:domain	उस डोमेन के अपने SPF रिकॉर्ड द्वारा अधिकृत हर चीज़ को अधिकृत करता है। अपने MigoSMTP डैशबोर्ड का मान उपयोग करें।
ip4:203.0.113.10	किसी विशिष्ट IPv4 पते या रेंज को अधिकृत करता है। IPv6 के लिए ip6: उपयोग होता है।
a, mx	आपके डोमेन के A या MX रिकॉर्ड के IP को अधिकृत करता है।
~all	सॉफ़्ट फ़ेल: सूची में न होने वाली हर चीज़ संदिग्ध है, पर सीधे अस्वीकार नहीं की जाती। सेंडर जोड़ते समय आम तौर पर यही उपयोग होता है।
-all	हार्ड फ़ेल: सूची में न होने वाली हर चीज़ अधिकृत नहीं है। तभी उपयोग करें जब आप निश्चित हों कि हर सेंडर सूची में है।

10-लुकअप की सीमा

SPF मूल्यांकन में अधिकतम 10 DNS लुकअप हो सकते हैं। हर include, a, mx, exists और redirect गिना जाता है, इनक्लूड किए गए रिकॉर्ड के अंदर किए गए लुकअप भी। सीमा पार होने पर रिसीवर स्थायी त्रुटि लौटाते हैं, जिससे हर संदेश के लिए SPF विफल हो जाता है। गिनती कम रखने के लिए उन सेवाओं को हटाएँ जिनका आप अब उपयोग नहीं करते, जहाँ रेंज स्थिर हों वहाँ a और mx की जगह स्पष्ट ip4 रेंज रखें, और कम उपयोग होने वाले टूल को उनके अपने सबडोमेन पर ले जाएँ।

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

• एक ही नाम पर दो SPF रिकॉर्ड (उन्हें एक में मर्ज करें)।
• +all का उपयोग, जो पूरे इंटरनेट को अधिकृत कर देता है।
• include मान में अतिरिक्त स्पेस या कोलन का छूट जाना।
• बिलिंग सिस्टम या हेल्प डेस्क जैसे किसी सेंडर को जोड़ना भूल जाना, जिससे उसका मेल SPF में विफल हो जाता है।
• SPF को गलत नाम पर पब्लिश करना, जैसे डोमेन रूट की जगह www होस्ट पर।

चरण 3: अपना DKIM रिकॉर्ड पब्लिश करें

DKIM हर संदेश में डिजिटल सिग्नेचर जोड़ता है। आपका सेंडिंग प्लेटफ़ॉर्म आउटगोइंग मेल पर उस निजी कुंजी से साइन करता है जिसे वह गोपनीय रखता है, और आप मेल खाती पब्लिक कुंजी को DNS में पब्लिश करते हैं ताकि रिसीवर सिग्नेचर सत्यापित कर सकें।

सेलेक्टर और रिकॉर्ड कहाँ जाता है

हर कुंजी सेलेक्टर नामक नाम के अंतर्गत रहती है, जिसका रूप selector._domainkey.yourdomain.com होता है। सेलेक्टर आपको एक साथ कई कुंजियाँ पब्लिश करने और बिना डाउनटाइम के उन्हें रोटेट करने देता है। आपका MigoSMTP डैशबोर्ड आपके डोमेन के लिए सटीक नाम और मान दिखाता है।

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT या CNAME?

कुछ प्लेटफ़ॉर्म पब्लिक कुंजी को सीधे TXT रिकॉर्ड के रूप में पब्लिश करने को कहते हैं। अन्य आपको एक CNAME देते हैं जो उनके होस्ट किए रिकॉर्ड की ओर इशारा करता है, जिससे वे आपके लिए कुंजियाँ रोटेट कर सकते हैं। ठीक वही प्रकार पब्लिश करें जो आपका डैशबोर्ड दिखाता है। एक को दूसरे में न बदलें।

कुंजी की लंबाई और फ़ॉर्मेटिंग

• उपलब्ध होने पर 2048-बिट RSA कुंजियाँ उपयोग करें। 1024-बिट कुंजियाँ अब भी कई रिसीवर स्वीकार करते हैं, पर उन्हें कमज़ोर माना जाता है।
• 2048-बिट कुंजी 255 अक्षरों से लंबी होती है, और एक DNS स्ट्रिंग 255 अक्षरों से अधिक नहीं हो सकती। आपके DNS होस्ट को मान को एक TXT रिकॉर्ड के अंदर कई कोटेड स्ट्रिंग में बाँटना होगा। ज़्यादातर डैशबोर्ड यह अपने आप करते हैं; यदि आपका नहीं करता, तो इसे हाथ से बाँटें।
• मान को अतिरिक्त लाइन ब्रेक या स्मार्ट कोट्स के बिना कॉपी करें, और जब तक आपके DNS होस्ट को ज़रूरत न हो, उसे अतिरिक्त उद्धरण चिह्नों में न लपेटें।

रोटेशन

DKIM कुंजियाँ हर छह से बारह महीने में रोटेट करें, या निजी कुंजी के उजागर होने की आशंका हो तो तुरंत। पहले नया सेलेक्टर पब्लिश करें, साइनिंग को उस पर स्विच करें, और पुराना सेलेक्टर तभी हटाएँ जब उससे साइन किया गया मेल पहुँचना पूरा कर चुका हो।

चरण 4: अपना DMARC रिकॉर्ड पब्लिश करें

DMARC, SPF और DKIM को उस डोमेन से जोड़ता है जो आपके प्राप्तकर्ताओं को From लाइन में वास्तव में दिखता है, और रिसीवर को बताता है कि विफल होने वाले मेल के साथ क्या करना है। यह _dmarc.yourdomain.com पर एक TXT रिकॉर्ड है। मॉनिटरिंग मोड में शुरू करें ताकि कुछ भी लागू करने से पहले आप देख सकें कि आपके नाम से कौन भेज रहा है।

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

टैग	यह क्या करता है	सामान्य मान
v	संस्करण। सबसे पहले होना चाहिए।	DMARC1
p	विफल मेल के लिए पॉलिसी: none (मॉनिटर), quarantine (स्पैम फ़ोल्डर) या reject (अस्वीकार)।	शुरुआत में none
rua	जहाँ दैनिक एग्रीगेट रिपोर्ट भेजी जाती हैं।	mailto:dmarc-reports@example.com
ruf	जहाँ विफलता के नमूने भेजे जाते हैं। बहुत कम रिसीवर इन्हें भेजते हैं।	वैकल्पिक
pct	विफल मेल का वह प्रतिशत जिस पर पॉलिसी लागू होती है, क्रमिक रोलआउट के दौरान उपयोग होता है।	25, 50, 100
sp	सबडोमेन के लिए पॉलिसी, यदि पैरेंट से अलग हो।	ज़रूरत न हो तो p के समान
adkim, aspf	अलाइनमेंट मोड: r (रिलैक्स्ड) या s (स्ट्रिक्ट)।	r (रिलैक्स्ड) डिफ़ॉल्ट है
fo	विफलता रिपोर्ट कब बनानी हैं।	1

"अलाइनमेंट" का वास्तविक अर्थ क्या है

DMARC तब पास होता है जब SPF या DKIM पास हो और पास होने वाला डोमेन From डोमेन से अलाइन हो। रिलैक्स्ड अलाइनमेंट में From डोमेन का सबडोमेन भी अलाइन माना जाता है, इसलिए bounce.example.com का Return-Path, news@example.com के From से अलाइन होता है। स्ट्रिक्ट अलाइनमेंट में डोमेन बिल्कुल मेल खाने चाहिए। "SPF पास होता है पर DMARC फ़ेल" का सबसे आम कारण ऐसा Return-Path या DKIM डोमेन है जो आपका नहीं बल्कि आपके सेंडिंग प्लेटफ़ॉर्म का है। इसे ठीक करने के लिए कस्टम Return-Path और अपना DKIM साइनिंग डोमेन सक्षम करें।

चरण 5: सत्यापित करें कि सब कुछ काम करता है

DNS में रिकॉर्ड जांचें

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

हर कमांड को वही रिकॉर्ड लौटाना चाहिए जो आपने पब्लिश किया है। यदि कुछ नहीं आता, तो रिकॉर्ड गलत नाम पर है या अभी प्रोपेगेट नहीं हुआ। TTL एक्सपायर होने तक प्रतीक्षा करें और फिर दोबारा जांचें।

टेस्ट संदेश भेजें और हेडर पढ़ें

1. अपने ऑथेंटिकेटेड डोमेन से अपने नियंत्रण वाले किसी Gmail पते पर संदेश भेजें।
2. संदेश खोलें, तीन-बिंदु मेनू चुनें और Show original चुनें।
3. ऊपर आपको SPF, DKIM और DMARC में से हर एक के लिए PASS या FAIL दिखेगा।
4. जाँचें कि हर PASS के आगे दिखाया गया डोमेन आपके From डोमेन से मेल खाता है।

DMARC को सुरक्षित रूप से लागू करें: p=none से p=reject तक

लक्ष्य p=reject है, क्योंकि यही एकमात्र पॉलिसी है जो दूसरों को आपके डोमेन की स्पूफ़िंग करने से रोकती है। लेकिन आँख मूँदकर सीधे वहाँ पहुँचने से उन टूल का वैध मेल रुक सकता है जिन्हें आप भूल गए थे। चरणबद्ध तरीके से आगे बढ़ें और रिपोर्ट को मार्गदर्शन करने दें।

चरण	पॉलिसी	अवधि	क्या करें
1. मॉनिटर	p=none	2 से 4 सप्ताह	एग्रीगेट रिपोर्ट पढ़ें। आपके डोमेन के नाम से भेजने वाले हर स्रोत की सूची बनाएँ और हर वैध स्रोत को ठीक या अधिकृत करें।
2. आंशिक quarantine	p=quarantine; pct=25	1 से 2 सप्ताह	25 प्रतिशत ट्रैफ़िक का विफल मेल स्पैम में जाता है। मेल न मिलने की शिकायतों पर नज़र रखें।
3. पूर्ण quarantine	p=quarantine	2 सप्ताह	जब रिपोर्ट में केवल अनधिकृत स्रोत विफल दिखें, तब pct को 100 करें।
4. Reject	p=reject	निरंतर	reject पर जाएँ, चाहें तो pct को चरणों में बढ़ाएँ। हर महीने रिपोर्ट पढ़ते रहें।

DMARC एग्रीगेट रिपोर्ट संपीड़ित XML फ़ाइलों के रूप में आती हैं और हाथ से पढ़ने के लिए नहीं बनी हैं। उन्हें भेजने वाले स्रोतों, वॉल्यूम और पास या फ़ेल परिणामों की तालिका में बदलने के लिए किसी निःशुल्क या सशुल्क DMARC रिपोर्ट एनालाइज़र का उपयोग करें।

बल्क सेंडर के लिए Gmail, Yahoo और Microsoft की आवश्यकताएँ

फ़रवरी 2024 से Gmail और Yahoo ने अधिक मात्रा में ईमेल भेजने वाले सभी के लिए ऑथेंटिकेशन और अनसब्सक्राइब नियम लागू करना शुरू किया, और Microsoft ने मई 2025 से Outlook.com कंज़्यूमर मेलबॉक्स पर तुलनीय आवश्यकताएँ लागू करनी शुरू कीं। संक्षेप में:

आवश्यकता	सभी भेजने वाले	बल्क सेंडर (प्रदाता को प्रतिदिन लगभग 5,000+ संदेश)
SPF या DKIM	अनिवार्य	दोनों अनिवार्य
DMARC रिकॉर्ड	अनुशंसित	अनिवार्य, कम से कम p=none, From के साथ अलाइन
वन-क्लिक अनसब्सक्राइब	ट्रांज़ैक्शनल मेल के लिए आवश्यक नहीं	मार्केटिंग और सब्सक्राइब किए गए मेल के लिए अनिवार्य (RFC 8058 हेडर); अनुरोधों का पालन दो दिनों के भीतर करें
स्पैम शिकायत दर	कम रखें	0.10 प्रतिशत से नीचे रखें और कभी 0.30 प्रतिशत तक न पहुँचें (Google Postmaster Tools)
वैध फ़ॉरवर्ड और रिवर्स DNS, TLS	अनिवार्य	अनिवार्य

प्रदाता सीमाएँ बदल सकते हैं, इसलिए उनके वर्तमान सेंडर दिशानिर्देश देखें। लिंक इस गाइड के अंत की संदर्भ सूची में हैं।

सबडोमेन से मार्केटिंग और ट्रांज़ैक्शनल मेल को अलग करें

रेप्युटेशन हर सेंडिंग डोमेन और IP के हिसाब से ट्रैक होती है। यदि कोई प्रचार कैंपेन शिकायतें पैदा करता है, तो आप नहीं चाहेंगे कि पासवर्ड-रीसेट ईमेल स्पैम में चले जाएँ। आम तरीका हर स्ट्रीम के लिए एक सबडोमेन रखना है:

स्ट्रीम	उदाहरण From पता	अलग क्यों रखें
ट्रांज़ैक्शनल	noreply@mail.example.com	हमेशा तेज़ी से पहुँचना चाहिए। कम वॉल्यूम और उच्च एंगेजमेंट रेप्युटेशन को ऊँचा रखते हैं।
मार्केटिंग	hello@news.example.com	अधिक वॉल्यूम और अधिक शिकायतें। समस्याएँ वहीं तक सीमित रहती हैं।
कॉर्पोरेट मेल	name@example.com	आपके कर्मचारियों के मेलबॉक्स बल्क सेंडिंग के जोखिम से दूर रहते हैं।

हर सबडोमेन को अपने SPF और DKIM रिकॉर्ड चाहिए। पैरेंट डोमेन पर DMARC रिकॉर्ड डिफ़ॉल्ट रूप से सबडोमेन की रक्षा करता है; यदि आपको अलग पॉलिसी चाहिए, तो sp= टैग जोड़ें या सबडोमेन पर अलग रिकॉर्ड रखें।

आम ऑथेंटिकेशन त्रुटियाँ और उनके समाधान

लक्षण	संभावित कारण	समाधान
SPF permerror या "too many DNS lookups"	10 से अधिक लुकअप, या सिंटैक्स त्रुटि	अनुपयोगी include हटाएँ, स्थिर रेंज को ip4 में बदलें, कम उपयोग वाले सेंडर को सबडोमेन पर ले जाएँ।
Multiple SPF records found	दो TXT रिकॉर्ड v=spf1 से शुरू होते हैं	उन्हें एक रिकॉर्ड में मर्ज करें।
DKIM: no key for signature	सेलेक्टर का नाम गलत है या रिकॉर्ड पब्लिश नहीं हुआ	DKIM-Signature हेडर में सेलेक्टर देखें और उसे अपने DNS नाम से मिलाएँ।
DKIM: body hash did not verify	साइन करने के बाद संदेश बदला गया (फ़ुटर, किसी अन्य सिस्टम द्वारा लिंक रीराइटिंग)	बदलाव करने वाला चरण बंद करें या उसे साइनिंग से पहले ले जाएँ।
SPF पास के साथ DMARC फ़ेल	Return-Path डोमेन From से अलाइन नहीं है	अपने डोमेन पर कस्टम Return-Path उपयोग करें।
DKIM पास के साथ DMARC फ़ेल	DKIM d= डोमेन From से अलाइन नहीं है	प्लेटफ़ॉर्म के डिफ़ॉल्ट की जगह अपने डोमेन से साइन करें।
Record not found	गलत होस्ट नाम, अंत में डॉट, या आपके DNS पैनल द्वारा डोमेन का दो बार जुड़ जाना	कई पैनल डोमेन अपने आप जोड़ देते हैं। केवल उससे पहले वाला भाग लिखें, उदाहरण के लिए selector1._domainkey।
रिकॉर्ड अपडेट नहीं हो रहे	पुराना रिकॉर्ड कैश में है	TTL एक्सपायर होने तक प्रतीक्षा करें। नियोजित बदलावों से पहले TTL घटा दें।

ऑथेंटिकेशन चेकलिस्ट

• डोमेन रूट पर एक SPF रिकॉर्ड, 10 लुकअप से कम, जो ~all या -all पर समाप्त हो।
• DKIM सेलेक्टर रिकॉर्ड पब्लिश हो, और यदि आपका DNS होस्ट अनुमति दे तो 2048-बिट।
• _dmarc पर p=none और काम करने वाले rua पते के साथ DMARC रिकॉर्ड।
• कस्टम Return-Path और DKIM डोमेन, ताकि दोनों आपके From डोमेन से अलाइन हों।
• टेस्ट संदेश में SPF, DKIM और DMARC तीनों PASS दिखें।
• रोलआउट के दौरान DMARC रिपोर्ट की साप्ताहिक समीक्षा।
• मार्केटिंग और ट्रांज़ैक्शनल मेल सबडोमेन से अलग किए गए हों।
• DKIM कुंजियाँ रोटेट करने के लिए कैलेंडर रिमाइंडर।

आगे पढ़ें और स्रोत

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Yahoo: Sender best practices
• संबंधित गाइड: ईमेल वॉर्म-अप गाइड और SMTP बाउंस कोड की व्याख्या।