نرسیدن ایمیل سفارش یک مسیر واحد ندارد. ممکن است رویداد ایمیل اصلاً به‌دلیل وضعیت سفارش اجرا نشده باشد، گیرنده یا template اشتباه باشد، وردپرس پیام را ساخته ولی SMTP آن را رد کرده باشد، یا سرور مقصد پیام پذیرفته و آن را در Spam قرار داده باشد. پیام «ارسال شد» در وردپرس فقط تحویل قطعی به Inbox را ثابت نمی‌کند.
پاسخ سریع: یک شماره سفارش و نوع ایمیل مشخص انتخاب کنید—مثلاً «سفارش جدید» مدیر یا «در حال پردازش» مشتری. وضعیت و note سفارش، فعال بودن همان notification و گیرنده را بررسی کنید. سپس log برنامه و SMTP را با timestamp و Message-ID تطبیق دهید؛ بدون این تفکیک، تغییر DNS یا نصب چند افزونه ایمیل کمکی نمی‌کند.
دقیقاً کدام ایمیل نمی‌رسد؟
| نوع پیام | مخاطب معمول | عامل آغاز |
|---|---|---|
| سفارش جدید | مدیر فروشگاه | ایجاد/وضعیت تعریف‌شده سفارش |
| در انتظار یا ناموفق | مشتری یا مدیر، بسته به نوع | تغییر وضعیت مشخص |
| در حال پردازش/تکمیل‌شده | مشتری | ورود سفارش به همان وضعیت |
| بازنشانی رمز | کاربر | رویداد حساب، مستقل از سفارش |
اگر reset password هم نمی‌رسد، مشکل عمومی‌تر از ووکامرس است و راهنمای ارسال‌نشدن ایمیل وردپرس اولویت دارد. اگر فقط یک notification خراب است، trigger، تنظیم و template همان نوع را بررسی کنید.
وضعیت سفارش Trigger را تعیین می‌کند
ایمیل پردازش سفارش زمانی انتظار می‌رود که سفارش واقعاً به وضعیت متناظر برسد. اگر پرداخت موفق است اما سفارش Pending یا Failed مانده، ایمیل ممکن است مطابق طراحی اجرا نشود. ابتدا مشکل وضعیت را با تطبیق پرداخت موفق و سفارش ناموفق حل کنید؛ ارسال دستی ایمیل علت وضعیت نادرست را پنهان می‌کند.
تنظیمات Notification و گیرنده
در WooCommerce → Settings → Emails، فعال بودن نوع ایمیل، recipient، subject و heading را بررسی کنید. ایمیل مدیر ممکن است هنوز به نشانی قدیمی برود. جداکننده و قالب نشانی‌ها باید مطابق رابط همان نسخه باشد. برای مشتری، billing email همان سفارش را کنترل کنید؛ ویرایش پروفایل کاربر الزاماً سفارش قبلی را تغییر نمی‌دهد.
Template Override و محتوای خالی
قالب یا افزونه ممکن است template ایمیل ووکامرس را override کرده باشد. گزارش وضعیت ووکامرس نسخه templateهای قدیمی را نشان می‌دهد. روی staging با template استاندارد مقایسه کنید. فایل اصلی WooCommerce را ویرایش نکنید؛ update بعدی تغییر را حذف می‌کند و اختلاف نسخه باقی می‌ماند.
اگر ایمیل می‌رسد ولی سفید یا ناقص است، source پیام و خطای PHP هنگام render را بررسی کنید. داده سفارشی سفارش ممکن است در یک hook exception ایجاد کند. نمایش خطای PHP به مشتری را فعال نکنید و اطلاعات سفارش را از log عمومی حذف کنید.
زبان، ترجمه و جهت نمایش
در فروشگاه چندزبانه، template، subject و locale ممکن است بر اساس زبان سفارش یا کاربر انتخاب شود. اگر فقط ایمیل فارسی ارسال نمی‌شود، template ترجمه‌شده، placeholderها و exception هنگام render را با نسخه سالم مقایسه کنید. تغییر زبان مدیر معیار زبان پیام مشتری نیست. قالب HTML باید در clientهای مختلف خوانا باشد و متن فارسی RTL، اما URL، کد رهگیری و قطعه‌کد در صورت نیاز LTR باقی بمانند.
فونت وب معمولاً در همه email clientها دانلود یا اجرا نمی‌شود؛ fallback مناسب تعریف کنید و تحویل پیام را به بارگذاری فونت وابسته نکنید. CSS پیچیده یا script در ایمیل قابل اتکا نیست و ممکن است توسط مقصد حذف شود.
wp_mail() چه چیزی را ثابت می‌کند؟
موفقیت تابع ارسال معمولاً یعنی لایه انتقال پیام را برای ارسال پذیرفته است، نه اینکه mailbox مقصد آن را تحویل گرفته باشد. برای تشخیص باید حداقل زمان، گیرنده، subject امن، Message-ID، پاسخ SMTP و provider event را داشته باشید. متن و داده شخصی سفارش را بی‌دلیل log نکنید.
SMTP را درست و امن تنظیم کنید
ارسال مستقیم PHP mail روی بسیاری از سرورها deliverability و قابلیت پیگیری مناسبی ندارد. SMTP یا API سرویس تراکنشی، احراز هویت و log روشن‌تری می‌دهد. راهنمای تنظیم SMTP وردپرس تفاوت transport، رمزنگاری و From را توضیح می‌دهد. رمز SMTP را در repository، screenshot یا log قرار ندهید و پس از افشا rotate کنید.
پورت، روش رمزنگاری و hostname باید دقیقاً مطابق ارائه‌دهنده باشد. خاموش‌کردن بررسی TLS برای عبور از خطای گواهی راه‌حل امنی نیست. DNS، ساعت سیستم، CA chain و hostname را اصلاح کنید.
From، SPF، DKIM و DMARC
نشانی From بهتر است از دامنه‌ای باشد که سرویس ارسال برای آن مجاز است. SPF مشخص می‌کند کدام سرویس‌ها اجازه ارسال دارند، DKIM امضای دامنه را فراهم می‌کند و DMARC سیاست و گزارش هم‌ترازی را تعریف می‌کند. افزودن چند رکورد SPF جداگانه یا کپی تنظیمات دامنه دیگر می‌تواند اعتبارسنجی را خراب کند؛ DNS را طبق مستندات provider و با یک رکورد معتبر طراحی کنید.
From و Reply-To یک چیز نیستند. می‌توان ارسال فنی را از نشانی معتبر دامنه انجام داد و پاسخ مشتری را به کانال پشتیبانی هدایت کرد، مشروط به تنظیم درست و جلوگیری از جعل header.
صف، Cron و Action Scheduler
بعضی افزونه‌ها ایمیل را async می‌فرستند. در این حالت ثبت سفارش فقط job می‌سازد و خرابی cron یا consumer باعث تأخیر می‌شود. صف pending/failed را بر اساس hook، سن و exception بررسی کنید. حذف همه jobها یا اجرای گروهی بدون شناخت می‌تواند ایمیل تکراری برای مشتریان بفرستد.
Concurrency، Retry و ایمیل تکراری
اگر worker پس از ارسال پیام ولی پیش از ثبت موفقیت متوقف شود، job ممکن است دوباره اجرا شود. Message-ID، شناسه سفارش و attempt را مقایسه کنید تا retry واقعی از دو trigger مستقل جدا شود. افزایش تعداد worker می‌تواند backlog را کم کند، اما بدون قفل و idempotency احتمال ارسال هم‌زمان را بیشتر می‌کند.
سیاست retry باید بین خطای موقت مانند timeout و خطای دائمی مانند mailbox نامعتبر تفاوت بگذارد. retry سریع و نامحدود reputation را آسیب می‌زند و صف پیام‌های سالم را عقب می‌اندازد. backoff، سقف تلاش و dead-letter یا وضعیت نیازمند بررسی را متناسب با ابزار موجود تنظیم کنید.
تحویل شده، Spam یا Bounce؟
اگر provider پیام را پذیرفته، eventهای delivered، deferred، bounced و complained را بررسی کنید. Inbox نبودن با ارسال‌نشدن یکی نیست. mailbox پر، نشانی نامعتبر، سیاست مقصد یا reputation می‌تواند bounce ایجاد کند. برای یک دامنه و یک mailbox آزمایشی نتیجه نگیرید؛ چند مقصد کنترل‌شده داشته باشید، اما ایمیل واقعی مشتری را بدون ضرورت به ابزارهای ناشناس ندهید.
چرا ایمیل فقط برای مدیر یا فقط برای مشتری نمی‌رسد؟
اگر همه پیام‌های مدیر غایب‌اند، recipient و policy دامنه سازمانی را بررسی کنید. اگر فقط مشتری مشکل دارد، billing email، trigger وضعیت و bounce همان مقصد مهم است. اگر یک provider خاص مشکل دارد، header، authentication result و event تحویل را مقایسه کنید؛ ارسال دوباره انبوه راه تشخیص نیست.
یک فرایند تشخیص قابل تکرار
- شماره سفارش، نوع notification و گیرنده را مشخص کنید.
- وضعیت و زمان transition سفارش را کنترل کنید.
- فعال بودن ایمیل و template را بررسی کنید.
- log ساخت پیام و transport را با Message-ID پیدا کنید.
- پاسخ SMTP/API و event تحویل را بخوانید.
- SPF، DKIM، DMARC و From را در صورت مشکل تحویل بررسی کنید.
- پس از اصلاح، یک سفارش کنترل‌شده و یک resend آگاهانه تست کنید.
ارسال مجدد بدون ساخت پیام تکراری
پیش از resend مطمئن شوید provider پیام قبلی را deferred نکرده است؛ ممکن است کمی بعد تحویل شود. ارسال مجدد باید برای همان سفارش و نوع ایمیل ثبت شود. از تغییر رفت‌وبرگشتی وضعیت فقط برای تحریک notification استفاده نکنید، چون موجودی، webhook و integrationهای دیگر نیز ممکن است اجرا شوند.
مانیتورینگ پیشنهادی
- نرخ failure و bounce سرویس تراکنشی
- سن قدیمی‌ترین job ایمیل در صف
- هشدار credential یا quota
- تست دوره‌ای ایمیل تراکنشی غیرواقعی
- گزارش انقضای DNS/دامنه و تغییر policy
- نمونه‌برداری از زمان سفارش تا پذیرش provider
اشتباه‌های رایج
- نصب هم‌زمان چند افزونه SMTP
- تغییر وضعیت سفارش برای ارسال مجدد
- ثبت رمز و داده سفارش در log
- خاموش کردن TLS verification
- فرض اینکه Spam یعنی وردپرس ارسال نکرده
- حذف صف pending بدون بررسی
- استفاده از From نامعتبر یا SPFهای متعدد
چه زمانی کمک تخصصی لازم است؟
اگر ایمیل‌های سفارش به‌صورت متناوب گم می‌شوند، وضعیت سفارش درست است اما provider پیامی نمی‌بیند، یا resend خطر اجرای دوباره عملیات دارد، پشتیبانی فروشگاه ووکامرس می‌تواند trigger، template، queue، transport و event تحویل را با یک Message-ID دنبال کند.
پرسش‌های متداول
آیا SMTP رسیدن به Inbox را تضمین می‌کند؟
خیر؛ قابلیت رهگیری و احراز هویت را بهتر می‌کند، اما مقصد، reputation و محتوای پیام نیز اثر دارند.
چرا ایمیل «سفارش جدید» به مشتری نمی‌رسد؟
این notification معمولاً برای مدیر است؛ نوع ایمیل مشتری و وضعیت سفارش را جدا بررسی کنید.
آیا می‌توان از Gmail شخصی برای فروشگاه استفاده کرد؟
باید محدودیت، روش احراز هویت و سیاست سرویس را بررسی کنید؛ برای حجم و پیام تراکنشی، سرویس مناسب و قابل مانیتور انتخاب کنید.
چرا تست SMTP موفق است ولی ایمیل سفارش نه؟
transport احتمالاً سالم است؛ trigger، وضعیت سفارش، recipient، render template و صف را بررسی کنید.