رسائل نموذج الاتصال تذهب إلى البريد العشوائي — إصلاح مُرسِل خادم الويب (2026)

نُشر 2026-07-08

الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.

رسائل نماذج الاتصال والمواقع تهبط في العشوائي لأن خادم الويب يُرسلها بلا مصادقة — لا تفويض SPF، لا توقيع DKIM. الإصلاح الموثوق هو توجيه ذلك البريد عبر SMTP موثَّق، لا وضع الخادم في قائمة بيضاء. 46.4% من 261,086,232 نطاق مُصنَّف في إحصاء Defaults.Exposed (البيانات بتاريخ 2026-06-29) لا تنشر سجل SPF أصلاً.

ترتيب الإصلاح مهم ومعظم البرامج التعليمية تعكسه. شغّل فحصاً مجانياً لترى ما ينشره نطاقك فعلاً؛ وجِّه بريد الموقع عبر SMTP موثَّق (مزوّد صندوق بريدك أو خدمة بريد معاملاتي) ليحصل على توقيع DKIM حقيقي؛ أصلح عنوان From للنموذج؛ وأضف IP الخادم إلى SPF كملاذ أخير فقط.

لماذا تذهب رسائل موقعي إلى البريد العشوائي؟

بسبب من يُرسلها فعلاً. حين يُقدِّم زائر نموذج الاتصال، الرسالة لا يُرسلها مزوّد بريدك — خادم الويب يُنشئها بنفسه، عادةً عبر mail() في PHP. من جانب المستقبِل، تلك الرسالة:

تأتي من IP لا يُفوِّضه سجل SPF الخاص بك (SPF يُغطي مزوّد بريدك، لا مضيف الويب)؛
لا تحمل توقيع DKIM، فلا شيء يربطها تشفيرياً بنطاقك؛
كثيراً ما تغادر من IP استضافة مشتركة يحدد سمعته مئات مواقع غرباء.

بريد غير موثَّق من IP متعدد السمعة هو بالضبط ما توجد منه مرشِّحات البريد العشوائي — Gmail وOutlook يريان خادماً عشوائياً يدّعي أنه أنت. الخط الأساسي الأوسع قاتم: 46.4% من النطاقات لا تنشر SPF أصلاً، و10.59% فقط (27,640,987 من 261,086,232 نطاق مُصنَّف، إحصاء بتاريخ 2026-06-29) يُطبِّق سياسة DMARC.

لماذا يُصيب هذا مواقع WordPress بشكل خاص؟

WordPress يُرسل كل بريده — إشعارات النماذج، إعادة تعيين كلمات المرور، تأكيدات الطلبات — عبر دالة واحدة، wp_mail()، التي تُغلِّف mail() في PHP على خادم الويب بصورة افتراضية. كل موقع WordPress لم يُعَد تهيئته عمداً هو مرسِل غير موثَّق من البداية. ملحقات النماذج (Contact Form 7، WPForms، Gravity Forms) جميعها تُسلِّم البريد لنفس الدالة: يبدو كمشكلة ملحق لكنه مشكلة نقل.

الإصلاح ليس ملحق نموذج مختلف بل ملحق SMTP (WP Mail SMTP ومكافئاته)، الذي يُعيد توجيه كل شيء تُرسله wp_mail() عبر حساب بريد موثَّق حقيقي — بنية تحتية يُفوِّضها SPF بالفعل مع توقيع DKIM مُرفَق.

أي طريقة إرسال يجب أن يستخدمها الموقع؟

طريقة الإرسال	SPF	DKIM	تصمد عند ترحيل المضيف؟	الحكم
`mail()` في PHP / `wp_mail()` الافتراضي من خادم الويب	يفشل	لا شيء	لا ينطبق — معطوب في كل مكان	المشكلة، ليس خياراً
SMTP موثَّق عبر مزوّد صندوق بريدك (Google Workspace أو Microsoft 365 إلخ.)	ينجح	موقَّع	نعم — مستقل عن الاستضافة	الإصلاح لمعظم المواقع
خدمة بريد معاملاتي (SES، Postmark، Brevo إلخ.) بنطاقك المُتحقَّق منه	ينجح	موقَّع	نعم	الإصلاح عند الحجم (تجارة إلكترونية، نماذج كبيرة)
IP خادم الويب مُضاف إلى سجل SPF	ينجح (SPF فقط)	لا شيء	لا — ينكسر بصمت حين يتغير IP	احتياطي فقط — انظر أدناه

