پاسخ کوتاه
چگونه جعل ایمیل را روی دامنه‌های استفاده‌نشده متوقف کنیم؟
سه رکورد DNS روی هر دامنه‌ای که ایمیل نمی‌فرستد منتشر کنید: یک MX تهی با preference برابر 0 که به یک نقطه اشاره می‌کند (RFC 7505)، یک رکورد SPF با مقدار v=spf1 -all، و یک رکورد DMARC با p=reject در _dmarc. قالب بدون ایمیل Wardmint هر سه را با یک کلیک منتشر می‌کند، و نُه پسوند مجموعه‌ی فیشرِ آن $212.41 در سال هزینه دارند.
سه رکوردی که یک دامنه را در برابر ایمیل ایمن می‌کنند
| رکورد | نام | نوع | مقدار | آنچه می‌گوید |
|---|---|---|---|---|
| MX تهی | @ | MX | 0 . | این دامنه هیچ ایمیلی نمی‌پذیرد (RFC 7505) |
| SPF | @ | TXT | "v=spf1 -all" | هیچ سروری مجاز نیست به نام این دامنه ارسال کند (RFC 7208) |
| DMARC | _dmarc | TXT | "v=DMARC1; p=reject; adkim=s; aspf=s" | از گیرندگان خواسته می‌شود ایمیلی را که بررسی‌ها را رد می‌کند پذیرش نکنند (RFC 7489) |
چرا دامنه‌های استفاده‌نشده به رکوردهای ایمیل نیاز دارند؟
چون هر کسی می‌تواند دامنه‌ی شما را در خط From هر ایمیلی قرار دهد، و یک دامنه‌ی بدون رکورد به گیرنده چیزی برای بررسی نمی‌دهد. یک دامنه‌ی دفاعی مانند غلط‌املای برند شما به همین دلیل جذاب است. فیشرها ایمیلی می‌فرستند که از طرف نسخه‌ی شما یا از نامی شبیه نشانی پشتیبانی شما به نظر برسد، و یک سیستم دریافت‌کننده که سیاستی پیدا نمی‌کند، مبنایی برای رد آن ندارد.
دو رکورد بیشتر این شکاف را می‌بندند. SPF فهرست سرورهایی را مشخص می‌کند که مجازند برای دامنه ارسال کنند، و یک رکورد SPF بدون سرور و با fail سخت، هر فرستنده‌ای را رد می‌کند. DMARC به گیرندگان می‌گوید با ایمیلی که SPF و DKIM را رد می‌کند چه کنند، و p=reject از آن‌ها می‌خواهد آن را نپذیرند. رکورد سوم، MX تهی، به فرستندگان می‌گوید که دامنه سرور ایمیل ندارد، پس پیامی که به آن برود بی‌درنگ شکست می‌خورد، نه اینکه روزها تلاش مجدد شود.
فهرست Wardmint از دامنه‌های دفاعی در کدام دامنه‌ها را یک پروژه‌ی کریپتویی باید ثبت کند آمده است. وقتی مالک آن‌ها شدید، این سه رکورد اولین چیزی هستند که باید اضافه کنید.
یک MX تهی (RFC 7505) چه می‌کند؟
MX تهی یک رکورد MX واحد با preference برابر 0 و هدفی با نقطه‌ی ریشه است، و یعنی دامنه هیچ ایمیلی نمی‌پذیرد. RFC 7505 آن را تعریف می‌کند. این exchange یک برچسب با طول صفر است که در فایل‌های منطقه به صورت نقطه نوشته می‌شود، و چون نقطه نام میزبان معتبر نیست، این رکورد را نمی‌توان با یک سرور ایمیل واقعی اشتباه گرفت.
دو قاعده وجود دارد. دامنه‌ای که MX تهی منتشر می‌کند نباید هیچ رکورد MX دیگری منتشر کند. و رکورد فقط در همین شکل دقیق MX تهی است: preference برابر 0 و هدف نقطه. فرستنده‌هایی که آن را ببینند بی‌درنگ با خطای دائمی شکست می‌خورند، که حلقه‌های ایمیل را متوقف می‌کند و صف تلاش مجدد فرستنده‌های صادقی را که دامنه‌ی شما را اشتباه تایپ کرده‌اند نجات می‌دهد.
بدون آن، فرستنده‌ای که MX پیدا نکند به رکورد A دامنه برمی‌گردد و سعی می‌کند آنجا تحویل دهد، که کندتر و کم‌واضح‌تر است. MX تهی این حدس‌زنی را حذف می‌کند.
معنای SPF با مقدار v=spf1 -all چیست؟
این یک رکورد TXT است که هیچ فرستنده‌ای را مجاز نمی‌کند، و علامت منفی هر بررسی را شکست می‌دهد. RFC 7208 آن را تعریف می‌کند: v=spf1 تگ نسخه است و -all یک دستور واحد است که در آن مکانیزم all همیشه تطابق دارد و قیدکننده‌ی منفی نتیجه‌ی fail برمی‌گرداند. با هم می‌گویند هیچ میزبانی مجاز نیست برای این نام ایمیل بفرستد.
RFC 7208 این روش را برای نام‌هایی پیشنهاد می‌کند که نه در نشانی‌های ایمیل استفاده می‌شوند و نه انتظار ارسال ایمیل دارند. آن را در رأس هر دامنه‌ی دفاعی منتشر کنید. SPF برای دامنه در فرستنده‌ی envelope یا نام HELO بررسی می‌شود، پس جعل‌کننده ممکن است یک زیردامنه‌ای را هم امتحان کند که هرگز پیکربندی نکرده‌اید. یک رکورد TXT عام (wildcard) که برای نام‌های زیر دامنه که رکورد خاص ندارند اعمال می‌شود، می‌تواند آن‌ها را پوشش دهد.
example.com. 3600 IN MX 0 .
example.com. 3600 IN TXT "v=spf1 -all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s"DMARC با p=reject چه چیزی می‌افزاید؟
DMARC سیاست و گزارش‌دهی را اضافه می‌کند: به گیرندگان می‌گوید ایمیل ناموفق را رد کنند و به شما امکان می‌دهد ببینید چه کسی تلاش می‌کند. RFC 7489 سیاست را به‌صورت یک رکورد TXT روی نام _dmarc دامنه قرار می‌دهد. تگ v باید اول بیاید و مقدار DMARC1 داشته باشد، و p سیاست را روی none، quarantine یا reject تنظیم می‌کند. تگ sp سیاست زیردامنه‌ها را تعیین می‌کند و اگر نباشد، p برای آن‌ها اعمال می‌شود. تگ‌های adkim و aspf هم‌ترازی سخت‌گیرانه یا آسان‌گیرانه را مشخص می‌کنند، و rua نشانی‌های گزارش‌های تجمیعی را می‌دهد.
RFC درباره‌ی قدرت p=reject محتاط است: صاحب دامنه از گیرندگان می‌خواهد رد کنند، و گیرندگان موظف به‌صورت قطعی نیستند، بلکه باید تلاش معقول کنند. ارائه‌دهندگان بزرگ صندوق ایمیل در عمل آن را دنبال می‌کنند، و به همین دلیل انتشار این رکورد ارزش دارد.
برای دیدن تلاش‌ها، یک نشانی گزارش بیفزایید، مثلاً rua=mailto:[email protected]، روی صندوقی که می‌خوانید. برای پروژه‌ای با چند دامنه‌ی دفاعی، یک صندوق گزارش برای همه کافی است. دامنه‌ای را که ایمیل می‌فرستد، مانند دامنه‌ی اصلی‌تان، روی سیاستی نگه دارید که با فرستندگان واقعی‌اش مطابقت دارد و پیش از رفتن به reject، گزارش‌های تجمیعی را بخوانید.
نگه داشتن یک مجموعه‌ی دفاعی چقدر هزینه دارد؟
سه رکورد در Wardmint هزینهٔ اضافی ندارند؛ هزینه، خود دامنه‌هاست. Wardmint الگوی DNS «بدون ایمیل» (null MX، SPF -all، DMARC p=reject) تا دامنه دفاعی برای جعل ایمیل شما استفاده نشود، هدایت رایگان URL برای ارسال هر واریانت به سایت اصلی شما، و تمدید خودکار از موجودی شما تا هیچ واریانتی منقضی نشود را ارائه می‌دهد.
طبق نظرسنجی Wardmint در 12 نوامبر 2026، نه پسوند در مجموعهٔ فیشینگ آن (.xyz، .pro، .info، .shop، .online، .icu، .click، .live و .support) روی هم سالانه $212.41 هزینه دارند، یا روی سه سال $637.23، و هر کدام می‌توانند الگوی بدون ایمیل را داشته باشند. مجموعهٔ هسته‌ای .com, .net, .org, .io, .xyz, .app سالانه $128.94 هزینه دارد. این مجموعه‌ها پیشنهادی هستند، نه بسته: نام‌ها از طریق جستجوی انبوه، تا 50 نام در هر بار، به سبد اضافه می‌شوند.
الگو را روی هر دامنهٔ دفاعی که ترافیک وب را بازهدایت نمی‌کند اعمال کنید، و آن را با فوروارد URL برای آن‌هایی که بازهدایت می‌کنند ترکیب کنید. روش انتخاب نام‌ها در چگونه فهرست دامنه‌های دفاعی برای برند خود بسازید آمده است.
چگونه پنج گام جعل ایمیل را روی یک دامنه‌ی استفاده‌نشده متوقف کنیم
مطمئن شوید دامنه ایمیل نمی‌فرستد
بررسی کنید هیچ سرویس، ابزار خبرنامه یا برنامه‌ای از این دامنه ارسال نمی‌کند. اگر یکی ارسال می‌کند، از این الگو استفاده نکنید.
MX تهی را منتشر کنید
یک رکورد MX با preference برابر 0 و هدف تنظیم‌شده روی یک نقطه‌ی تنها اضافه کنید و هر رکورد MX دیگری را حذف کنید.
رکورد SPF را منتشر کنید
یک رکورد TXT روی رأس دامنه با مقدار v=spf1 -all اضافه کنید و آن را تنها رکورد SPF نگه دارید.
رکورد DMARC را منتشر کنید
یک رکورد TXT روی _dmarc با v=DMARC1; p=reject اضافه کنید، و اگر گزارش می‌خواهید یک نشانی در rua بگذارید.
رکوردها را بررسی کنید
روی دامنه dig MX، dig TXT و dig TXT _dmarc را اجرا کنید و پاسخ‌ها را با الگو مقایسه کنید.
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +shortپرسش‌هایی درباره‌ی جعل ایمیل و دامنه‌های استفاده‌نشده
آیا می‌توانم p=reject را بدون نشانی گزارش استفاده کنم؟
بله. تگ rua اختیاری است و بدون آن گیرندگان گزارش تجمیعی نمی‌فرستند. اگر می‌خواهید تلاش‌ها را ببینید یکی اضافه کنید.
آیا MX تهی به‌تنهایی جعل را متوقف می‌کند؟
خیر. فقط جلوی تحویل ایمیل به دامنه را می‌گیرد. SPF و DMARC هستند که به گیرندگان می‌گویند به ایمیلی که ادعا می‌کند از این دامنه است بی‌اعتماد باشند.
آیا دامنه‌ی اصلی من باید همان رکوردها را داشته باشد؟
خیر. دامنه‌ای که ایمیل می‌فرستد برای فرستندگان واقعی‌اش به SPF و DKIM نیاز دارد. p=reject را فقط پس از خواندن گزارش‌های DMARC و هم‌ترازی همه‌ی فرستندگان آنجا به کار ببرید.
آیا روی هر دامنه‌ی دفاعی به هر سه رکورد نیاز دارم؟
بله، روی هر دامنه‌ای که ایمیل نمی‌فرستد و دریافت هم نمی‌کند. هر رکورد بخش متفاوتی از بررسی را پوشش می‌دهد و الگوی Wardmint آن‌ها را با هم منتشر می‌کند.
آیا الگو هزینه‌ی اضافی دارد؟
خیر. بخشی از ابزارهای دفاعی همراه با ثبت است، در کنار هدایت رایگان URL و تمدید خودکار از موجودی.
خلاصه
- یک دامنه‌ی دفاعی که ایمیل نمی‌فرستد به سه رکورد DNS نیاز دارد.
- MX تهی: preference برابر 0، هدف یک نقطه (RFC 7505)، و هیچ رکورد MX دیگری.
- SPF: v=spf1 -all، که هیچ فرستنده‌ای را مجاز نمی‌کند (RFC 7208).
- DMARC: v=DMARC1; p=reject روی _dmarc، که از گیرندگان می‌خواهد ایمیل ناموفق را رد کنند (RFC 7489).
- الگوی بدون ایمیل Wardmint هر سه رکورد را با یک کلیک منتشر می‌کند.
- نُه پسوند مجموعه‌ی فیشر $212.41 در سال هزینه دارند؛ الگو رایگان است.
- الگو را روی دامنه‌ای که ایمیل واقعی می‌فرستد به کار نبرید.
منابع (3)
- RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail — IETF / RFC Editor (خوانده‌شده 2026-11-12)
- RFC 7208: Sender Policy Framework (SPF) — IETF / RFC Editor (خوانده‌شده 2026-11-12)
- RFC 7489: DMARC — IETF / RFC Editor (خوانده‌شده 2026-11-12)