خطای عدم ارسال ایمیل توسط افزونه

کاربر فرم تماس را پر می‌کند، دکمه ارسال را می‌زند، پیام موفقیت سبز ظاهر می‌شود، ولی هیچ ایمیلی به دست شما نمی‌رسد. سفارش ووکامرس ثبت می‌شود ولی ایمیل تأیید برای مشتری ارسال نمی‌شود. اگر با خطای عدم ارسال ایمیل توسط افزونه روبرو هستید، این مقاله همان مسیری را طی می‌کند که در سال‌ها کار روی صدها پروژه واقعی وردپرس بارها و بارها پیموده‌ام. برخلاف خطاهای PHP یا JS که خودشان را در لاگ یا کنسول نشان می‌دهند، خطای ارسال ایمیل معمولاً ساکت است: تابع موفقیت برمی‌گرداند، پیام سبز نمایش داده می‌شود، ولی ایمیل هرگز به دست گیرنده نمی‌رسد. این خطا در عمل همیشه در یکی از پنج لایه مشخص ریشه دارد: پیکربندی نادرست wp_mail و توابع مرتبط، نبود SMTP و احراز هویت، مشکل در SPF، DKIM و DMARC، فیلتر شدن توسط هاست یا فیلترهای ضداسپم، و مدیریت نادرست صف و لاگ تحویل. اگر این پنج لایه را به ترتیب بررسی کنید، تقریباً همیشه به علت دقیق می‌رسید بدون آنکه ساعت‌ها وقت خود را صرف آزمون‌وخطا کنید.

ایمیل افزونه ارسال نمی‌شود — تفکیک نشانه‌ها

قبل از هر اقدامی باید مشخص کنید کدام یک از این پنج نشانه را می‌بینید، چون هرکدام جهت عیب‌یابی را به لایه متفاوتی هدایت می‌کند. نشانه اول: تابع wp_mail مقدار false برمی‌گرداند. این صریح‌ترین حالت است و مستقیماً به لایه اول (پیکربندی wp_mail) یا لایه دوم (SMTP) اشاره دارد. اگر با معماری کلی افزونه‌های وردپرس آشنایی ندارید، پیش از ادامه نگاهی به افزونه وردپرس چیست بیندازید تا لایه‌بندی و چرخه ارسال ایمیل را در ذهن داشته باشید.

نشانه دوم: تابع wp_mail مقدار true برمی‌گرداند ولی ایمیل دریافت نمی‌شود. این حالت شایع‌ترین حالت است و به لایه سوم (SPF و DKIM)، لایه چهارم (فیلتر هاست) یا لایه پنجم (صف و تاخیر) برمی‌گردد. نکته مهم: مقدار true از wp_mail فقط یعنی «پیام به سرور ارسال سپرده شد»، نه اینکه «به دست گیرنده رسید». نشانه سوم: ایمیل به برخی گیرندگان می‌رسد و به برخی دیگر نه. این حالت تقریباً همیشه به لایه سوم یا چهارم مربوط است — سرور گیرنده یا پیکربندی DNS شما در یک سرویس ایمیل مقصد پذیرفته نمی‌شود. نشانه چهارم: ایمیل مستقیم به پوشه اسپم گیرنده می‌رود. این نشانه مستقیماً به لایه سوم (SPF، DKIM، DMARC) اشاره دارد. نشانه پنجم: ایمیل با تأخیر زیاد (چند ساعت) می‌رسد. این حالت به لایه پنجم (صف ایمیل) یا به rate limiting سرور اشاره دارد.

در عیب‌یابی ایمیل، مقدار بازگشتی wp_mail گمراه‌کننده است. مقدار true فقط یعنی «پیام به MTA محلی سپرده شد»، نه اینکه «به گیرنده رسید». تفاوت میان این دو معنا، منشأ سردرگمی بسیاری از توسعه‌دهندگان است.

wp_mail در وردپرس چطور کار می‌کند؟

وردپرس برای ارسال ایمیل، تابعی به نام wp_mail دارد که یک wrapper ساده روی تابع mail بومی PHP است. وقتی افزونه شما wp_mail را صدا می‌زند، وردپرس پارامترها را آماده می‌کند، هوک‌های مختلف را اجرا می‌کند و در نهایت تابع mail را فراخوانی می‌کند. تابع mail به نوبه خود پیام را به MTA (Mail Transfer Agent) محلی سرور می‌سپارد. از این لحظه، مسئولیت تحویل پیام به سرور گیرنده، بر عهده MTA است و خارج از کنترل وردپرس. اگر با مفهوم افزونه وردپرس و لایه‌های آن آشنا نیستید، پیش از ادامه آن مقاله را مرور کنید.

چهار مکانیزم اصلی که در فرآیند ارسال دخیل‌اند: اول، تابع wp_mail که پیش از ارسال، فیلترهای مختلفی مثل wp_mail_from، wp_mail_from_name، wp_mail_content_type و wp_mail را اجرا می‌کند. دوم، فیلتر phpmailer_init که به افزونه‌ها اجازه می‌دهد پیکربندی SMTP را تغییر دهند. سوم، خود تابع mail PHP یا PHPMailer که در وردپرس مدرن جایگزین شده است. چهارم، MTA محلی سرور (مثل Postfix، Exim یا Sendmail) که مسئول ارسال واقعی است. برای مرور اصول کلی ارتباط با SMTP و روش‌های ارسال ایمیل در وردپرس، SMTP و ارسال ایمیل از وب‌سایت را ببینید — این مقاله بر پیش‌فرض آشنایی با آن بنا شده است.

