पोस्टमार्क के माध्यम से भेजे गए ईमेल को प्रमाणित करें: कॉन्फ़िगरेशन और सत्यापन

Postmark मार्ग और पहचान चुनें

यह मार्गदर्शिका वास्तव में Postmark पर सबमिट किए गए आउटबाउंड संदेशों को कवर करती है, न कि केवल इनबाउंड प्रोसेसिंग के लिए Postmark का उपयोग करने वाली वेबसाइट को। एप्लिकेशन, Postmark सर्वर और संदेश स्ट्रीम, इच्छित फ़्रॉम डोमेन और DNS व्यवस्थापक को रिकॉर्ड करें। किसी भिन्न एप्लिकेशन द्वारा भेजी गई रसीद का परीक्षण अलग से किया जाना चाहिए, भले ही उसकी ब्रांडिंग समान दिखे। DNS बदलने से पहले, मौजूदा रिकॉर्ड और एक बेसलाइन संदेश को सटीक वर्कफ़्लो से सहेजें।

Postmark का डोमेन-सत्यापन वर्कफ़्लो एक आपूर्ति करता है DKIM TXT रिकॉर्ड और कस्टम Return-Path CNAME. एक सत्यापित डोमेन उस डोमेन के सभी पतों से भेजने की अनुमति देता है, इसलिए डोमेन सत्यापन का स्वामित्व उसका प्रतिनिधित्व करने के लिए अधिकृत टीम के पास होना चाहिए। अपने डोमेन के लिए दिखाए गए मानों का उपयोग करें, किसी भिन्न टैनेंट के मानों का नहीं। Postmark डोमेन सत्यापन.

नीति बदलने से पहले हस्ताक्षर सक्षम करें

प्रेषक हस्ताक्षर खोलें, डोमेन चुनें और DNS सेटिंग्स दर्ज करें। DKIM होस्टनाम और मान को आधिकारिक DNS प्रदाता के TXT रिकॉर्ड में कॉपी करें। जांचें कि क्या DNS संपादक ज़ोन का नाम जोड़ता है; डुप्लिकेट प्रत्यय कुंजी को गलत स्थान पर रख देगा। Postmark पर लौटें और रिकॉर्ड सत्यापित करें। Postmark दस्तावेजों में 48 घंटों के भीतर स्वचालित जांच और एक मैनुअल सत्यापन नियंत्रण होता है। सत्यापन के बाद हस्ताक्षर करना शुरू होता है। DKIM सेटअप.

हरित स्थिति को अंतिम स्वीकृति परीक्षण न मानें। यह स्थापित करता है कि प्रदाता ने पाया एक अभिलिखित, ऐसा नहीं है कि आपके उत्पादन एप्लिकेशन ने इच्छित प्रेषक पते का उपयोग किया है या बाद के गेटवे ने हस्ताक्षर को संरक्षित किया है। सत्यापन के बाद नियंत्रित प्रेषण शेड्यूल करें और सभी DKIM हस्ताक्षरों सहित प्राप्तकर्ता के मूल संदेश को सुरक्षित रखें।

समर्थित Return-Path अलग से जोड़ें

समान डोमेन सेटिंग्स में प्रदर्शित Return-Path होस्टनाम और उसके CNAME लक्ष्य का उपयोग करें, जिसे pm.mtasv.net के रूप में प्रलेखित किया गया है। इस उद्देश्य के लिए एक अप्रयुक्त होस्टनाम आरक्षित करें। एक न रखें SPF उसी मालिक के नाम पर CNAME के ​​साथ TXT रिकॉर्ड करें, और अपने शीर्ष रिकॉर्ड को बाउंस CNAME से न बदलें। Postmark दस्तावेज़ अलग-अलग डिफ़ॉल्ट होस्टनाम वर्तनी दिखाता है, इसलिए लाइव खाता मान को कॉपी किए गए उदाहरण पर प्राथमिकता दी जाती है। डोमेन सत्यापन.

Postmark ग्राहक के शीर्ष में शामिल करने की आवश्यकता नहीं है SPF रिकॉर्ड. SPF जांच वास्तविक लिफ़ाफ़ा डोमेन का अनुसरण करती है। शीर्ष शामिल जोड़ने से प्रदाता-स्वामित्व वाले Return-Path ग्राहक-स्वामित्व वाले रिटर्न-पाथ में परिवर्तित नहीं किया जा सकता है। प्रलेखित कस्टम Return-Path एक उपडोमेन है; Postmark आरामदायक SPF सलाह देता है संरेखण इस मार्ग के लिए. एक सख्त SPF आवश्यकता को और अधिक शामिल करके तय नहीं किया जाता है। डोमेन की स्वीकृत नीति को सुरक्षित रखें और जहां उपयुक्त हो, सत्यापित संरेखित DKIM पथ का उपयोग करें। Postmark SPF मार्गदर्शन.

आवेदन परिणाम सिद्ध करें

निम्नलिखित एक सिंथेटिक स्वीकृति डिज़ाइन है, कैप्चर की गई डिलीवरी नहीं। प्रत्येक उदाहरण को देखे गए मान से बदलें और परीक्षण का टाइमस्टैम्प और संदेश आईडी रखें।

