قابلية توصيل البريد الإلكتروني لمواقع إعلانات البالغين: لماذا لا يصل رمز التحقق أبدًا
العطل الذي لا يتلقى أحد تنبيهًا بشأنه
يسجّل مستخدم جديد، يدخل عنوان بريد إلكتروني، وينتظر الرمز المكوّن من ستة أرقام الذي يتيح له إتمام التحقق من العمر. لا يصل الرمز في الدقيقة التي يفترض أن يصل فيها. ربما يقع في مجلد البريد المزعج بعد عشر دقائق، بعد أن يكون المستخدم قد يئس وأغلق التبويب. وربما يرفضه خادم البريد المستقبِل مباشرة لحظة الإرسال، برسالة ارتداد تمر في سجلّ لا يراقبه أحد. في الحالتين، لا شيء في هذه التجربة يخبر مشغّل الموقع أن هناك خللًا ما. تُظهر قناة التسجيل ببساطة زائرًا آخر أدخل عنوان بريد إلكتروني ولم يعد أبدًا، لا يمكن تمييزه عن شخص غيّر رأيه فحسب.
هذا الغموض هو المشكلة الحقيقية، أكثر من أي سبب تقني منفرد. تراقب معظم المواقع ما إذا كان البريد قد أُرسل، علامة صح خضراء في لوحة تحكم، لا ما إذا كان قد وصل فعلًا أمام إنسان. هذان حدثان مختلفان، والفجوة بينهما هي بالضبط حيث تختبئ مشكلة التوصيل لأشهر. مشغّل لم يمر يومًا بانقطاع في الاستضافة أو تجميد لحساب معالج الدفع قد يظل يخسر نسبة حقيقية من التسجيلات الجديدة بسبب مشكلة بريد ليس لديه أي طريقة لملاحظتها، لأنه لا حادثة هناك، ولا تذكرة دعم، ولا لوحة تحكم تتحول إلى اللون الأحمر.
هذا نوع مختلف من مخاطر الموردين عن ذلك الذي يغلق حساب استضافة بإشعار يستشهد ببند لم يُعِد أحد قراءته منذ يوم التوقيع. المضيف المُعلَّق صاخب: يظلم الموقع، ويكتشف المشغّل الأمر خلال دقائق لأن العملاء يبلغون عن ذلك ولوحة التحكم تبلغ عنه أيضًا. أما مشكلة التوصيل فهادئة بطبيعتها. يبقى حساب الإرسال مفتوحًا، وتستمر الفاتورة الشهرية بالوصول، والعرض الوحيد المرئي هو قناة تسجيل تفقد أشخاصًا في الخطوة الأخيرة لأسباب تبدو، من جانب المشغّل، كتسرّب طبيعي لا كخلل تقني قابل للإصلاح.
يظل السبب الجذري نفس نوع الاحتكاك القائم على الفئة الذي يظهر مع مقدّمي الاستضافة والبنوك ومعالجات الدفع. تصنّف مزوّدات صناديق البريد وخدمات إرسال البريد الإلكتروني هذه الفئة على أنها أعلى خطورة من معظم غيرها، بعضها بشكل صريح وباسمها، ويبدأ نطاق جديد بلا سجل إرسال كل رسالة بعائق لا علاقة له بمحتوى الرسالة فعليًا.
لماذا تُرشَّح هذه الفئة أكثر من غيرها
لا تتعامل مرشّحات البريد المزعج ومزوّدو خدمة البريد الإلكتروني مع كل قطاع بنفس الطريقة، ويستحق الأمر قراءة الفروق قبل التسجيل لا بعد أن يُعلَّم حساب ما. تسرد سياسة سيندغريد المنشورة بشأن المحتوى المحظور، كبندين منفصلين، «الإباحية أو المحتوى الجنسي الصريح»، وبشكل مستقل، «خدمات المرافقة، والبحث عن عرائس أو أزواج بالمراسلة، ووكالات الزواج الدولية، وخدمات مشابهة». هذا البند الثاني لا يتعلق بما تحتويه الرسالة. إنه يسمّي النشاط التجاري نفسه سببًا للاستبعاد، ما يعني أن رمز تحقق نصيًا بسيطًا يرسله دليل مرافقة قد يقع خارج السياسة بسبب الفئة وحدها، بغض النظر عن مدى حياد الرسالة.
أما سياسة الاستخدام المقبول لدى ميلغن فترسم الحد في مكان مختلف تمامًا. يقتصر قسمها الخاص بالمحتوى المحظور على المواد التي تشكّل أو تروّج لاستغلال الأطفال، أو ممارسات جنسية مع الحيوانات، أو أفعال غير قائمة على الرضا، دون بند منفصل يسمّي أنشطة البالغين أو خدمات المرافقة كفئة. هذا قيد أضيق بكثير من قيد سيندغريد، موجّه نحو ما هو غير قانوني بدلًا من القطاع الذي يرسل. مزوّدان كبيران وعامّان يمكن الوصول إليهما عبر النوع نفسه من نموذج التسجيل، لكنهما يرسمان الحد في موقعين مختلفين حقًا، ومشغّل يختار أحدهما دون قراءة ما بعد صفحة الأسعار لا سبيل له لمعرفة أي جانب من ذلك الحد يقع فيه حسابه حتى تكشف ذلك مراجعة ما.
هذه الفجوة نفسها في العناية الواجبة تفاجئ المشغّلين ببند إنهاء استضافة أو شبكة توصيل محتوى لم يقرؤوه قط، على مستوى أعمق في المكدّس. السؤال الذي ينبغي طرحه قبل اختيار مزوّد بريد إلكتروني ليس ما إذا كان يسمح تقنيًا بإرسال البريد لهذا النوع من الأعمال عمومًا. السؤال هو ما إذا كانت سياسة المزوّد المكتوبة تسمّي فئة النشاط تحديدًا، كتابيًا، قبل خروج أول رمز تحقق، لا بعد أن تكتشفه مراجعة مكافحة الإساءة.
يفاقم النطاق الجديد للإرسال هذا الأمر إلى جانب أي شيء يسمح به المزوّد. تُقدّر المرشّحات تاريخ النطاق ونمط حجمه بشدة، ونطاق ظهر مؤخرًا وبدأ فورًا بإرسال رموز تلقائية بحجم كبير يبدو، لمرشّح بلا إشارة أخرى، وكأنه نمط حساب أُنشئ لغرض ضيق ثم هُجر بعد أن جرى تعليمه. هذا ليس حكمًا على النشاط التجاري؛ إنه تطابق نمط يثيره أي نطاق جديد تمامًا، سواء كان إعلانات بالغين أو لا، ولا يتلاشى إلا مع الوقت وسلوك إرسال ثابت.
الحد الأدنى التقني الذي يفرضه الآن كل مزوّد صندوق بريد
حتى مزوّد ترحّب سياسته بالحساب دون تحفّظ لا يستطيع بمفرده جعل رسالة تصل إلى صندوق الوارد. اعتبارًا من الأول من فبراير 2024، تطلب غوغل من كل مرسِل يبعث بريدًا إلى عناوين جيميل، بصرف النظر عن الحجم، تحقيق حد أدنى موثّق: كحد أدنى، ضبط SPF أو DKIM بشكل صحيح على نطاق الإرسال. يسرد SPF الخوادم المخوّلة بالإرسال باسم النطاق؛ ويوقّع DKIM كل رسالة كي يتمكن الخادم المستقبِل من التأكد من أنها لم تتعرض للتعديل أثناء النقل. أما المرسلون الذين يبلغون 5000 رسالة يوميًا إلى عناوين جيميل تحديدًا فيواجهون عتبة أعلى: SPF وDKIM معًا، بالإضافة إلى DMARC منشورًا على النطاق، على الأقل في وضع المراقبة. موقع إعلانات يرسل رموز التحقق من العمر، وإعادة تعيين كلمات المرور، وإيصالات الدفع بحجم حقيقي يتجاوز عتبة الـ5000 رسالة هذه بسرعة، لأن كل واحدة منها تُحتسب ضمن المجموع.
تضع إرشادات غوغل المنشورة نفسها رقمًا صارمًا فوق المصادقة: يجب على المرسلين من أي حجم إبقاء معدل الشكاوى المُبلَّغ عنه عبر أدوات بريد غوغل الرئيسي تحت 0.30 بالمئة، وتوصي الإرشادات نفسها بالبقاء تحت 0.10 بالمئة كهامش أمان حقيقي، بدل معاملة 0.30 بالمئة كهدف مريح يُقترب منه. يظهر عدم الامتثال في صورة عطلين منفصلين وموثّقين على حدة، لا عقوبة غامضة واحدة. البريد الذي يفشل في SPF أو DKIM أو DMARC قد يُعلَّم كبريد مزعج أو يُرفض مباشرة برمز خطأ SMTP رقم 5.7.26. أما المرسلون الذين يتجاوزون حصة الإرسال التي تسمح بها غوغل فيصطدمون بجدار مختلف، خطأ تقييد المعدل رقم 4.7.28. لا يعلن أي منهما «هذا القطاع غير مرحّب به هنا». يبدوان معًا، من لوحة تحكم المطوّر، وكأنهما خلل تقني عادي، وهذا بالضبط سبب ملاحظتهما بعد أسابيع بدل إصلاحهما في يوم بدئهما.
تنشر ياهو، التي تخدم بنيتها التحتية عناوين AOL أيضًا، النوع نفسه من المتطلبات باستقلالية: SPF وDKIM معًا، وسياسة DMARC بحد أدنى p=none يجب أن تنجح، وسقف الشكاوى نفسه عند 0.30 بالمئة، ساري المفعول وفق الجدول الزمني نفسه منذ فبراير 2024. مشغّل يحلّ هذه المسألة لجيميل ويفترض أن ياهو وAOL ستحذوان حذوها يكون عادة محقًا في الآلية، بما أن المزوّدين تقاربا نحو أرقام شبه متطابقة، لكن النظامين ما زالا يقيسان القواعد ويطبّقانها بشكل منفصل، فنطاق في وضع سليم مع أحدهما ليس بالضرورة في وضع سليم مع الآخر تلقائيًا.
يُكتب أحد متطلبات هذه المجموعة بضيق عن قصد. يُطبَّق إلغاء الاشتراك بنقرة واحدة، باستخدام ترويسة List-Unsubscribe، على رسائل التسويق والرسائل المشترَك بها تحديدًا، بحسب صياغة غوغل نفسها. رمز التحقق أو إيصال الدفع ليسا من أي من الفئتين، فليس هذا ما يستهدفه هذا البند بالتحديد. أما متطلبات المصادقة والسمعة الأعلى منه، SPF وDKIM وDMARC وسقف الشكاوى، فليست مقيَّدة بهذا الشكل: تنطبق على كل رسالة يرسلها النطاق، بما في ذلك الرسائل المعاملاتية.
الخطأ الذي يجرّ معه البريد المهم أيضًا
الطريقة الأكثر شيوعًا التي يُتلف بها مشغّل رسائل التحقق الخاصة به هي إرسال بريد تسويقي من النطاق نفسه الذي يرسل رموز التحقق وإيصالات الدفع. تُتابَع السمعة غالبًا على مستوى نطاق ونطاق فرعي الإرسال، وهذا سبب فائدة فصل التدفقات، لكن العزل بين النطاقات الفرعية ليس مطلقًا: قد ترتد زيادة الشكاوى على نطاق فرعي واحد على النطاق الرئيسي أيضًا، خاصة إذا شارك التدفقان هوية توقيع DKIM نفسها خلف الكواليس. رسالة ترويجية تعلن عن ميزة جديدة أو عرض موسمي، تُرسَل إلى قائمة أصبحت قديمة، تنتج بالضبط ذلك النوع من زيادة الشكاوى القادرة على خفض سمعة نطاق مشترك، ويصل جزء من هذا الضرر إلى رمز التحقق الذي ينتظره الآن مستخدم سجّل للتو، رسالة لا علاقة لها إطلاقًا بالإرسال التسويقي الذي سبّب المشكلة.
هنا أيضًا يتقاطع الانضباط التشغيلي المبني حول التحقق من العمر مع مشكلة تسليم بريد تقنية بحتة بطريقة يسهل إغفالها. لا يكون تدفق التحقق الذي يعتمد على وصول رمز إلى صندوق بريد موثوقًا إلا بقدر موثوقية سمعة نطاق الإرسال في اليوم الذي يخرج فيه ذلك الرمز، والسمعة مورد مشترك بين كل أنواع الرسائل التي تستخدم بنية تحتية مرتبطة، ما لم يحرص المشغّل عن قصد على إبقائها منفصلة.
الحل هيكلي، وليس إعدادًا يُقلَب بعد وقوع زيادة الشكاوى بالفعل. أرسل البريد المعاملاتي، رموز التحقق، تأكيدات الدفع، إعادة تعيين كلمات المرور، من نطاق فرعي مخصص لا يُستخدم لأي شيء آخر، مثل mail.example.com بدلًا من النطاق العاري أو نطاق فرعي تسويقي مشترك، ووقّعه بمفتاح DKIM خاص به بدلًا من مفتاح يُعاد استخدامه عبر كل التدفقات. أرسل المحتوى التسويقي أو النشرات البريدية من نطاق فرعي منفصل تمامًا، مثل news.example.com، بسجلات مصادقة خاصة به وسمعة خاصة به قادرة على امتصاص أسبوع شكاوى سيئ دون أن تجرّ معها البريد الذي يجب أن يصل. يمكن للتدفقين المرور عبر الحساب نفسه لدى المزوّد، لكن يجب أن يبدوا، وأن يُوقَّعا، كمرسلَين متمايزين بوضوح من منظور خادم البريد المستقبِل.
ما يجب فحصه فعليًا هذا الأسبوع
ابدأ بسحب سياسة الاستخدام المقبول لأي خدمة ترسل حاليًا البريد المعاملاتي للموقع، وتحقق كتابيًا مما إذا كانت تسمّي فئة النشاط تحديدًا، بالطريقة نفسها التي نجح بها الفحص السابق لعقود الاستضافة وشبكات توصيل المحتوى لدى مزوّدي البنية التحتية. مزوّد تستبعد سياسته الفئة بالاسم بالفعل ليس مزوّدًا يُبنى عليه تدفق تحقق، مهما كان موثوقًا حتى الآن، لأن مراجعة الحساب قد تنهي تلك الموثوقية دون أي إنذار مسبق.
تحقق من أن SPF وDKIM وDMARC منشورة بالفعل وناجحة على النطاق الذي يرسل حاليًا رسائل التحقق والإيصال، بدلًا من افتراض صحتها لأن أحدهم ضبطها مرة، منذ سنوات. سجل DNS كان صحيحًا وقت كتابته قد يصبح قديمًا بعد ترحيل مزوّد، ونطاق بلا مصادقة يبدأ كل رسالة باحتمال رفض حقيقي بموجب القواعد التي تطبّقها غوغل وياهو منذ فبراير 2024، بصرف النظر عمّا تقوله الرسالة.
افصل البريد المعاملاتي عن التسويقي على نطاقين فرعيين منفصلين بمفتاحي توقيع منفصلين إن لم يكونا منفصلين بالفعل، وعامل هذا كعمل بنية تحتية لا كقرار يخص فريق التسويق، إذ يكلّف الخطأ هنا فشل تحقق هوية، لا صفقة مفقودة.
راقب معدل الشكاوى الفعلي عبر تقارير المزوّد نفسه أو عبر أدوات بريد غوغل الرئيسي وفق جدول ثابت، وعامل أي اقتراب من 0.10 بالمئة كنقطة يجب التحقيق فيها، لا 0.30 بالمئة، إذ إن 0.30 بالمئة أقرب إلى النقطة التي يبدأ عندها رفض البريد من كونها نقطة بداية المشكلة. وأرسل من وقت لآخر تسجيلًا اختباريًا حقيقيًا إلى عنوان جيميل شخصي وعنوان ياهو شخصي، وقِس المدة التي يستغرقها الرمز للوصول ومكان وصوله، لأن لوحة تحكم تُبلغ عن إرسال ناجح تُبلغ عمّا غادر الخادم، لا عمّا رآه المستخدم فعليًا.
