كل موقع إلكتروني يرسل رسائل بريدية. تأكيدات الطلبات، وإعادة تعيين كلمات المرور، والرسائل الواردة عبر نماذج التواصل، وتذكيرات الحجوزات، كلها تندرج ضمن بريد معاملات الموقع. إنها فئة لا يخطط لها أحد تقريبا، مع أن الجميع يعتمد عليها، وغالبا ما يضبطها منشئ الموقع مرة واحدة ثم لا يراجعها مجددا.
بعد ذلك يتوقف العملاء عن تلقي تأكيدات الطلبات، ليتبين أنها كانت تصل إلى مجلد الرسائل غير المرغوب فيها طوال ثمانية أشهر. تشرح هذه الصفحة سبب حدوث ذلك بغض النظر عن المنصة التي تستخدمها، وتوضح الإعداد الذي يمنع المشكلة.
لماذا يفشل بريد معاملات الموقع من دون أن يلفت الانتباه
ترسل الإعدادات الافتراضية في معظم المنصات البريد مباشرة من خادم الويب، باستخدام دالة البريد التي توفرها لغة البرمجة. يبدو كل شيء سليما أثناء الاختبار لأنك تتحقق من صندوق بريدك الشخصي، ولأن مزود البريد الذي تستخدمه يثق بك.
لكن الإرسال يفشل في بيئة التشغيل لسبب لا علاقة له بالكود. خادم الويب ليست له سمعة إرسال، وعنوان IP الخاص به مشترك مع خدمات أخرى يشغلها مزود الاستضافة، كما تدعي الرسالة أنها صادرة من نطاقك بينما تأتي من جهة لم يمنحها نطاقك إذنا بالإرسال. تتعامل خدمات البريد المستقبلة مع هذا النمط على أنه انتحال، لأنه يكون كذلك في معظم الحالات. ولهذا تحديدا تشترط إرشادات Google لمرسلي البريد الإلكتروني استخدام المصادقة.
ولا يظهر الفشل من جهتك. يفيد الموقع بأن الرسالة أرسلت، ولا تعرض السجلات أي خطأ، ولا توجد إشارة إلى أن الرسالة صنفت كبريد غير مرغوب فيه لدى الجهة المستقبلة. يتميز بريد معاملات الموقع بسوء قدرته على تنبيهك إلى تعطله، ولذلك لا تكتشف المشكلة عادة إلا عندما يشتكي أحد العملاء بعد أشهر.
المشكلة نفسها على كل منصة
هذه ليست مشكلة خاصة بـ WordPress، رغم أنه يتحمل اللوم غالبا لأنه الأكثر انتشارا. فالآلية نفسها في كل مكان.
WordPress يستخدم دالة البريد في PHP افتراضيا، أي إنه يرسل مباشرة من الخادم بكل المشكلات السابقة. يستبدل مكون SMTP الإضافي هذه الآلية، وهو الحل المعتاد.
Shopify وWix وSquarespace ترسل رسائل المعاملات من بنيتها التحتية الخاصة التي تحظى عادة بصيانة جيدة. لكنها لا تتيح دائما الإرسال من نطاقك مع مصادقة صحيحة ما لم تضبط ذلك بنفسك، وبالتالي قد يتعذر التحقق من أن الرسائل التي تدعي صدورها منك قد صدرت منك فعلا.
Webflow وGhost والتطبيقات المخصصة تختلف في التفاصيل، لكن النمط واحد: نادرا ما تكون وسيلة الإرسال الافتراضية موثقة بالاعتماد على نطاقك.
الحل الثابت على جميع هذه المنصات هو تمرير بريد معاملات الموقع عبر اتصال SMTP موثق، باستخدام نطاق توضح سجلات DNS الخاصة به أن هذا الاتصال مخول بالإرسال.
حل من ثلاثة أجزاء
تحتاج إلى ثلاثة عناصر، ولا غنى عن أي منها. الاكتفاء بعنصرين يظل ينتج رسائل قد تصل إلى مجلد البريد غير المرغوب فيه.
حساب SMTP للإرسال من خلاله. بدلا من أن يرسل خادم الويب مباشرة، يتصل الموقع بخادم بريد بعد المصادقة ويسلمه الرسالة. تدعم كل منصة ذلك إما بصورة مدمجة أو من خلال مكون إضافي.
إعداد DNS يمنحه الإذن. تحتاج إلى سجل SPF يحدد خادم الإرسال، وإلى توقيع DKIM حتى تحمل الرسالة توقيعا يمكن التحقق منه. من دونهما سيظل الإرسال الموثق يبدو غير مصرح به لدى المستلم. يشرح دليلا SPF وDKIM كيفية إعداد السجلات نفسها.
عنوان إرسال موجود فعليا. الإرسال من noreply@yourdomain.com من دون وجود صندوق بريد بهذا العنوان يمثل إشارة سلبية صغيرة لكنها حقيقية، ويعني أيضا أن الردود ستضيع. إنشاء صندوق البريد هنا لا يكلف شيئا، لأن الفوترة لا تتم لكل مستخدم.
فصله عن مراسلاتك المعتادة
عندما يتجاوز حجم الإرسال حدا معينا، يجدر تخصيص مسار مستقل لبريد معاملات الموقع.
يختلف البريد الآلي عن البريد الذي يكتبه الأشخاص في سلوكه وطريقة تقييمه. إرسال خمسمئة رسالة لإعادة تعيين كلمات المرور دفعة واحدة بعد حادث أمني لا يشبه مراسلات شخص يكتب رسائله بنفسه. وإذا خرج النوعان عبر المسار نفسه، أصبحت سمعة حركة البريد الآلي هي نفسها سمعة مراسلاتك العادية.
تجعل ملفات SMTP المخصصة لكل نطاق عملية الفصل مباشرة: وجّه النطاق الذي يرسل منه تطبيقك إلى مسار، والنطاق الذي يراسل منه فريقك إلى مسار آخر. عندها تظل المشكلة في الجهة التي حدثت فيها. تجد خطوات الإعداد في دليل إعداد SMTP مخصص لكل نطاق.
تذهب بعض الشركات إلى أبعد من ذلك وتستخدم نطاقا فرعيا منفصلا بالكامل للبريد الآلي، ما يعزل السمعة تماما مقابل عنوان مرسل يبدو أقل ترتيبا بقليل. يعتمد ما إذا كان ذلك يستحق العناء على حجم الإرسال.
متى تكون خدمة البريد المخصصة للمعاملات هي الخيار الصحيح
لنكن واضحين بشأن الحدود: عند الوصول إلى حجم إرسال كبير فعلا، توجد خدمات متخصصة في بريد المعاملات لأسباب وجيهة.
إذا كنت ترسل عشرات الآلاف من الرسائل يوميا، فستحتاج إلى أحداث تسليم لكل رسالة، وإشعارات webhook عند الارتداد، وإدارة القوالب، وتحليلات مفصلة. هذه الوظائف هي الغرض الأساسي من تلك الخدمات، ولا يقدمها أي مستضيف بريد بالمستوى نفسه.
صممت حدودنا اليومية للمراسلات لا للحملات، إذ تتيح باقة Starter إرسال 1,000 رسالة لكل صندوق بريد يوميا، وتصل باقة Agency إلى 2,500 رسالة. يندرج بريد معاملات موقع متجر صغير أو نظام حجوزات ضمن هذه الحدود بسهولة. أما المنصة ذات الحجم الكبير فلا تناسبها هذه الحدود، والبنية الصحيحة لها هي ربط خدمة متخصصة في بريد المعاملات عبر ملف SMTP مخصص. يفصل ذلك استضافة البريد عن الإرسال الجماعي من دون الحاجة إلى التعامل مع مزودين منفصلين لاستضافة البريد.
التأكد من أنه يعمل فعلا
أهم عادة يمكنك اتباعها هي التحقق بدلا من الافتراض، لأن أعطال هذا النوع من البريد تمر من دون تنبيه.
أنشئ رسالة حقيقية، كأن تقدم طلبا تجريبيا أو تطلب إعادة تعيين كلمة المرور، ثم أرسلها إلى عنوانين لدى مزودين رئيسيين مختلفين. افتح ترويسات الرسالة وتأكد من اجتياز SPF وDKIM ومن تحقق المحاذاة في DMARC. نجاح الاختبارات الثلاثة يعني أن الإعداد اكتمل فعليا.
كرر هذا الفحص كل ثلاثة أشهر، وكذلك فور إجراء أي تعديل على DNS أو تغيير شركة الاستضافة. غالبا لا يتعطل بريد معاملات الموقع عند إعداده، بل حين يتغير شيء مرتبط به، ولا يخطر لأحد إعادة اختبار تأكيدات الطلبات بعد نقل خوادم الأسماء.
إذا كانت الرسائل تصل ولكنها تذهب إلى مجلد الرسائل غير المرغوب فيها، فعادة ما تكشف إحصاءات التسليم الخاصة بالنطاق وتقارير DMARC عن السبب أسرع من تخمين تعديلات يمكن إجراؤها على المحتوى.