• साक्ष्य: से दिखाई दे रहा है; उदाहरणात्मक मूल्य: receipts@example.com ; स्वीकृति प्रश्न: क्या यह स्वीकृत आवेदन पहचान है?
• साक्ष्य: लिफाफा डोमेन; उदाहरणात्मक मान: pm-bounces.example.com ; स्वीकृति प्रश्न: क्या इस संदेश पर कस्टम Return-Path सक्रिय हुआ?
• साक्ष्य: DKIM हस्ताक्षरित डोमेन; उदाहरणात्मक मूल्य: example.com ; स्वीकृति प्रश्न: क्या विश्वसनीय प्राप्तकर्ता ने इस हस्ताक्षर को सत्यापित किया?
• प्रमाण: DMARC; निदर्शी मान: उत्तीर्ण होना; स्वीकृति प्रश्न: किस संरेखित उत्तीर्ण पद्धति ने यह परिणाम उत्पन्न किया?
• example.com के डोमेन और उसके नीचे एक बाउंस उपडोमेन से, आरामदायक SPF संरेखण काम कर सकता है जबकि सख्त SPF संरेखण नहीं करता है। एक सटीक-डोमेन पासिंग DKIM हस्ताक्षर अभी भी DMARC संतुष्ट कर सकता है। देखे गए हस्ताक्षर का मूल्यांकन करें, न कि इस वादे का कि हर संदेश पर हस्ताक्षर किए गए हैं। DMARC संरेखण.

उनके संबंधित एप्लिकेशन पथों के माध्यम से वास्तविक रसीद और पासवर्ड-रीसेट ईवेंट का परीक्षण करें। उनकी स्ट्रीम और प्रेषक कॉन्फ़िगरेशन की तुलना करें। यदि एक पास हो जाता है और दूसरा विफल हो जाता है, तो साझा DNS बदलने से पहले भिन्न मार्ग की जांच करें। परीक्षण के तौर पर ग्राहकों को वास्तविक वित्तीय रसीदें दोबारा न भेजें।

निदान करें और पुनर्प्राप्त करें

यदि DKIM अनुपस्थित है, तो पुष्टि करें कि एप्लिकेशन का डोमेन सत्यापित डोमेन से मेल खाता है और हस्ताक्षर सक्रिय है। यदि हस्ताक्षर मौजूद है लेकिन विफल रहता है, तो प्राप्तकर्ता का कारण सुरक्षित रखें और सटीक का निरीक्षण करें चयनकर्ता लुकअप और कोई भी सामग्री-संशोधित रिले। यदि SPF पास हो जाता है लेकिन असंरेखित है, तो शीर्ष अनुमतियाँ जोड़ने के बजाय Return-Path सक्रियण का निरीक्षण करें। यदि DNS सत्यापन विफल हो जाता है, तो खाते के मानों के साथ आधिकारिक उत्तरों, पूर्ण होस्टनाम और रिकॉर्ड प्रकार की तुलना करें।

स्वीकृति विफल होने पर केवल प्रभावित एप्लिकेशन स्ट्रीम को रोकें। परिवर्तन स्वामी के माध्यम से सहेजे गए रिकॉर्ड या प्रेषक सेटिंग को पुनर्स्थापित करें, फिर नियंत्रित घटना का पुनः परीक्षण करें। पुराने चयनकर्ता को न हटाएं जबकि कतारबद्ध मेल को अभी भी इसकी आवश्यकता हो सकती है। अप्रयुक्त बाउंस प्रतिनिधिमंडल और हस्ताक्षरित रिकॉर्ड को केवल यह पुष्टि करने के बाद ही हटाएं कि कोई अन्य Postmark एप्लिकेशन उन्हें साझा नहीं करता है। यह पांडुलिपि दस्तावेज़ीकरण पर आधारित है; किसी किरायेदार, DNS परिवर्तन या लाइव डिलीवरी का परीक्षण नहीं किया गया।

सख्त और आरामदेह परिणामों की स्पष्ट रूप से तुलना करें

लिखित मामले PM-01 के लिए, मान लें receipts@example.com से, मेल प्रेषक bounce@pm-bounces.example.com pm-bounces.example.com और pm-bounces.example.com के लिए एक विश्वसनीय SPF पास। सामान्य समान-संगठनात्मक-डोमेन शिथिल संरेखण के तहत, वह SPF पथ संरेखित होता है; aspf=s के साथ यह example.com बिल्कुल मेल नहीं खाता है। अलग से एक पासिंग सिग्नेचर d=example.com, s=demo1: वह पथ बिल्कुल संरेखित है और सख्त-एसपीएफ मामले में भी DMARC संतुष्ट कर सकता है। यदि DKIM पास होने के बजाय अज्ञात हो जाता है, तो पहले के आधार पर पास न रखें। ये निर्धारित इनपुट हैं, न कि कैप्चर की गई Postmark डिलीवरी या किसी नीति को कमजोर करने की सलाह।

प्रवर्तन सीमा को सुरक्षित रखें

RFC 9989 धारा 7.4 को p=reject, प्रकाशित करने वाले डोमेन के लिए वैध DKIM की आवश्यकता है, अकेले SPF नहीं, और अप्रत्यक्ष-मेल और मेलिंग-सूची अंतरसंचालनीयता के बारे में चेतावनी देता है। एक भी सफल प्रत्यक्ष-संदेश परीक्षण इस बात का प्रमाण नहीं है कि हर वैध मार्ग मजबूत नीति के लिए तैयार है। वास्तविक अंतर का निदान करते समय मौजूदा अनुमोदित सुरक्षा बनाए रखें; किसी भी नीति परिवर्तन के लिए अपने स्वयं के निर्णय की आवश्यकता होती है।