لایه	مسئولیت	نشانه خطا
wp_mail	آماده‌سازی پارامترها و فیلترها	return false یا خطای پارامتر
PHPMailer / SMTP	ارسال به MTA یا SMTP خارجی	return false یا خطای احراز هویت
DNS و اعتبار دامنه	SPF، DKIM، DMARC	رفتن به اسپم یا رد شدن
MTA سرور	تحویل به سرور گیرنده	تاخیر زیاد یا بلاک شدن
سرور گیرنده	پذیرش یا رد پیام	عدم تحویل یا اسپم

این جدول، نقشه راه عیب‌یابی است. اگر wp_mail مقدار false برمی‌گرداند، به لایه اول یا دوم بروید. اگر true برمی‌گرداند ولی ایمیل نمی‌رسد، به لایه‌های سوم، چهارم یا پنجم بروید. این تفکیک ساده، نیمی از عیب‌یابی است و در پروژه‌های واقعی مرا از ساعت‌ها سردرگمی نجات داده.

لایه اول — پیکربندی نادرست wp_mail و پارامترها

شایع‌ترین علت عدم ارسال ایمیل، خطا در خود فراخوانی wp_mail است. سه اشتباه رایج در این لایه وجود دارد که هرکدام می‌تواند باعث return false یا خطای silent شود.

پارامترهای نادرست یا ناقص

تابع wp_mail پنج پارامتر می‌گیرد: $to، $subject، $message، $headers، $attachments. اگر پارامتر $to یک ایمیل معتبر نباشد یا $subject خالی باشد، تابع false برمی‌گرداند. الگوی درست:

$to      = 'user@example.com';
$subject = 'تأیید سفارش شما';
$message = 'سفارش شما با موفقیت ثبت شد.';
$headers = array( 'Content-Type: text/html; charset=UTF-8' );

$sent = wp_mail( $to, $subject, $message, $headers );

if ( ! $sent ) {
    error_log( 'wp_mail failed for: ' . $to );
}

سه نکته کلیدی: اول، بررسی ایمیل معتبر با is_email پیش از فراخوانی. دوم، همیشه Content-Type را با charset=UTF-8 تنظیم کنید تا متن فارسی به‌درستی منتقل شود. سوم، همیشه مقدار بازگشتی wp_mail را بررسی کنید و در صورت شکست، لاگ بگیرید. عدم بررسی بازگشت، شایع‌ترین اشتباه در کد افزونه‌هاست. برای مرور اصول دقیق ارسال ایمیل و پارامترهای آن، توابع وردپرس برای ارسال ایمیل و همچنین توابع ایمیل وردپرس را ببینید.

هدرهای نادرست و مشکلات charset

اگر ایمیل شما فارسی یا با کاراکترهای یونیکد است و charset=UTF-8 را تنظیم نکرده‌اید، ممکن است پیام به‌عنوان اسپم تلقی شود یا در سمت گیرنده به‌شکل نامفهوم نمایش داده شود. الگوی درست هدرها:

$headers = array(
    'Content-Type: text/html; charset=UTF-8',
    'From: My Site <noreply@example.com>',
    'Reply-To: support@example.com',
);

نکته حساس: هدر From باید با دامنه سایت شما هم‌خوانی داشته باشد. اگر هدر From با دامنه‌ای غیر از دامنه سایت باشد و SPF آن دامنه اجازه ارسال از سرور شما را نداشته باشد، پیام رد می‌شود. یک اشتباه رایج در پروژه‌های واقعی: استفاده از From: WordPress <wordpress@example.com> که با دامنه سایت جور نیست یا از یک سرویس عمومی مثل Gmail استفاده می‌کند. نتیجه: فیلترهای ضداسپم پیام شما را بلاک می‌کنند.

فراخوانی زودهنگام یا اشتباه در هوک

اگر wp_mail را در هوکی صدا بزنید که پیش از آماده شدن سیستم ایمیل اجرا می‌شود، ممکن است تابع به‌درستی کار نکند. هوک مناسب برای ارسال ایمیل، معمولاً بعد از init است. الگوی توصیه‌شده:

add_action( 'init', 'my_plugin_setup_email_sending' );

function my_plugin_setup_email_sending() {
    if ( isset( $_POST['my_form_submit'] ) ) {
        // پردازش فرم و ارسال ایمیل
    }
}

اشتباه رایج دیگر: استفاده از wp_mail در هوک admin_init برای ارسال ایمیل به کاربران front-end. این اشتباه در بافت پلاگین‌های فرم که در پیشخوان تست می‌شوند شایع است. برای مطالعه دقیق هوک‌ها، نحوه استفاده صحیح از هوک‌های وردپرس را ببینید.

در ارسال ایمیل، جزئیات کوچک اثر بزرگی دارند. یک هدر Content-Type فراموش‌شده، یک charset نادرست، یا یک From نادرست می‌تواند تفاوت بین ایمیل رسیده و ایمیل ردشده باشد. دقت در این لایه، همه چیز است.

لایه دوم — SMTP و احراز هویت

