چرا ایمیل سایت به اسپم می‌رود یا برگشت می‌خورد؟ راهنمای SPF، DKIM و DMARC

«چرا ایمیل به اسپم می‌رود» پاسخ کوتاهی دارد: ایمیل وقتی به اسپم می‌رود که سرور گیرنده نتواند ثابت کند نامه واقعاً از دامنه‌ی ادعاشده آمده است — و سه رکورد TXT به نام‌های SPF، DKIM و DMARC همین اثبات را انجام می‌دهند. اما این پاسخ کوتاه سه اتفاق کاملاً متفاوت را زیر یک نام پنهان می‌کند: نامه‌ای که پذیرفته می‌شود و در پوشه‌ی اسپم می‌نشیند، نامه‌ای که با کد 550 برگشت می‌خورد، و نامه‌ای که روزها در صف می‌ماند و نه می‌رسد و نه برگشتی تولید می‌کند. هر سه با یک نسخه‌ی واحد درمان نمی‌شوند. در این راهنما اول این سه حالت را جدا می‌کنیم، بعد هدر Authentication-Results یک نامه‌ی واقعی را می‌خوانیم و از روی نتیجه‌اش شاخه می‌زنیم، سپس SPF، DKIM و DMARC را با نسخه‌ی به‌روز استاندارد می‌سازیم و در ناحیه‌ی DNS معتبر می‌نشانیم — و صادقانه می‌گوییم کجاها روی هاست اشتراکی دست شما بسته است.

ایمیل به اسپم می‌رود یا اصلاً نمی‌رسد؟ اول این دو را از هم جدا کنید

پیش از هر تغییری در DNS باید بدانید سرور مقصد با ایمیل شما چه کرده است. سه پایان پرتکرار وجود دارد. اول: مقصد نامه را می‌پذیرد و پاسخ 250 می‌دهد، اما فیلتر محتوا آن را در پوشه‌ی اسپم می‌گذارد؛ اینجا هیچ برگشتی تولید نمی‌شود و منتظر ماندن برای نامه‌ی خطا بی‌فایده است. دوم: مقصد کدی از خانواده‌ی 5xx می‌دهد و سرور شما گزارش عدم تحویل با متن دقیق خطا می‌فرستد. سوم: کد 4xx یعنی «الان نه، بعداً امتحان کن»؛ نامه چند روز در صف می‌ماند و در تمام این مدت نه رسیده است نه برگشتی گرفته‌اید، تا سرانجام یا تحویل شود یا به برگشت دائمی تبدیل گردد. حالت چهارمی هم هست که کمتر دیده می‌شود: مقصد نامه را با 250 می‌پذیرد و بعد بی‌صدا دور می‌ریزد؛ در این حالت هیچ نشانه‌ای جز نرسیدن نامه ندارید و تنها راه، خواندن گزارش‌های rua است.

رقم اول کد SMTP همه‌ی داستان است: ۴ یعنی موقت، ۵ یعنی دائمی. آزمون درست این است که نامه را از همان مسیری بفرستید که مشکل دارد — اگر شکایت درباره‌ی فرم تماس است، از خود فرم، نه از وبمیل — و هم‌زمان به یک نشانی جی‌میل و یک اوت‌لوک. بعد سه چیز را ثبت کنید: رسید یا نه، در کدام پوشه نشست، و آیا گزارش عدم تحویلی آمد.

یک تفکیک دیگر هم لازم است، چون تمام بحث SPF و DMARC روی آن بنا شده: هر نامه دو نشانی فرستنده دارد. نشانی پاکت یا MAIL FROM در هدر Return-Path ثبت می‌شود و کاربر هرگز نمی‌بیندش؛ هدر From همان است که گیرنده می‌بیند. این دو می‌توانند کاملاً متفاوت باشند و SMTP اعتراضی نمی‌کند.

هدر Authentication-Results ایمیل را کجا ببینم و چطور بخوانم؟

در جی‌میل نامه را باز کنید، از منوی سه‌نقطه گزینه‌ی «نمایش اصل پیام» را بزنید و دنبال هدر Authentication-Results بگردید؛ قالبش در RFC 8601 استاندارد شده. نمونه‌ی زیر شکل تیپیک یک شکست نامرئی است:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@mailer.example.net header.s=s1;
       spf=pass (google.com: domain of bounce-42@mailer.example.net designates
              203.0.113.10 as permitted sender) smtp.mailfrom=bounce-42@mailer.example.net;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

هم SPF و هم DKIM نتیجه‌ی pass دارند و DMARC باز هم شکست خورده. دلیلش انتهای هر خط است: دامنه‌ی تأییدشده mailer.example.net است اما هدر From example.com — همان مسئله‌ای که در بخش هم‌ترازی DMARC باز می‌کنیم. شاخه‌های دیگر:

