2024 में ईमेल डिलिवरेबिलिटी का गहन विश्लेषण

 (xomedia.io)
3 पॉइंट द्वारा GN⁺ 2024-04-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें

ईमेल डिलिवरेबिलिटी का गहन विश्लेषण

  • अक्टूबर 1971 में, MIT के स्नातक Ray Tomlinson ने नेटवर्क के माध्यम से पहला ईमेल भेजा।
  • पिछले वर्ष लगभग 121 ट्रिलियन ईमेल लगभग 4.3 अरब लोगों के बीच भेजे गए।
  • ईमेल पृथ्वी पर लिखित संचार का सबसे महत्वपूर्ण माध्यम है, और निकट भविष्य में भी ऐसा ही रहेगा।

अवलोकन

  • 3 अक्टूबर 2023 को, Google और Yahoo ने spam, phishing और malware प्रयासों को रोकने के लिए नए ईमेल सुरक्षा मानक घोषित किए।
  • जैसे-जैसे ईमेल सेवा प्रदाता इन नीतियों को लागू कर रहे हैं, ईमेल डिलिवरेबिलिटी के लिए दिशानिर्देशों का पालन करना अनिवार्य हो गया है।
  • सबसे बड़ा बदलाव SPF, DKIM, DMARC जैसे ईमेल authentication standards के implementation का है।
  • Gmail के मामले में, authenticated न होने वाले मेल ब्लॉक कर दिए जाते हैं।

कौन प्रभावित होंगे

  • मुख्य रूप से bulk senders प्रभावित होंगे, और उन्हें अपने domain पर SPF, DMARC, DKIM सक्रिय करने होंगे।
  • यदि आप bulk sender नहीं भी हैं, तब भी दिशानिर्देशों का पालन न करने पर आप प्रभावित हो सकते हैं।

टाइमलाइन

  • Google ने फरवरी 2024 से bulk senders के लिए ईमेल authentication अनिवार्य किया।
  • Yahoo ने भी 2024 की पहली तिमाही से वही आवश्यकताएँ लागू कीं।

दिशानिर्देश

  • sender authentication: SPF, DKIM, DMARC जैसे ईमेल authentication protocols लागू करें।
  • bulk sender requirements: spam filtering और reputation damage से बचने के लिए अनावश्यक bulk emails भेजने से बचें।
  • आसान unsubscribe: unsubscribe विकल्प को आसानी से लागू करें।
  • engagement: भ्रामक subject lines, अत्यधिक personalization, और spam filters को trigger करने वाले promotional content से बचें।

sender authentication

  • SPF, DKIM, DMARC ऐसे 3 authentication standards हैं जो किसी संगठन के ईमेल की सुरक्षा में मदद करते हैं।
  • इन standards का सही configuration हमलों से सुरक्षा देता है और deliverability बढ़ाता है, जिससे ईमेल spam folder के बजाय inbox तक पहुँचते हैं।

प्रभाव

  • Google, ईमेल filtering और user experience सुधारने के लिए algorithms और user report data को लगातार update करता है।
  • नए सुरक्षा दिशानिर्देश ईमेल deliverability और engagement पर पड़ने वाले प्रभाव को उजागर करते हैं।

टूल

  • ईमेल hygiene को सेट up, verify और maintain करने में मदद करने वाले free online resources की सूची प्रदान की गई है।

implementation

  • इन दिशानिर्देशों को लागू करना सीमित संसाधनों वाले छोटे संगठनों के लिए चुनौतीपूर्ण हो सकता है।
  • ईमेल authentication लागू करने के लिए service providers के resources या support का संदर्भ लें।

बोनस

  • कुछ ऐसे तरीके बताए गए हैं जिनसे hackers ईमेल सुरक्षा की कमजोरियों का फायदा उठाते हैं।