لایه دوم جایی است که wp_mail درست صدا زده می‌شود ولی چون PHP Mail سرور شما به سرور گیرنده احراز نمی‌کند، پیام رد می‌شود. در سال‌های اخیر با سخت‌گیری سرویس‌هایی مثل Gmail و Outlook، استفاده از SMTP با احراز هویت تقریباً اجباری شده است.

نصب و پیکربندی افزونه SMTP

ساده‌ترین راه تنظیم SMTP در وردپرس، نصب یک افزونه SMTP است. سه گزینه محبوب: WP Mail SMTP، Post SMTP، و FluentSMTP. از این سه، FluentSMTP به‌دلیل رابط کاربری سبک و پشتیبانی خوب از SMTPهای مختلف، انتخاب شخصی من است. الگوی پیکربندی عمومی:

Host:     smtp.example.com
Port:     587
Encryption: TLS
Username: your-email@example.com
Password: [رمز عبور یا app password]

سه نکته کلیدی: اول، اکثر سرویس‌های مدرن مثل Gmail نیاز به app password دارند نه رمز اصلی. دوم، پورت 587 با TLS معمولاً پیشنهاد اول است؛ اگر مسدود بود، پورت 465 با SSL را امتحان کنید. سوم، همیشه پس از پیکربندی، دکمه «ارسال ایمیل تست» را از خود افزونه SMTP اجرا کنید.

پیکربندی SMTP از طریق فیلتر phpmailer_init

اگر نمی‌خواهید افزونه اضافی نصب کنید، می‌توانید SMTP را مستقیماً در کد افزونه یا functions.php قالب فرزند پیکربندی کنید:

add_action( 'phpmailer_init', 'my_plugin_configure_smtp' );

function my_plugin_configure_smtp( $phpmailer ) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtp.example.com';
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Username   = 'your-email@example.com';
    $phpmailer->Password   = 'your-app-password';
    $phpmailer->SMTPSecure = 'tls';
    $phpmailer->Port       = 587;
    $phpmailer->From       = 'noreply@example.com';
    $phpmailer->FromName   = 'My Site';
}

نکته امنیتی مهم: هرگز رمز SMTP را در کد هاردکد نکنید. بهترین روش، ذخیره آن در wp-config.php به‌عنوان ثابت است:

define( 'MY_SMTP_PASSWORD', 'your-app-password' );
// در کد:
$phpmailer->Password = MY_SMTP_PASSWORD;

این کار جلوی افشای رمز در صورت نشت کد از طریق بکاپ یا افزونه‌های بازرسی را می‌گیرد. اصول امنیتی کلید و رمز در بافت وردپرس در نوشتن کد PHP امن برای وردپرس آمده است.

احراز هویت با OAuth2 و API

برخی سرویس‌ها مثل Gmail و Microsoft 365 به‌طور تدریجی از احراز هویت با رمز عبور ساده پشتیبانی نمی‌کنند و به OAuth2 روی آورده‌اند. اگر با این سرویس‌ها کار می‌کنید و افزونه SMTP شما از OAuth2 پشتیبانی می‌کند، باید اپلیکیشن را در کنسول سرویس ثبت کنید و client_id و client_secret بگیرید. این پیچیدگی برای کاربران نهایی می‌تواند گیج‌کننده باشد، ولی برای امنیت و پایداری ارزشش را دارد. مکانیزم دقیق OAuth2 در OAuth چیست و چگونه کار می‌کند توضیح داده شده است.

سرویس‌های ایمیل تراکنشی

برای سایت‌های پربازدید یا فروشگاه‌های اینترنتی، استفاده از سرویس ایمیل تراکنشی مثل Mailgun، SendGrid، Postmark یا Amazon SES توصیه می‌شود. این سرویس‌ها با تنظیمات DNS و رپورتینگ دقیق، هم شانس رسیدن ایمیل را بالا می‌برند و هم اگر مشکلی پیش آمد، اطلاعات دقیقی برای عیب‌یابی می‌دهند. برای مطالعه تفاوت این سرویس‌ها و انتخاب درست، بهترین سرویس ایمیل تراکنشی: مقایسه را ببینید.

لایه سوم — SPF، DKIM، DMARC و اعتبار دامنه

لایه سوم جایی است که ایمیل شما ارسال می‌شود ولی در سمت گیرنده به‌عنوان اسپم یا جعل هویت تلقی می‌شود. سه استاندارد اصلی در این لایه وجود دارد که بدون آن‌ها، حتی ایمیل‌های کاملاً قانونی ممکن است در پوشه اسپم گیرنده بیفتند یا اصلاً تحویل نشوند.

SPF — مجوز ارسال از سرور شما

SPF (Sender Policy Framework) یک رکورد DNS است که به سرور گیرنده می‌گوید «این IPها مجاز هستند از دامنه من ایمیل بفرستند». اگر SPF نداشته باشید، سرور گیرنده نمی‌داند ایمیل شما از منبع مجاز آمده یا نه. الگوی عمومی SPF:

v=spf1 include:_spf.example.com ~all

سه حالت مختلف در انتهای رکورد: -all (Fail — ایمیل‌های غیرمجاز را رد کن)، ~all (Soft Fail — ایمیل‌های غیرمجاز را با هشدار بپذیر)، و ?all (Neutral — هیچ قضاوتی نکن). برای بیشتر سایت‌ها، ~all توصیه می‌شود چون در حالت گذر، اجازه می‌دهد ایمیل‌های معتبر از سرورهای قدیمی هم کار کنند. برای مطالعه دقیق SPF، SPF چیست و چگونه از جعل ایمیل جلوگیری می‌کند و برای تنظیم آن در دامنه‌های ایرانی، تنظیم SPF برای دامنه‌های ایرانی را ببینید.

