SPF और DKIM पास, फिर भी DMARC फ़ेल

संक्षेप में

• DMARC तभी पास होता है जब SPF या DKIM आपके From पते के डोमेन के लिए पास हो। आपके प्रदाता के डोमेन के लिए पास गिना नहीं जाता।
• Gmail में भेजा हुआ कोई संदेश Show original से खोलें और Authentication-Results हेडर में smtp.mailfrom, header.i और header.from की तुलना करें।
• पहले DKIM ठीक करें: आपकी ओर से भेजने वाली हर सेवा में अपने डोमेन से हस्ताक्षर चालू करें। DKIM हस्ताक्षर फ़ॉरवर्ड होने पर भी बचा रहता है, SPF नहीं।
• डिफ़ॉल्ट रूप से सबडोमेन काफ़ी क़रीब माना जाता है। अगर आपके DMARC रिकॉर्ड में adkim=s या aspf=s है, तो नहीं।
• वॉर्मअप अलाइनमेंट को ठीक नहीं करता। वॉर्मअप ईमेल आपके मेलबॉक्स से भेजे जाते हैं और उसी के साथ फ़ेल होते हैं।

DMARC यह नहीं पूछता कि SPF और DKIM पास हुए या नहीं। वह पूछता है कि उनमें से कोई एक आपके From पते के डोमेन के लिए पास हुआ या नहीं। अगर SPF आपके प्रदाता के बाउंस डोमेन के लिए पास हुआ और DKIM आपके प्रदाता के हस्ताक्षर वाले डोमेन के लिए, तो दोनों पंक्तियाँ “pass” कहती हैं और DMARC फिर भी “fail” कहता है। हल भेजने वाली सेवा में है: उससे अपने डोमेन से हस्ताक्षर कराएँ, या अपने डोमेन का बाउंस पता इस्तेमाल करें। दोनों में से एक काफ़ी है।

इस मेल खाने को अलाइनमेंट (alignment) कहते हैं। यह DMARC का वह हिस्सा है जिसे DNS जाँच टूल नहीं देख सकता। आपका ईमेल अलाइन है या नहीं, यह केवल ऐसे संदेश में दिखता है जो सचमुच भेजा गया हो। यह पेज दिखाता है कि ऐसा संदेश कैसे पढ़ें।

हर ईमेल के साथ तीन डोमेन चलते हैं

एक ईमेल में आपका डोमेन तीन जगहों तक आ सकता है। हर जाँच एक अलग जगह देखती है।

SPF (RFC 7208) और DKIM (RFC 6376) दोनों एक-एक संकरे सवाल का जवाब देते हैं, और किसी भी सवाल में आपकी From पंक्ति का ज़िक्र नहीं है। कोई न्यूज़लेटर सेवा अपने बाउंस डोमेन के लिए SPF पास कर सकती है और अपनी कुंजी से हस्ताक्षर कर सकती है, और संदेश फिर भी आपकी ओर से आने का दावा कर सकता है। DMARC यह कमी भरता है। RFC 9989, जो मई 2026 से DMARC का मानक है, कोई नतीजा तभी मानता है जब उसके पीछे का डोमेन From डोमेन से मेल खाए, और DKIM के लिए कारण एक वाक्य में देता है:

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

यही बात SPF पर लागू है, क्योंकि कोई भी अपने डोमेन के लिए SPF रिकॉर्ड प्रकाशित कर सकता है। इसलिए नियम यह है: DMARC तब पास होता है जब SPF पास हो और उसका डोमेन अलाइन हो, या जब DKIM पास हो और उसका डोमेन अलाइन हो।

एक असली संदेश में बेमेल ढूँढ़ें

आपको एक ऐसा ईमेल चाहिए जो उसी तरह भेजा गया हो जैसे आपके असली ईमेल भेजे जाते हैं, और उसे पाने के लिए एक Gmail पता।

