مرجع کامل تگ‌های رکورد DMARC و مقدار مجاز هرکدام

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

۶ دقیقه به‌روزرسانی ۹ آبان ۱۴۰۵

رکورد DMARC را تنظیم کرده‌اید، گزارش‌ها هم می‌آید، اما نمی‌دانید چرا p=none هیچ ایمیلی را متوقف نمی‌کند یا چرا با p=reject ناگهان فرم تماس سایت‌تان ایمیل نمی‌فرستد. مشکل تقریباً همیشه در مقدار یک تگ است، نه در کل رکورد. این متن مرجع کوتاه هر تگ است: مقدار مجاز، اثر واقعی، و ترکیبی که بدون شکستن ایمیل می‌شود روی آن رفت.

رکورد DMARC یک رکورد TXT روی _dmarc.example.com است و با v=DMARC1 شروع می‌شود. ترتیب تگ‌ها مهم نیست، اما v باید اولین باشد. اگر با dig چک می‌کنید:

dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

اگر خروجی خالی بود، رکورد وجود ندارد یا روی نام اشتباه ثبت شده. یک اشتباه رایج ثبت روی example.com به‌جای _dmarc.example.com است که هیچ ابزاری آن را نمی‌بیند.

تگ p: سیاستی که واقعاً اعمال می‌شود

سه مقدار مجاز دارد: none، quarantine، reject. این تگ تعیین می‌کند گیرنده با ایمیلی که SPF و DKIM هر دو شکست خورده چه کند. none یعنی فقط گزارش بده و کاری نکن؛ quarantine یعنی بفرست به اسپم؛ reject یعنی اصلاً تحویل نده.

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

ترتیب مهاجرت عملی: دو تا چهار هفته روی p=none بمانید، گزارش‌ها را بخوانید، منابع مجاز را در SPF و DKIM تثبیت کنید، بعد p=quarantine و در نهایت p=reject. اگر می‌خواهید بدانید چرا ایمیل‌ها به اسپم می‌روند، راهنمای کامل رفع مشکل اسپم دقیقاً همین زنجیره را باز می‌کند.

تگ‌های rua و ruf: گزارش‌ها کجا می‌روند

rua آدرس گزارش تجمیعی است (XML روزانه) و ruf گزارش forensic (نمونه پیام شکست‌خورده). هر دو با mailto: شروع می‌شوند و با کاما جدا می‌شوند. محدودیت عملی: بسیاری از گیرندگان بزرگ، از جمله Gmail، گزارش ruf نمی‌فرستند. اگر فقط به ruf تکیه کنید، صندوق‌تان خالی می‌ماند و فکر می‌کنید رکورد کار نمی‌کند.

حجم گزارش rua را دست‌کم نگیرید. برای دامنه‌ای با چند هزار ایمیل روزانه، فایل XML روزانه به چند مگابایت می‌رسد و اگر آدرس را روی صندوق شخصی بگذارید، سهمیه صندوق در چند روز پر می‌شود. مدیریت سهمیه ایمیل توضیح می‌دهد وقتی صندوق پر شد چه اتفاقی می‌افتد و چطور جلوی آن را بگیرید. راه درست، یک صندوق اختصاصی یا سرویس تحلیل DMARC است.

این‌جا اشتباه می‌کنند

آدرس rua را روی همان دامنه‌ای می‌گذارند که DMARC برایش تنظیم شده، بدون اینکه مطمئن شوند آن صندوق وجود دارد. نتیجه: گزارش‌ها بی‌صدا دور ریخته می‌شوند، هیچ خطایی هم دیده نمی‌شود. علامتش این است که هفته‌ها منتظر گزارش می‌مانید و هیچ‌وقت نمی‌رسد، در حالی که رکورد کاملاً معتبر است.

تگ‌های pct، fo و rf

pct درصد پیام‌هایی است که سیاست روی آن‌ها اعمال می‌شود؛ مقدار مجاز ۰ تا ۱۰۰. پیش‌فرض ۱۰۰ است. اگر pct=25 بگذارید، فقط یک‌چهارم ایمیل‌های شکست‌خورده طبق سیاست رفتار می‌شوند. این تگ برای مهاجرت تدریجی ساخته شده، اما در عمل بیشتر باعث سردرگمی می‌شود تا امنیت. توصیه من: از pct استفاده نکنید و به‌جایش مستقیم از p=none به p=reject بروید.

fo تعیین می‌کند در چه شرایطی گزارش forensic بفرست: 0 (هر دو شکست)، 1 (هر کدام شکست)، d (DKIM شکست)، s (SPF شکست). مقدار 1 بیشترین گزارش را می‌دهد و برای عیب‌یابی مفید است. rf قالب گزارش است و امروز فقط afrf معنا دارد؛ گذاشتنش اختیاری است.

تگ‌های adkim و aspf: حالت سخت‌گیرانه

