پاسخ کوتاه
چگونه DMARC را برای دامنهام راهاندازی کنم؟
یک رکورد TXT در _dmarc.yourdomain منتشر کنید که v=DMARC1; p=none; rua=mailto:you@yourdomain را داشته باشد، حدود یک ماه گزارشهای جمعی را بخوانید، سپس سیاست را به قرنطینه و در نهایت رد (reject) ارتقا دهید. DMARC از ماه می 2026 با RFC 9989 تعریف میشود. Postelva رکورد را در ویرایشگر DNS رایگان خود میزبانی میکند.
سه سیاست DMARC و کار هر یک
| سیاست | رکورد | اثر روی پیامی که DMARC را رد نمیکند | زمان استفاده |
|---|---|---|---|
| پایش | v=DMARC1; p=none; rua=mailto:[email protected] | مثل همیشه تحویل میشود؛ گزارشها برای شما فرستاده میشوند | چند هفتهی اول، برای دیدن هر فرستنده |
| قرنطینه | v=DMARC1; p=quarantine; rua=mailto:[email protected] | مشکوک تلقی میشود، معمولاً به هرزنامه میرود | پس از اینکه SPF و DKIM روی همهی ایمیلهای قانونی شما قبول شوند |
| رد (Reject) | v=DMARC1; p=reject; rua=mailto:[email protected] | توسط سرور گیرنده رد میشود | وقتی گزارشها دیگر هیچ خطای قانونی نشان ندهند |
راهاندازی DMARC در شش مرحله
ابتدا SPF و DKIM را تأیید کنید
DMARC به حداقل یکی از آنها نیاز دارد که قبول شود و با دامنهی From شما همراستا باشد. هر دو را پیش از DMARC منتشر کنید، با استفاده از راهنماهای SPF و DKIM.
یک صندوق برای گزارشها انتخاب کنید
نشانیای مثل dmarc@yourdomain بسازید. RFC 9989 میگوید مالک باید یک صندوق برای دریافت و تحلیل گزارشهای جمعی راهاندازی کند.
رکورد پایش را منتشر کنید
یک رکورد TXT با میزبان _dmarc و مقدار v=DMARC1; p=none; rua=mailto:dmarc@yourdomain اضافه کنید.
حدود یک ماه گزارشها را بخوانید
گزارشها تقریباً روزی یک بار از گیرندگانی که آنها را میفرستند میرسند. دنبال ایمیلهای قانونی بگردید که همراستایی SPF و DKIM را رد میکنند، و آن فرستندهها را درست کنید.
به قرنطینه بروید
p=none را به p=quarantine تغییر دهید. همان مدت تقریبی نگه دارید و ببینید در گزارشها پیامها چگونه مدیریت شدهاند.
به رد (reject) بروید، یا در قرنطینه بمانید
وقتی گزارشها پاک هستند، به p=reject تغییر دهید. اگر از این دامنه به فهرستهای پستی ارسال میکنید، در قرنطینه بمانید.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"یک رکورد DMARC چه چیزهایی دارد؟
یک رکورد DMARC یک رکورد TXT در _dmarc.yourdomain است که با v=DMARC1 شروع میشود و تگهایش با نقطهویرگول از هم جدا میشوند. تگ نسخه اول میآید و به حروف بزرگ و کوچک حساس است. RFC 9989 این تگها را تعریف میکند: p (سیاست برای دامنه)، sp (سیاست برای زیردامنههای موجود)، np (سیاست برای زیردامنههای غیرموجود)، adkim و aspf (همراستایی، r برای relaxed یا s برای strict، بهطور پیشفرض relaxed)، rua (نشانیهای گزارش جمعی)، ruf (نشانیهای گزارش خطا)، fo (گزینههای گزارش خطا)، t (حالت آزمایشی، y یا n) و psd.
اگر p نباشد، گیرنده سیاست را none میگیرد. اگر sp نباشد، سیاست p زیردامنهها را هم پوشش میدهد. اگر rua نباشد، گزارش جمعی تولید نمیشود. بنابراین یک رکورد مفید حداقلی سه بخش دارد: نسخه، یک سیاست و یک نشانی گزارش.
تگ pct که بسیاری از راهنماهای قدیمی هنوز نشان میدهند، توسط RFC 9989 حذف شده، زیرا بهندرت بهدرستی جز در 0 و 100 اعمال میشد. تگ t جای آن را میگیرد: t=y مثل pct=0 رفتار میکند و t=n مثل pct=100، و n پیشفرض است. pct را از رکوردهای قدیمی حذف کنید. پیشینهی گستردهتر در SPF در برابر DKIM در برابر DMARC است.
همراستایی در DMARC یعنی چه؟
همراستایی یعنی دامنهای که با SPF یا DKIM احراز شده با دامنهی نشانی قابلمشاهدهی From یکی باشد. در حالت relaxed، که پیشفرض است، این دو فقط باید دامنهی سازمانی یکسان داشته باشند، پس mail.example.com با example.com همراستا است. در حالت strict باید دقیقاً یکی باشند. RFC 9989 توضیح میدهد که تقریباً همهی مالکان دامنه همراستایی relaxed را کافی میدانند.
پیامی از DMARC عبور میکند که SPF یا DKIM قبول شود و همراستا باشد. یکی از این دو کافی است. یک ارائهدهندهی صندوق مثل Proton Mail یا Fastmail با رکوردهای CNAME مربوط به DKIM با دامنهی شما امضا میکند، پس همراستایی بدون کار اضافی برقرار است. تله این است: سرویس شخص ثالثی که با دامنهی خودش امضا میکند. DKIM آن قبول میشود اما همراستا نیست، تا وقتی برایش یک دامنهی امضای سفارشی راهاندازی نکنید.
RFC 9989 دامنهی سازمانی را از طریق پیمایش درخت DNS با حداکثر هشت پرسوجو پیدا میکند، نه با فهرست پسوند عمومی. برای یک دامنهی معمولی روی .com یا .me، برای شما چیزی تغییر نمیکند.
چقدر باید روی p=none بمانم؟
دستکم یک ماه روی p=none بمانید، سپس برای مدت مشابهی روی p=quarantine، و بعد به p=reject برسید. این ترتیبی است که RFC 9989 در راهنمای استقرار خود توصیه میکند، و با صفحات راهنمای ارائهدهندگان همخوان است. Mailbox.org رکورد نمونهاش را با p=none شروع میکند و هشدار میدهد که سیاست سختگیرانهی زودهنگام ممکن است ایمیل قانونی را برگرداند. Proton توصیه میکند p=quarantine و سپس انتقال به p=reject وقتی ایمیل قانونی احراز میشود.
بر اساس قرائت Postelva در 12 نوامبر 2026 از راهنمای DMARC سه ارائهدهندهای که آن را منتشر میکنند (Proton Mail، Mailbox.org و Mailfence)، 2 مورد با p=none شروع میکنند و 1 مورد p=quarantine را توصیه میکند.
دو هشدار برای p=reject اعمال میشود. RFC 9989 میگوید دامنهای که از آن استفاده میکند نباید فقط به SPF تکیه کند و باید با DKIM امضا کند، زیرا SPF با هدایت میشکند. همچنین میگوید دامنههایی که کاربرانشان به فهرستهای پستی ارسال میکنند نباید اصلاً p=reject منتشر کنند، زیرا فهرستها اغلب پیامها را تغییر میدهند و این امضا را میشکند.
گزارشهای DMARC کجا میروند و چه نشان میدهند؟
گزارشهای جمعی به نشانی mailto: موجود در rua میروند، معمولاً روزی یک بار از هر گیرنده، و فهرست فرستندههایی را نشان میدهند که با دامنهی شما در خط From ایمیل فرستادهاند. RFC 9989 از گیرندگان میخواهد نشانیهای mailto: را پشتیبانی کنند و توصیه میکند گزارشهای جمعی دستکم هر 24 ساعت فرستاده شوند. گزارشدهی جمعی در RFC 9990 تعریف شده است.
گزارشهای خطا که با ruf درخواست میشوند، نسخههای هر پیام بهصورت جداگانهاند. بسیاری از گیرندگان آنها را برای حفظ حریم خصوصی حذف یا پنهان میکنند، پس روی آنها حساب نکنید. اگر نشانی rua بیرون از دامنهی شما باشد، مالک آن دامنهی دیگر باید آن را با یک رکورد TXT در yourdomain._report._dmarc.otherdomain که v=DMARC1; را دارد مجاز کند، قاعدهای که سوءاستفاده از صندوقهای شخص ثالث را متوقف میکند. برای یک دامنهی شخصی کوچک، فهرست فرستندهها کوتاه است: ارائهدهندهتان، و چیز کمی دیگر.
برای خواندن آنچه DNS شما پیش و پس از هر مرحله منتشر میکند، از دستورهای بررسی رکوردهای MX، SPF، DKIM و DMARC استفاده کنید.
آیا دامنهی شخصی من به DMARC نیاز دارد؟
بله، برای هر دامنهای که ایمیل میفرستد: یک رکورد TXT هزینه دارد و جعل پیامهایی را که نام شما را به کار میبرند مسدود میکند. Google از فرستندههایی با بیش از 5,000 پیام در روز به حسابهای Gmail، داشتن DMARC را الزامی میکند، که سیاست none برای آن کافی است، و Microsoft همان آستانه را برای Outlook.com اعمال میکند. یک صندوق شخصی بسیار پایینتر از این محدودیتهاست. رکورد باز هم به گیرندگان میگوید در برابر یک جعل چه میخواهید انجام دهند.
برای دامنهای که چیزی نمیفرستد، فوراً p=reject را همراه با SPF -all و یک MX تهی تنظیم کنید. Postelva برای آن حالت یک قالب «بدون ایمیل» دارد. برای دامنهای با صندوق، از none شروع کنید. بخش انتقالی همین حفاظت، یعنی رمزگذاری بین سرورها، در چگونه MTA-STS و TLS-RPT را راهاندازی کنیم پوشش داده شده است.
یک تعریف قابل استناد: DMARC سیاست DNS است که به گیرندگان میگوید وقتی نتایج SPF و DKIM با دامنهی From همراستا نیستند چه کار کنند، و گزارشهایی دربارهی آن را کجا بفرستند.
پرسشهای راهاندازی DMARC
آیا RFC 9989 به p=reject نیاز دارد؟
خیر. استاندارد سه سیاست را تعریف میکند و انتخاب را به مالک دامنه واگذار میکند. یک مسیر تدریجی را توصیه میکند و از p=reject برای دامنههایی که کاربرانشان به فهرستهای پستی ارسال میکنند هشدار میدهد.
آیا RFC 9989 رکورد DMARC موجود مرا عوض میکند؟
رکوردها همچنان با v=DMARC1 شروع میشوند، پس رکورد کارکنده همچنان کار میکند. تگ ri حذف شد، pct حذف شد و t، np و psd اضافه شدند.
اگر p=reject را زودتر از موعد منتشر کنم چه میشود؟
ایمیل قانونی که همراستایی را رد میکند، مثل یک ابزار خبرنامهی فراموششده، توسط گیرندگان رد میشود. گزارشهای p=none برای پیدا کردن آن فرستندهها پیش از همه وجود دارند.
آیا میتوانم برای گزارشها از یک صندوق رایگان استفاده کنم؟
بله، هر صندوقی که بخوانید. یک نشانی یا نام مستعار جدا فایلهای روزانهی گزارش را از صندوق اصلیتان دور نگه میدارد.
یک دامنه چند رکورد DMARC میتواند داشته باشد؟
یکی برای هر نام، در _dmarc.yourdomain. زیردامنهها میتوانند رکورد خودشان داشته باشند یا سیاست والد را از طریق sp به ارث ببرند.
خلاصه
- DMARC یک رکورد TXT در _dmarc.yourdomain است که با v=DMARC1 شروع میشود.
- RFC 9989 (مه 2026) مشخصهی فعلی است؛ RFC 7489 را منسوخ میکند و pct را حذف کرده است.
- با p=none و یک نشانی rua شروع کنید، و حدود یک ماه گزارشها را بخوانید.
- سپس برای مدت مشابهی p=quarantine، و بعد p=reject.
- پیامی از DMARC عبور میکند که SPF یا DKIM قبول شود و با دامنهی From همراستا باشد؛ همراستایی relaxed پیشفرض است.
- دامنهای با p=reject نباید فقط به SPF تکیه کند و نباید با فهرستهای پستی به کار رود.
- Postelva رکورد را در DNS رایگان میزبانی میکند؛ یک .com $ 12.49/سال در سال هزینه دارد.
منابع (6)
- RFC 9989، Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (خواندهشده در 2026-11-12)
- RFC 7489، DMARC (منسوخشده) — RFC Editor (خواندهشده در 2026-11-12)
- SPF، DKIM و DMARC برای یک دامنهی سفارشی — Mailbox.org (خواندهشده در 2026-11-12)
- دامنهی سفارشی و ضد جعل — Proton (خواندهشده در 2026-11-12)
- دستورالعملهای فرستندهی ایمیل — Google Workspace Admin Help (خواندهشده در 2026-11-12)
- تقویت امنیت ایمیل: الزامات جدید برای فرستندههای پرحجم — Microsoft Tech Community (خواندهشده در 2026-11-12)