DMARC با p=none در برابر quarantine و reject: راهنمای عملیاتی

بده‌بستان اصلی

انتخاب سیاست DMARC انتخابی میان دیدپذیری و اعمال سیاست است. p=none بدون اثر بر تحویل، امکان پایش را فراهم می‌کند. p=quarantine ایمیل‌های مشکوک را به پوشه اسپم می‌فرستد. p=reject ایمیل‌های احراز هویت‌نشده را به‌طور کامل مسدود می‌کند. امن‌ترین مسیر، استقرار مرحله‌ای است: با none شروع کنید تا همه فرستندگان مشروع را شناسایی کنید، سپس به quarantine بروید تا اثر آن را بسنجید و در نهایت به reject برسید تا دامنه‌تان به‌طور کامل در برابر جعل ایمیل ایمن شود.

چرا سیاست DMARC برای صف رخدادها اهمیت دارد

به‌عنوان مهندسی که مسئول تحویل‌پذیری است، هدف اصلی شما این است که ایمیل‌های تراکنشی مشروع به گیرنده برسند و در عین حال مهاجمان نتوانند از دامنه شما استفاده کنند. اگر بدون دوره پایش مستقیماً سراغ p=reject بروید، به احتمال زیاد وقتی یک سیستم قدیمی فراموش‌شده یا ابزار بازاریابی شخص ثالث ناگهان از تحویل ایمیل بازمی‌ماند، با یک رخداد با اولویت بالا روبه‌رو خواهید شد.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) به هم‌راستایی SPF و DKIM متکی است. اگر پیامی در هر دو رد شود، تگ p= دقیقاً به سرور ایمیل گیرنده می‌گوید با آن پیام چه کند.

سه سطح سیاست

1. p=none (حالت پایش)

در این حالت، گیرنده صرف‌نظر از نتیجه احراز هویت هیچ اقدامی روی پیام انجام نمی‌دهد. این حالت صرفاً برای جمع‌آوری داده است.

چه زمانی از آن استفاده کنیم:

• راه‌اندازی اولیه DMARC.
• وقتی از همه سرویس‌هایی که از طرف شما ایمیل می‌فرستند مطمئن نیستید.
• در حین مهاجرت به یک API ایمیل جدید.

payload:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

بده‌بستان: هیچ محافظتی در برابر جعل ایمیل ندارید. مهاجمان همچنان می‌توانند به نام دامنه شما ایمیل بفرستند، اما آن را در گزارش‌های RUA (تجمیعی) خود خواهید دید.

2. p=quarantine (اعمال نرم)

پیام‌هایی که در DMARC رد می‌شوند مشکوک تلقی می‌شوند. بیشتر گیرنده‌ها آن‌ها را به پوشه اسپم یا Junk منتقل می‌کنند.

چه زمانی از آن استفاده کنیم:

• پس از آنکه گزارش‌های p=none را تحلیل کردید و مطمئن شدید همه جریان‌های مشروع هم‌راستا هستند.
• به‌عنوان یک لایه ایمنی پیش از رفتن به رد کامل.

payload:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

بده‌بستان: دیده شدن ایمیل‌های جعلی را کاهش می‌دهد اما آن را از بین نمی‌برد. اگر کلیدهای DKIM شما به‌اشتباه چرخانده شوند یا رکوردهای SPF به محدودیت 10 lookup در DNS برسند، ممکن است برخی ایمیل‌های مشروع همچنان در اسپم قرار بگیرند.

3. p=reject (اعمال کامل)

این استاندارد طلایی امنیت دامنه است. اگر پیامی در DMARC رد شود، سرور گیرنده به‌کلی از پذیرش آن خودداری می‌کند.

چه زمانی از آن استفاده کنیم:

• وقتی پایش شما هم‌راستایی 99.9% را برای همه ترافیک مشروع نشان می‌دهد.
• وقتی خطر جعل دامنه از خطر شکست گاه‌به‌گاه تحویل بیشتر است.