DKIM — امضای دیجیتال پیام

DKIM (DomainKeys Identified Mail) یک امضای دیجیتال به هدر ایمیل اضافه می‌کند که سرور گیرنده می‌تواند با کلید عمومی در DNS شما اعتبار آن را تایید کند. اگر DKIM نداشته باشید، سرور گیرنده نمی‌تواند تایید کند که ایمیل واقعاً از شما آمده و دستکاری نشده است. پیاده‌سازی DKIM در سرور ایمیل در پیاده‌سازی DKIM در سرور ایمیل توضیح داده شده است. تنظیم DKIM از طریق افزونه SMTP هم معمولاً ساده‌تر است چون افزونه تولید کلید و ثبت رکورد را خودش راهنمایی می‌کند.

DMARC — سیاست ترکیبی

DMARC (Domain-based Message Authentication, Reporting, and Conformance) سیاستی را تعیین می‌کند که سرور گیرنده در صورت عدم تطابق SPF و DKIM چه رفتاری داشته باشد. سه حالت: none (هیچ کاری نکن)، quarantine (به اسپم بفرست)، reject (رد کن). بهترین رویکرد تدریجی این است که ابتدا با p=none شروع کنید و گزارش‌ها را پایش کنید، سپس به quarantine و در نهایت به reject بروید. راهنمای کامل DMARC در DMARC چیست و چگونه امنیت ایمیل را تقویت می‌کند و روش گام‌به‌گام در راه‌اندازی DMARC گام‌به‌گام آمده است.

ابزارهای بررسی اعتبار

برای بررسی اعتبار دامنه و رکوردهای DNS، از ابزارهایی مثل MXToolbox، Mail-Tester، یا dmarcian استفاده کنید. این ابزارها امتیاز اعتبار ایمیل شما را در بازه صفر تا ده می‌دهند و نشان می‌دهند کدام رکورد نادرست است. یک امتیاز زیر ۷ معمولاً به‌معنی ریسک بالای افتادن در اسپم است. یک نکته از تجربه: حتی وقتی SPF و DKIM درست تنظیم شده‌اند، اگر رکورد DMARC یا رکورد MX نادرست باشد، امتیاز اعتبار پایین می‌آید.

لایه چهارم — فیلتر هاست، لیست سیاه و ضداسپم

لایه چهارم جایی است که همه‌چیز در سمت شما درست است ولی سرور مقصد یا سرور شما پیام را فیلتر می‌کند. این لایه، دشوارترین لایه برای تشخیص است چون خطاها اغلب مبهم و متناوب‌اند.

مسدود شدن IP سرور در لیست‌های سیاه

اگر سرور شما در یک لیست سیاه (RBL) قرار گرفته باشد، همه ایمیل‌های شما از آن سرور بلاک می‌شوند. این حالت در هاست‌های اشتراکی شایع است چون IP سرور بین چندین سایت مشترک است و اگر یکی از سایت‌ها ایمیل اسپم ارسال کرده باشد، IP در لیست سیاه قرار می‌گیرد. راه تشخیص: با ابزار MXToolbox، IP سرور خود را در لیست‌های سیاه عمومی جستجو کنید. اگر در لیست بود، راه‌حل یا درخواست unblock از آن لیست است یا مهاجرت به سرور دیگر. در هاست‌های اشتراکی، این مسئله ممکن است از کنترل شما خارج باشد و باید با پشتیبانی هاست تماس بگیرید.

محدودیت‌های ارسال در هاست اشتراکی

بسیاری از هاست‌های اشتراکی محدودیت تعداد ایمیل در ساعت یا روز دارند (مثلاً ۲۰۰ ایمیل در ساعت). اگر افزونه شما فراتر از این محدودیت ایمیل بفرستد، ارسال‌های بعدی بلاک می‌شوند بدون اطلاع. این مسئله در پروژه‌هایی که افزونه خبرنامه یا اعلان انبوه دارند شایع است. راه‌حل: یا از سرویس ایمیل تراکنشی استفاده کنید که سقف بالاتری دارد، یا ارسال‌ها را در WP-Cron با تاخیر زمان‌بندی کنید تا سقف هاست رعایت شود.

فیلترهای ضداسپم سرور

بعضی هاست‌ها فیلترهای ضداسپم سختگیرانه‌ای روی سرور دارند که پیام‌های خروجی را بازرسی می‌کنند. اگر پیام شما شامل کلمات مشکوک یا الگوهای اسپم باشد، پیام بلاک می‌شود. این مسئله در پروژه‌هایی که افزونه شما اعلان‌های خودکار یا ایمیل‌های حجیم می‌فرستد شایع است. راه‌حل: با پشتیبانی هاست تماس بگیرید و بپرسید آیا فیلتر ضداسپم روی ایمیل‌های خروجی دارند. اگر بله، می‌توانید درخواست استثنا برای دامنه یا IP خود کنید.

مسدودسازی توسط سرور گیرنده

