ارسال نشدن ایمیل وردپرس را در سه مرحله بررسی کنید: آیا سایت باید پیام را تولید می‌کرد، آیا سرویس ارسال آن را پذیرفته و آیا گیرنده آن را دریافت کرده است؟ نصب SMTP فقط یکی از بخش‌های این مسیر است. برای رسیدن به جواب، یک پیام آزمایشی مشخص بفرستید و زمان، گیرنده و نتیجه هر مرحله را ثبت کنید.
این راهنما برای ایمیل‌های عملیاتی مانند بازیابی رمز، اعلان فرم و پیام سفارش ووکامرس است. اگر سفارش جدید دارید اما مشتری ایمیل نمی‌گیرد، ابتدا رویداد و تنظیم اعلان را بررسی کنید؛ سپس مسیر ارسال و احراز هویت دامنه را بسنجید. تغییر هم‌زمان چند افزونه ایمیل و چند رکورد DNS، پیدا کردن علت را دشوار می‌کند.
تولید پیام، تحویل به سرویس و رسیدن به Inbox متفاوت‌اند
طبق مستندات وردپرس، موفقیت تابع wp_mail به‌تنهایی دریافت ایمیل توسط کاربر را ثابت نمی‌کند. ممکن است درخواست پردازش شده باشد، اما پیام در مرحله بعد رد شود، در صف بماند یا به Spam برود. در مقابل، وقتی رویداد اصلاً اجرا نشده، بررسی اعتبار دامنه فرستنده توضیح نمی‌دهد چرا پیام ساخته نشده است. بنابراین ابتدا محل توقف را پیدا کنید.
| مشاهده | لایه محتمل | بررسی بعدی |
|---|---|---|
| هیچ اثری از تولید پیام نیست | رویداد، اعلان یا کد سایت | فعال‌بودن اعلان و وقوع رویداد |
| خطای اتصال یا ورود SMTP | ارتباط با ارائه‌دهنده ارسال | سرور، پورت، TLS و اطلاعات دسترسی |
| سرویس پیام را پذیرفته، گیرنده ندارد | صف، رد مقصد یا فیلتر | گزارش تحویل و کد پاسخ گیرنده |
| پیام در Spam است | احراز هویت و اعتبار فرستنده | هدر پیام و SPF، DKIM، DMARC |
| فقط یک اعلان ووکامرس نمی‌آید | تنظیم همان اعلان و وضعیت سفارش | گیرنده و رویداد مربوط به همان ایمیل |
۱. یک آزمون قابل پیگیری بسازید
یک گیرنده تحت کنترل خودتان انتخاب کنید و موضوعی یکتا مانند «آزمون اعلان سایت، نوبت اول» بگذارید. زمان ارسال و منطقه زمانی را ثبت کنید. به‌جای فشردن مکرر دکمه ارسال، یک بار آزمون بگیرید و نتیجه را دنبال کنید. اگر چند پیام مشابه با هم در جریان باشند، تطبیق لاگ با پیام دریافت‌شده سخت می‌شود و احتمال ارسال تکراری بالا می‌رود.
در صورت وجود ابزار ثبت ایمیل یا گزارش ارائه‌دهنده، شناسه پیام را نگه دارید. ثبت محتوا باید حداقلی و موقت باشد؛ ایمیل بازیابی رمز و اعلان سفارش می‌تواند حاوی اطلاعات حساس باشد. لاگ عمومی نسازید، مدت نگهداری را محدود کنید و برای گزارش مشکل فقط بخش لازم را پس از پوشاندن اطلاعات شخصی ارسال کنید.
۲. بررسی کنید رویداد موردنظر واقعاً رخ داده است
برای فرم تماس، نتیجه ثبت فرم و گیرنده اعلان را ببینید. برای بازیابی رمز، از حساب آزمایشی خودتان استفاده کنید. در ووکامرس، وضعیت واقعی سفارش و یادداشت‌های آن را بخوانید. برخی ایمیل‌ها با یک تغییر وضعیت مشخص فعال می‌شوند؛ باقی‌ماندن سفارش در انتظار پرداخت لزوماً همان اعلان سفارش پردازش‌شده را ایجاد نمی‌کند.
اگر پرداخت انجام شده اما وضعیت سفارش تغییر نکرده، ممکن است موضوع ارتباط درگاه با سایت باشد. برای امتحان ایمیل، وضعیت تعداد زیادی سفارش واقعی را تغییر ندهید. یک سفارش آزمایشی با روش امن و مطابق راهنمای درگاه بسازید و بررسی را از گزارش رویداد جدا کنید. اگر فقط یک نوع اعلان غیرفعال است، SMTP جدید آن تنظیم را فعال نمی‌کند.
بخش ایمیل‌های تنظیمات ووکامرس را باز کنید و فعال‌بودن نوع پیام، نشانی گیرنده و قالب آن را ببینید. نام گزینه‌ها با نسخه و افزونه‌ها تغییر می‌کند؛ مهم این است که همان اعلان مشکل‌دار را پیدا کنید. پس از اصلاح، همان رویداد آزمایشی را دوباره ایجاد کنید و فقط به موفقیت پیام تست افزونه SMTP اکتفا نکنید.
۳. یک مسیر ارسال مشخص انتخاب کنید
اگر میزبان ارسال از PHP را محدود کرده یا برای ارسال عملیاتی از سرویس جدا استفاده می‌کنید، اتصال SMTP یا API رسمی ارائه‌دهنده را تنظیم کنید. مقدارهای سرور، پورت و نوع رمزنگاری را از مستندات همان سرویس بگیرید. یک مقدار ثابت برای همه ارائه‌دهندگان درست نیست. استفاده از TLS با پورت نامناسب می‌تواند به شکست اتصال منجر شود.
فقط یک اتصال فعال مسئول ارسال باشد. افزونه‌های متعدد با تنظیم فرستنده یا SMTP می‌توانند رفتار یکدیگر را تغییر دهند. اطلاعات دسترسی را در کد عمومی قالب، تصویر آموزشی یا تیکت بدون حفاظت قرار ندهید. اگر ارائه‌دهنده کلید یا دسترسی محدود مخصوص ارسال دارد، از همان سازوکار رسمی استفاده کنید و دسترسی غیرضروری به صندوق‌ها ندهید.
خطا را دقیق بخوانید: timeout، رد اتصال و ناموفق‌بودن احراز هویت یک علت مشترک ندارند. timeout می‌تواند به مسیر شبکه مربوط باشد؛ خطای ورود ممکن است از اطلاعات دسترسی یا سیاست سرویس بیاید. غیرفعال‌کردن بررسی گواهی TLS راه‌حل درستی برای خطای گواهی نیست؛ نام میزبان، زمان سیستم و زنجیره اعتماد باید بررسی شوند.
۴. نشانی From را با دامنه مجاز هماهنگ کنید
برای فرم تماس، نشانی بازدیدکننده را به‌عنوان From جعل نکنید. پیام را از یک نشانی مجاز روی دامنه خودتان بفرستید و در صورت نیاز، نشانی مخاطب را در Reply-To قرار دهید. این تفاوت به پاسخ‌دادن کمک می‌کند و هویت فرستنده را با دامنه ارسال هماهنگ نگه می‌دارد. نام نمایشی زیبا، جای مجوز ارسال از دامنه را نمی‌گیرد.
ارائه‌دهنده ممکن است فقط نشانی یا دامنه تأییدشده را مجاز بداند. اگر افزونه فرستنده را بازنویسی می‌کند، نتیجه واقعی پیام را در هدر ببینید. آدرسی که در فرم تنظیم کرده‌اید الزاماً همان آدرسی نیست که پس از فیلترهای افزونه‌ها و سرویس ارسال به گیرنده نمایش داده می‌شود. مستندکردن همین تفاوت، بسیاری از بررسی‌های تکراری را حذف می‌کند.
۵. SPF، DKIM و DMARC را از روی هدر پیام بررسی کنید
SPF به مجازبودن مسیر ارسال برای دامنه مربوط می‌شود؛ DKIM امضای پیام را بررسی می‌کند؛ DMARC نیز هم‌راستایی دامنه قابل مشاهده فرستنده با نتیجه احراز هویت را در نظر می‌گیرد. داشتن سه رکورد در پنل به‌تنهایی نشان نمی‌دهد پیام از مسیر درست ارسال شده است. نتیجه را در هدر پیام واقعی و گزارش ارائه‌دهنده بخوانید.
در بخش نمایش اصل پیام یا هدر کامل، نتیجه Authentication-Results را پیدا کنید. برچسب‌هایی مانند spf=pass، dkim=pass و dmarc=pass سرنخ هستند و به معنی تضمین رسیدن به Inbox نیستند. اگر یک آزمون از سرویس قدیمی ارسال شده، رکورد سرویس جدید الزاماً روی آن اثری ندارد. نمونه پیام را با زمان و مسیر ارسال تطبیق دهید.
برای SPF چند رکورد مستقل با نسخه SPF روی یک نام نسازید. منابع مجاز باید طبق محدودیت‌ها و راهنمای ارائه‌دهندگان در سیاست صحیح جمع شوند. مقدار DKIM و selector را از سرویس واقعی بگیرید. سیاست DMARC سخت‌گیرانه را هم پیش از شناخت همه فرستنده‌های مجاز، ناگهانی اعمال نکنید؛ ممکن است نامه‌های معتبر بخش‌های دیگر سازمان تحت تأثیر قرار گیرند.
۶. اگر سرویس پیام را پذیرفته، گزارش تحویل را دنبال کنید
در پنل ارسال، وضعیت پیام را با شناسه یا گیرنده و زمان پیدا کنید. پذیرفته‌شدن در صف فرستنده با تحویل به سرور مقصد تفاوت دارد. برای bounce، کد و متن پاسخ را بخوانید؛ صندوق نامعتبر، محدودیت مقصد و مشکل احراز هویت اقدامات متفاوتی می‌خواهند. یک نشانی نامعتبر را با ارسال مکرر اصلاح نمی‌کنیم.
اگر پیام به مقصد تحویل شده ولی در Inbox نیست، Spam، قوانین صندوق و گروه‌بندی پیام‌ها را بررسی کنید. یک گیرنده مستقل دوم می‌تواند محدوده مسئله را روشن‌تر کند. با این حال، نتیجه یک صندوق را به همه سرویس‌های ایمیل تعمیم ندهید. محتوای پیام، سابقه فرستنده و الگوی ارسال نیز می‌توانند در تصمیم فیلتر مقصد نقش داشته باشند.
پس از اصلاح، سناریوی اصلی را دوباره آزمایش کنید
معیار پایان کار، دریافت همان اعلان واقعی در گیرنده آزمایشی است: فرم ثبت شود، سفارش آزمایشی به وضعیت موردنظر برسد یا بازیابی رمز اجرا شود. زمان رسیدن، فرستنده نمایش‌داده‌شده و امکان پاسخ‌گویی را بررسی کنید. سپس ثبت محتوای موقت را خاموش یا محدود کنید و نتیجه و تغییر انجام‌شده را در پرونده فنی نگه دارید.
برای ارتباطات کسب‌وکار، درباره شرایط سرویس ایمیل سازمانی آفاق هاست از پشتیبانی اطلاعات بگیرید. اگر زیرساخت و افزونه‌ها به رسیدگی مستمر نیاز دارند، مدیریت سرور و سایت آفاق هاست مسیر مرتبطی است. برای تشخیص، زمان و کد خطا را بفرستید؛ رمز ایمیل و متن کامل پیام مشتری لازم نیست.
پرسش‌های رایج
پیام تست SMTP موفق است؛ چرا ایمیل سفارش نمی‌آید؟
پیام تست فقط بخشی از مسیر ارسال را بررسی می‌کند. فعال‌بودن اعلان، گیرنده و رویداد تغییر وضعیت سفارش را جدا بسنجید.
آیا نتیجه wp_mail موفق، دریافت مشتری را ثابت می‌کند؟
خیر. این نتیجه به پردازش درخواست ارسال مربوط است. گزارش تحویل ارائه‌دهنده و بررسی صندوق مقصد برای مراحل بعد لازم است.
آیا SPF و DKIM دریافت در Inbox را تضمین می‌کنند؟
خیر. احراز هویت بخش مهمی از مسیر است، اما تصمیم فیلتر مقصد به عوامل دیگری نیز وابسته است. پیام واقعی و نتیجه تحویل را پیگیری کنید.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.