1. जिस मेलबॉक्स या टूल की बात है उससे किसी ऐसे Gmail पते पर संदेश भेजें जिसे आप खोल सकते हैं।
2. उसे कंप्यूटर पर Gmail में खोलें। Reply (जवाब दें) के पास More (ज़्यादा) पर क्लिक करें, फिर Show original (मूल संदेश दिखाएँ) पर। Google यही चरण Trace an email with its full header में बताता है।
3. Authentication-Results हेडर ढूँढ़ें, जिसमें प्राप्त करने वाला सर्वर अपनी जाँचों का नतीजा लिखता है (RFC 8601)। तीन मानों की तुलना करें: smtp.mailfrom= के बाद का डोमेन, header.i=@ के बाद का डोमेन (कुछ प्राप्त करने वाले सर्वर header.d= लिखते हैं), और header.from= के बाद का डोमेन। ईमेल हेडर कैसे पढ़ें में इस पंक्ति को चरण दर चरण समझाया गया है।

यह ऐसे संदेश का नमूना है जो SPF और DKIM में पास और DMARC में फ़ेल होता है। हेडर छोटा किया गया है और उसमें उदाहरण वाले डोमेन हैं:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

इसे नीचे से पढ़ें। From डोमेन example.com है। SPF पास हुआ, पर send.vendor-mail.example के लिए। DKIM पास हुआ, पर हस्ताक्षर vendor-mail.example का है। दोनों में से कोई example.com नहीं है, इसलिए From पंक्ति के नाम की पुष्टि कोई नहीं करता।

सेवा को आपके डोमेन से हस्ताक्षर करने के लिए सेट करने के बाद वही संदेश ऐसा दिखता है:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF अब भी विक्रेता की ओर इशारा करता है। इसमें कोई दिक़्क़त नहीं। DKIM अब मेल खाता है, और DMARC को एक अलाइन पास ही चाहिए।

कितना क़रीब काफ़ी है: relaxed और strict

दोनों डोमेन का हूबहू एक होना ज़रूरी नहीं है। डिफ़ॉल्ट रूप से अलाइनमेंट relaxed (ढीला) होता है: इतना काफ़ी है कि दोनों एक ही रजिस्टर्ड डोमेन के हों, जिसे मानक organizational domain (संगठन का डोमेन) कहता है। Strict (सख़्त) अलाइनमेंट हूबहू मेल माँगता है। आप अपने DMARC रिकॉर्ड में DKIM के लिए adkim और SPF के लिए aspf टैग से चुनते हैं।

मानक बताता है कि “लगभग सभी डोमेन मालिकों ने relaxed अलाइनमेंट को अपनी ज़रूरतों के लिए काफ़ी पाया है”। फिर भी अपना रिकॉर्ड जाँच लें। Google के Set up DMARC पेज के ऊपर दिया उदाहरण रिकॉर्ड adkim=s; aspf=s पर ख़त्म होता है, इसलिए वहाँ से कॉपी किया गया रिकॉर्ड strict है। अगर आपके रिकॉर्ड में ये दोनों टैग हैं और कोई टूल सबडोमेन से भेजता है, तो इन्हें हटा दें। Google ख़ुद उस पेज पर चेतावनी देता है कि strict अलाइनमेंट की वजह से “जुड़े हुए सबडोमेन के संदेश अस्वीकार हो सकते हैं या स्पैम में भेजे जा सकते हैं”।

बेमेल आम तौर पर कहाँ से आता है

ऐसी सेवा जो अपने सर्वरों से भेजती है