• هر سه pass. احراز هویت سالم است؛ مشکل اعتبار آی‌پی، محتوا یا نرخ شکایت گیرنده‌هاست — بخش‌های الزام‌های فرستنده و آی‌پی مشترک و لیست سیاه.
• spf=fail یا softfail ولی dkim=pass و dmarc=pass. رکورد SPF سرور فرستنده‌ی فعلی را در بر نمی‌گیرد و امضای DKIM نجاتش داده؛ هنوز باید SPF را کامل کنید.
• spf=permerror. رکورد از نظر نحو یا بودجه‌ی جست‌وجو خراب است — معمولاً دو رکورد SPF هم‌زمان یا عبور از سقف ده جست‌وجوی DNS.
• dkim=none یا dkim=fail. در اولی سرور اصلاً امضا نمی‌کند؛ در دومی امضا با کلید عمومی جور درنمی‌آید — یا کلید در DNS ناقص نشسته یا چیزی متن نامه را دستکاری کرده.
• dmarc=none. رکورد DMARC منتشر نکرده‌اید؛ در ارسال انبوه به جی‌میل همین کافی است که نامه با 550 5.7.40 رد شود.

در نامه‌های رسیده به اوت‌لوک همین هدر فیلد compauth را هم دارد: نتیجه‌ی ترکیبی احراز هویت و اعتبار فرستنده، طبق مستندات احراز هویت ایمیل مایکروسافت.

نامه‌ای که برگشت می‌خورد: کدهای خطای جی‌میل مثل 550 5.7.26 و معنی دقیقشان

گزارش عدم تحویل، متن خام پاسخ سرور گیرنده را حمل می‌کند و دقیقاً می‌گوید چرا ایمیل شما برگشت خورده است؛ تکه‌ی مهمش این شکل را دارد:

Final-Recipient: rfc822; user@gmail.com
Action: failed
Status: 5.7.26
Diagnostic-Code: smtp; 550-5.7.26 This mail has been blocked because the sender is
 unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

گوگل فهرست کامل این کدها را در راهنمای کدهای خطای SMTP جی‌میل منتشر کرده است:

دو نکته: کدهای 5.7.27 و 5.7.30 در متن گوگل صریحاً به «فرستنده‌های انبوه» اشاره دارند، پس اگر سایت شما روزی ده نامه می‌فرستد و این کد را می‌بیند، آی‌پی مشترک سرورتان در دسته‌ی انبوه افتاده است. و 451 4.7.26 مشکل SPF یا DKIM نیست — درمانش نِیم‌سرور پایدار است.

SPF چیست و چرا معمولاً اشتباه تنظیم می‌شود؟

SPF یک رکورد TXT روی خود دامنه است که فهرست می‌کند کدام سرورها اجازه دارند با نام آن دامنه ایمیل بفرستند. گیرنده آی‌پی طرف مقابل را با این فهرست می‌سنجد و نتیجه را none (دامنه اصلاً رکورد SPF ندارد — پرتکرارترین حالت)، pass، fail، softfail، neutral یا خطا (temperror و permerror) اعلام می‌کند:

dig +short TXT example.com

"v=spf1 ip4:203.0.113.10 include:_spf.example.net ~all"

نکته‌ی حیاتی که بیشتر راهنماهای فارسی از قلم می‌اندازند: SPF دامنه‌ی MAIL FROM را می‌سنجد — و وقتی MAIL FROM خالی باشد، مثل نامه‌های برگشتی، نام میزبانی را که در HELO/EHLO اعلام شده — و کاری به هدر From ندارد؛ یعنی SPF می‌تواند کاملاً درست باشد و نامه باز هم جعلی علامت بخورد. ضعف دومش بازارسال است: سرور فوروارد‌کننده در فهرست شما نیست و نتیجه fail می‌شود.

پنج خطای رایج در رکورد SPF

RFC 7208 محدودیت‌هایی گذاشته که نادیده‌گرفتنشان رکورد را بی‌اثر می‌کند:

• دو رکورد SPF هم‌زمان. بند ۳٫۲ می‌گوید یک دامنه نباید بیش از یک رکورد قابل‌انتخاب داشته باشد؛ رکورد دوم یعنی permerror و عملاً هیچ SPF.
• عبور از سقف ده جست‌وجوی DNS. بند ۴٫۶٫۴ این جست‌وجوها را به ۱۰ محدود می‌کند و هر include، a، mx، ptr، exists و redirect — از جمله تودرتوها — شمرده می‌شود. بعضی includeها ارزان‌اند و بعضی گران، و راه سنجیدنش این است که خودِ رکورد را باز کنید: dig +short TXT _spf.google.com امروز رکوردی صاف و فقط پر از ip4 و ip6 برمی‌گرداند، پس تمام هزینه‌اش همان یک جست‌وجوی include است؛ اما اگر در خروجی include دیگری دیدید، آن‌ها را هم باید شمرد — و includeهای بعضی سرویس‌های بازاریابی چند لایه تودرتو می‌روند. این بررسی را برای هر سرویسی که include می‌کنید تکرار کنید، چون رکورد سرویس‌دهنده بدون اطلاع شما عوض می‌شود.
• تکیه بر مکانیزم ptr. بند ۵٫۵ می‌گوید نباید منتشر شود، چون کند است و بار سنگینی روی نِیم‌سرورها می‌گذارد.
• رکورد بیش از حد بلند. بند ۳٫۴ فقط توصیه می‌کند پاسخ پرس‌وجو در ۵۱۲ اوکتت جا شود؛ این یک SHOULD است و امروز با EDNS0 معمولاً مشکل‌ساز نیست. سقف سختی که واقعاً رکورد را می‌شکند همان ۲۵۵ بایتِ هر رشته‌ی TXT است — اگر رکورد SPF از آن رد شد، باید مثل DKIM به چند رشته‌ی نقل‌قول‌شده در یک رکورد تقسیمش کنید.
• انتخاب نسنجیده‌ی -all. یعنی «هرچه غیر از این فهرست است جعلی است» و متن خطای 550 5.7.26 جی‌میل دقیقاً به همین اشاره می‌کند. تا مطمئن نشده‌اید همه‌ی فرستنده‌ها را می‌شناسید، ~all امن‌تر است.

نیمی از خطاهای SPF در واقع خطای نحو رکورد است؛ اگر نحو TXT برایتان جا نیفتاده، اول راهنمای رکوردهای DNS را بخوانید.

DKIM چیست؟ امضای دیجیتالی که روی خود ایمیل سفر می‌کند

DKIM امضایی رمزنگاری‌شده است که سرور فرستنده روی بخش‌هایی از نامه — از جمله هدر From و بدنه — می‌گذارد و در هدر DKIM-Signature حمل می‌کند. کلید خصوصی روی سرور می‌ماند و کلید عمومی در DNS، در نشانی selector._domainkey.example.com، منتشر می‌شود. مزیتش نسبت به SPF این است که امضا داخل نامه سفر می‌کند، پس بازارسال نمی‌شکندش.

چرا کلید ۲۰۴۸ بیتی در یک رشته جا نمی‌شود

RFC 8301 می‌گوید امضاکننده باید دست‌کم کلید ۱۰۲۴ بیتی داشته باشد و بهتر است ۲۰۴۸ بیتی باشد. اندازه‌ی واقعی p= را خودتان بسنجید:

openssl genrsa -out dkim.pem 2048
openssl rsa -in dkim.pem -pubout -outform DER | base64 -w0 | wc -c

392

یعنی p= برای کلید ۲۰۴۸ بیتی دقیقاً ۳۹۲ کاراکتر base64 است و با پیشوند v=DKIM1; k=rsa; p= به حدود ۴۱۰ کاراکتر می‌رسد — در حالی که RFC 1035 برای هر «رشته‌ی کاراکتری» در DNS سقف ۲۵۵ بایت گذاشته است. راه‌حل، دو رکورد TXT نیست؛ یک رکورد TXT است با چند رشته‌ی نقل‌قول‌شده‌ی پشت‌سرهم که گیرنده بدون فاصله به هم می‌چسباند:

dig +short TXT mail._domainkey.example.com

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB...first 255 bytes..." "...remainder of the base64 key...IDAQAB"

سوئیچ -w0 مخصوص نسخه‌ی گنوی base64 است؛ اگر روی مک یا BSD کار می‌کنید به‌جایش openssl rsa -in dkim.pem -pubout -outform DER | openssl base64 -A | wc -c را بزنید. یک راه فرار از کل این ماجرا هم هست: RFC 8463 الگوریتم ed25519-sha256 را به DKIM اضافه کرده که کلید عمومی‌اش تنها ۴۴ کاراکتر base64 است و مسئله‌ی ۲۵۵ بایت اصلاً پیش نمی‌آید؛ اما پشتیبانی گیرنده‌ها از آن هنوز کامل نیست، پس اگر سراغش رفتید نامه را هم‌زمان با یک کلید RSA هم امضا کنید.

می‌توانید چند کلید DKIM هم‌زمان روی یک دامنه داشته باشید، چون هر نامه در امضایش می‌گوید با کدام سلکتور امضا شده.

تنظیم SPF و DKIM در سی‌پنل و دایرکت ادمین