GN⁺ की राय

  • यह लेख ईमेल सुरक्षा से जुड़े नवीनतम standards का पालन करने के महत्व पर जोर देता है। इससे ईमेल आधारित संचार की विश्वसनीयता बढ़ती है और उपयोगकर्ताओं को spam या phishing जैसे खतरों से बचाने में मदद मिलती है।
  • जैसे-जैसे ईमेल सेवा प्रदाता नए सुरक्षा standards लागू कर रहे हैं, संगठनों को इन बदलावों के अनुसार खुद को ढालने और अनुपालन सुनिश्चित करने के लिए प्रयास करने होंगे। यह खास तौर पर उस समय और भी महत्वपूर्ण है जब privacy और data security के प्रति संवेदनशीलता बहुत अधिक है।
  • यह लेख खास तौर पर उन कंपनियों के लिए उपयोगी हो सकता है जो email marketing से जुड़े व्यवसाय चलाती हैं। चूँकि email marketing अभी भी कई कंपनियों के लिए एक महत्वपूर्ण marketing channel है, इसलिए ईमेल deliverability बनाए रखना सफल campaigns के लिए अनिवार्य है।
  • ईमेल authentication standards को लागू करना एक तकनीकी चुनौती हो सकता है, खासकर उन संगठनों के लिए जो पहली बार SPF, DKIM, DMARC जैसे protocols के संपर्क में आ रहे हैं। इन standards को अपनाते समय technical support और resources की आवश्यकता हो सकती है, और इसके लिए समय तथा लागत दोनों लग सकते हैं।
  • यह लेख ईमेल सुरक्षा मजबूत करने की इच्छा रखने वाले संगठनों को उपयोगी दिशानिर्देश और tools प्रदान करता है, जिससे वे अपने ईमेल systems की कमजोरियों को दूर कर सकें और user experience बेहतर बना सकें।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-02
