Amazon SES ईमेल का परीक्षण

पहले sandbox की जाँच करें, क्योंकि इसी से तय होता है कि यह काम करेगा भी या नहीं। हर Region में नया SES खाता sandbox में शुरू होता है। जब तक वह वहाँ रहता है, SES केवल सत्यापित पतों, सत्यापित डोमेन और अपने mailbox simulator को ईमेल डिलीवर करता है। इसके अलावा, प्रति 24 घंटे में 200 संदेश और प्रति सेकंड एक संदेश की सीमा होती है।

Email Spam Tester के पते को सत्यापित करने से यह पाबंदी नहीं हटेगी। SES किसी प्राप्तकर्ता को सत्यापित करने के लिए उसे एक लिंक वाला ईमेल भेजता है। चूँकि हमारे पते बंद होने से पहले ठीक एक संदेश स्वीकार करते हैं, इसलिए सत्यापन ईमेल ही उस पते का उपयोग कर लेगा। इस कारण, व्यवहार में आपको उस Region में production access चाहिए जहाँ से आप ईमेल भेजते हैं। AWS उस अनुरोध पर 96 घंटे के भीतर शुरुआती जवाब देने का वादा करता है।

चूँकि sandbox की स्थिति हर Region के लिए अलग होती है, इसलिए eu-west-1 में production में मौजूद खाता अभी भी us-east-1 में sandbox में हो सकता है। identities भी हर Region के लिए अलग होती हैं और हर identity के अपने DKIM रिकॉर्ड होते हैं।

एक पता लें, एक संदेश भेजें

email-spam-tester.com खोलें और वहाँ दिखाया गया पता कॉपी करें। इसके लिए किसी खाते या API key की आवश्यकता नहीं है। यह test- के बाद बीस वर्णों और फिर t.email-spam-tester.com से बना होता है। आपके पास एक घंटा और एक संदेश है, इसलिए पता लेने से पहले send command तैयार कर लें।

भेजने का सबसे छोटा तरीका CLI है। इसे SES tenants पेज पर दिए गए AWS के अपने उदाहरण से लिया गया है, जिसमें tenant और configuration-set flags हटा दिए गए हैं:

aws sesv2 send-email \
  --from-email-address "sender@yourdomain.com" \
  --destination "ToAddresses=test-xxxxxxxxxxxxxxxxxxxx@t.email-spam-tester.com" \
  --content "Simple={Subject={Data='Test Subject',Charset=utf-8},Body={Text={Data='Test email body',Charset=utf-8}}}"

From एक verified identity होना चाहिए, production में भी। केवल text वाली ऐसी body authentication और IP की जाँच के लिए पर्याप्त है, लेकिन content के बारे में लगभग कुछ नहीं बताती। वास्तविक परिणाम के लिए वही संदेश भेजें जो आपका application वास्तव में भेजता है, उसके HTML part और headers सहित। उसी code path का भी उपयोग करें, चाहे वह boto3 का send_email, कोई SMTP library या कुछ और हो। अगर production में भेजे जाने वाले संदेश configuration set का उपयोग करते हैं, तो यहाँ --configuration-set-name भी जोड़ें, ताकि परीक्षण उन्हीं settings से होकर चले।

Inbox test इसी command में जुड़ जाता है। इसके provider inboxes को test address के साथ ToAddresses में और इसके marker को Subject data में डालें। इसके बाद एक call से दो reports भर जाती हैं। दूसरी report बताती है कि संदेश Gmail, Outlook, Yahoo और अन्य providers में किस folder में पहुँचा। वे inboxes भी verified नहीं हैं, इसलिए इसके लिए भी production access आवश्यक है।

Console से भी यह किया जा सकता है। Configuration > Identities खोलें, identity पर click करें और Send test email चुनें। अगर आप अपने headers के साथ पूरा MIME संदेश paste करना चाहते हैं, तो Raw चुनें। AWS के अनुसार console ऐसा tool है जिसका उपयोग आम तौर पर केवल test emails के लिए किया जाता है, और docs में किसी test prefix या संदेश में किसी अन्य बदलाव का उल्लेख नहीं है। Sandbox में Custom recipient field के लिए verified address आवश्यक है, जिससे आप फिर ऊपर बताई गई समस्या पर लौट आते हैं।

रिपोर्ट में नई SES पहचान कैसी दिखती है

DKIM। Easy DKIM डोमेन पहचान के लिए डिफ़ॉल्ट है और 2048-बिट कुंजी से हर संदेश पर हस्ताक्षर करता है। इसे सेट अप करने के लिए token._domainkey.yourdomain.com नाम के तीन CNAME रिकॉर्ड चाहिए, जो token.dkim.<region>.amazonses.com पर पॉइंट करते हैं। अगर DKIM जाँच विफल होती है, तो पहले दो चीजें देखें: क्या DNS अपडेट हो चुका है (AWS के अनुसार इसमें 72 घंटे तक लग सकते हैं) और क्या आपके DNS होस्ट ने नाम के साथ डोमेन जोड़कर token._domainkey.yourdomain.com.yourdomain.com बना दिया है। BYODKIM के साथ, इसके बजाय आप अपने selector पर एक TXT रिकॉर्ड प्रकाशित करते हैं। दोनों के बीच स्विच करते समय SES बिना किसी हस्ताक्षर के संदेश भेज सकता है, जिसे रिपोर्ट missing DKIM के रूप में दिखाती है। DKIM जाँचकर्ता token को selector के रूप में लेता है।