تولید کلید DKIM کار کنترل‌پنل است، نه کار دستی: در سی‌پنل مسیرش Email → Email Deliverability است و در دایرکت‌ادمین (پوسته‌ی Evolution) دکمه‌ی Enable DKIM در E-Mail Manager → E-Mail Accounts؛ رکوردی که ساخته می‌شود بعد از آن در Account Manager → DNS Management دیده می‌شود. هر دو پنل کنار همان صفحه رکورد SPF پیشنهادی را هم می‌سازند. تفاوت‌های عمومی‌شان را در مقایسه‌ی کنترل‌پنل‌های رایگان شکافته‌ایم. یک نکته را صادقانه بگوییم: اگر هاستتان روی مهران هاست است، ورود مستقیم به این صفحه‌ها باز نیست و مسیر درست برای کلید DKIM سطح پنل، ثبت تیکت پشتیبانی است — در بخش ایمیل روی هاست مهران هاست دقیق‌تر می‌گوییم چه چیزی در دست خودتان است.

رکورد DMARC چیست و چه چیزی به SPF و DKIM اضافه می‌کند؟

DMARC رکورد TXT سومی است که روی _dmarc.example.com منتشر می‌شود و سه کار می‌کند: الزام می‌کند دامنه‌ای که در ایمیل تأیید شده با دامنه‌ی هدر From هم‌تراز باشد، تکلیف نامه‌ی ناهم‌تراز را روشن می‌کند، و نشانی گزارش‌های تجمیعی را می‌دهد. بدون DMARC، یک pass در SPF یا DKIM درباره‌ی نامی که کاربر می‌بیند چیزی نمی‌گوید.

استاندارد عوض شده است: pct دیگر وجود ندارد

این بخش را با دقت بخوانید، چون تقریباً هر راهنمای فارسی موجود در این نقطه قدیمی شده است. در می ۲۰۲۶ سه سند RFC 9989 و RFC 9990 و RFC 9991 منتشر شدند و RFC 7489 را منسوخ کردند. برچسب pct= همراه با rf= و ri= از استاندارد حذف شده است؛ اگر جایی دیدید که توصیه می‌کند با pct=10 شروع کنید، آن متن مربوط به پیش از ۲۰۲۶ است.

جایش را t= گرفته است؛ پیش‌فرضش n است و با t=y گیرنده طبق متن استاندارد یک پله ملایم‌تر عمل می‌کند: با p=quarantine رفتار none و با p=reject رفتار quarantine. این برچسب با سیاست none بی‌معناست. برچسب تازه‌ی دیگر np= است که سیاست را فقط برای زیردامنه‌های ناموجود تعیین می‌کند — همان جایی که جعل‌کننده‌ها سراغش می‌روند — و در نبودش sp= و بعد p= اعمال می‌شود؛ یعنی np وقتی ارزش دارد که سیاست اصلی ملایم‌تر باشد، چون با p=reject و بدون sp، زیردامنه‌های ناموجود همان reject را ارث می‌برند.

اما یک هشدار عملی درباره‌ی t=: RFC 9989 تازه در می ۲۰۲۶ منتشر شده و بیشتر گیرنده‌های بزرگ هنوز این برچسب را پیاده نکرده‌اند. متن خود استاندارد می‌گوید گیرنده باید برچسب ناشناخته را نادیده بگیرد و بقیه‌ی رکورد را اجرا کند؛ نتیجه این است که p=quarantine; t=y امروز روی بسیاری از گیرنده‌ها قرنطینه‌ی واقعی می‌گیرد، نه رفتار none. تا وقتی پشتیبانی گیرنده‌ها روشن نشده، پله‌ی امن ماندن روی p=none و خواندن گزارش‌های rua است و t=y را نشانه‌ی نیت خود بدانید، نه ضمانت.

تغییر بزرگ‌تر DMARCbis اما جای دیگری است: تا پیش از این، گیرنده برای پیدا کردن «دامنه‌ی سازمانی» به فهرست پسوندهای عمومی (PSL) تکیه می‌کرد. RFC 9989 روش تازه‌ای به نام «پیمایش درخت DNS» تعریف می‌کند — گیرنده از دامنه‌ی هدر From برچسب‌به‌برچسب بالا می‌رود و دنبال رکورد DMARC می‌گردد، و برای جلوگیری از سوءاستفاده، دامنه‌ای با بیش از هشت برچسب هم بیش از هشت پرس‌وجو خرج نمی‌کند. پیامد عملی برای شما: اگر روی زیردامنه‌ها ایمیل می‌فرستید، انتشار رکورد DMARC روی همان زیردامنه دیگر یک بهینه‌سازی نیست، تعیین‌کننده‌ی سیاستی است که اعمال می‌شود.

نردبان مهاجرت، بدون pct

مسیر امن چهار پله دارد و هر پله دست‌کم دو هفته زمان می‌خواهد:

