راهنما · DMARC در Cloudflare
یک تیم محصول چگونه باید DMARC را بهصورت امن در Cloudflare پیاده‌سازی کند؟
برای پیکربندی DMARC در Cloudflare، همه سرویس‌هایی را که با دامنه‌های From قابلمشاهده شما ایمیل ارسال می‌کنند فهرست کنید، هم‌راستایی SPF یا DKIM را روی پیام‌های کنترل‌شده بررسی کنید و یک سیاست TXT در نام دقیق _dmarc اضافه کنید. با گزارش‌گیری شروع کنید، وضعیت قبلی DNS را نگه دارید، پاسخ‌های authoritative و recursive را اعتبارسنجی کنید و پیش از درخواست quarantine یا reject گزارش‌های تجمیعی را بررسی کنید. Cloudflare سیاست DNS را میزبانی یا تحلیل میکند؛ اما فرستنده را همراستا نمیکند و تحویل را هم ثابت نمیکند.
DNS در Cloudflare را از پیکربندی فرستنده جدا کنید
Cloudflare میتواند DNS authoritative را اداره کند، در حالی که ارائهدهنده دیگری ایمیل‌های برنامه را ارسال و امضا میکند. پیش از هر ویرایشی این مرزها را ثبت کنید. zone سیاست TXT مربوط به DMARC را منتشر میکند؛ هر ارائهدهنده ایمیل return path، دامنه امضای DKIM و selector، تأیید و گاهی گزارش‌دهی خود را کنترل میکند؛ و برنامه، tenant، نوع پیام، گیرنده، قالب، نشانی From قابلمشاهده و مسیر ارائهدهنده را کنترل میکند. یک رکورد DNS معتبر نمی‌تواند فرستنده غیرمجاز، امضای DKIM ناموجود، return path ناهم‌راستا یا مقدار From متعلق به tenant دیگر را اصلاح کند. سیستم‌های production، staging، پشتیبانی، صورتحساب، هویت، پایش، CRM، بازاریابی و ایمیل انسانی را بر اساس دامنه From قابلمشاهده فهرست کنید. برای هر کدام یک مالک و یک مسئول بازگشت تعیین کنید و پیش از افزایش سطح اعمال سیاست، منابع ناشناخته در گزارش‌ها را دسته‌بندی کنید.
نام سیاستی را که گیرندگان ارزیابی می‌کنند کوئری کنید
برای ایمیل از alerts@notify.example.test، با رکورد TXT در _dmarc.notify.example.test شروع کنید. سیاست را اشتباهاً در نام میزبان وب‌سایت، mail exchanger، selector مربوط به DKIM یا نام return-path منتشر نکنید. روش فعلی کشف DMARC میتواند وقتی دامنه نویسنده رکورد معتبری ندارد، یک سیاست قابل‌اعمال در سطح دامنه سازمانی یا public suffix را انتخاب کند؛ بنابراین هم نام کوئری‌شده و هم دامنه سیاست انتخاب‌شده را ثبت کنید. پیش از باز کردن Cloudflare، پاسخ‌های authoritative و recursive موجود را کوئری کنید. وجود چند رکورد سیاست در یک نام، سینتکس نادرست تگ‌ها یا یک CNAME متعارض میتواند نتیجه را غیرقابل‌استفاده کند. محتوای قبلی، TTL، خروجی resolver، مالک و مقدار موردانتظار پس از تغییر را ثبت کنید تا بازگشت دقیق باشد و نه اینکه در میانه یک حادثه بازسازی شود.
یک رکورد TXT بازبینی‌شده در Cloudflare ایجاد کنید
حساب و zone درست را در Cloudflare باز کنید، به DNS Records بروید، Add record را انتخاب کنید و نوع TXT را برگزینید. برای سیاست روی apex، از _dmarc به‌عنوان نام نسبی استفاده کنید یا برای زیردامنه موردنظر، برچسب دقیق _dmarc را وارد کنید. یک مقدار بازبینی‌شده را بدون علامت‌های نقلقول ناهماهنگ وارد کنید؛ Cloudflare مستند کرده است که به محتوای TXT جدیدی که بدون نقلقول ذخیره شود، نقلقولهای دربرگیرنده اضافه میکند. TTL را متناسب با روند انتشار و بازیابی انتخاب کنید، در صورت لزوم یک ارجاع تغییر بدون اطلاعات حساس اضافه کنید و فقط پس از بررسی zone، نام، مقدار قبلی و مقدار جدید ذخیره کنید. سیاست‌های TXT داده DNS هستند، نه مسیرهای وب پراکسی‌شده. اگر یک شریک میزبانی یا ارائهدهنده authoritative دیگری zone را مدیریت میکند، تغییر را همان‌جا انجام دهید و فرض نکنید داشبورد Cloudflare مرجع authoritative است.
مقدار DMARC را بر اساس تصمیم‌های صریح بسازید
رکورد مرحله مشاهده میتواند با v=DMARC1; p=none و یک URI تأییدشده برای گزارش‌های تجمیعی شروع شود، اما این فقط یک مثال است و مقداری همگانی نیست. نسخه را اول بگذارید، سیاست درخواستی را آگاهانه تعیین کنید و هر مقصد گزارش را مجاز کنید. سیاست زیردامنه، حالت هم‌راستایی، درصد و تگ‌های گزارش‌دهی را فقط زمانی بازبینی کنید که یک الزام مستند و تفسیر به‌روزی از استاندارد وجود داشته باشد. نمونه یک فروشنده را که صندوق rua شخص دیگری در آن است کپی نکنید و صرفاً چون سینتکس معتبر است به p=reject نپرید. یک رکورد معتبر، نحوه برخورد درخواستی از گیرنده را بیان میکند؛ ثابت نمیکند که SPF یا DKIM احراز هویت می‌کنند، هیچ‌یک از شناسه‌های احرازهویتشده با دامنه From هم‌راستاست، همه مسیرهای ارسال مشروع فهرست شده‌اند یا اینکه پیامی به صندوق ورودی رسیده است.
هم‌راستایی SPF و DKIM را روی پیام‌های واقعی بررسی کنید
از هر مسیر برنامه، نمونه‌های کنترل‌شده به گیرندگانی ارسال کنید که بتوانید هدرهای خام آن‌ها را بررسی کنید. From قابلمشاهده، SMTP MAIL FROM، IP ارسال، دامنه d= و selector در DKIM، Authentication-Results، شناسه ارائهدهنده، نوع پیام، محیط و زمان را ثبت کنید. DMARC میتواند با SPF احرازهویتشده و همراستا یا با یک امضای DKIM تأییدشده و همراستا موفق شود. SPF یک هویت SMTP را ارزیابی میکند و ممکن است در forwarding تغییر کند؛ DKIM امضایی را روی محتوای انتخاب‌شده تأیید میکند. هیچ‌کدام جایگزین مجوزدهی در سطح برنامه نیست. هم‌راستایی relaxed یا strict را آگاهانه آزمایش کنید، از جمله زیردامنه‌ها و مسیرهای failover. پذیرش توسط API ارائهدهنده، پذیرش توسط سرور مقصد، موفقیت DMARC، قرار گرفتن در صندوق و تعامل کاربر مشاهدات متفاوتی هستند. این وضعیت‌ها را جدا نگه دارید تا یک فراخوانی موفق API یا نشانگر سبز سیاست هرگز به‌عنوان شاهد قوی‌تری از تحویل تلقی نشود.
DNS و گزارش‌ها را بیرون از داشبورد اعتبارسنجی کنید
پس از ذخیره، رکورد TXT در نام دقیق _dmarc را از name serverهای authoritative در Cloudflare و از چند resolver بازگشتی مستقل کوئری کنید. پاسخ‌های خام، دامنه سیاست انتخاب‌شده، TTL، resolver، زمان و نتیجه parser را ذخیره کنید. تأیید کنید که دقیقاً یک رکورد قابل‌استفاده وجود دارد، v=DMARC1 در ابتدای آن است، مقادیر الزامی معتبرند و URIهای گزارش تأییدشده‌اند. پس از پایان بازه کش موردانتظار، این کار را تکرار کنید. دوباره پیام‌های کنترل‌شده ارسال کنید و هدرهای گیرنده را بررسی کنید. Cloudflare قابلیت DMARC Management را راهی برای مشاهده منابع ارسال و نتایج تجمیعی SPF، DKIM و DMARC معرفی میکند، اما گزارش‌ها مشاهداتی با تأخیر هستند که گیرندگان ارائه می‌دهند، نه سرشماری کامل و زنده. آن‌ها را با شواهد ارائهدهنده تطبیق دهید. در صورت اختلاف resolverها، نبود ترافیک کم‌تکرار، منابع مشروع ناشناخته، پیام‌های کنترل‌شده ناهم‌راستا یا تغییرات غیرمنتظره در حجم گزارش‌ها، کار را متوقف کنید.
DMARC Management در Cloudflare را یک تغییر DNS در نظر بگیرید
Cloudflare میگوید فعال کردن DMARC Management ممکن است در صورت نبود رکورد، ایجاد آن را پیشنهاد دهد یا یک نشانی گزارش تجمیعی Cloudflare را به تگ rua موجود اضافه کند. این تغییر پیشنهادی را مانند زیرساخت production بازبینی کنید: مقدار قبلی را خروجی بگیرید، مطمئن شوید مقصدهای موجود همچنان آگاهانه‌اند، محدوده دامنه را تأیید کنید و امکان بازگشت را حفظ کنید. مستندات فعالسازی آن همچنین محدوده فعلی دامنه apex و یک نکته احتیاطی درباره رکورد SPF خارجی را شرح می‌دهد. نتیجه نگیرید که این قابلیت میتواند مسیر SPF میزبانی‌شده در جای دیگر را بهصورت امن بازنویسی کند. وجود یک منبع یا IP در فهرست ثابت نمیکند کدام برنامه، tenant یا شخص آن را مجاز کرده است، و نبود یک ردیف هم ثابت نمیکند که ترافیکی وجود ندارد. از این نما برای جمع‌آوری شواهد استفاده کنید و در عین حال شواهد DNS authoritative، پیام خام، لاگ ارائهدهنده و ممیزی برنامه را حفظ کنید.
سطح اعمال سیاست را با شواهد مرحله‌به‌مرحله افزایش دهید
آن‌قدر مشاهده کنید که همه فرستندگان مشروع، انواع پیام، الگوهای روزهای هفته، jobهای دسته‌ای، مسیرهای failover و گردش‌کارهای کم‌تکرار پوشش داده شوند. منابع را بهصورت متعلق به خودتان، فروشنده تأییدشده، forwardشده، ناشناخته یا سوءاستفاده‌گر دسته‌بندی کنید. پیش از درخواست برخورد سخت‌گیرانه‌تر، هم‌راستایی ترافیک مشروع را اصلاح کنید. دروازه تصمیم go/no-go باید شامل DNS معتبر، موفقیت پیام‌های کنترل‌شده، پوشش همراستای قابل‌قبول، نبود منابع مشروع ناشناخته، مالکیت حوادث، آمادگی پشتیبانی و بازگشت آزموده‌شده باشد. سیاست را فقط از طریق یک تغییر محدود و تأییدشده افزایش دهید و هم خطاهای احراز هویت و هم خطاهای کسب‌وکار را پایش کنید. در صورت رد شدن پیام‌های مشروع، از دست رفتن گزارش‌ها، منابع غیرمنتظره، ناهماهنگی resolverها، مهاجرت ارائهدهنده یا رفتار غیرمنتظره در به ارث رسیدن سیاست زیردامنه، تغییر را برگردانید یا متوقف کنید. در صورت امکان SPF، DKIM و DMARC را جداگانه تغییر دهید تا علت هر پسرفت روشن بماند.
از خطاهای رایج DMARC در Cloudflare پرهیز کنید
خطاهای رایج شامل ویرایش zone اشتباه، انتشار در نام _dmarc نادرست، باقی گذاشتن دو رکورد سیاست، افزودن علامت‌های نقلقول خراب، جایگزین کردن فهرست rua تأییدشده، فرض یکسان بودن سیاست apex و زیردامنه، و استفاده از p=reject پیش از ظاهر شدن فرستندگان کم‌تکرار است. اشتباه دیگر این است که وضعیت ذخیره‌شده یا شناسایی‌شده در داشبورد را اثباتی در سطح پیام بدانید. از diffهای دقیق، گیرندگان کنترل‌شده، کوئری‌های مستقل، هدرهای خام و لاگ‌های حادثه محدود به گیرنده استفاده کنید. نشانی‌های مشتریان، بدنه پیام‌ها، کلیدهای API و داده‌های گزارش بدون محدودیت را از تیکت‌ها و analytics دور نگه دارید. اگر پاسخ‌های authoritative و کش‌شده فراتر از برنامه ناهماهنگ ماندند، یک فرستنده موردانتظار دیده نشد یا یک پیام واقعی در هم‌راستایی رد شد، کار را متوقف کنید و delegation، کش، سینتکس رکورد، فهرست فرستندگان، SPF و DKIM را جداگانه عیب‌یابی کنید.
SendHQ چگونه جای میگیرد
مرز امن، مستقل از ارائهدهنده است: اپلیکیشن یک پیام را مجاز میکند، ارائهدهنده ارسال آن را احراز هویت میکند، Cloudflare وضعیت DNS را منتشر یا تحلیل میکند و گیرندگان پیام را ارزیابی می‌کنند. به مستندات رسمی کنونی Cloudflare، استاندارد کنونی DMARC، پاسخ‌های مشاهده‌شده DNS و شواهد کنترل‌شده پیام دریافت‌شده تکیه کنید.
پرسش‌های متداول
سیاست DMARC دامنه apex در Cloudflare در چه نامی قرار میگیرد؟
رکورد TXT را در _dmarc برای zone ایجاد کنید که بهصورت _dmarc.example.com resolve میشود. برای هویت From روی زیردامنه، همان دامنه نویسنده و قواعد فعلی کشف را ارزیابی کنید.
آیا مقدار TXT باید نقلقول دستی داشته باشد؟
Cloudflare میگوید محتوای TXT جدیدی که بدون نقلقول ذخیره شود، بهطور خودکار داخل نقلقول قرار میگیرد. از نقلقولهای دستی ناهماهنگ پرهیز کنید و سپس پاسخ خام authoritative و نتیجه parser را بررسی کنید.
آیا Cloudflare رکورد TXT مربوط به DMARC را پراکسی میکند؟
برای این سیاست TXT هیچ تصمیمی درباره پراکسی HTTP مطرح نیست. آن را در DNS authoritative منتشر کنید و از بیرون اعتبارسنجی کنید؛ رفتار پراکسی وب کارکرد دیگری است.
آیا DMARC Management میتواند رکورد را تغییر دهد؟
مستندات فعالسازی Cloudflare میگوید ممکن است افزودن یک رکورد یا یک مقصد rua متعلق به Cloudflare را پیشنهاد دهد. این تغییر را بهصراحت بازبینی کنید، وضعیت قبلی را حفظ کنید، نتیجه را تأیید کنید و در صورت نیاز آن را برگردانید.
آیا p=none ایمیل‌های ناموفق را رد میکند؟
خیر. این یک سیاست درخواستی با هدف مشاهده است. پیش از در نظر گرفتن درخواست سخت‌گیرانه‌تر از گیرنده، فرستندگان مشروع را با کمک گزارش‌ها و پیام‌های کنترل‌شده فهرست و اصلاح کنید.
آیا موفقیت DMARC رسیدن به صندوق ورودی را ثابت میکند؟
خیر. فقط ثابت میکند که ارزیابی احراز هویت همراستای مربوط موفق بوده است. پذیرش توسط ارائهدهنده، پذیرش توسط گیرنده، پوشه مقصد و تعامل کاربر هر کدام به شواهد جداگانه و مشخص نیاز دارند.
چرا ممکن است SPF موفق شود ولی DMARC رد شود؟
ممکن است هویت SMTP احرازهویتشده با دامنه From قابلمشاهده همراستا نباشد یا خطای ارزیابی دیگری رخ داده باشد. هویتهای دقیق و نتایج خام گیرنده را بررسی کنید.
آیا رکورد DMARC یک یکپارچهسازی ارائهدهنده ایمیل را اثبات میکند؟
خیر. رکورد DMARC بهتنهایی یک یکپارچهسازی ارائهدهنده ایمیل را اثبات نمیکند.
منابع
- مدیریت رکوردهای DNS — Cloudflare
- انواع رکوردهای DNS در Cloudflare — Cloudflare
- مروری بر DMARC Management در Cloudflare — Cloudflare
- فعالسازی DMARC Management در Cloudflare — Cloudflare
- بررسی آمار DMARC در Cloudflare — Cloudflare
- RFC 9989: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
- RFC 7208: چارچوب سیاست فرستنده (SPF) — RFC Editor
- RFC 6376: امضاهای DomainKeys Identified Mail (DKIM) — RFC Editor