هر دو مقدار r (relaxed، پیش‌فرض) یا s (strict) می‌گیرند. adkim برای DKIM و aspf برای SPF. تفاوت در هم‌ترازی دامنه است: در حالت relaxed، زیردامنه‌ها هم قبول می‌شوند؛ در strict فقط دامنه دقیق.

تگمقدار مجازپیش‌فرضاثر عملی
vDMARC1الزامینسخه رکورد؛ باید اول باشد
pnone / quarantine / reject—سیاست برای دامنه اصلی
spهمان مقادیر pبرابر pسیاست جدا برای زیردامنه‌ها
ruaلیست mailto:—گزارش تجمیعی روزانه
rufلیست mailto:—گزارش forensic؛ پشتیبانی محدود
pct0–100100درصد اعمال سیاست
adkimr / srهم‌ترازی DKIM
aspfr / srهم‌ترازی SPF
fo0 / 1 / d / s0شرط ارسال گزارش forensic

حالت strict را فقط وقتی انتخاب کنید که کنترل کامل روی همه منابع ارسال دارید. اگر از یک سرویس ایمیل تراکنشی استفاده می‌کنید که روی زیردامنه ارسال می‌کند، aspf=s بی‌دلیل ایمیل‌هایتان را رد می‌کند. راهنمای ایمیل تراکنشی توضیح می‌دهد چرا فرستادن از هاست اشتراکی مشکل‌ساز است و جایگزین درست چیست.

تگ sp و مدیریت زیردامنه‌ها

اگر sp نگذارید، مقدار p برای زیردامنه‌ها هم اعمال می‌شود. این پیش‌فرض در بسیاری از سازمان‌ها فاجعه است: زیردامنه‌ای که هیچ‌وقت ایمیل نمی‌فرستد، ناگهان با p=reject مواجه می‌شود و اگر کسی از آن ارسال کند، بی‌صدا رد می‌شود.

دو راه دارید. یا sp=quarantine بگذارید تا زیردامنه‌ها ملایم‌تر برخورد کنند، یا برای زیردامنه‌های بی‌استفاده رکورد جدا با p=reject بگذارید. راه دوم امن‌تر است و جلوی جعل از زیردامنه‌های فراموش‌شده را می‌گیرد.

ترکیبی که برای شروع امن است

اگر امروز می‌خواهید رکورد را بگذارید و فردا پشیمان نشوید، این خط را روی _dmarc.example.com ثبت کنید:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r

دو هفته گزارش‌ها را بخوانید. هر منبعی که در گزارش به‌عنوان fail دیده می‌شود، یا باید در SPF اضافه شود یا DKIM درست بگیرد. بعد p را به quarantine و در نهایت reject تغییر دهید. کل مسیر معمولاً یک ماه طول می‌کشد و اگر عجله کنید، فرم تماس سایت یا ایمیل بازیابی رمز عبور اولین قربانی است.

یک نکته درباره ابزارها: قبل از هر تغییر، رکورد MX و SPF را با بررسی رکورد MX چک کنید تا مطمئن شوید ارسال از جای درست انجام می‌شود. اگر روی هاست اشتراکی کار می‌کنید و کنترل کاملی روی رکوردها ندارید، هاست لینوکس با دسترسی کامل به DNS همان چیزی است که این مسیر را ساده می‌کند. مستندات فنی بیشتر هم در پایگاه دانش سرورنت در دسترس است.

اگر بعد از p=reject متوجه شدید بخشی از ایمیل‌های داخلی رد می‌شود، اول SPF را چک کنید نه DMARC را. در نود و نه مورد از صد مورد، مشکل آن‌جاست.

پرسش‌های پرتکرار

تفاوت p و sp در رکورد DMARC چیست؟

p سیاست دامنه اصلی را تعیین می‌کند و sp سیاست زیردامنه‌ها را. اگر sp را نگذارید، مقدار p به‌طور خودکار برای زیردامنه‌ها هم اعمال می‌شود که در بسیاری از موارد ناخواسته است.

آیا pct=50 امنیت را نصف می‌کند؟

بله، دقیقاً همین کار را می‌کند. با pct=50 فقط نیمی از ایمیل‌های شکست‌خورده طبق سیاست رفتار می‌شوند و بقیه عبور می‌کنند. برای مهاجرت تدریجی ساخته شده، اما در عمل پیشنهاد نمی‌شود؛ بهتر است مستقیم از none به reject بروید.

چرا گزارش rua نمی‌آید؟

سه دلیل رایج: آدرس صندوق وجود ندارد، رکورد روی نام اشتباه ثبت شده، یا گیرنده گزارش تجمیعی نمی‌فرستد. اول با dig +short TXT _dmarc.example.com وجود رکورد را تأیید کنید، بعد وجود صندوق مقصد را.

آیا DMARC جای SPF و DKIM را می‌گیرد؟

نه. DMARC روی SPF و DKIM سوار می‌شود و بدون آن‌ها کاری نمی‌کند. اگر SPF درست تنظیم نشده باشد، p=reject فقط ایمیل‌های سالم شما را هم رد می‌کند.

آیا این مطلب برایتان مفید بود؟