گاهی مسئله از سمت شما نیست؛ سرور گیرنده دامنه یا IP شما را بلاک کرده است. این حالت در بافت ایمیل‌های سازمانی یا سرویس‌های ایمیل سختگیرانه مثل Yahoo و AOL شایع‌تر است. نشانه: ایمیل به بعضی گیرندگان می‌رسد و به بعضی دیگر نه. راه‌حل: از گیرنده بخواهید بررسی کند که دامنه شما در لیست سیاه داخلی آن‌ها هست یا نه، یا از سرویس checkr استفاده کنید که وضعیت IP و دامنه شما را در لیست‌های سیاه متعدد گزارش می‌دهد.

در بافت ایمیل، اعتبار دامنه و IP به‌مرور ساخته می‌شود. اگر IP شما در لیست سیاه قرار گرفت، حتی با تنظیمات درست SPF و DKIM، ایمیل‌های شما تا مدتی اسپم تلقی می‌شوند. صبر و پایداری، بخشی از راه‌حل است.

لایه پنجم — صف ایمیل، لاگ تحویل و تاخیر

لایه پنجم جایی است که ایمیل ارسال می‌شود ولی با تاخیر یا بدون لاگ دقیق به دست نمی‌رسد. این لایه به مدیریت صف ایمیل، لاگ تحویل، و رفتار سرور مربوط می‌شود.

WP-Cron و صف ایمیل

افزونه‌هایی که ایمیل انبوه می‌فرستند (مثل خبرنامه‌ها) معمولاً ایمیل‌ها را در صف قرار می‌دهند و با WP-Cron در بازه‌های زمانی ارسال می‌کنند. اگر WP-Cron به‌درستی کار نکند، صف تخلیه نمی‌شود و ایمیل‌ها ارسال نمی‌شوند. راه تشخیص: در پیشخوان وردپرس، صفحه «ابزارها ← سلامت سایت» را ببینید و وضعیت WP-Cron را بررسی کنید. اگر مشکل داشت، در مقالات رفع مشکلات cron در وردپرس و کرون وردپرس و زمان‌بندی خودکار کارها راه‌حل‌ها توضیح داده شده است.

لاگ تحویل و رپورتینگ

یکی از بهترین راه‌های عیب‌یابی ایمیل، فعال‌سازی لاگ تحویل است. اگر از سرویس ایمیل تراکنشی استفاده می‌کنید، داشبورد آنها معمولاً نشان می‌دهد هر ایمیل به چه سرنوشتی دچار شده (تحویل، بلاک، اسپم، یا در صف). اگر از SMTP مستقیم استفاده می‌کنید، لاگ خود سرور SMTP را بررسی کنید. برای افزونه‌های SMTP مثل WP Mail SMTP، معمولاً یک صفحه لاگ در پیشخوان وجود دارد که همه ارسال‌ها را با کد وضعیت و پیام خطا ثبت می‌کند. این لاگ، اولین جایی است که باید در صورت شکست بررسی کنید.

تاخیر زیاد در ارسال

گاهی ایمیل شما با تاخیر چند ساعته می‌رسد. این حالت سه علت رایج دارد: اول، صف MTA سرور شما شلوغ است (معمولاً در هاست‌های اشتراکی). دوم، سرور گیرنده پیام شما را با «تاخیر موقت» پذیرفته و در صف خودش نگه داشته. سوم، rate limiting سرویس ایمیل تراکنشی شما فعال شده. راه‌حل: برای علت اول، سرور SMTP اختصاصی یا سرویس ایمیل تراکنشی را جایگزین کنید. برای علت دوم، نمی‌توانید کاری کنید مگر آنکه اعتبار دامنه‌تان را بالا ببرید. برای علت سوم، ارسال‌ها را در بازه‌های طولانی‌تر توزیع کنید.

اسکریپت‌های تست و بررسی مستقیم SMTP

برای تشخیص لایه پنجم از لایه‌های دیگر، می‌توانید مستقیماً به SMTP سرور متصل شوید و یک ایمیل تست بفرستید:

// اجرا از خط فرمان سرور:
swaks --to test@example.com 
      --from noreply@example.com 
      --server smtp.example.com:587 
      --auth LOGIN 
      --auth-user your-email@example.com 
      --auth-password your-app-password 
      --tls

این ابزار، تمام مراحل دست‌دادن با سرور SMTP را نمایش می‌دهد و اگر خطایی رخ دهد، دقیقاً مشخص می‌کند در کدام مرحله بوده. اگر این تست موفق شد ولی ایمیل از سایت شما ارسال نمی‌شود، مسئله در پیکربندی وردپرس است نه در سرور SMTP.

چک‌لیست دیباگ گام‌به‌گام خطای ارسال ایمیل

این ترتیبی است که در پروژه‌های واقعی طی می‌کنم. اگر ترتیب را حفظ کنید، از ارزان‌ترین و سریع‌ترین راه به پیچیده‌ترین می‌رسید:

فعال‌سازی WP_DEBUG: در wp-config.php مقادیر WP_DEBUG، WP_DEBUG_LOG و WP_DEBUG_DISPLAY را تنظیم کنید. لاگ در wp-content/debug.log نوشته می‌شود.
بررسی return wp_mail: اگر wp_mail مقدار false برمی‌گرداند، به لایه اول یا دوم بروید. اگر true برمی‌گرداند، به لایه‌های سوم تا پنجم.
تست ارسال مستقیم: در یک فایل PHP موقت یا با wp eval در WP-CLI، یک wp_mail ساده به ایمیل خودتان بفرستید و ببینید می‌رسد یا نه. اگر این ساده‌ترین تست شکست خورد، مسئله در پیکربندی SMTP است نه در افزونه شما.
نصب افزونه SMTP: اگر پیکربندی SMTP ندارید، یک افزونه SMTP نصب کنید و تنظیمات را تکمیل کنید. این گام، شایع‌ترین ریشه خطاهای ارسال ایمیل را حل می‌کند.
بررسی SPF، DKIM، DMARC: در ابزار MXToolbox یا Mail-Tester این سه رکورد را بررسی کنید و امتیاز اعتبار را ببینید. اگر امتیاز زیر ۷ است، به لایه سوم برگردید.
بررسی لیست سیاه: با ابزار MXToolbox، IP سرور خود را در لیست‌های سیاه عمومی جستجو کنید. اگر در لیست بود، با پشتیبانی هاست یا سرویس ایمیل تراکنشی تماس بگیرید.
بررسی محدودیت‌های هاست: با پشتیبانی هاست چک کنید که سقف ایمیل روزانه یا ساعتی چقدر است و آیا فیلتر ضداسپم روی ایمیل‌های خروجی دارند یا نه.
بررسی لاگ افزونه SMTP: در پیشخوان افزونه SMTP، صفحه لاگ را باز کنید و پیام‌های خطا را بررسی کنید. کد وضعیت و پیام خطا، سرنخ دقیقی می‌دهند.
تست با swaks از SSH: اگر به SSH سرور دسترسی دارید، با ابزار swaks مستقیماً به SMTP تست کنید تا مطمئن شوید سرور می‌تواند به‌درستی به SMTP خارجی وصل شود.
تست با ایمیل گیرنده مختلف: به چند گیرنده مختلف (Gmail، Outlook، Yahoo) ایمیل تست بفرستید و ببینید در کدام یک مشکل دارید. اگر فقط در Gmail مشکل دارید، SPF و DKIM و DMARC شما ممکن است ناقص باشند.
غیرفعال کردن افزونه‌های دیگر: اگر از افزونه فرم‌ساز یا خبرنامه استفاده می‌کنید، افزونه‌های دیگر را غیرفعال کنید و تست کنید تا مقصر پیدا شود. الگوی کامل در چگونه افزونه مشکل‌ساز وردپرس را پیدا کنیم آمده است.
تست روی محیط استجینگ: اگر روی محیط محلی کار می‌کند ولی روی سرور نه، تفاوت‌های محیطی مسئول است. روی محیط استجینگ با همان SMTP و پیکربندی سرور تست کنید.

این ترتیب در تست و دیباگ پروژه‌های توسعه وردپرس به‌عنوان پروتکل عیب‌یابی معرفی شده است. در بیشتر موارد، مسئله در گام چهارم (نصب و پیکربندی SMTP) تشخیص داده می‌شود، پس قبل از رفتن به سراغ SPF و DMARC، همان گام چهارم را جدی بگیرید. اگر در حین عیب‌یابی به خطاهای PHP برخوردید، دیباگ کردن کدهای سفارشی وردپرس را ببینید.

پرسش‌های پرتکرار درباره عدم ارسال ایمیل افزونه

این بخش به پرسش‌هایی اختصاص دارد که در انجمن‌ها و تیکت‌های پشتیبانی بیشترین تکرار را دارند و در نتایج جستجو به‌عنوان پاسخ کوتاه ارزشمندند.

چرا wp_mail مقدار true برمی‌گرداند ولی ایمیل نمی‌رسد؟

این شایع‌ترین سردرگمی در بافت ایمیل است. مقدار true از wp_mail فقط یعنی «پیام به MTA محلی سپرده شد»، نه اینکه «به دست گیرنده رسید». از این لحظه به بعد، تحویل پیام بر عهده MTA است. اگر ایمیل نمی‌رسد، مسئله در SPF، DKIM، لیست سیاه، فیلترهای سرور یا صف MTA است. راه‌حل: از افزونه SMTP با لاگ تحویل استفاده کنید تا مسیر واقعی پیام را ببینید.

چرا ایمیل به Gmail می‌رسد ولی به Yahoo یا Outlook نه؟

هر سرویس ایمیل، سیاست‌های ضداسپم متفاوتی دارد. Yahoo و AOL به‌طور تاریخی سختگیرتر هستند. اگر ایمیل شما به Gmail می‌رسد ولی به Yahoo نه، احتمالاً DMARC شما ناقص است یا SPF شما ناقص است. در سال‌های اخیر، Yahoo سیاست DMARC سختگیرانه‌ای اجرا می‌کند. راه‌حل: DMARC را روی p=quarantine یا p=reject تنظیم کنید و رکوردهای DKIM را برای همه سرویس‌های ارسال اضافه کنید.

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

چند علت رایج. اول، نبود SPF یا DKIM. دوم، محتوای ایمیل شامل کلمات مشکوک یا لینک‌های پرتعداد. سوم، IP شما در لیست سیاه قرار گرفته. چهارم، نسبت متن به تصویر یا HTML نامتعادل. پنجم، استفاده از دامنه‌ای که با دامنه سایت شما هم‌خوان نیست. راه‌حل: از ابزار Mail-Tester استفاده کنید تا امتیاز دقیق و توصیه‌های اصلاحی را ببینید.

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