# step 1 - observe only, and shut the door on non-existent subdomains from day one
_dmarc.example.com. IN TXT "v=DMARC1; p=none; np=reject; rua=mailto:dmarc@example.com"

# step 2 - quarantine; t=y signals testing, but assume most receivers ignore it today
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; t=y; np=reject; rua=mailto:dmarc@example.com"

# step 3 - real quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com"

# step 4 - enforce
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

پله‌ی اول را رد نکنید. گزارش‌های rua فایل‌های XML فشرده‌اند و فهرست می‌کنند چه آی‌پی‌هایی با نام دامنه‌ی شما نامه فرستاده‌اند. تقریباً همیشه یکی دو فرستنده‌ی فراموش‌شده پیدا می‌شود که با پریدن مستقیم به p=reject بی‌صدا قطع می‌شدند.

هم‌ترازی DMARC (Alignment) چیست و چرا SPF و DKIM سالم هم شکست می‌خورند؟

هم‌ترازی در DMARC یعنی دامنه‌ای که SPF یا DKIM تأیید کرده باید با دامنه‌ی هدر From یکی باشد یا زیرمجموعه‌ی همان دامنه‌ی سازمانی. هسته‌ی DMARC همین است و دلیل آن شکست نامرئی که در نمونه‌ی هدر Authentication-Results دیدیم: هر دو آزمون pass و DMARC باز هم شکست‌خورده. در حالت «آسان‌گیرانه» کافی است هر دو یک دامنه‌ی سازمانی مشترک داشته باشند، مثلاً news.example.com و foo.example.com؛ در حالت «سخت‌گیرانه» باید عیناً یکی باشند. پیش‌فرض adkim و aspf آسان‌گیرانه است. یادتان باشد که «دامنه‌ی سازمانی» را حالا پیمایش درخت DNS تعیین می‌کند، نه فهرست پسوندهای عمومی؛ برای دامنه‌های معمولی نتیجه فرقی ندارد، اما روی پسوندهای چندبخشی ممکن است متفاوت دربیاید — آنجا نتیجه را با گزارش‌های rua بسنجید، نه با فرض.

سناریوی کلاسیک: سرویس ارسال ایمیل شخص ثالث نامه را با MAIL FROM دامنه‌ی خودش می‌فرستد؛ SPF برای دامنه‌ی آن سرویس pass می‌شود، اما آن دامنه با example.com در هدر From نسبتی ندارد. دو درمان دارد و هر دو در پنل همان سرویس تنظیم می‌شوند: یا نامه را با کلید DKIM دامنه‌ی شما امضا کنند — یعنی d=example.com در امضا — یا زیردامنه‌ای اختصاصی برای Return-Path تعریف کنید که در DNS شما به سرویسشان اشاره کند.

یک تله‌ی خاص هم برای زیردامنه‌ها هست: هر زیردامنه رکورد SPF مستقل خودش را می‌خواهد و ارث نمی‌برد. اگر نامه‌های تراکنشی را از mail.example.com می‌فرستید و SPF فقط روی example.com نشسته، آن نامه‌ها SPF ندارند.

رکورد SPF و DKIM را دقیقاً در کدام ناحیه‌ی DNS بسازم؟ سه پنلی که با هم اشتباه می‌شوند

پرتکرارترین دلیل بی‌اثر بودن یک اصلاح درست همین است: رکورد صحیح، در ناحیه‌ای که هیچ‌کس نمی‌خواندش. سه سطح وجود دارد و فقط یکی معتبر است — همان که نِیم‌سرورهای دامنه به آن اشاره می‌کنند.

سطح اول پنل ثبت‌کننده‌ی دامنه است؛ بخش DNS آن فقط وقتی معتبر است که نِیم‌سرورها روی نِیم‌سرورهای خود ثبت‌کننده مانده باشند. سطح دوم پنل DNS مدیریت‌شده است — جایی که نِیم‌سرورها به آن سپرده شده‌اند. سطح سوم، ناحیه‌ی DNS خودِ حساب هاست است. اگر هاستتان روی مهران هاست است، این ناحیه را از تب «DNS» در همان پنل فارسی ویرایش می‌کنید — ورود مستقیم به سی‌پنل یا دایرکت‌ادمین به‌صورت پیش‌فرض باز نیست — و آن تب رکوردهای A، AAAA، CNAME، TXT و MX را می‌پذیرد که برای هر سه رکورد این مقاله کافی است. روی هر هاست دیگری همین ناحیه در تب DNS سی‌پنل یا دایرکت‌ادمین است. در هر دو حالت یک شرط دارد: فقط وقتی اثر می‌کند که نِیم‌سرورهای دامنه به همان هاست اشاره کنند. راه قطعی تشخیص، پرسیدن مستقیم از نِیم‌سرور معتبر است:

# 1) which nameservers are authoritative for the domain?
dig +short NS example.com