न्यूज़लेटर प्लेटफ़ॉर्म, CRM, इनवॉइस टूल और हेल्प डेस्क आपके ईमेल अपने इंफ़्रास्ट्रक्चर से भेजते हैं। जब तक आप अपना डोमेन नहीं जोड़ते, वे आम तौर पर अपने डोमेन का बाउंस पता इस्तेमाल करते हैं और अपनी कुंजी से हस्ताक्षर करते हैं। Amazon का दस्तावेज़ साफ़ बताता है कि यहाँ SPF अलाइनमेंट क्यों कम मिलता है: Return-Path “उन बाउंस और शिकायतों के लिए इस्तेमाल होता है जिन्हें प्रदाता (SES) अपने एक पते से ट्रैक करता है” (Amazon SES)। इसे ठीक करने वाली सेटिंग का नाम हर सेवा में अलग है, और उसका अंत आपकी तरफ़ कुछ DNS रिकॉर्ड में होता है।

ये विक्रेताओं के अपने वर्णन हैं, अक्टूबर 2026 की स्थिति के अनुसार। दूसरी सेवाएँ भी इसी ढर्रे पर काम करती हैं। उनकी सहायता में “authenticate domain”, “custom DKIM” या “branded sending domain” खोजें।

आपका मेल प्रदाता अपने डोमेन से हस्ताक्षर करता है, या करता ही नहीं

अपने डोमेन के मेलबॉक्स में Return-Path आम तौर पर आपका अपना पता होता है, इसलिए जैसे ही आपके SPF रिकॉर्ड में प्रदाता शामिल होता है, SPF अलाइन हो जाता है। smtp.mailfrom= के बाद का मान यह बता देता है। DKIM वह हिस्सा है जिसे चालू करना पड़ता है।

• Google Workspace। जब तक आप अपने डोमेन के लिए DKIM चालू नहीं करते, Google अपने किसी डोमेन से हस्ताक्षर करता रहा है। Google के सहायता पेज का एक पुराना संस्करण कहता था कि तब Gmail “इस डिफ़ॉल्ट DKIM डोमेन कुंजी से: d=*.gappssmtp.com” हस्ताक्षर करता है। मौजूदा पेज अब डोमेन का नाम नहीं देता, इसलिए अपना हेडर जाँचें: gappssmtp.com पर ख़त्म होने वाला header.i बताता है कि आपकी कुंजी सक्रिय नहीं है। इसे Admin console में Apps, Google Workspace, Gmail, Authenticate email के तहत बनाएँ, वह जो TXT रिकॉर्ड दिखाए उसे जोड़ें, फिर Start authentication पर क्लिक करें (Set up DKIM)।
• Microsoft 365। अगस्त 2026 में अपडेट हुआ Microsoft का दस्तावेज़ कहता है: “फ़िलहाल कस्टम डोमेन से बाहर जाने वाले ईमेल पर कोई DKIM हस्ताक्षर नहीं होता”। आप दो CNAME रिकॉर्ड प्रकाशित करते हैं और Defender पोर्टल में हस्ताक्षर चालू करते हैं (How to use DKIM for email in your custom domain)।

DKIM कुंजी के लिए जो रिकॉर्ड आप जोड़ते हैं वह हमेशा _domainkey के नीचे होता है, उस नाम के तहत जो प्रदाता चुनता है। Google Workspace के लिए यह ऐसा दिखता है, कुंजी छोटी करके:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

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

संदेश फ़ॉरवर्ड किया गया

जब कोई प्राप्तकर्ता आपका ईमेल अपने आप फ़ॉरवर्ड करता है, तो वह ऐसे सर्वर से पहुँचता है जो आपके SPF रिकॉर्ड में नहीं है। SPF फ़ेल होता है या फ़ॉरवर्ड करने वाले के डोमेन के लिए पास होता है। DKIM हस्ताक्षर इस सफ़र में बचा रहता है, जब तक कोई संदेश को न बदले। जो मेलिंग लिस्ट फ़ुटर या विषय में टैग जोड़ती हैं वे हस्ताक्षर को भी तोड़ देती हैं। इसे आप अपनी तरफ़ से ठीक नहीं कर सकते। Google का भेजने वालों के लिए FAQ कहता है कि Gmail के लिए “फ़ॉरवर्ड किए गए या मेलिंग लिस्ट के संदेशों के लिए DMARC अलाइनमेंट ज़रूरी नहीं है”। यही कारण है कि DKIM को अलाइन रखें और केवल SPF के भरोसे न रहें।

