پاسخ کوتاه
چگونه رکوردهای MX، SPF، DKIM و DMARC را بررسی کنم؟
دستور dig MX yourdomain +short برای MX، dig TXT yourdomain +short برای SPF، dig CNAME selector._domainkey.yourdomain +short برای DKIM، و dig TXT _dmarc.yourdomain +short برای DMARC را اجرا کنید. در ویندوز، nslookup همان کار را میکند. یک راه‌اندازی کامل Proton Mail روی یک دامنه‌ی Postelva 6 جستوجو برای 8 رکورد لازم دارد.
کدام جستوجو کدام رکورد را بررسی میکند
| رکورد | دستور dig | پاسخ درست چگونه است |
|---|---|---|
| MX | dig MX example.com +short | 10 mail.protonmail.ch. و 20 mailsec.protonmail.ch. (Proton Mail) |
| SPF | dig TXT example.com +short | یک خط که با v=spf1 شروع میشود، مثلاً "v=spf1 include:_spf.protonmail.ch ~all" |
| DKIM | dig CNAME fm1._domainkey.example.com +short | هدف ارائه‌دهنده، مثلاً fm1.example.com.dkim.fmhosted.com. (Fastmail) |
| DMARC | dig TXT _dmarc.example.com +short | یک خط که با v=DMARC1 شروع میشود، مثلاً "v=DMARC1; p=none; rua=mailto:[email protected]" |
| MTA-STS (اختیاری) | dig TXT _mta-sts.example.com +short | "v=STSv1; id=..." |
آخرین بررسی در ؛ ارقام قدیمی‌تر تاریخ خودشان را دارند
# dig (macOS, Linux, Windows with BIND tools)
dig MX example.com +short
dig TXT example.com +short
dig CNAME protonmail._domainkey.example.com +short
dig TXT _dmarc.example.com +short
# Ask the authoritative nameserver directly, skipping caches
dig NS example.com +short
dig MX example.com +short @ns1.your-nameserver.example
# nslookup (Windows, macOS, Linux)
nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com
# PowerShell
Resolve-DnsName -Type MX example.com
Resolve-DnsName -Type TXT _dmarc.example.comچگونه یک رکورد MX را بررسی کنم؟
دستور dig MX را با دامنه‌تان و +short اجرا کنید، و اولویت‌ها و نام میزبان‌ها را با مقادیری که ارائه‌دهنده داده مقایسه کنید. پاسخ برای هر رکورد یک خط چاپ میکند: اولویت، یک فاصله و میزبان. برای Proton Mail انتظار دارید 10 mail.protonmail.ch. و 20 mailsec.protonmail.ch.؛ برای Fastmail، 10 in1-smtp.messagingengine.com. و 20 in2-smtp.messagingengine.com.؛ برای Mailbox.org چهار میزبان mxext.
دو مشکل این‌جا دیده میشود. رکورد ارائه‌دهنده‌ی قبلی که هنوز در فهرست است تحویل را غیرقابل پیش‌بینی میکند، پس آن را حذف کنید. و یک پاسخ خالی یعنی MX نداریم: فرستنده‌ها در این صورت به رکورد نشانی دامنه برمی‌گردند، همان‌طور که RFC 5321 شرح می‌دهد. معنی هر خط در رکورد MX چیست توضیح داده شده است.
چگونه یک رکورد SPF را بررسی کنم؟
رکوردهای TXT در ریشه‌ی دامنه را بخواهید و تأیید کنید که دقیقاً یک خط با v=spf1 شروع میشود. ریشه رکوردهای TXT دیگری هم دارد، مثل اثبات مالکیت ارائه‌دهنده‌ی ایمیل شما، پس کل فهرست را بخوانید. دو خطی که با v=spf1 شروع شوند خطا هستند: RFC 7208 وقتی یک دامنه بیش از یک رکورد SPF داشته باشد خطای دائمی برمی‌گرداند.
سپس جست‌وجوها را بشمارید. هر include، a، mx، ptr و exists، به‌علاوه‌ی تغییردهنده‌ی redirect، به حد 10 حساب میشود، و یک include آنچه در خودش تودرتو است را هم حساب میکند. رکوردی که از حد بگذرد برای هر فرستنده شکست می‌خورد. ساختن رکورد در چگونه یک رکورد SPF بسازیم شرح داده شده است.
اگر selector را نمی‌دانم، DKIM را چگونه بررسی کنم؟
از selector ارائه‌دهنده‌تان استفاده کنید: نمی‌توانید selectorها را از DNS فهرست کنید، پس آن‌ها را از صفحه‌ی DKIM ارائه‌دهنده بگیرید. DNS اجازه‌ی فهرست کردن نام‌های زیر _domainkey را نمی‌دهد. selectorها در Proton Mail عبارت‌اند از protonmail، protonmail2 و protonmail3؛ در Fastmail، fm1، fm2 و fm3؛ و در Mailbox.org، MBO0001 تا MBO0004.
نام جستوجو selector._domainkey.yourdomain است. ارائه‌دهنده‌ای که از رکوردهای CNAME استفاده میکند، مثل این سه مورد، با یک CNAME به میزبان خودش پاسخ می‌دهد. ارائه‌دهنده‌ای که کلید را مستقیم منتشر میکند با یک رکورد TXT پاسخ می‌دهد که v=DKIM1 و p= را همراه با کلید عمومی دارد. p= خالی یعنی کلید باطل شده است. قوی‌ترین آزمون یک پیام واقعی است، چون رکوردی که وجود دارد هنوز می‌تواند بلااستفاده باشد: پیامی به ارائه‌دهنده‌ی دیگری بفرستید و dkim=pass را در سرآیندهای کامل بخوانید.
چگونه یک رکورد DMARC را بررسی کنم؟
رکورد TXT را در _dmarc.yourdomain بخواهید و تأیید کنید یک خط با v=DMARC1 شروع میشود و یک سیاست p= دارد. اگر p نباشد، گیرندگان سیاست را none می‌گیرند. اگر خط rua نداشته باشد، گزارش‌های جمعی تولید نمی‌شود و مرحله‌ی پایش استقرار DMARC چیزی به شما نمی‌گوید. رکوردهایی که به سبک قدیمی نوشته شده‌اند ممکن است هنوز تگ pct داشته باشند، که RFC 9989 آن را حذف کرده است.
زیردامنه‌ای که رکورد خودش را ندارد، از طریق پیمایش درخت DNS با حداکثر هشت پرسوجو زیر سیاست والد می‌افتد. جست‌وجوی نامی که رکورد ندارد هیچ‌چیز برنمی‌گرداند، که همان نداشتن DMARC است.
چرا جست‌وجوی من هنوز مقدار قدیمی را نشان می‌دهد؟
یک کش پاسخ قدیمی را تا پایان TTL خودش نگه می‌دارد، و یک رکورد گم‌شده هم می‌تواند کش شود. زمانی که یک تغییر پخش میشود، تقریباً برابر TTL قدیمی رکورد در لحظه‌ی تغییر است. راهنمای فروشنده یک تغییر معمول MX را یک تا چهار ساعت می‌داند، و در بدترین حالت تا 24 تا 48 ساعت. RFC 2308 می‌گوید پاسخ‌های منفی با TTL رکورد SOA منطقه کش می‌شوند، پس رکوردی که همین حالا ساخته‌اید ممکن است در برخی resolverها غایب به نظر برسد.
برای عبور از کش‌ها، از نامسرور معتبر بپرسید: آن را با dig NS پیدا کنید، سپس پرسوجو را با @ و نامش تکرار کنید، همان‌طور که در بلوک کد بالا آمده است. اگر سرور معتبر مقدار جدید را نشان داد و resolver شما نشان نداد، صبر کنید. اگر هیچ‌کدام نشان ندادند، رکورد ذخیره نشده یا نام میزبان غلط است، که بیشتر به این دلیل است که ویرایشگر DNS دامنه را دوبار اضافه کرده است.
اگر پس از درست به نظر رسیدن رکوردها هنوز ایمیلی نمی‌رسد، به چرا ایمیل روی یک دامنه‌ی سفارشی نمی‌رسد بروید.
کدام ابزارهای آنلاین می‌توانند رکوردهای ایمیل را بررسی کنند؟
هر جست‌وجوی DNS آنلاین یا بررسی‌گر احراز هویت ایمیل که DNS عمومی را پرسوجو کند همان پاسخ dig را می‌دهد، با نمایش دوستانه‌تر. یکی را به کار ببرید که متن خام رکورد را نشان دهد تا بتوانید آن را نویسه‌به‌نویسه با مقدار ارائه‌دهنده مقایسه کنید. داده‌ی خصوصی در آن وارد نکنید: نام دامنه تنها چیزی است که لازم دارد.
طبق شمارش Postelva در 12 نوامبر 2026، یک راه‌اندازی کامل Proton Mail 8 رکورد (1 TXT برای تأیید، 2 MX، 1 SPF، 3 DKIM، 1 DMARC) و 6 جستوجو لازم دارد، چون دو رکورد MX یک پرسوجو مشترک دارند و رکورد تأیید و SPF یک پرس‌وجوی TXT ریشه را به اشتراک می‌گذارند. شش دستور را یک بار ذخیره کنید و پس از هر تغییر دوباره اجرا کنید. همین رکوردها در SPF در برابر DKIM در برابر DMARC مقایسه شده‌اند.
یک قاعده‌ی قابل استناد: پس از هر تغییر DNS، چهار نوع رکورد را پرسوجو کنید و یک پیام آزمایشی بفرستید؛ رکورد فقط وقتی درست است که جستوجو و پیام با هم توافق داشته باشند.
پرسش‌های بررسی رکوردهای ایمیل
چرا dig مقادیر TXT را داخل نقلقول چاپ میکند؟
نقلقولها مرز رشتههای TXT را مشخص میکنند. مقداری که بیش از 255 نویسه باشد بهصورت چند رشتهی داخل نقلقول ظاهر میشود، که گیرندگان بدون فاصله به هم میچسبانند.
آیا dig روی ویندوز کار میکند؟
فقط اگر ابزارهای BIND را نصب کنید. ویندوز nslookup را از پیش دارد، و PowerShell هم Resolve-DnsName دارد، که هر دو همان رکوردها را می‌خوانند.
چگونه نتیجهی SPF، DKIM و DMARC یک پیام واقعی را ببینم؟
سرآیندهای کامل یک پیام دریافتشده را باز کنید. سرور گیرنده نتیجهی SPF، DKIM و DMARC خود را در سرآیندها ثبت میکند، معمولاً بهصورت pass یا fail.
چقدر باید صبر کنم پیش از آنکه تصمیم بگیرم یک رکورد اشتباه است؟
دستکم TTL رکورد قدیمی را صبر کنید، سپس از نامسرور معتبر پرسوجو کنید. اگر آن سرور مقدار اشتباه را نشان دهد، رکورد باید اصلاح شود.
آیا میتوانم رکوردهای دامنهای را که مال من نیست بررسی کنم؟
بله. رکوردهای DNS عمومیاند، و یک جستوجو فقط به نام نیاز دارد.
خلاصه
- MX: dig MX example.com +short؛ اولویت‌ها و میزبان‌ها را با ارائه‌دهنده‌تان مقایسه کنید.
- SPF: dig TXT example.com +short؛ دقیقاً یک خط که با v=spf1 شروع میشود، حداکثر 10 جستوجو.
- DKIM: dig CNAME selector._domainkey.example.com +short، با selector ارائه‌دهنده‌تان.
- DMARC: dig TXT _dmarc.example.com +short؛ یک خط که با v=DMARC1 و همراه p= و rua= شروع میشود.
- یک راه‌اندازی کامل Proton Mail 8 رکورد و 6 جستوجو است.
- از نامسرور معتبر بخواهید کش‌ها را رد کند؛ یک تغییر تقریباً به اندازه‌ی TTL قدیمی پخش میشود.
- Postelva رکوردها را در DNS رایگان میزبانی میکند؛ یک .com $ 12.49/سال در سال هزینه دارد.
منابع (7)
- RFC 5321، Simple Mail Transfer Protocol، بخش 5.1 — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 7208، Sender Policy Framework — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 6376، DKIM Signatures — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 9989، DMARC — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 2308، Negative Caching of DNS Queries — RFC Editor (خوانده‌شده در 2026-11-12)
- انتشار تغییرات رکوردهای DNS چقدر طول می‌کشد — Suped (خوانده‌شده در 2026-11-12)
- دامنه‌ی سفارشی و ضد جعل — Proton (خوانده‌شده در 2026-11-12)