لبضعة إشعارات يومياً، SMTP عبر صندوق البريد الذي تدفع له بالفعل هو أقصر طريق؛ عند حجم حقيقي، الخدمة المعاملاتية مصنوعة لذلك. كلاهما يمنحك DKIM — الاختصار بالقائمة البيضاء للـ IP لا يمنحك إياه أبداً.

كيف أُصلح قابلية تسليم رسائل نموذج الاتصال؟

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس أي شيء. يُظهر ما ينشره نطاقك فعلاً من SPF وDKIM وDMARC — سواء كنت تُصلح نقل النموذج، سجلاً مفقوداً، أم الاثنَين. لا SPF أصلاً؟ ابدأ من كيف تُصلح SPF.
أنشئ هوية SMTP مخصصة للموقع — مثلاً [email protected] عند مزوّد صندوق بريدك، أو نطاق إرسال مُتحقَّق منه في خدمة معاملاتية. استخدم كلمة مرور تطبيق أو مفتاح API يمكن إلغاؤه، لا كلمة مرور صندوق بريد شخص ما.
وجِّه بريد الموقع عبره. WordPress: ثبِّت ملحق SMTP ووجِّهه إلى ذلك الحساب. أُطر عمل أخرى: هيِّئ مُرسِل الإطار بدلاً من mail() المحلي.
أصلح عنوان From (الأسلوب المضاد أدناه): يجب أن يكون From من نطاقك الخاص؛ الزائر يذهب في Reply-To.
إن كان المُرسِل خدمة معاملاتية، أضف سجلات DKIM الخاصة بها (عادةً زوج CNAMEs) ليُوقَّع البريد بنطاقك — خطوات DNS تُماثل أدلة إعداد SPF.
أرسل تقديم اختبار وأعد الفحص. يجب أن تُظهر الترويسات spf=pass وdkim=pass لنطاقك أنت؛ ثم أزِل أي شيء آخر يُشير إليه الفحص عبر إصلاح SPF وإصلاح DKIM.

لماذا يرسل النموذج “من” عنوان بريد الزائر؟

أكثر الجروح الذاتية شيوعاً في تهيئة النماذج، وكثير من الملحقات اعتادت فعل ذلك بصورة افتراضية: الإشعار يصل From: عنوان الزائر، فيمكنك الرد مباشرةً. يبدو مريحاً، وهو تزوير. خادمك لا يملك حق إرسال بريد باسم [email protected] — يفشل في SPF وDKIM لـ gmail.com، وسياسة DMARC لـ Gmail تُخبر المستقبِلين بوضعه في العشوائي أو رفضه. الإصلاح لا يكلف شيئاً:

From: عنوان عند نطاقك الخاص (هوية SMTP من الخطوة 2)
Reply-To: عنوان الزائر — الرد لا يزال يذهب مباشرةً إليه

كل ملحق نماذج رئيسي يدعم هذا؛ إنهما حقلان في إعدادات الإشعار.

لماذا لا أُضيف IP الخادم فقط إلى سجل SPF؟

هو الإصلاح الذي تصل إليه معظم مقاطع المنتديات أولاً، وهو الاحتياطي لسبب. إضافة ip4:<server> (أو آلية a لمضيف الويب) إلى SPF يجعل الفحص الخام ينجح — لكن:

على الاستضافة المشتركة يُفوِّض الغرباء. IP ينتمي للخادم، لا لك؛ كل موقع آخر على ذلك الخادم يستطيع الآن إرسال بريد ينجح في SPF باسم نطاقك.
ينكسر بصمت. المضيفون يُرحِّلون الخوادم ويُدوِّرون IPs دون إخبارك؛ SPF الخاص بك يستمر في تفويض عنوان تركته منذ أشهر.
لا يمنحك DKIM. SPF وحده ينكسر تحت التوجيه ولا يستطيع اصطحابك نحو تطبيق DMARC بالطريقة التي يستطيعها التوقيع.