यह आपका ईमेल नहीं है

अगर आपकी DMARC रिपोर्ट ऐसे सर्वरों से फ़ेल दिखाती हैं जिन्हें आपने कभी इस्तेमाल नहीं किया, तो हो सकता है कोई आपके पते से भेज रहा हो। उन संदेशों को फ़ेल ही होना चाहिए। कुछ ठीक करने की ज़रूरत नहीं है, और आगे चलकर सख़्त नीति के पक्ष में यही तर्क है।

पहले DKIM ठीक करें, फिर SPF

दोनों में से कोई भी आपको पास दिला देता है। DKIM रखना बेहतर है, क्योंकि वह संदेश के साथ चलता है। M3AAWG के सुझाए गए तरीक़े इसे नियम के रूप में कहते हैं: “बाहर जाने वाले सभी ईमेल पर ऐसी DKIM कुंजी से हस्ताक्षर करें जो RFC5322.From हेडर के डोमेन के साथ अलाइन हो।” RFC 9989 दोनों के इस्तेमाल की सलाह देता है।

1. वह सब कुछ गिनें जो आपके डोमेन के नाम से भेजता है। मेलबॉक्स, न्यूज़लेटर टूल, CRM, इनवॉइस, आपकी वेबसाइट का संपर्क फ़ॉर्म। जिन्हें आप भूल गए उनके नाम आपकी DMARC रिपोर्ट बता देती हैं।
2. हर एक को टेस्ट करें, ऊपर वाली हेडर जाँच से, और लिख लें कि दोनों में से कौन-सा डोमेन आपका नहीं है।
3. अपने डोमेन से हस्ताक्षर चालू करें, जहाँ भी header.i कोई और नाम दिखाए, और वे रिकॉर्ड प्रकाशित करें जो सेवा आपको देती है। अगर आपका DNS होस्ट स्वीकार करे तो 2048-बिट कुंजी चुनें। Gmail कम से कम 1024 बिट माँगता है और 2048 की सलाह देता है।
4. कस्टम बाउंस डोमेन सेट करें, जहाँ सेवा यह विकल्प देती हो, bounce.example.com जैसे सबडोमेन पर। इससे SPF भी अलाइन हो जाता है।
5. टेस्ट दोबारा भेजें और dmarc=pass ढूँढ़ें। DNS के बदलावों में कुछ समय लग सकता है। Google नई DKIM कुंजी के काम शुरू करने के लिए 48 घंटे तक का समय बताता है।

जो काम नहीं करता वह है विक्रेता को अपने रिकॉर्ड में जोड़ना। अगर Return-Path विक्रेता के डोमेन पर है, तो आपके SPF रिकॉर्ड में विक्रेता के लिए include: से कुछ नहीं बदलता, क्योंकि SPF उसी डोमेन का रिकॉर्ड देखता है, आपका नहीं। DMARC रिकॉर्ड भी भरोसेमंद तीसरे पक्षों की सूची नहीं दे सकता। मानक कहता है कि इसके लिए “कोई आम तौर पर स्वीकृत तरीक़ा नहीं” है।

अगर हेडर dmarc=pass दिखाता है और संदेश फिर भी स्पैम में पहुँचता है, तो कारण अब प्रमाणीकरण नहीं है। SPF, DKIM और DMARC पास, फिर भी ईमेल स्पैम में वहीं से आगे बढ़ता है।

p=none नीति के रहते फ़ेल होते DMARC की क़ीमत

