SMTP پروتکلی برای تحویل پیام از برنامه به یک mail server است. در وردپرس، افزونه یا کد transport می‌تواند پیام‌های wp_mail() را به سرویس احراز هویت‌شده بسپارد. مزیت اصلی فقط «ارسال شدن» نیست؛ log، هویت دامنه، کنترل نرخ و مشاهده وضعیت تحویل، عیب‌یابی را قابل اتکاتر می‌کند.
پاسخ کوتاه: اگر سایت ایمیل تراکنشی مهم مانند بازیابی رمز، فرم یا سفارش دارد، استفاده از provider معتبر با TLS، From هم‌دامنه، SPF/DKIM و log تحویل معمولاً از mail محلی بدون مشاهده‌پذیری مناسب‌تر است. SMTP به‌تنهایی مشکل ساخته نشدن پیام یا DNS اشتباه را حل نمی‌کند.
PHP mail و SMTP چه تفاوتی دارند؟
| معیار | mail محلی | SMTP/provider |
|---|---|---|
| احراز هویت | وابسته به سرور | credential یا API مشخص |
| مشاهده‌پذیری | اغلب محدود | message ID و event تحویل |
| DNS و هویت | نیازمند کانفیگ سرور | راهنمای دامنه provider |
| نگهداری | صف و reputation با شما | بخشی بر عهده سرویس |
هیچ گزینه‌ای ذاتاً تضمین Inbox نمی‌دهد. محتوا، رضایت گیرنده، reputation و policy مقصد همچنان مهم‌اند.
معیار انتخاب سرویس
- پشتیبانی از دامنه و منطقه فعالیت شما
- log رویدادهای delivered، bounced و deferred
- نرخ و سقف متناسب با ایمیل تراکنشی
- TLS معتبر و روش امن credential
- SPF، DKIM و DMARC مستند
- امکان webhook و مدیریت bounce در صورت نیاز
سرویس بازاریابی و ایمیل تراکنشی الزاماً یک کاربرد ندارند. سفارش و reset password نباید پشت صف کمپین غیرضروری متوقف شوند.
تنظیمات حیاتی
Host، port، نوع encryption، نام کاربری و From باید دقیقاً از مستندات provider گرفته شوند. ترکیب دلخواه پورت و TLS باعث timeout یا handshake failure می‌شود. verification گواهی را برای پنهان کردن خطا خاموش نکنید؛ ساعت سرور، CA و hostname را اصلاح کنید.
رمز SMTP را کجا نگه داریم؟
credential نباید در repository، export عمومی یا screenshot باشد. اگر افزونه آن را در دیتابیس نگه می‌دارد، دسترسی مدیران، backup و secret rotation را در نظر بگیرید. در استقرار کدنویسی‌شده، environment یا secret manager با دسترسی حداقلی مناسب‌تر است. پس از افشای احتمالی، رمز باید rotate شود.
هویت دامنه و headerها
From را از دامنه تأییدشده انتخاب و آدرس کاربر فرم را در Reply-To قرار دهید. رکورد SPF را به‌جای ایجاد چند رکورد جدا، مطابق دستور provider ادغام کنید. DKIM باید با selector واقعی منتشر شود و DMARC بر اساس alignment و گزارش‌ها مرحله‌ای سخت‌گیرانه شود.
آزمون پس از تنظیم
- ارسال تست را به دو مقصد کنترل‌شده انجام دهید.
- message ID و log provider را ذخیره کنید.
- بازیابی رمز، فرم تماس و سفارش را جدا آزمایش کنید.
- From، Reply-To و headerهای احراز هویت را بررسی کنید.
- bounce و retry را بدون ارسال واقعی به مشتری شبیه‌سازی کنترل‌شده کنید.
ارسال هم‌زمان یا صف؟
برای سایت کم‌حجم، ارسال مستقیم ساده است، اما کندی provider می‌تواند درخواست کاربر را معطل کند. در فروشگاه پرترافیک، queue دوام‌دار با retry محدود، idempotency و مانیتورینگ مناسب‌تر است. صف بدون worker و alert فقط پیام را از request به محل دیگری منتقل می‌کند. ایمیل بازیابی رمز و سفارش نیز ممکن است اولویت‌های متفاوت داشته باشند.
محدودیت نرخ و retry
providerها معمولاً سقف یا rate limit دارند. retry فوری و نامحدود می‌تواند مشکل را تشدید یا پیام تکراری تولید کند. خطاهای موقت و دائمی را جدا کنید، backoff داشته باشید و پس از سقف مشخص alert بدهید. message ID یا کلید idempotency کمک می‌کند یک سفارش چند ایمیل یکسان نسازد.
SMTP یا API ارائه‌دهنده؟
برخی سرویس‌ها علاوه بر SMTP، API ارائه می‌کنند. SMTP سازگاری عمومی‌تری دارد؛ API ممکن است event و کنترل بیشتری بدهد. انتخاب باید بر اساس افزونه سازگار، قابلیت مشاهده، نگهداری credential و نیاز retry باشد. صرف جدیدتر بودن API یا ساده‌تر بودن SMTP دلیل کافی نیست.
حریم خصوصی و نگهداری داده
متن پیام، آدرس گیرنده و metadata سفارش ممکن است در log provider نگهداری شود. retention، دسترسی کارکنان، export و حذف داده را بررسی کنید. logging کامل body برای عیب‌یابی دائمی لازم نیست؛ حداقل اطلاعات لازم مانند message ID و status امن‌تر است.
اشتباه‌های رایج
- نصب هم‌زمان چند افزونه SMTP
- استفاده از From نامعتبر یا آدرس بازدیدکننده
- افشای credential در log و backup
- خاموش کردن TLS verification
- نداشتن مانیتور برای افزایش bounce یا توقف ارسال
چه زمانی SMTP کافی نیست؟
اگر وردپرس اصلاً پیام را تولید نمی‌کند، queue/cron متوقف است یا template شرطی غلط دارد، transport سالم هم پیامی دریافت نمی‌کند. ابتدا راهنمای تشخیص ارسال نشدن ایمیل وردپرس را اجرا کنید.
چه زمانی کمک تخصصی مناسب است؟
برای سایت فروشگاهی یا عضویتی، تغییر transport باید بدون از دست رفتن پیام و با آزمون flowهای اصلی انجام شود. سرویس رفع مشکل فنی وردپرس می‌تواند تنظیم WordPress، provider و DNS را یکپارچه بررسی کند.
پرسش‌های متداول
پورت 465 بهتر است یا 587؟
«بهتر» عمومی وجود ندارد؛ mode رمزنگاری و پورتی را استفاده کنید که provider مستند کرده است.
آیا SMTP رایگان برای فروشگاه کافی است؟
به سقف، log، SLA و حجم واقعی بستگی دارد. تصمیم را با نیاز عملیاتی بگیرید، نه فقط قیمت.
آیا SMTP سرعت سایت را کم می‌کند؟
ارسال synchronous می‌تواند request را منتظر بگذارد. queue کنترل‌شده و timeout مناسب برای حجم بالاتر بررسی شود.