احتفظ بهذا المسار للحالة المُقيَّدة حقاً: خادم مخصص بـ IP ثابت تتحكم فيه وتطبيق لا يستطيع التحدث بـ SMTP — وزوِّجه بتوقيع DKIM على الخادم إن أمكن.

هل SPF يفحص العنوان الذي يضعه النموذج في “From”؟

لا — وهذا يُعثر نصف التشخيصات الذاتية. يُقيِّم المستقبِلون SPF مقابل نطاق Return-Path (RFC5321.MailFrom)، لا ترويسة From. خوادم الويب كثيراً ما تختم اسم مضيفها الخاص على Return-Path، فسجل SPF الخاص بك لم يُستشر أصلاً — المستقبِل فحص SPF لـ srv0421.examplehost.com. SMTP الموثَّق يُصلح هذا أيضاً: يصبح Return-Path نطاقك، فنجاح SPF أخيراً يُحتسَب لك. لهذا أيضاً يهم DKIM — توافق DMARC يحتاج نجاحاً مرتبطاً بالنطاق في From، وتوقيع DKIM يُسافر مع الرسالة.

الأسئلة الشائعة

هل يُصلح ملحق SMTP رسائل إعادة تعيين كلمة المرور وWooCommerce أيضاً؟ نعم. على WordPress كل شيء يتدفق عبر wp_mail()، فإعادة توجيهه تُصلح إشعارات النماذج وإعادة تعيين كلمات المرور ورسائل الطلبات في خطوة واحدة.

هل أحتاج لا يزال سجلات SPF وDKIM إن استخدمت ملحق SMTP؟ نعم — الملحق يغيّر أي بنية تحتية ترسل بريدك؛ السجلات هي ما يُفوِّضها. إن كان نطاقك من 46.4% من 261,086,232 نطاق مُصنَّف بلا سجل SPF (الإحصاء، 2026-06-29)، SMTP الموثَّق وحده لن ينقذك. قائمة مهام البريد للنطاق الجديد تُغطي مجموعة السجلات الكاملة.

رسائل النموذج لديّ تنجح في SPF لكنها لا تزال تفشل في DMARC — لماذا؟ في كل الأحوال تقريباً الأسلوب المضاد لتزوير From أعلاه، أو SPF ينجح لنطاق Return-Path للمضيف لا لنطاقك. أصلح From/Reply-To أولاً؛ إن استمر الفشل، القطعة المفقودة هي توقيع DKIM متوافق — انظر “توقيع DKIM غير صالح”. إن فشلت أدوات SaaS خارج الموقع أيضاً، دليل SPF الفاشل لـ SaaS يُغطي ترتيب الإصلاح.

هل يستحق كل هذا لنموذج اتصال منخفض الحركة؟ النموذج عادةً حيث تدخل الأموال — استفسار ضائع هو عميل لم تعلم بخسارته أبداً. والإصلاح مجاني؛ العائق هو معرفة أن خادم الويب كان المرسِل غير الموثَّق طوال الوقت.

أرسل للمالك التقرير

إن كنت المطوِّر أو المقاول الذي يُصلح هذا: بمجرد نجاح تقديم الاختبار، أعد الفحص المجاني وأرسل التقرير المُصنَّف لمالك الموقع — سجل مؤرَّخ بلغة بسيطة أن النطاق يُصادق بشكل صحيح، والوثيقة التي يحتاجها لتجديد تأمين الإنترنت القادم أو استبيان أمان العميل. إن كنت المالك تقرأ هذا لأن الاستفسارات توقفت عن الوصول: أرسل هذه الصفحة وتقرير الفحص لمن يشغّل موقعك — مهمة نصف يوم مع قبل وبعد يمكنك إظهاره.

افحص نطاقك ← · SPF يفشل لأدوات SaaS لديك؟ ← · إصلاح SPF ← · طريقة التصنيف ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.