SPF और return path। डिफ़ॉल्ट रूप से SES, MAIL FROM के रूप में amazonses.com के एक सबडोमेन का उपयोग करता है। SPF पास होता है, लेकिन amazonses.com के लिए, इसलिए रिपोर्ट SPF को आपके From के साथ unaligned दिखाती है। DKIM aligned होने पर इसका प्रभाव कम होता है (100-पॉइंट स्केल पर 5 के बजाय 2 पॉइंट), और DMARC फिर भी DKIM के आधार पर पास होता है। SPF को भी aligned करने के लिए, ठीक एक MX रिकॉर्ड 10 feedback-smtp.<region>.amazonses.com और एक TXT रिकॉर्ड v=spf1 include:amazonses.com ~all के साथ कस्टम MAIL FROM सबडोमेन सेट अप करें। ऐसा सबडोमेन न चुनें जो मेल प्राप्त करता हो, और अपने DMARC रिकॉर्ड में aspf=s शामिल न करें, क्योंकि AWS के अनुसार सख्त SPF नीति के तहत SES के साथ SPF alignment काम नहीं करता।

DMARC। SES इसे आपके लिए प्रकाशित नहीं करता। AWS का नमूना v=DMARC1;p=quarantine;rua=mailto:my_dmarc_report@example.com है। अगर अभी कोई आपकी DMARC रिपोर्ट नहीं पढ़ता है, तो मैं p=none से शुरू करने और बाद में नीति सख्त करने की सलाह दूँगा। DMARC जाँचकर्ता दिखाता है कि आपने क्या सेट किया है, और DMARC fail में आम गड़बड़ियों की जानकारी है।

List-Unsubscribe। SES केवल तभी List-Unsubscribe और List-Unsubscribe-Post जोड़ता है, जब आप किसी संपर्क सूची और विषय की ओर पॉइंट करने वाले ListManagementOptions के साथ संदेश भेजते हैं। तब भी, यह केवल एक प्राप्तकर्ता वाले संदेशों और Easy DKIM के साथ काम करता है, और SES आपके स्वयं सेट किए गए unsubscribe headers को ओवरराइट कर देता है। बाकी सभी संदेश बिना किसी unsubscribe headers के भेजे जाते हैं। न्यूज़लेटर के लिए इसका मतलब है कि List-Unsubscribe जाँच और एक-क्लिक जाँच, दोनों तब तक विफल होंगी जब तक आप इन्हें स्वयं नहीं जोड़ते। मार्च 2024 से v2 API, raw MIME के बिना कस्टम headers स्वीकार करता है। AWS की एक-क्लिक ब्लॉग पोस्ट से लिए गए दोनों headers इस तरह दिखते हैं:

"Headers": [
  { "Name": "List-Unsubscribe",
    "Value": "<https://yourdomain.com/unsub?address=x&topic=x>, <mailto:unsubscribe@yourdomain.com>" },
  { "Name": "List-Unsubscribe-Post",
    "Value": "List-Unsubscribe=One-Click" }
]

इसके बाद आपके endpoint को POST संभालना होगा। list headers के बिना password reset और receipts अलग मामला हैं, और उनके लिए रिपोर्ट bulk-sender समूह को skipped के रूप में दिखाती है। header के बारे में अधिक जानकारी हमारे List-Unsubscribe पेज पर है।

IP और blocklists

नए खाते अन्य SES उपयोगकर्ताओं के साथ साझा किए गए IP से ईमेल भेजते हैं। AWS का सुझाव है कि जब तक आपके ईमेल की मात्रा बड़ी और नियमित न हो, आप इन्हीं IP का उपयोग करें। रिपोर्ट भेजने वाले IP को 21 blocklists में जाँचती है। साझा पतों पर किसी सूची में पाया गया IP पूरे पूल से संबंधित होता है। Dedicated IP दो प्रकार के होते हैं: Standard, जिसे आपको खुद धीरे-धीरे सक्रिय करना होता है, और Managed, जिसमें SES यह प्रक्रिया संभालता है। इनके मामले में किसी सूची में शामिल होना सीधे आपके अपने ईमेल भेजने से जुड़ा होता है। Headers टैब में मिले किसी भी IP को आप सीधे blocklist जाँचकर्ता में डाल सकते हैं।

AWS आपके खाते की भी निगरानी करता है। उसके प्रवर्तन FAQ में कहा गया है कि आप ऐसे वास्तविक पतों पर परीक्षण करें जो ईमेल प्राप्त कर सकते हों, या simulator का उपयोग करें, ताकि काल्पनिक प्राप्तकर्ताओं के कारण bounce दर न बढ़े। 5% bounce दर या 0.1% complaint दर होने पर खाते को समीक्षा के तहत रखा जाता है।

नीचे दिया गया सुधार प्लान अधिकतम आठ बदलाव सूचीबद्ध करता है। जहाँ लागू हो, हर बदलाव के साथ कॉपी करने के लिए DNS रिकॉर्ड दिया जाता है। हर सुधार के पास दिए गए अंक उन जाँचों की मौजूदा penalties हैं जिन पर वह असर डालता है। मॉडल सुधार चुनता है और उनकी व्याख्या करता है। वह उनकी कीमत तय नहीं करता। अगर किसी जाँच का नाम आपके लिए अस्पष्ट है, तो दस्तावेज़ सभी 42 जाँचों की व्याख्या करते हैं।