p=none के साथ आप प्राप्त करने वाले सर्वरों से कहते हैं कि फ़ेल होने पर कोई कार्रवाई न करें, इसलिए आपकी नीति की वजह से कुछ अस्वीकार नहीं होता। फिर भी यह दो तरह से आपके ख़िलाफ़ जाता है।

• बड़े पैमाने पर भेजने वालों के नियम। Gmail, Yahoo और Outlook.com बड़े पैमाने पर भेजने वालों से अलाइन ईमेल माँगते हैं, जिसका मतलब Gmail और Outlook.com के लिए हर दिन 5,000 संदेशों से है। Google का भेजने वालों के लिए FAQ ऐसे ईमेल के लिए अस्थायी एरर 4.7.32 बताता है जिसका From हेडर “न प्रमाणित SPF के और न DKIM के organizational domain के साथ अलाइन है”, और नतीजे के तौर पर “अस्थायी या स्थायी विफलता के कोड, या स्पैम फ़ोल्डर में डालना” गिनाता है।
• यह अगला क़दम रोक देता है। जैसे ही आप p=quarantine या p=reject पर जाते हैं, आपके अपने हर बिना अलाइन वाले संदेश को स्पैम माना जाना है या अस्वीकार किया जाना है। Gmail में बाउंस में लिखा आता है “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy” (डोमेन की DMARC नीति के कारण domain-name का अप्रमाणित ईमेल स्वीकार नहीं किया जाता), एरर 5.7.26 (Troubleshoot DMARC issues)।

अगर आपके पास कोई DMARC रिकॉर्ड है ही नहीं, तो जोड़ने वाले रिकॉर्ड से शुरू करें। उससे वे रिपोर्ट भी चालू हो जाती हैं जो आपकी सभी भेजने वाली सेवाओं का अलाइनमेंट एक साथ दिखाती हैं।

यहाँ वॉर्मअप क्या कर सकता है और क्या नहीं

वॉर्मअप अलाइनमेंट को ठीक नहीं करता। WarmupBay आपके मेलबॉक्स से जुड़ता है और उसी से भेजता है, इसलिए उसके वॉर्मअप ईमेल आपका प्रदाता ठीक वैसे ही भेजता और हस्ताक्षरित करता है जैसे आपके ख़ुद लिखे ईमेल। अगर आपका मेलबॉक्स DMARC में फ़ेल होता है, तो वे भी उसके साथ फ़ेल होते हैं। पहले रिकॉर्ड ठीक करें।

WarmupBay उससे पहले और उसके बाद वाले हिस्से में मदद करता है। जब आप मेलबॉक्स जोड़ते हैं, वह डोमेन के SPF, DKIM और DMARC जाँचता है, और अगर वे 72 घंटे बाद भी गायब हों तो वॉर्मअप रोक देता है। उनके लग जाने के बाद आपका मेलबॉक्स साझा पूल के दूसरे मेलबॉक्स के साथ हर दिन कुछ ईमेल का आदान-प्रदान करता है, और डैशबोर्ड दिखाता है कि वे कहाँ पहुँचे: इनबॉक्स, कोई Gmail टैब, या स्पैम, Google और अन्य प्रदाताओं के लिए अलग-अलग। वह आपके न्यूज़लेटर टूल या CRM के ईमेल टेस्ट नहीं करता, क्योंकि वे कभी आपके मेलबॉक्स से होकर नहीं जाते, और वह अभी Microsoft 365 या Outlook.com के मेलबॉक्स नहीं जोड़ सकता। हर दिन 10 वॉर्मअप ईमेल के लिए यह मुफ़्त है। जब हेडर dmarc=pass दिखाए, तब अपना मेलबॉक्स जोड़ें।

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

SPF पास है और अलाइन है, DKIM अलाइन नहीं है। क्या यह काफ़ी है?

