این مقاله عضو خوشهٔ «سرور و عملیات» است و ستون آن، صفحهٔ مقایسهٔ وب‌سرورهاست. موضوع را از ایمیل شروع می‌کنم چون در پروژه‌های واقعی، «ایمیل سفارش من به دستم نمی‌رسد» یکی از پرتکرارترین گزارش‌هاست و بیشترِ وقت‌ها، پاسخ در تنظیم افزونهت نیست؛ در DNS و در آدرس IP سرور است.
نکتهٔ پایه: فرستادن ایمیل با ارسال‌کردنش تمام نمی‌شود. سرور مقصد باید بتواند ثابت کند که تو اجازه داری از آن دامنه ایمیل بفرستی، وگرنه با بی‌اعتمادی برخورد می‌کند. سه رکورد برای همین ساخته شده‌اند و هر کدام سؤال متفاوتی را جواب می‌دهد.
هر کدام چه سؤالی را جواب می‌دهند
SPF می‌گوید: «از فهرست IPها یا سرویس‌هایی که اینجا نوشته‌ام، پذیرش ایمیل با این دامنه مجاز است.» یعنی یک فهرست مجاز. اگر ایمیلی از بیرون این فهرست با فرستندهٔ دامنهٔ تو دیده شود، گیرنده می‌فهمد که جعل بوده یا تنظیم ناقص.
DKIM می‌گوید: «این ایمیل امضای رمزنگاری‌شدهٔ دامنه را دارد و در مسیر تغییر نکرده.» کلید خصوصی روی سرور امضا می‌کند و کلید عمومی در DNS منتشر می‌شود. گیرنده با کلید عمومی، امضا را راستی‌آزمایی می‌کند. بدون DKIM، گیرنده فقط می‌داند چه کسی ادعا کرده فرستنده کیست.
DMARC می‌گوید: «اگر SPF یا DKIM رد شد، چه کار کنم و گزارشش را به کجا بفرست.» این رکورد، سیاست اعمال است؛ و مهم‌ترین خاصیتش این است که گزارش می‌دهد. تا DMARC با حالت گزارش فعال نباشد، تو نمی‌دانی در دنیای واقعی چه ایمیل‌هایی از دامنت رد می‌شوند.
سه رکورد، سه لایه‌اند. ترتیب درست برای راه‌اندازی هم همین است: اول SPF، بعد DKIM، بعد DMARC آهسته.
SPF: چطور ساخته شود و کجا غلط می‌شود
رکورد SPF از نوع TXT روی خود دامنه نوشته می‌شود و معمولاً با v=spf1 شروع می‌شود. یک شکل ساده روی سی‌پنل:
v=spf1 a mx ip4:203.0.113.10 -allهر بخش چه می‌گوید: a یعنی اگر IP سرورِ خودِ دامنه با IP فرستنده یکی بود، مجاز؛ mx یعنی رکوردهای مبادی این دامنه را هم بپذیر؛ ip4: یعنی یک IP مشخص؛ و -all یعنی هر چیز دیگر، رد.
سه خطای پرتکرار:
یک: دو رکورد SPF. این حالت در عمل زیاد دیده می‌شود: سی‌پنل یکی ساخته و صاحب سایت برای سرویس بازاریابی یکی دیگر اضافه کرده. گیرنده با دو رکورد SPF، اعتبارسنجی را رد می‌کند. باید یکی باشد و سرویس‌های دیگر به‌صورت include: در همان یکی بیایند:
v=spf1 a mx include:mail.thirdparty.example -allدو: استفادهٔ +all یا ?all. علامت +all عملاً می‌گوید هر IP مجاز است؛ یعنی محافظتی نداری. ~all نرم‌تر است و برای شروع خوب است، ولی -all بعد از اطمینان از صحت فهرست، درست‌تر است.
سه: فراموش‌کردن مسیر ارسال واقعی. اگر افزونهٔ تو از SMTP بیرونی استفاده می‌کند، IP سرور میزانت هیچ‌وقت فرستندهٔ واقعی نیست و باید سرویس SMTP وارد رکورد شود. همین یک مورد، نیمی از مشکل‌های بی‌دلیل را توضیح می‌دهد.
بررسی سریع با خط فرمان:
dig +short TXT example.comیا با nslookup -type=TXT روی ویندوز. اگر خروجی دو رشتهٔ v=spf1 داشتی، مشکل را پیدا کرده‌ای.
DKIM: امضا، کلید، و selectors
DKIM در DNS با نام‌های selector._domainkey.دامنه ظاهر می‌شود. چند selector معمول است و هر کدام می‌تواند کلید جدا داشته باشد؛ مثلاً یکی برای وب‌میل و یکی برای MTA اصلی. خروجی یک رکورد سالم این شکل را دارد:
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."سه نکتهٔ عملی:
امضا را باید نرم‌افزار فرستنده اعمال کند. رکورد DNS به‌تنهایی هیچ چیزی را امضا نمی‌کند. اگر در سی‌پنل یا در افزونهٔ SMTP، امضای DKIM روشن نباشد، رکورد بیهوده است. علامت این حالت: رکورد DNS هست، ولی در هدر ایمیل، DKIM-Signature نداری.
دامنهٔ امضا با آدرس «از» باید بخواند. دو دامنهٔ متفاوت در این دو جا، در بسیاری سرویس‌ها مشکوک حساب می‌شود. این در سایت‌هایی که از سرویس خبرنامهٔ بیرونی استفاده می‌کنند زیاد اتفاق می‌افتد.
کلیدها می‌چرخند. اگر کلید عوض شد و رکورد DNS قدیمی ماند، همهٔ ایمیل‌ها از همان لحظه بی‌امضای معتبر می‌شوند. در گزارش DMARC این حالت دسته‌دیده‌تر از آن است که حدس می‌زنی.
بررسی با یک ایمیل آزمایشی، بهترین راه است. آدرس آزمایشی خودت را باز کن و هدر کامل را ببین؛ دو خط این‌ها باید باشند:
Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=passاگر هر سه pass است، در مسیر درست قرار داری و مشکل اسپم احتمالاً از محتوای پیام یا از اعتبار IP است.
DMARC: با گزارش شروع کن، نه با رد کردن
رکورد DMARC روی _dmarc.دامنه نوشته می‌شود. سه مقدار سیاست: none یعنی فقط گزارش بده و کاری نکن، quarantine یعنی مشکوک‌ها را به اسپم ببر، و reject یعنی رد کن.
اشتباه رایج و پرهزینه این است که مستقیم روی reject بروند. اگر یک سرویس بیرونی (فرم، خبرنامه، CRM) از دامنهٔ تو ایمیل می‌فرستد و در SPF یا DKIM پوشش نداری، با reject همان روز، ایمیل‌های آن سرویس رد می‌شوند. ترتیب امن:
۱. _dmarc با p=none و یک آدرس گزارش بنویس:
v=DMARC1; p=none; rua=mailto:dmarc-report@example.com۲. دو تا چهار هفته صبر کن و گزارش‌ها را ببین. در گزارش‌ها، منابع ارسال با مقدار source یا ip فهرست می‌شوند؛ همان‌جا می‌فهمی چه چیزهایی واقعاً به‌جای تو ایمیل می‌فرستند.
۳. منابع مشروع را در SPF یا DKIM بگنجان.
۴. بعد از پاک شدن رد شدن‌های مجاز، سیاست را به quarantine و سپس reject ببر.
یک احتیاط: آدرس صندوق گزارش، صندوقی شلوغ با فایل‌های فشردهٔ XML است. خواندن خامش بی‌فایده است؛ یا از ابزار تجزیه‌گر استفاده کن یا فقط دو عدد را دنبال کن: شمار پیام‌های مجاز و شمار پیام‌های نامجاز در هر روز. روند این دو، جواب أکثر سؤال‌ها را می‌دهد.
رکورد PTR؛ همان چیزی که همه فراموش می‌کنند
حتی با سه رکورد سالم، ایمیل ارسالی از IP بی‌نام معکوس، بد عمل می‌کند. PTR یا DNS معکوس، آدرس IP را به نام میزبان تبدیل می‌کند. گیرنده، IP فرستنده را برعکس بررسی می‌کند تا ببیند با نام اعلامی می‌خواند یا نه.
سه نکته:
PTR را صاحب IP تعیین می‌کند، نه صاحب دامنه. یعنی در هاست اشتراکی، این کار میزبان است؛ و روی VPS، معمولاً از پنل ارائه‌دهنده. اگر میزبان اجازهٔ تنظیم ندهد، عملاً مسیر ارسال مستقیم از آن IP را نبستی.
نام معکوس باید به میزبانی برگردد که ایمیل از آن می‌آید. ناهمخوانی، نمرهٔ اعتبار را پایین می‌آورد.
مهم‌تر از نام، تاریخچهٔ IP است. IP که سابقهٔ ارسال هرزنامه داشته باشد، با همهٔ رکوردهای سالم هم سخت تحویل می‌شود. این روی VPSهای چندمستأجِر رایج است: یک همسایه بد، اعتبار IP مشترک را خراب می‌کند. علامتش: دیشب همه‌چیز درست بود، امروز نه، و تو هیچ چیزی عوض نکردی.
اگر سایتت ایمیل تراکنشی می‌فرستد و این حالت را می‌بینی، راه‌حل سالم، جداکردن مسیر ارسال از IP اشتراکی است: یا سرویس ارسال اختصاصی، یا دامنهٔ ارسال جدا روی IP تازه.
ورود‌سازی ایمیل در وردپرس؛ mail() تنها گزینه نیست
وردپرس پیش‌فرض از تابع PHP برای ارسال استفاده می‌کند. روی هاست‌های اشتراکی، این مسیر دو مشکل دارد: سرور اغلب ارسال از IP مشترک را محدود می‌کند، و آدرس فرستنده در پیام، با دامنهٔ میزبان می‌خواند نه دامنهٔ تو. نتیجه: صندوق هرزنامه یا نبود تحویل.
روش درست‌تر، اتصال SMTP با احراز هویت است. دو نکتهٔ عملی:
پورت‌ها. 465 با TLS ضمنی و 587 با ارتقای اتصال، دو مسیر متعارف‌اند. اگر اتصال برقرار نمی‌شود، معمولاً فایروال خروجی سرور، یکی از این دو را بسته است.
مخاطب «از» را با دامنهٔ خودت ست کن. اگر From روی دامنهٔ میزبان بماند، SPF و DKIM تو دربارهٔ دامنهٔ دیگری صحبت می‌کنند و DMARC رد می‌شود. ساده و شایع.
نکتهٔ تشخیصی که خیلی‌ها نمی‌دانند: ایمیل‌های خروجیِ سیستم (فرم تماس، سفارش ووکامرس، پیام بازنشانی رمز) از ایمیل‌های بازاریابی، با معیارهای متفاوتی داوری می‌شوند. اگر پیام بازنشانی رمز به اسپم می‌رود، مشکل فنی است؛ اگر خبرنامه می‌رود، ممکن است مسئلهٔ محتوا و نرخ شکایت باشد.
چطور تست کنیم و عدد را بخوانیم
آزمون در چهار سطح، از ساده به کامل:
سطح یک: رکوردها دیده شوند. با ابزار DNS، سه رکورد را بررسی کن. این فقط صحت ساختار را ثابت می‌کند، نه کارکرد.
سطح دو: ایمیل واقعی بفرست و هدر را بخوان. به دو سرویس متفاوت (مثلاً Gmail و یک میزبان ایرانی) بفرست و هر دو خط Authentication-Results را مقایسه کن. تفاوت این دو، بیشتر از هر توضیحی بهت می‌گوید کجای کار لنگ می‌زند.
سطح سه: گزارش DMARC. دو هفته با p=none. این تنها آزمون است که تو را با واقعیتِ ترافیک ارسال دامنه مواجه می‌کند، نه با آنچه فکر می‌کنی می‌فرستی.
سطح چهار: سنجش مستمر. یک ایمیل آزمایشی هفتگی از همان مسیری که فرم‌ها استفاده می‌کنند؛ و یک نگاه به صندوق هرزنامهٔ آن آدرس. این کارِ بی‌صدا، قبل از گزارش مشتری، کج‌روی را لو می‌دهد.
اگر می‌خواهی سریع تشخیص دهی، این سؤال مفید است: آیا ایمیل‌های ورودی سالم‌اند ولی خروجی‌ها می‌روند به اسپم؟ اگر بله، مشکل در مسیر ارسال توست، نه در دامنه.
چهار موقعیت واقعی و تشخیصشان
فرم تماس، ایمیل می‌فرستد ولی در صندوق نمی‌آید. معمولاً: مسیر mail() بدون SMTP، یا From روی دامنهٔ اشتباه، یا IP فاقد PTR. اول دو مورد اول را درست کن؛ ارزان‌ترند.
سفارش ووکامرس برای مشتری نرفته. اگر ایمیل مشتری به دامنهٔ خارجی می‌رود، مشکل از اعتبار IP ارسالی توست، نه تنظیم فروشگاه. یک ارسال آزمایشی به دو سرویس، مسئله را روشن می‌کند.
خبرنامه‌ها داخل هرزنامه‌اند. اگر سه رکورد سالم‌اند، علت‌های رایج‌تر: نرخ بازکردن پایین، لینک‌های کوتاه‌کنندهٔ مشکوک، و نبود راه خروج روشن. این یک مسئلهٔ اعتباری است، نه یک مسئلهٔ DNS.
ناگهان همه چیز خراب شده، بدون تغییر سمت من. بیشترین احتمال: IP مشترک یا دامنهٔ مشترک روی همان سرور، در فهرست مسدودی قرار گرفته. این روی سرورهای چندمستأجِر که سهم ارسال روزانه دارند، تقریباً اجتناب‌ناپذیر است؛ و تشخیصش از گزارش DMARC و ابزارهای بررسی فهرست مسدودی انجام می‌شود.
پیش از فرم‌ها: یک تصمیم ساختاری که نصف مشکل را کم می‌کند
قبل از تنظیم رکوردها، یک تصمیم معماری وجود دارد که در پروژه‌های واقعی، بیشتر از هر تنظیم DNS اثر می‌گذارد: مسیر ارسال را از مسیر وب‌سرور جدا کن.
دلیل عملی: روی هاست اشتراکی، IP ارسال، IP وب‌سرور است و آن IP را تو کنترل نمی‌کنی؛ نه نام معکوس، نه سابقهٔ ارسال، و نه سهم روزانه. اگر همسایه‌ات اسپم بفرستد، اعتبار همان IP می‌آید پایین و ایمیل فرم تماس تو هم زیر سؤال می‌رود. با ارسال از یک سرویس اختصاصی، این ریسک از کنترل میزبان بیرون می‌آید و به کنترل خودت برمی‌گردد؛ و رکوردهای SPF و DKIM هم تمیزتر می‌شوند، چون منبع ارسال، معلوم و یک‌تاست.
یک اشتباه معماری رایج: استفاده از همان دامنهٔ اصلی برای ارسال انبوه خبرنامه. دامنهٔ اصلی، اعتبار جستجو و ایمیل را با هم حمل می‌کند و خرابی در یکی، به دیگری هم لطمه می‌زند. روش سالم، یک زیردامنهٔ مجزا برای ارسال است با SPF و DKIM مخصوص خودش.
چک‌لیست راه‌اندازی، به ترتیب اجرا
این ترتیب را روی هر پروژه‌ای که انجام می‌دهم، اجرا می‌کنم:
۱. مسیر ارسال واقعی را مشخص کن: تابع PHP، SMTP سرور، یا سرویس بیرونی. تا این روشن نشود، نوشتن رکورد حدس است. ۲. دامنهٔ ارسال را با دامنهٔ سایت یکی کن، یا آگاهانه جدا کن و برای دامنهٔ جدا، رکورد جدا بساز. ۳. یک رکورد SPF بنویس که همهٔ منابع ارسال را پوشش بده؛ نه بیشتر، نه کمتر. ۴. از پنل هاست، SPF اضافه‌ای که خودکار ساخته شده را بردار تا فقط یکی بماند. ۵. DKIM را روی همان سرویس ارسالی روشن کن، بعد رکوردش را در DNS ببین. ۶. DMARC را با p=none و یک صندوق گزارش بنویس. ۷. دو هفته گزارش را ببین؛ هر منبع نامشروع را یا حذف کن یا مجازش کن. ۸. وقتی گزارش‌ها تمیز شد، سیاست را به quarantine ببر و بعد از آن، به reject. ۹. نام معکوس IP را با میزبان یا از پنل VPS تنظیم کن. ۱۰. یک آزمون هفتگی با یک آدرس بیرونی ثابت نگه دار.
مرحلهٔ چهارم را جدی بگیر؛ دو رکورد SPF، شایع‌ترین دلیلی است که هر سه رکورد سالم‌اند و ایمیل باز هم رد می‌شود.
با میزبان ایرانی و خارجی، فرق دارد
در عمل، گیرنده‌های خارجی سخت‌گیرانه‌ترند: Gmail و سرویس‌های بزرگ، DMARC را جدی می‌گیرند و برای فرستندهٔ حجم بالا، سابقهٔ پنل و نرخ شکایت را می‌سنجند. در مقابل، در مسیر داخلی، بسیاری از مشکلات از محدودیت‌های خروجی و IP مشترک می‌آیند نه از سیاست گیرنده.
سه پیامد عملی:
برای ایمیل سیستمی (رمز، فاکتور، اطلاع‌رسانی سفارش) لازم نیست به سرویس گران‌قیمت بروی؛ ولی باید رکوردها درست و مسیر ارسال مشخص باشد. ایمیل‌های سیستمی که نمی‌رسند، مستقیم به درآمد و اعتماد ضربه می‌زنند.
برای خبرنامه و ارسال حجم‌دار معیارها فقط DNS نیستند: فهرست تمیز، راه خروج روشن، و فاصلهٔ زمانی ارسال‌ها. نرخ بازگشت بالا، از هر تنظیم فنی، سریع‌تر اعتبار را می‌سوزاند.
برای دامنهٔ تازه انتظار فوری نداشته باش. اعتبار ارسال، مثل اعتبار جستجو، با زمان ساخته می‌شود و با یک روز ارسال سنگین، خراب.
جمع‌بندی
سه رکورد لازم‌اند و کافی نیستند: SPF یک‌دانه و کامل، DKIM با امضای واقعی و هم‌دامنه، DMARC که با گزارش شروع می‌شود. نصف دیگر ماجرا، خارج از DNS است: رکورد نام معکوس، سابقهٔ IP مشترک، و اینکه مسیر ارسال را از وب‌سرور جدا کرده‌ای یا نه.
اگر فقط یک کار می‌توانی امشب بکنی: یک ایمیل آزمایشی به یک سرویس بیرونی بفرست، هدر کامل را باز کن و سه خط spf، dkim و dmarc را بخوان. همان سه کلمهٔ داخل آن هدر، وضعیت واقعی دامنهٔ تو را می‌گوید؛ پیش از آنکه مشتری از اسپم شکایت کند.
جمع‌بندی
سه رکورد را به همین ترتیب ببند: SPF سالم و یک‌دانه، DKIM با امضای واقعی و هم‌دامنه، و DMARC که با گزارش شروع می‌شود و بعد سخت می‌گیرد. اما انتظار نداشته باش که همین سه، کافی باشند: رکورد PTR و اعتبار IP، نصف ماجرا هستند و معمولاً همان‌جا است که کار گیر می‌کند.
اعضای دیگر این خوشه، مرزهای همسایه را باز می‌کنند: راهنمای فوروارد ایمیل سی‌پنل، تفاوت پورت‌های ارسال و سهم روزانهٔ آن‌ها روی VPS، و اینکه چرا حذف وب‌شل از روی سرور، فقط نیمی از راه است.
مقالبی بخوانی
- forward-cpanel-email-to-gmail
- email-database-dns-site-hosting
- تفاوت LiteSpeed با Nginx و Apache برای وردپرس؛ کدام وب‌سرور واقعیت را سریع می‌کند؟
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.