Hacker News की टिप्पणियां

  • “Gmail”, “Outlook”, “Yahoo” जैसे ईमेल providers के प्रभाव को देखते हुए, मैं हमेशा सोचता रहा हूं कि क्या कंपनियों को निशाना बनाने वाले किसी और हमले के रूप में targeted delivery failure संभव नहीं होगा
    पीड़ित, खासकर कंपनियों·mailing lists·NGO, को attacker के स्वामित्व वाले addresses पर bulk mail भेजने के लिए मजबूर करना, और फिर attacker Gmail/Yahoo/Outlook में उन mails को spam के रूप में mark कर दे
    तब AI spam filter इसे नई spam activity के तौर पर सीख सकता है और बाद में असली customers को जाने वाले mails तक को spam में डाल सकता है या पहुंचने से पहले delete कर सकता है
    करीब एक साल बाद कंपनी हर quarter पैसा गंवा रही होगी, advertising department email engagement rate गिरने पर हैरान होगा, और technical department उलझन में पड़ सकता है
    बड़ी कंपनी शायद टिक जाए या email को पूरी तरह छोड़ दे, लेकिन छोटी कंपनी या NGO·political mailing list को donations घटने जैसी चोट लग सकती है
    सच कहूं तो attack vector के रूप में इसकी संभावना कम है, लेकिन यह विचार मन में बना रहा है

    • मैं ऐसे victim को जानता हूं, जिसका legitimate email template असली spammers ने हूबहू चुरा लिया था
      Spammer ने legitimate template को email के अंदर invisible रूप में डाल दिया, और असली scam text की सिर्फ कुछ lines दिखाईं
      तरीका यह था कि filter email के अधिकतर हिस्से को normal मानकर उसे pass कर दे; और अंततः जब users पर्याप्त spam reports करते हैं तो template खुद blocking trigger करने लगता है
      फिर spammer अगले victim के email template पर चला जाता है जो अभी भी filters से pass हो रहा होता है, और पहला victim इस aftermath से जूझता रहता है कि उसके mails कहीं भी नहीं पहुंच रहे
    • मैंने इसे corporate attack के नजरिए से नहीं, बल्कि consumer rights या boycott के नजरिए से सोचा है
      shareholder value maximization का हवाला देने वाली एक बड़ी कंपनी के साथ मेरा अनुभव इतना खराब रहा कि मैंने पुराने email records खंगाले और उस कंपनी की सारी communications को spam के रूप में mark कर दिया
      यह एक बूंद भर हो सकता है, लेकिन spam की दुनिया में शायद बहुत ज्यादा votes की जरूरत न हो
      Email delivery जल्द ही और भी खुलकर paid passage model में evolve होगी, और हो सकता है पहले से ही पर्दे के पीछे कुछ समझौते हों
    • इसलिए अधिकांश e-commerce sites marketing mails को अलग domain से भेजती हैं
      अगर वह domain report हो भी जाए, तो transactional emails मुख्य domain से भेजी जा सकती हैं
      बेशक, इसके लिए यह धारणा जरूरी है कि दोनों mail servers अलग-अलग IPs पर हों
    • एक web forum जिसे मैं जानता हूं, उसमें नियम है कि उनके भेजे email notifications को spam के रूप में mark न करें
      Site पर unsubscribe किया जा सकता है, लेकिन वे कह रहे हैं कि email client की तरफ से spam में न डालें
      छोटे organizations के लिए यह काफी वास्तविक risk हो सकता है
      बड़े organizations इसे कैसे mitigate करते हैं, यह मुझे ठीक से नहीं पता
    • मुझे लगता है इसे DMARC policy से रोका जा सकता है
      अगर attacker द्वारा भेजा गया email SPF/DKIM में fail होता है, तो Gmail को वह fake mail शुरू में ही deliver न करने के लिए DMARC policy set की जा सकती है
      तब ऐसा attack काम नहीं करेगा

  • यह बदलाव जरूरी था और बहुत देर से आया
    बड़ी मात्रा में email भेजने वाले domain owners से message signing ठीक से require करने पर recipients IP address reputation के बजाय domain reputation के आधार पर अच्छे और खराब mails को ज्यादा साफ तौर पर अलग कर सकते हैं
    जैसे-जैसे अधिक domains transactional·marketing services के shared IP space के जरिए email भेज रहे हैं, reputation को sending domain से भरोसेमंद तरीके से जोड़ पाने की क्षमता abuse कम करने में बहुत उपयोगी है

    • “बड़ी मात्रा” वाली शर्त असल में सही नहीं है
      Google कहता है कि नई requirements सिर्फ तब mandatory हैं जब आप दिन में 5,000 से ज्यादा mails भेजते हैं, लेकिन यह झूठ है
      मैं दिन में ज्यादा से ज्यादा कुछ ही mails भेजता था, आम तौर पर Gmail account से दिन में एक mail भी नहीं भेजता था, और requirements का सिर्फ कुछ हिस्सा implement किया था, फिर भी Google ने मेरे messages reject करने शुरू कर दिए
      अंत में मुझे थोड़ी redundant requirements तक सब implement करने में समय बर्बाद करना पड़ा
    • एक system administrator के तौर पर, अगर recipient के Office365 mail server की configuration error के कारण 5% emails spam में जा रहे हों तो मैं क्या करूं, समझ नहीं आता
      कुल मिलाकर मैं इस positive change से सहमत हूं, लेकिन जब email spam folder में जाने की वजह recipient-side configuration error हो, तो यह सच में frustrating है
      उदाहरण के लिए delivery process में SPF टूट जाने के मामले होते हैं
    • हम भी धीरे-धीरे IPv6 की तरफ बढ़ रहे हैं, और अगर मनचाहे जितने नए IP addresses मिल सकते हैं तो IP-based reputation कुछ हद तक बेकार हो जाएगी
      अगर malicious sender हर email अलग IPv6 address से भेज सकता है, तो नए दिखने वाले सभी IPv6 addresses को default रूप से untrusted मानना पड़ सकता है
    • सहमत हूं, यह इसका साफ फायदा है
      असुविधा है, लेकिन उम्मीद है कि यह बदलाव email ecosystem को साफ-सुथरा करेगा

  • Spam को malicious content से अलग नहीं किया जा सकता
    आपने उस “newsletter” के लिए sign up नहीं किया था, और आपका email address collect करके किसी malicious actor को दे दिया गया था जो आपको परेशान करना चाहता है
    आप कुछ भी click करें, वह आपको ऐसी website पर ले जाएगा जहां उस company के पास आपकी जानकारी होगी और वह आपके हितों का बिल्कुल ध्यान नहीं रखेगी
    सबसे अच्छे case में आप inbox के कचरे के एक source को हटा पाएंगे, और सबसे खराब case में आप किसी ऐसी चीज पर click कर देंगे जो आपके computer में malware install कर दे
    इसलिए unsubscribe link पर click न करें, spam report button दबाएं, और उन बड़े email services को छोड़ दें जो spam reports को ignore करती हैं
    Gmail दूसरी बड़ी कंपनियों को आपको spam भेजने देता है और आपको पूरे domain को सीधे block करने का option भी नहीं देता
    जब तक आप privacy और security को गंभीरता से लेने वाले email provider पर नहीं जाते, malicious content आपके inbox में आती रहेगी

    • यह आकलन उचित है
      जानना चाहूंगा कि आप कौन-सा email service provider इस्तेमाल करते हैं

  • यह देखकर हैरानी होती है कि इतनी बड़ी-बड़ी कंपनियां one-click unsubscribe टेस्ट पास नहीं कर पातीं
    या तो Cloudflare या Akamai कनेक्शन रोक देते हैं, या पेज लोड होने में 5 सेकंड से ज़्यादा लगते हैं, या लॉगिन करने या ईमेल पता दोबारा डालने को कहते हैं
    फिर उन्हें हैरान नहीं होना चाहिए जब ग्राहक spam report बटन दबाते हैं

    • जिस ईमेल के लिए मैंने सहमति नहीं दी, उससे मैं unsubscribe नहीं करता
      इसलिए मैं spam report दबाता हूं
    • मैं NextDNS में ad-block lists लगाकर इस्तेमाल कर रहा हूं, यह असल में cloud वाला Pi-hole है
      सबसे चिढ़ाने वाली बात यह है कि ईमेल भेजने वाले click tracking ऐसे domain से करते हैं जो ad-block lists में block हो जाते हैं
      ऐसे links को copy-paste करने के लिए मैंने एक अलग browser instance रखा है, लेकिन फिर उसमें भी login करना पड़ता है
      link पर click करने के बजाय unsubscribe ईमेल भेजना मुझे बेहतर लगता है, और Gmail इसे automate कर सकता है
    • unsubscribe तो कर दूंगा, लेकिन 2024 में “लागू होने में 14 दिन लग सकते हैं” जैसी बकवास अब स्वीकार नहीं है
      अगर कुछ दिनों में फिर ईमेल आया तो उसे spam mark करूंगा
      अगर TripAdvisor AI-generated travel itinerary बना सकता है, तो उसे ईमेल से न भेजने का तरीका भी निकालना चाहिए
    • अंततः मुझे यह एक साधारण UI competition लगता है
      ग्राहक unsubscribe और spam report में से जो ज़्यादा आसान होगा, वही चुनेंगे

  • अप्रैल के बदलावों से टूटने वाली चीजों में से एक ईमेल सेवाओं के बीच forwarding है
    उदाहरण के लिए, अगर आप पुराने university address foo@school.edu से अपने personal Gmail account bar@gmail.com पर forward कर रहे हैं, तो यह अब काम नहीं करेगा
    बड़े providers जिस तरह इसे आगे बढ़ा रहे हैं, उससे लगता है कि यह उपयोग का अपेक्षाकृत rare case है, लेकिन जिन लोगों पर असर पड़ेगा उनके लिए यह काफ़ी परेशान करने वाला बदलाव है

    • समझ नहीं आ रहा कि यह अब क्यों काम नहीं करेगा
      ईमेल forward करते समय अगर forwarder message content में बदलाव नहीं करता, तो DKIM signature अब भी match करना चाहिए और इसलिए pass होना चाहिए
    • यह कोई नया बदलाव नहीं है
      SPF हमेशा से ऐसे forwarders को तोड़ता रहा है जो envelope के sender address को नहीं छूते, और यह सही व उचित है
      mail forwarding अब भी संभव है, लेकिन forwarder को return path दोबारा लिखना होगा
    • यह तो काफी बड़ा मामला है, क्या इसका मतलब है कि अब email forwarding नहीं चलेगी?

  • हैरानी है कि SPF, DKIM, DMARC पूरी तरह set up न होने के बावजूद कोई mail pass करा रहा था
    मैंने कई साल तक एक अच्छे से configured self-hosted personal email server चलाया, फिर भी कभी-कभी pass कराने में मुश्किल हुई, हालांकि लगता है धीरे-धीरे सुधार हो रहा है

    • SPF, DKIM, DMARC को पूरी तरह set up करने का मतलब यह नहीं कि receiving server भी इसे वैसा ही देखेगा
      खासकर Microsoft servers अक्सर बिना वजह बिल्कुल ठीक DKIM configuration को randomly fail कर देते हैं
    • बात सिर्फ configuration की नहीं, reputation भी महत्वपूर्ण है
      sending volume कम हो तो सिर्फ इसलिए भी mail discard होने का जोखिम रहता है कि आप कोई well-known sender नहीं हैं
    • मैं भी कई सालों से इस समस्या से जूझ रहा हूं
      उम्मीद है कि बड़े 3 players ने ये guidelines public और transparent कर दी हैं, तो behavior ज़्यादा consistent होगा
    • मेरे अनुभव में DKIM ज़रूरी नहीं था, और नई Google guidelines में भी अगर SPF इस्तेमाल करते हैं तो यह अब भी mandatory नहीं है
    • हैरानी होती है कि लोग email deliverability को सिर्फ SPF, DKIM, DMARC settings के रूप में देखते हैं
      entry barrier कम है, इसलिए spammers भी यही कर सकते हैं
      ये महत्वपूर्ण हैं, लेकिन real-world deliverability से इनका संबंध बहुत कम है

  • DMARC में सबसे मुश्किल बात यह है कि खासकर Microsoft पर यह अक्सर fail हो जाता है
    और उन सभी use cases में भी समस्या आती है जहां recipient mail forward करता है, क्योंकि तब SPF alignment टूट जाता है
    best practices follow करना चाहता था, इसलिए हाल ही में मैंने p=quarantine को p=none में बदल दिया
    वजह यह थी कि DKIM और SPF सही set होने के बावजूद legitimate email के DMARC pass न होने का डर था
    मैं सच में p=reject इस्तेमाल करना चाहता हूं, लेकिन जब तक recipients के incoming mail servers email forwarding से DMARC टूटने जैसी exception situations को handle करने के लिए ठीक नहीं किए जाते, तब तक नहीं कर सकता

    • DMARC लागू करते हुए जो sender चाहता है कि उसका email forward हो, उसे DKIM इस्तेमाल करना चाहिए
      DKIM-signed message forward करने से DMARC बिल्कुल नहीं टूटता

  • सबसे बुरा यह है कि mail accept कर लेने के बाद चुपचाप उसे spam mark कर देना और ऐसी जगह डाल देना जहां intended recipient उसे कभी देख ही न पाए
    Google का Gmail यह सबसे ज़्यादा करता है
    corporate email अब email नहीं रहा, बल्कि Facebook जैसा walled garden और silo बन गया है

    • अच्छा है कि ऐसी walls हैं
      वरना हम cold email spam में डूब गए होते
      गंभीरता से कहूं तो, अपने server चलाना और manage करना छोड़कर हम सभी companies के लिए Gmail इस्तेमाल कर रहे हैं
      यह इतना मुश्किल हो गया है, यह दुखद है
      अगर आप अच्छे से configured Gmail Workspace पर नहीं हैं, तो लगता है कि legitimate mail के भी pass होने की कोई संभावना नहीं है
    • वाकई चिढ़ होती है
      मेरी समझ के अनुसार वे spammers को यह signal नहीं देना चाहते कि message को normal mail या spam के रूप में classify किया गया है
      मैं जानना चाहूंगा कि spammers सच में ऐसी जानकारी का कितना चतुराई से इस्तेमाल करते हैं
      ज़्यादातर spam मुझे ऐसी कोशिश लगती है जो failure feedback की परवाह किए बिना बस लगातार hammer करती रहती है
      अपने mail server पर मैं junk के रूप में classified messages को सामान्य error message के साथ temporary reject करता रहता हूं
      कम से कम गलत classify हुए legitimate senders को delayed DSN मिलता है, और अंततः feedback मिलता है कि message receive नहीं हुआ
      लगता है कि कई mail servers और services गलत classify हुए legitimate users को उपयोगी signal देने के बजाय spammers को signal न देने को ज्यादा महत्वपूर्ण मानते हैं
      शायद वे सोचते हों कि उनकी classification इतनी शानदार है कि false classifications होते ही नहीं
    • यह नहीं कह रहा कि यह सही है, लेकिन असरदार है
      user के नजरिए से Gmail के spam filter और promotions filter 99% से अधिक भरोसेमंद हैं, और false positives भी सच में बहुत कम हैं
    • दुर्भाग्य से unsolicited spam के खिलाफ कई कानूनी protections सिर्फ consumer use पर लागू होती हैं
      B2B में, जो marketer आपका email address जान सकता है, मानो उसे जितने चाहें उतने messages भेजने का अधिकार है
      walls न होतीं तो यह पूरी तरह unusable हो गया होता

  • मेरी निजी VM किसी RBL में आ गई, क्योंकि पूरा /24 address space blacklist हो गया था
    कहा गया कि किसी ने spam भेजा था, और अब मेरी machine भी block हो गई है, जो हफ्ते में करीब तीन email भेजती है

    • समस्या यह है कि VM provider अनजाने में वही address space spammers को दे रहा है
      spammer ने उस range के अंदर कोई भी random address इस्तेमाल किया हो सकता है, या किसी ने relay allow करने वाला गलत तरीके से configured SMTP server चला दिया हो सकता है
      customer IP range से outgoing SMTP server चलाना वैसे भी आसानी से समस्या बन सकता है
      ऐसी ranges को पूरी तरह संदिग्ध माना जा सकता है, क्योंकि spammers उन्हें reputation की परवाह किए बिना इस्तेमाल करते हैं
    • सही, यह दर्दनाक है
      लगता है block list operators abuse reports को ठीक से verify नहीं करते, या network operators से कार्रवाई करवाने के लिए collateral damage पैदा करते हैं
      block list में आना अच्छा नहीं लगता, लेकिन व्यापक internet के लिए शायद इसका net effect हो सकता है
      मुझे लगता है mail servers और services IP-based block lists का गलत इस्तेमाल कर रहे हैं
      उन्हें कई signals में से एक के रूप में इस्तेमाल करना चाहिए, और पहली बार दिखने वाले senders के लिए उसका weight थोड़ा बढ़ाया जा सकता है
      लेकिन अगर SPF/DKIM/DMARC से authenticated messages के साथ लगातार लेन-देन करता रहा कोई IP अचानक block list में आ जाए, तो पुरानी positive reputation उस block से ज्यादा मजबूत होनी चाहिए
      known counterparties के साथ communication जारी रहना चाहिए, और उनके spam mark करने के बाद ही आगे delivery reject या junk में डालनी चाहिए
      अभी लगता है कई mail servers और services system load कम करने के लिए SMTP process की शुरुआत में ही IP block lists लागू कर देते हैं
      system load के लिए अच्छा है, लेकिन analysis performance के लिए खराब
      कुल मिलाकर, बड़े free mail services भी ham/spam decisions में existing reputation का इस्तेमाल करने में बहुत अच्छे नहीं दिखते
      हाल ही में मैंने अपनी बनाई online web service को email-based signup में बदला, mailing list signup की तरह, जहां किसी खास address पर email भेजकर signup किया जाता है
      idea यह है कि जब user मेरी service को email भेजता है, तो मैं user की known correspondents list में आ जाता हूं
      तब मेरे mail server की तरफ से भेजा गया SPF/DKIM/DMARC-aligned confirmation reply स्वाभाविक रूप से accept होना चाहिए
      इससे ज्यादा साफ opt-in और कितना चाहिए
      कुछ बड़े free mail providers पर test किया, तो Yahoo ने original message को reference करने वाले confirmation reply को भी junk folder में डाल दिया
      जो लोग सोचते हैं कि बड़े mail services से compete नहीं किया जा सकता, उनसे कहूंगा कि bar उतनी ऊंची नहीं है जितनी आप सोचते हैं
    • सच में बुरा हुआ
      reputation ठीक करना, अच्छे से भी किया जाए तो, nightmare के करीब है
      मैंने यह सुझाव भी देखा है कि main domain को protect करने के लिए कोई और domain खरीदकर उसी से email भेजो, लेकिन मैं ऐसा करना खास नहीं चाहता

  • लगता है article में envelope (RFC5321) और header (RFC5322) को मिला दिया गया है
    उसमें कहा गया है कि “email envelope header के From: field में मौजूद domain name check किया जाता है और SPF या DKIM से authenticated किसी दूसरे domain के साथ align किया जाता है”, लेकिन envelope में headers नहीं होते और headers email content/body के अंदर होते हैं
    “सभी email security guidelines पास करने वाले organization के email envelope का उदाहरण” वाला screenshot भी envelope information नहीं, बल्कि mail headers है
    इस topic पर dmarc.org की एक अच्छी presentation है
    https://dmarc.org/presentations/Email-Authentication-Basics-...