payload:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

بده‌بستان: هیچ تور ایمنی وجود ندارد. اگر یک سیستم حیاتی اشتباه پیکربندی شده باشد، ایمیل از دست می‌رود. این شکست‌ها را در گزارش‌های RUA می‌بینید، اما کاربر هرگز ایمیل را دریافت نمی‌کند.

چک‌لیست استقرار برای اپراتورها

سیاست‌ها را بر اساس حس تغییر ندهید؛ بر اساس داده‌های گزارش‌های تجمیعی تغییر دهید. پیش از هر تغییر، با ابزاری مانند بررسی DNS ایمیل SendHQ مطمئن شوید رکوردهایتان به‌درستی منتشر شده‌اند.

مرحله 1: شناسایی (p=none)

1. p=none را همراه با یک نشانی rua منتشر کنید.
2. 7 تا 14 روز صبر کنید تا یک چرخه کامل کسب‌وکار از ایمیل‌ها (از جمله گزارش‌های هفتگی) ثبت شود.
3. گزارش‌ها را برای یافتن ترافیک «ناهم‌راستا» تحلیل کنید.
4. فرستندگان شخص ثالث مشروع (مثلاً Zendesk، Salesforce، Shopify) را شناسایی کنید.
5. برای هر فرستنده شناسایی‌شده DKIM را پیکربندی کنید. این مطمئن‌ترین راه برای تضمین هم‌راستایی است.

مرحله 2: آزمایش (p=quarantine)

1. سیاست را به p=quarantine تغییر دهید.
2. تیکت‌های پشتیبانی را برای پیام‌هایی مانند «ایمیل به دستم نرسید» یا «ایمیل در اسپم است» زیر نظر بگیرید.
3. گزارش‌های RUA را برای هرگونه جهش تازه در شکست‌ها بررسی کنید.
4. اگر شکستی رخ داد، احراز هویت را اصلاح کنید و یک هفته دیگر در quarantine بمانید.

مرحله 3: سخت‌سازی (p=reject)

1. سیاست را به p=reject تغییر دهید.
2. مطمئن شوید حیاتی‌ترین جریان‌های تراکنشی شما (بازنشانی رمز عبور، فاکتورها) همچنان تحویل داده می‌شوند.
3. پایش را ادامه دهید. DMARC پیکربندی‌ای نیست که یک بار تنظیم و فراموش شود.

ایمیل به‌عنوان یک اثر جانبی

برای مهندسان محصولی که ایجنت‌های هوش مصنوعی یا گردش‌کارهای خودکار می‌سازند، ارسال ایمیل یک اثر جانبی خارجی است. یعنی ممکن است به دلایلی خارج از منطق برنامه شما (مشکلات DNS، رد شدن توسط DMARC، محدودیت نرخ) شکست بخورد.

idempotency و تأیید

وقتی یک ایجنت هوش مصنوعی ایمیلی را راه می‌اندازد، باید از ارسال تکراری هنگام تلاش مجدد جلوگیری کنید. در درخواست‌های API خود از یک کلید idempotency استفاده کنید تا یک timeout شبکه باعث نشود مشتری یک ایمیل را پنج بار دریافت کند.

علاوه بر این، ایجنت‌ها نباید اجازه خودکار برای ارسال ایمیل‌های حساس و پرریسک داشته باشند. برای محتوای تولیدشده توسط ایجنت یک صف تأیید پیاده‌سازی کنید تا مطمئن شوید نشانی «From» و محتوا با برند و سیاست‌های احراز هویت شما هم‌خوانی دارند.

هزینه زیرساخت تحویل

انتخاب ارائه‌دهنده ارسال بر نحوه مدیریت DMARC اثر می‌گذارد. برخی ارائه‌دهندگان راه‌اندازی DKIM را بسیار ساده می‌کنند، در حالی که برخی دیگر برای هر زیردامنه ورودی‌های دستی DNS لازم دارند.