ns1.example-dns.com.
ns2.example-dns.com.

# 2) ask that nameserver directly, bypassing every cache
dig +short TXT example.com @ns1.example-dns.com
dig +short TXT _dmarc.example.com @ns1.example-dns.com
dig +short TXT mail._domainkey.example.com @ns1.example-dns.com

دو نکته درباره‌ی همین دستورها. اول اینکه dig +short NS فهرست NS داخل خودِ ناحیه را می‌دهد، نه واگذاری ثبت‌شده در رجیستری؛ اگر ناحیه‌ی قدیمی NS کهنه داشته باشد همین دستور شما را به سرور اشتباه می‌فرستد، پس در صورت شک همان را از سرورهای TLD بپرسید: dig +short NS example.com @a.gtld-servers.net. دوم اینکه +short در پاسخ SERVFAIL و REFUSED هم خالی برمی‌گردد؛ برای تفکیک «رکورد نیست» از «سرور جواب نداد» یک‌بار بدون +short بزنید و به خط status نگاه کنید. با این تفکیک، خروجی خالیِ مرحله‌ی دوم یعنی رکورد شما در ناحیه‌ی درست نیست. نکته‌ی آخر زمان است: در پنل DNS مهران هاست حداقل TTL شصت ثانیه و پیش‌فرض ۳۶۰۰ ثانیه است؛ اگر رکوردی را چند بار عوض خواهید کرد، پیش از شروع TTL را پایین بیاورید و بعد از تثبیت بالا ببرید. بازبینی MX و SPF یکی از قدم‌های فراموش‌شده‌ی جابه‌جایی هم هست و در نقشه‌ی راه انتقال سایت بدون قطعی آورده‌ایمش.

الزام‌های فرستنده در جی‌میل، یاهو و اوت‌لوک

گوگل و یاهو الزام‌هایشان برای فرستنده‌ی ایمیل را از فوریه‌ی ۲۰۲۴ اجرایی کردند و مایکروسافت بیش از یک سال بعد، از مه ۲۰۲۵، به آن‌ها پیوست. راهنمای فرستنده‌های جی‌میل برای همه‌ی فرستنده‌ها می‌گوید: دست‌کم یکی از SPF یا DKIM، اتصال TLS، رکورد PTR معتبر و هم‌خوان، قالب‌بندی مطابق RFC 5322، و نرخ اسپم زیر ۰٫۳ درصد بر اساس Postmaster Tools — گوگل هدف واقعی را زیر ۰٫۱ درصد اعلام کرده و ۰٫۳ درصد سقفی است که نباید به آن رسید. برای فرستنده‌های انبوه — ۵۰۰۰ نامه یا بیشتر در روز به حساب‌های شخصی جی‌میل، و به گفته‌ی گوگل دامنه‌ای که یک‌بار از این آستانه رد شود حتی با افت حجم هم فرستنده‌ی انبوه می‌ماند — هم SPF و هم DKIM لازم است، به‌علاوه‌ی رکورد DMARC (حتی با p=none)، هم‌ترازی دامنه‌ی From، و لغو اشتراک یک‌کلیکی با هدرهای List-Unsubscribe و List-Unsubscribe-Post.

راهنمای فرستنده‌های یاهو تقریباً همین را می‌خواهد، با نرخ شکایت زیر ۰٫۳ درصد و پاسخ به لغو اشتراک ظرف دو روز. مایکروسافت هم در آوریل ۲۰۲۵ برای فرستنده‌های پرحجم اوت‌لوک اعلام کرد دامنه‌هایی که روزانه ۵۰۰۰ نامه یا بیشتر به صندوق‌های شخصی outlook.com، hotmail.com و live.com می‌فرستند باید هر سه را داشته باشند. اعلام اول گفته بود نامه‌ی ناسازگار به Junk می‌رود، اما مایکروسافت چند روز بعد همان متن را اصلاح کرد و از ۵ مه ۲۰۲۵ نامه‌ی ناسازگار در همان جلسه‌ی SMTP با خطای دائمی 550 5.7.515 Access denied, sending domain does not meet the required authentication level رد می‌شود — نه فیلتر، نه Junk. این الزام صندوق‌های سازمانی Microsoft 365 را در بر نمی‌گیرد. نتیجه روشن است: SPF + DKIM + DMARC دیگر «کار حرفه‌ای‌ها» نیست، کف پذیرش است.

چرا ایمیل وردپرس به اسپم می‌رود؟ تابع mail() و ارسال با SMTP احراز هویت‌شده