DMARC के लिए, हाँ। एक अलाइन पास काफ़ी है। यह तब काफ़ी नहीं रहता जब कोई प्राप्तकर्ता आपका ईमेल फ़ॉरवर्ड करता है, क्योंकि तब SPF मेल नहीं खाता। Google अपने भेजने वालों के लिए FAQ में यह भी लिखता है कि SPF और DKIM दोनों के साथ अलाइनमेंट आगे चलकर शायद अनिवार्य हो जाएगा, इसलिए अपने डोमेन के लिए DKIM फिर भी सेट करें।

DMARC कुछ प्राप्तकर्ताओं के लिए फ़ेल और कुछ के लिए पास क्यों होता है?

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

क्या Reply-To पते की DMARC में कोई भूमिका है?

नहीं। DMARC केवल From हेडर के डोमेन का इस्तेमाल करता है। Reply-To पता, दिखने वाला नाम और Sender हेडर जाँच का हिस्सा नहीं हैं।

हेडर खोले बिना अलाइनमेंट की समस्याएँ कैसे देखूँ?

DMARC की एग्रीगेट रिपोर्ट में। हर रिकॉर्ड में एक policy_evaluated ब्लॉक होता है जिसमें dkim और spf का नतीजा होता है; ये अलाइनमेंट की जाँच के बाद के नतीजे हैं। उसके नीचे का auth_results ब्लॉक कच्चे नतीजे और वे डोमेन दिखाता है जिनके लिए वे थे। कच्चा pass और उसके साथ जाँच के बाद का fail ठीक वही मामला है जिसके बारे में यह पेज है। रिपोर्ट आपको अपने DMARC रिकॉर्ड में rua पता जोड़ने पर मिलती हैं।

हेडर में dkim=fail या dkim=neutral लिखा है। क्या यह वही समस्या है?

नहीं। तब हस्ताक्षर ही सत्यापित नहीं हुआ, जो एक अलग गड़बड़ी है। अगर टेक्स्ट में body hash did not verify लिखा है, तो Google का समस्या-निवारण पेज कारण बताता है: संदेश हस्ताक्षर के बाद बदला गया, उदाहरण के लिए किसी गेटवे ने फ़ुटर जोड़ दिया। अलाइनमेंट ऐसे हस्ताक्षर के बारे में है जो मान्य है पर किसी दूसरे डोमेन का है।

क्या मुझे अपनी ओर से भेजने वाली हर सेवा के लिए अलग DKIM कुंजी चाहिए?

व्यवहार में, हाँ। हर सेवा अपनी कुंजी से हस्ताक्षर करती है और उसे आपके डोमेन पर _domainkey के नीचे अपने सिलेक्टर नाम के तहत प्रकाशित करती है, इसलिए कई कुंजियाँ बिना टकराव के साथ-साथ रहती हैं। यह SPF से अलग है, जहाँ एक डोमेन का केवल एक रिकॉर्ड हो सकता है।

स्रोत

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. RFC 7208: Sender Policy Framework (SPF)
4. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
5. RFC 8601: Message Header Field for Indicating Message Authentication Status
6. Email sender guidelines – Gmail Help
7. Email sender guidelines FAQ – Gmail Help
8. Set up DMARC – Google Workspace Help
9. Set up DKIM – Google Workspace Help
10. Troubleshoot DMARC issues – Google Workspace Help
11. Troubleshoot DKIM issues – Google Workspace Help
12. Trace an email with its full header – Gmail Help
13. Check if your Gmail message is authenticated – Gmail Help
14. Set up DKIM to prevent email spoofing – Google Workspace Admin Help, archived version of 30 June 2021
15. How to use DKIM for email in your custom domain – Microsoft Learn
16. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
17. Sender Best Practices – Yahoo Sender Hub
18. Configure domain authentication – Twilio SendGrid Docs
19. Complying with DMARC authentication protocol in Amazon SES – AWS Documentation
20. Using a custom MAIL FROM domain – Amazon SES, AWS Documentation
21. About Email Domain Authentication – Mailchimp Help
22. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)