هنگام ارزیابی هزینه‌ها، هزینه کل مالکیت را در نظر بگیرید. برای مثال، ارسال 50,000 ایمیل روی Amazon SES با پرداخت به‌ازای مصرف (با نرخ 0.10 USD برای هر 1,000 ایمیل) حدود 5 USD هزینه دارد، در حالی که پلن‌های Postmark برای همین حجم حدود 66 USD هزینه دارند (15 USD برای 10,000 ایمیل به‌علاوه مصرف مازاد بین 1.20 تا 1.80 USD برای هر 1,000 ایمیل).

گزینه‌های دیگر شامل Resend است که پلن رایگانی با 3,000 ایمیل در ماه (با سقف 100 ایمیل در روز) ارائه می‌دهد، یا Mailgun که از 15 USD در ماه برای 10,000 ایمیل شروع می‌شود. SendGrid اکنون برای پلن رایگان خود یک دوره آزمایشی 60 روزه دارد و پلن Essentials آن از 19.95 USD در ماه شروع می‌شود.

صرف‌نظر از ارائه‌دهنده، سیاست DMARC سپر اصلی دامنه شما باقی می‌ماند. اگر از ارائه‌دهنده‌ای استفاده کنید که فقط SPF را پشتیبانی می‌کند، هنگام رفتن به p=reject در معرض خطر بیشتری برای شکست تحویل هستید، چون SPF در فوروارد ایمیل می‌شکند. DKIM تنها راه حفظ هم‌راستایی در فورواردهاست.

حالت‌های رایج شکست

تله فوروارد

کاربر A ایمیلی به کاربر B می‌فرستد. کاربر B فوروارد خودکار به کاربر C دارد. سرور فورواردکننده اغلب فرستنده envelope را به دامنه خودش تغییر می‌دهد تا به‌عنوان اسپم علامت‌گذاری نشود. این کار هم‌راستایی SPF را می‌شکند. اگر p=reject داشته باشید و امضای DKIM نداشته باشید، کاربر C هرگز آن ایمیل را نخواهد دید.

محدودیت lookup در DNS

رکوردهای SPF به 10 lookup در DNS محدودند. اگر ارائه‌دهندگان زیادی به رکورد SPF خود اضافه کنید، گیرنده permerror برمی‌گرداند. این باعث شکست DMARC می‌شود. برای حل آن، از ارائه‌دهنده‌ای استفاده کنید که احراز هویت با اولویت DKIM را تشویق می‌کند، یا از SPF flattening بهره بگیرید.

مشکل «Shadow IT»

تیم‌های بازاریابی اغلب بدون اطلاع تیم مهندسی در ابزارهای جدید (مثلاً یک سرویس خبرنامه تازه) ثبت‌نام می‌کنند. آن‌ها از دامنه شما ایمیل می‌فرستند، ایمیل در DMARC رد می‌شود و پس زده می‌شود. به همین دلیل مرحله p=none غیرقابل‌چشم‌پوشی است.

جدول خلاصه برای اپراتورها

سیاست | اقدام | ریسک | دیدپذیری | کاربرد پیشنهادی

p=none | هیچ | کم | زیاد | شناسایی و ممیزی

p=quarantine | پوشه اسپم | متوسط | زیاد | آزمایش و گذار

p=reject | مسدود | زیاد | متوسط | امنیت کامل محیط عملیاتی

برای بررسی عمیق‌تر پیاده‌سازی فنی این رکوردها، راهنمای ما درباره DKIM، SPF و DMARC را ببینید.

مدیریت دستی این رکوردها خسته‌کننده است. SendHQ با ارائه ارسال تراکنشی از دامنه‌های تأییدشده و ابزارهایی برای آماده‌سازی زیرساخت شما برای ایجنت‌ها، این کار را ساده می‌کند.

اطلاعات بیشتر در https://sendhq.cc.