وردپرس به‌صورت پیش‌فرض از تابع mail() در PHP استفاده می‌کند و این تابع نامه را بدون هیچ نام کاربری و رمزی مستقیم به سرویس ایمیل محلی سرور تحویل می‌دهد. دو پیامد مهم دارد. اول، نشانی پاکت را سیستم انتخاب می‌کند و معمولاً کاربر سیستمی روی نام میزبان سرور می‌شود، نه دامنه‌ی سایت — یعنی SPF برای دامنه‌ای سنجیده می‌شود که دامنه‌ی شما نیست. دوم، بسیاری از افزونه‌های فرم تماس نشانی خودِ بازدیدکننده را در هدر From می‌گذارند؛ نتیجه این است که سرور شما ادعا می‌کند نامه از gmail.com آمده و DMARC آن دامنه بلافاصله ردش می‌کند.

شکل درست، ارسال با SMTP احراز هویت‌شده روی درگاه ثبت پیام RFC 6409 است:

SMTP host:  mail.example.com
Port:       587            # STARTTLS  (465 = implicit TLS; 25 is often blocked outbound)
Encryption: STARTTLS
Username:   noreply@example.com
From:       noreply@example.com      # must be a mailbox on YOUR domain
Reply-To:   set by the form plugin to the visitor's address

قاعده‌ی طلایی فرم تماس همان خط آخر است: نشانی بازدیدکننده در Reply-To می‌نشیند، نه در From. با این کار هم دکمه‌ی «پاسخ» درست کار می‌کند و هم نامه با هویت دامنه‌ی خودتان هم‌تراز می‌ماند. گواهی TLS معتبر برای همان نام میزبان هم لازم است؛ مسیر صدورش در راهنمای نصب SSL رایگان با Certbot آمده است.

آی‌پی مشترک، رکورد PTR و لیست سیاه — بخش صادقانه

حالا به مرزی می‌رسیم که روی هاست اشتراکی از دستتان خارج است. آی‌پی خروجی ایمیل‌های شما متعلق به سرویس‌دهنده است و ده‌ها سایت دیگر هم از همان می‌فرستند. رکورد PTR — همان جست‌وجوی معکوس که جی‌میل نبودش را با 550 5.7.25 جواب می‌دهد — روی آن آی‌پی تعریف می‌شود و فقط دارنده‌ی بلوک می‌تواند تغییرش دهد. وضعیت را اما می‌توانید ببینید:

# reverse lookup of the sending IP, then confirm it resolves forward again
dig +short -x 203.0.113.10

mail.example-host.com.

dig +short A mail.example-host.com

203.0.113.10

اگر این دو با هم نخوانند، PTR هم‌خوان نیست و همان کد 550 5.7.25 را می‌گیرید؛ تنها راه تیکت‌زدن است. پیامد دوم آی‌پی مشترک، اعتبار مشترک است: هرزنامه‌ی همسایه اعتبار آن آی‌پی را پایین می‌آورد و نامه‌ی شما بی‌تقصیر در اسپم می‌نشیند. بررسی فهرست‌های سیاه ساده است اما یک تله دارد:

# octets reversed, then the zone name appended
dig +short 10.113.0.203.zen.spamhaus.org

# empty / NXDOMAIN       = not listed
# 127.0.0.2 .. 127.0.0.11 = listed; the code identifies which list

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

۸ اشتباه رایج که نامه را به اسپم می‌فرستد

جمع‌بندی الگوهایی که بیشترین سهم را در برگشت خوردن و اسپم‌شدن ایمیل سایت دارند — ستون آخر می‌گوید هرکدام را با چه دستوری روی دامنه‌ی خودتان تشخیص می‌دهید:

ایمیل روی هاست مهران هاست

صادقانه بگوییم کدام بخش این کار در پنل فارسی مهران هاست انجام می‌شود و کدام نه. پنل کاربری صندوق‌های ایمیل دامنه را مدیریت می‌کند: ساخت و حذف صندوق، تغییر رمز، سهمیه‌ی فضا و فورواردر. تولید کلید DKIM و ساخت خودکار SPF و DMARC در این پنل انجام نمی‌شود؛ اگر به کلید DKIM سطح پنل نیاز دارید، مسیر درست ثبت تیکت پشتیبانی است.

در عوض سمت DNS در اختیار خودتان است: پنل DNS مدیریت‌شده رکوردهای A، AAAA، CNAME، MX، TXT، NS، SRV و CAA را پشتیبانی می‌کند — و هر سه رکورد این مقاله TXT هستند — با حداقل TTL شصت ثانیه، پیش‌فرض ۳۶۰۰ ثانیه و نِیم‌سرورهای رایگان. یعنی اگر نِیم‌سرورهای دامنه به این پنل سپرده شده باشد، همان ناحیه‌ی معتبری را که در بخش رکورد را کجا بسازیم توضیح دادیم در اختیار دارید. و اگر نِیم‌سرورهای دامنه‌تان به‌جای پنل DNS به خود سرور هاست اشاره می‌کند، ناحیه‌ی معتبر شما تب «DNS» در صفحه‌ی سرویس هاست است؛ آنجا رکوردهای A، AAAA، CNAME، TXT و MX در دسترس‌اند و چون هر سه رکورد این مقاله TXT هستند، همان‌جا هم ساخته می‌شوند. تعداد صندوق‌های ایمیل هر پلن هم روی کارت همان پلن در صفحه‌ی میزبانی وب نوشته شده است.