این حالت معمولاً به فیلترهای سمت سرور گیرنده برمی‌گردد. اگر شما از یک سرویس ایمیل سازمانی مثل Microsoft 365 استفاده می‌کنید، ممکن است سرور آن‌ها پیام‌های خودکار از سایت‌ها را به‌عنوان اسپم علامت‌گذاری کنند. راه‌حل: از طریق کنسول ادمین سرویس ایمیل خود، دامنه سایت را به‌عنوان فرستنده مجاز تعریف کنید، یا از یک زیر‌دامنه اختصاصی برای ارسال ایمیل‌های سیستمی استفاده کنید.

آیا استفاده از SMTP با پورت 25 مشکل دارد؟

بله. اکثر سرویس‌های ابری و هاست‌های مدرن پورت 25 را برای جلوگیری از ارسال اسپم مسدود می‌کنند. توصیه می‌شود از پورت 587 با TLS یا پورت 465 با SSL استفاده کنید. اگر پورت 587 هم مسدود بود، معمولاً می‌توانید از پورت‌های جایگزین مثل 2525 استفاده کنید که Mailgun و Postmark و چند سرویس دیگر ارائه می‌دهند.

چرا ایمیل خبرنامه من با تاخیر چند ساعته می‌رسد؟

سه علت اصلی. اول، صف MTA سرور شلوغ است — این مسئله در هاست‌های اشتراکی شایع است. دوم، rate limiting سرویس ایمیل تراکنشی شما فعال شده. سوم، خود سرور SMTP کند است. راه‌حل: برای خبرنامه‌های حجیم، از سرویس ایمیل تراکنشی با پهنای باند اختصاصی استفاده کنید یا ارسال‌ها را در بازه‌های طولانی‌تر توزیع کنید.

آیا افزونه‌های فرم‌ساز آماده ارسال ایمیل را خودشان مدیریت می‌کنند؟

بله ولی همه آن‌ها به پیکربندی SMTP وابسته‌اند. حتی محبوب‌ترین افزونه‌های فرم‌ساز مثل Contact Form 7 یا WPForms، از همان wp_mail استفاده می‌کنند. اگر پیکربندی SMTP درستی نداشته باشید، این افزونه‌ها هم نمی‌توانند ایمیل ارسال کنند. برای مرور رفتار افزونه‌های فرم‌ساز در این زمینه، بهترین افزونه‌های فرم‌ساز وردپرس و نقد اختصاصی افزونه Contact Form 7 را ببینید.

آیا استفاده از سرویس ایمیل تراکنشی می‌تواند همه مشکلات را حل کند؟

خیر، ولی آن‌ها بسیاری از لایه‌های سخت را ساده‌تر می‌کنند. سرویس‌های ایمیل تراکنشی مثل Mailgun و SendGrid معمولاً SPF و DKIM و DMARC را راهنمایی می‌کنند، لاگ دقیق ارسال می‌دهند، و پهنای باند اختصاصی برای شما فراهم می‌کنند. اما اگر رکوردهای DNS نادرست باشند یا محتوای ایمیل شما مشکوک باشد، حتی این سرویس‌ها هم نمی‌توانند کمکی کنند. رویکرد درست: ابتدا پیکربندی SMTP و DNS را درست کنید، سپس در صورت نیاز به سرویس تراکنشی مهاجرت کنید.

آیا مشکل ارسال ایمیل می‌تواند به دلیل قالب باشد؟

خیر به‌طور مستقیم، ولی قالب می‌تواند روی رفتار افزونه اثر بگذارد. اگر قالب شما در فایل functions.php تغییری در رفتار wp_mail یا phpmailer_init ایجاد کند، می‌تواند ارسال ایمیل را مختل کند. همچنین، اگر قالب شما از یک افزونه SMTP خاص استفاده می‌کند یا خودش پیکربندی SMTP دارد، با افزونه شما تعارض می‌کند. برای تشخیص، قالب را به Twenty Twenty-Five تغییر دهید و تست کنید. اگر ایمیل ارسال شد، مسئله در قالب است.

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

سه ابزار کلیدی: اول، Mail-Tester که به شما یک آدرس ایمیل تستی می‌دهد و امتیاز اسپم سایت شما را در بازه صفر تا ده اعلام می‌کند. دوم، MXToolbox که وضعیت IP، SPF، DKIM و DMARC شما را بررسی می‌کند. سوم، Gmail Postmaster Tools که اگر حجم ایمیل شما بالا باشد، اطلاعات دقیقی از نرخ تحویل و نرخ اسپم شما می‌دهد. توصیه می‌کنم پیش از راه‌اندازی هر سیستم ایمیل، این سه ابزار را اجرا کنید و امتیازتان را ببینید.

معماری پایدار برای ارسال مطمئن ایمیل

پس از حل مشکل، ارزش دارد معماری افزونه را طوری تنظیم کنید که این نوع خطا در آینده تکرار نشود. فهرستی از اصول که در پروژه‌های خودم به‌طور منظم رعایت می‌کنم:

استفاده اجباری از SMTP: برای همه سایت‌ها، پیکربندی SMTP با احراز هویت را استاندارد کنید. تابع mail PHP به‌تنهایی در سال‌های اخیر قابل اعتماد نیست.
ذخیره امن رمز SMTP: رمز SMTP را در wp-config.php به‌عنوان ثابت ذخیره کنید، نه در wp_options و نه در کد هاردکد.
تنظیم SPF، DKIM، DMARC: این سه رکورد، پایه اعتبار ایمیل شماست. قبل از هر ارسال انبوه، این‌ها را راه‌اندازی کنید.
بررسی return value: همیشه مقدار بازگشتی wp_mail را بررسی کنید و در صورت شکست لاگ بگیرید. عدم بررسی، ریشه‌یابی را بسیار دشوار می‌کند.
لاگ تحویل: اگر از افزونه SMTP استفاده می‌کنید، لاگ تحویل را فعال کنید. اگر از سرویس تراکنشی استفاده می‌کنید، داشبورد را دوره‌ای بررسی کنید.
هدرهای استاندارد: از هدرهای From، Reply-To، و Content-Type استفاده کنید و مطمئن شوید From با دامنه سایت هم‌خوانی دارد.
استفاده از دامنه فرعی برای ایمیل سیستمی: به‌جای ارسال از دامنه اصلی، از یک زیر‌دامنه مثل mail.example.com استفاده کنید. این کار اعتبار دامنه اصلی را از اثر ارسال انبوه محافظت می‌کند.
تست روی محیط استجینگ: پیش از انتشار نسخه جدید، ارسال ایمیل را روی محیط استجینگ با همان پیکربندی سرور تست کنید. ساخت محیط استجینگ در توسعه وردپرس با محیط لوکال توصیه می‌شود.
استفاده از صف ایمیل: برای ارسال انبوه، از صف با WP-Cron یا یک صف خارجی استفاده کنید تا سرعت پاسخ سایت کاهش نیابد. الگوهای صف در بافت WP-Cron در کرون وردپرس و زمان‌بندی خودکار کارها آمده است.
رعایت استانداردهای کدنویسی: کد ایمیل افزونه باید با escape مناسب، sanitize پارامترها، و مدیریت خطای دقیق نوشته شود. مرور اصول در استانداردهای کدنویسی وردپرس چیست و اصول امنیتی در نوشتن کد PHP امن برای وردپرس آمده است.

یک نکته از تجربه شخصی در پروژه‌های فروشگاهی: اگر ایمیل‌های تراکنشی مثل تأیید سفارش یا تأیید پرداخت به دست مشتری نمی‌رسد، اثرش مستقیماً روی اعتماد و نرخ تبدیل است. حتی اگر مشکل برطرف شد، توصیه می‌کنم یک بررسی هفتگی از لاگ تحویل داشته باشید. رویکرد کلی این مدیریت در CRO برای فروشگاه‌های ووکامرس توضیح داده شده است.

سخن پایانی

خطای عدم ارسال ایمیل توسط افزونه، در نگاه اول یکی از پیچیده‌ترین انواع خطا در وردپرس است چون کاربر پیام موفقیت می‌بیند ولی در واقع ایمیل هرگز به دست گیرنده نمی‌رسد. این خطا در عمل همیشه در یکی از پنج لایه‌ای که در این مقاله بررسی کردیم ریشه دارد: پیکربندی نادرست wp_mail، نبود SMTP و احراز هویت، مشکل در SPF و DKIM و DMARC، فیلتر شدن توسط هاست یا سرور گیرنده، و مدیریت نادرست صف و لاگ. ابزار اصلی عیب‌یابی در این بافت، ترکیب سه چیز است: فعال‌سازی افزونه SMTP با لاگ دقیق، بررسی رکوردهای DNS با ابزارهایی مثل MXToolbox و Mail-Tester، و تست مستقیم SMTP از خط فرمان با swaks. مسیر عیب‌یابی که در چک‌لیست ارائه کردم، همان ترتیبی است که در پروژه‌های واقعی مرا سریع به علت رسانده؛ نکته کلیدی این است که از گام‌های ارزان (فعال‌سازی WP_DEBUG، بررسی return wp_mail) شروع کنید و به گام‌های گران (بررسی SPF و DKIM، تست SMTP از SSH) برسید. در بلندمدت، استفاده اجباری از SMTP، راه‌اندازی SPF و DKIM و DMARC، ذخیره امن رمز SMTP، و لاگ‌گیری دقیق، مهم‌تر از هر راه‌حل لحظه‌ای است — چون این انضباط است که اجازه نمی‌دهد ایمیل‌های شما به پوشه اسپم یا لیست سیاه بروند و کاربران نهایی را در بلاتکلیفی بگذارند.

اگر این خطا را در یک پروژه واقعی تجربه کرده‌اید و به علت غیرمنتظره‌ای برخورده‌اید — مثلاً سرویس ایمیل تراکنشی که فقط برای دامنه‌های ایرانی رفتار خاصی داشت، یا هاست اشتراکی که پورت 587 را مسدود کرده بود، یا Gmail که فقط ایمیل‌های یک بازه زمانی خاص را رد می‌کرد — خوشحال می‌شوم تجربه‌تان را در دیدگاه‌ها بنویسید. به‌ویژه اگر ترفند خلاقانه‌ای برای تشخیص سریع‌تر پیدا کرده‌اید، آن تجربه برای نفر بعدی که با همین خطا روبرو می‌شود، ارزشمندتر از هر مستند رسمی است. ✉️