یک نکته‌ی عملی درباره‌ی کلید DKIM: پنل DNS مقدار TXT را همان‌طور که وارد می‌کنید ذخیره می‌کند و خودش رشته‌ی بلند را نمی‌شکند. پس مقدار حدود ۴۱۰ کاراکتری کلید ۲۰۴۸ بیتی را خودتان به دو بخش زیر ۲۵۵ کاراکتر تقسیم کنید و هر بخش را داخل گیومه، پشت‌سرهم و در یک خط وارد کنید — به شکل "بخش اول" "بخش دوم"؛ مقدارِ بدون گیومه‌ی بلندتر از ۲۵۵ کاراکتر پذیرفته نمی‌شود. یک نکته را هم بگوییم تا انتظار اشتباهی شکل نگیرد: ابزار «بررسی رکوردهای ایمیل» در فهرست ابزارهای سایت هست اما هنوز در دست ساخت است؛ تا آن زمان همان دستورهای dig دقیق‌ترین راه‌اند.

سؤالات پرتکرار

چرا ایمیل سایت من به اسپم می‌رود؟

ایمیل سایت شما معمولاً به این دلیل به اسپم می‌رود که سرور گیرنده نتوانسته ثابت کند نامه واقعاً از دامنه‌ی ادعاشده آمده است. سه رکورد TXT این را ثابت می‌کنند: SPF سرورهای مجاز را فهرست می‌کند، DKIM امضای رمزنگاری‌شده روی نامه می‌گذارد و DMARC هم‌ترازی این دو با دامنه‌ی نمایشی را الزامی می‌کند. برای تشخیص، در جی‌میل «نمایش اصل پیام» را بزنید و هدر Authentication-Results را بخوانید؛ نتیجه‌ی هر سه همان‌جاست.

رکورد SPF چیست و چطور بسازمش؟

رکورد SPF یک رکورد TXT روی خود دامنه است که فهرست می‌کند کدام سرورها اجازه دارند با نام آن دامنه نامه بفرستند؛ شکلش شبیه v=spf1 ip4:… include:… ~all است. آن را در ناحیه‌ی DNS معتبر دامنه بسازید و سه محدودیت را رعایت کنید: یک رکورد برای هر دامنه، حداکثر ده جست‌وجوی DNS، و پرهیز از مکانیزم ptr.

خطای 550 5.7.26 در ارسال ایمیل یعنی چه؟

کد 550 5.7.26 پاسخ دائمی جی‌میل است و یعنی نامه بدون احراز هویت رسیده: نه SPF و نه DKIM فرستنده را تأیید نکرده‌اند، یا SPF دامنه‌ی MAIL FROM با سیاست -all رد شده است. چون رقم اول ۵ است، نامه قطعی برگشت می‌خورد. درمانش این است که دست‌کم یکی از SPF یا DKIM را برای همان مسیر ارسال درست کنید.

رکورد DMARC چیست و با چه سیاستی شروع کنم؟

DMARC رکورد TXT روی نشانی _dmarc دامنه است که می‌گوید دامنه‌ی تأییدشده در SPF یا DKIM باید با دامنه‌ی هدر From هم‌تراز باشد و با نامه‌ی ناهم‌تراز چه باید کرد. با p=none و یک نشانی rua شروع کنید، دو هفته گزارش‌ها را بخوانید، بعد به quarantine و در پایان reject بروید. برچسب pct از استاندارد ۲۰۲۶ حذف شده و جایش را t=y گرفته است، اما چون گیرنده‌های بزرگ هنوز t را پیاده نکرده‌اند، پله‌ها را با تغییر خودِ p= بالا ببرید.

چرا ایمیل فرم تماس وردپرس نمی‌رسد؟

ایمیل فرم تماس وردپرس معمولاً به این دلیل نمی‌رسد که افزونه‌ی فرم نشانی خودِ بازدیدکننده را در هدر From می‌گذارد؛ آن‌وقت سرور شما ادعا می‌کند نامه از دامنه‌ای مثل gmail.com آمده و سیاست DMARC آن دامنه ردش می‌کند. راه درست این است که From روی صندوقی از دامنه‌ی خودتان بماند و نشانی بازدیدکننده در Reply-To بنشیند. اگر مشکل ماند، ارسال را از mail() به SMTP احراز هویت‌شده روی پورت 587 ببرید.