مشكلة جمع استضافة الويب وبريد النطاق وحلها

يعد بريد النطاق المرفق باستضافة ويب مشتركة من مشكلات قابلية التسليم الشائعة التي يقع فيها صغار المشغلين. تكون الحزمة مريحة عند التسجيل، لكن بنيتها قد تضعف الوصول إلى صندوق الوارد. وبعد ستة أشهر، قد تبدأ ردود العملاء بالوصول إلى الرسائل غير المرغوب فيها من دون أن يعرف المشغل السبب، لأن سمعة عنوان IP المشترك لا تظهر من داخل الخدمة.

نشأت معظم إعدادات «نطاق البريد مع استضافة الويب» لأن صفحة الدفع لدى المسجل دفعت بالحزمة عند التسجيل. ويظهر الفخ عندما يتسبب أحد المستأجرين على عنوان IP المشترك في إدراجه ضمن قائمة حظر، فتتراجع قدرة جميع المستأجرين على ذلك العنوان على الوصول إلى صندوق الوارد أياما أو أسابيع. ويمكن أن تستغرق إحدى طرق المعالجة 30 دقيقة: نقل البريد إلى مضيف متخصص مع إبقاء الموقع في مكانه.

يسمي هذا الدليل أنماط الإخفاق ويشرح المعالجة. ولإطار تحديد احتياجات الفريق الصغير، راجع استضافة البريد للشركات الصغيرة.

ما هو نطاق البريد مع استضافة الويب فعليا

إنه ميزة استضافة البريد التي تأتي ضمن خطط استضافة الويب المشتركة. يبيع مزودو الخدمات المعتمدة على cPanel، مثل Bluehost وHostGator وHostinger واستضافة GoDaddy وما يشابهها، النطاق والموقع والبريد في حزمة واحدة. ويعمل خادم البريد على عنوان IP نفسه الذي يستخدمه موقعك ومواقع مئات المستأجرين الآخرين.

تنطوي الحزمة على جوانب ضعف هيكلية في عدة أبعاد مهمة للوصول إلى صندوق الوارد: سمعة عنوان IP المشترك، والمصادقة الافتراضية الضعيفة، وغياب رؤية DMARC، وجمع DNS في الحزمة بما يربط كل طبقة بالمزود نفسه. وقد تخفي راحة التسجيل تكلفة في قابلية التسليم لا تظهر إلا بعد أشهر.

أنماط إخفاق الحزمة الأربعة

قد تؤثر أربعة أنماط من الإخفاق في نطاق البريد المرفق باستضافة ويب مشتركة. وهي مشكلات هيكلية وليست مجرد خيارات إعداد يسهل تصحيحها. وكل منها قد يكلفك قابلية التسليم أو يزيد صعوبة النقل، وهي تكاليف نادرا ما يضيفها المشغلون إلى حساب الوفورات الظاهرية للحزمة عند التسجيل.

1. تضرر سمعة عنوان IP المشترك. يتسبب مستأجر مزعج في إدراج العنوان ضمن قائمة حظر، فيتراجع وصول الجميع إلى صندوق الوارد.
2. مصادقة افتراضية ضعيفة. يكون SPF سجلا مشتركا واحدا؛ وقد يغيب DKIM؛ ونادرا ما يرسل DMARC التقارير إلى وجهة مفيدة.
3. غياب الرؤية عبر DMARC. لا يمكنك معرفة من ينتحل نطاقك إذا لم توجه الحزمة التقارير إلى صندوق بريد تتحكم فيه.
4. صعوبة الخروج عند النقل. يكون DNS والمسجل ومضيف صندوق البريد لدى مزود واحد، ولذلك يعني المغادرة تبديل الثلاثة.

يضاعف كل إخفاق أثر الإخفاقات الأخرى. فالمصادقة الضعيفة تزيد مشكلة عنوان IP المشترك، وغياب رؤية DMARC يعني اكتشاف المشكلات متأخرا، وصعوبة الخروج تمنع الانتقال السريع. وتفسر المشكلات الأربع معا سبب تراجع أداء إعدادات البريد المجمعة غالبا عند التوسع.

الإخفاق 1: تضرر سمعة عنوان IP المشترك

تضرر سمعة عنوان IP المشترك هو أول مشكلة هيكلية. يخرج بريدك الصادر من عنوان IP مشترك مع 100-500 مستأجر آخر. وعندما يرسل أحدهم رسائل مزعجة، قد يدرج العنوان في قوائم حظر رئيسية، فيتراجع وصول رسائلك إلى صندوق الوارد حتى إزالة الإدراج، وهو أمر يستغرق غالبا أياما أو أسابيع.

لا يتوزع الضرر بالتساوي. فنادرا ما يتحمل المستأجر الذي تسبب في الإدراج تكلفة المعالجة. أما بقية المستأجرين على عنوان IP نفسه، فيدفعون الثمن في صورة ردود مفقودة وشكاوى عملاء. ولا يبادر كثير من مزودي استضافة الويب إلى تنبيه المستأجرين المتأثرين عند وقوع حدث في قائمة حظر؛ بل تكتشفه عندما تلاحظ ردودا أقل من المعتاد وتبدأ التحقيق. وقد يكون الأثر حينها قد تراكم خلال أيام أو أسابيع من البريد المهم للأعمال.

الإخفاق 2: مصادقة افتراضية ضعيفة

المصادقة الافتراضية الضعيفة هي الإخفاق الثاني. ينشر SPF في سجل مشترك واحد يغطي مرسلي المنصة المشتركة كلها، ولا يمكنك حصره في المرسلين الفعليين لنطاقك. وغالبا ما يغيب DKIM تماما؛ وإذا وجد، فقد لا يدور المفتاح بانتظام. كما أن DMARC نادرا ما ينشر.

حتى عندما تكون سمعة عنوان IP المشترك نظيفة، قد تكون مصادقة بريدك الصادر ضعيفة. تفرض جهات الاستقبال الحديثة، مثل تطبيق Gmail لقواعد المرسلين بكميات كبيرة وفحوص المحاذاة الأكثر صرامة لدى Microsoft، عقوبات على البريد غير الموثق عند إرساله بكميات كبيرة. وتطبق العقوبة على نطاقك بصرف النظر عن سمعة عنوان IP، ولذلك قد يكون أداء البريد المرفق بالاستضافة أدنى من المتوقع حتى على عنوان مشترك نظيف.

الإخفاق 3: غياب الرؤية عبر DMARC

تتيح تقارير DMARC اكتشاف من يرسل بريدا مدعيا أنه من نطاقك: سواء كانوا مرسليك الشرعيين، الذين يحتاجون إلى المصادقة، أو منتحلين يحاولون تقليد العلامة التجارية. ومن دون تدفق التقارير إلى صندوق بريد تتحكم فيه، يظل الطرفان غير مرئيين.

لا تعرض منصات كثيرة لاستضافة الويب المجمعة توجيه تقارير DMARC. فلا يمكنك رؤية من ينتحل نطاقك لأن التقارير تتجه إلى المزود بدلا منك. وقد يسمح غياب الرؤية بتراكم المشكلات أشهرا قبل ظهورها. ويمكن لمضيفي صناديق البريد المتخصصين توجيه التقارير إلى صندوق مخصص لكل نطاق لتوفير الرؤية من البداية. راجع البريد الإلكتروني بنطاق مخصص للإطار الأشمل للمصادقة.

الإخفاق 4: صعوبة الخروج عند النقل

تضع الحزمة DNS والمسجل ومضيف صندوق البريد لدى المزود نفسه. ويعني تبديل أحدها عادة تبديل البقية، ما يحول تغييرا كان يفترض أن يقتصر على سجل MX إلى مشروع نقل يستمر عدة أسابيع. كما يفرض بعض المزودين رسوما قدرها $50-200 لكل صندوق بريد مقابل المساعدة في الخروج من المنصة.

تفسر هذه الصعوبة سبب بقاء المشغلين على الإعدادات المجمعة مدة أطول مما ينبغي. فقد تتجاوز تكلفة النقل، من حيث الوقت والمال وتعطيل العملاء، التكلفة الهامشية للبقاء ربع سنة آخر. وقد تؤدي تكلفة قابلية التسليم المتراكمة في النهاية إلى النقل على أي حال، لكن في وقت متأخر عما كان سيحدث لو قلت صعوبة الانتقال. ويمكن لأي حزمة تتحكم في الطبقات الثلاث أن تنشئ هذا الفخ.

شرح المعالجة في 30 دقيقة

تتمثل إحدى طرق معالجة أنماط الإخفاق في نقل البريد إلى مضيف صناديق متخصص مع إبقاء الموقع في مكانه. لا تتغير سجلات A وCNAME للموقع. بل تحدث سجلات MX فقط لتشير إلى مضيف صندوق البريد الجديد. والتكلفة المذكورة للصندوق الجديد هي $0-51/year.

الخطوات بالتفصيل: سجل في TrekMail، باستخدام Nano المجاني أو Starter بسعر $4/month. أضف النطاق في لوحة التحكم. ابحث عن قسم سجلات DNS في cPanel الخاص باستضافة الويب، ويوجد عادة ضمن "Zone Editor" أو "DNS Manager." استبدل سجلات MX، وهي الإعدادات التي تخبر الإنترنت بمكان تسليم بريد نطاقك، بقيم TrekMail. انشر سجلات SPF وDKIM وDMARC التي ينشئها معالج TrekMail. أرسل رسالة اختبار من الصندوق الجديد إلى Gmail وOutlook وYahoo. وتأكد من ظهور PASS في الترويسات لدى الثلاثة. بذلك تكتمل العملية. ويمكن لكثير من المشغلين إتمامها في أقل من 30 دقيقة.

كيف ينسجم TrekMail مع المعالجة

يتولى TrekMail طبقة صندوق البريد من دون التحكم في DNS أو استضافة الموقع أو تسجيل النطاق. تنشئ المنصة سجلات DNS لتنشرها لدى مضيف DNS الحالي؛ ويستمر تقديم الموقع من مضيف الويب القائم؛ ويبقى النطاق لدى المسجل الحالي. ولا تنتقل سوى طبقة البريد.

وفقا للإعداد الموصوف، يحدث تدوير DKIM لكل عميل وإدارة SPF آليا وتوجيه تقارير DMARC بصورة افتراضية. وتكون وسائل الحماية الهيكلية من أنماط الإخفاق الأربعة مدمجة في المنصة، ما يقلل حاجة المشغل إلى الإعداد اليدوي. راجع أسعار البريد الإلكتروني للأعمال لمقارنة التكلفة بالحزمة.

الخطوات التالية

معالجة بريد النطاق المرفق باستضافة مشتركة واضحة: أبق الموقع في مكانه وانقل البريد إلى مضيف صناديق متخصص. حدث سجلات MX والمصادقة فقط. ويعالج هذا الفصل أنماط الإخفاق الأربعة هيكليا من دون المساس بنظام DNS للموقع أو المسجل.

جرب TrekMail Nano وفقا للشروط الحالية على trekmail.net/pricing؛ فالعرض الموصوف لا يتطلب بطاقة ولا يذكر انتهاء للتجربة. تغطي فئة Nano عدد 10 domains × 10 mailboxes؛ وتوسع Starter بسعر $4/month السعة إلى 50 × 100 عندما يرتفع حجم الإرسال.

نادرا ما يعاد النظر في هذه المشكلات لأن المشغلين لا يرون تكلفتها؛ فهي تدفع في صورة ردود مفقودة ومحادثات مبيعات أبطأ بدلا من فواتير مالية. وقد يكشف الانتقال إلى مضيف متخصص أن التكلفة كانت حقيقية طوال الوقت؛ ويشير بعض المشغلين إلى تحسن معدلات الرد وتسارع دورات المبيعات خلال أسابيع من النقل، لكن النتيجة تعتمد أيضا على عوامل أخرى.

التشخيص بسيط: تحقق مما إذا كانت تقارير DMARC المجمعة، وهي ملخصات يومية توضح من يرسل بريدا مدعيا أنه من نطاقك، تصل إلى صندوق بريد تتحكم فيه. وإذا لم تصل، فلديك نمط الإخفاق 3 وينبغي التحقق من الأنماط الثلاثة الأخرى أيضا. وقد تعالج الهجرة إلى مضيف متخصص الأنماط الأربعة دفعة واحدة. ونادرا ما ينبه المسجلون الذين يبيعون الحزم إلى مشكلة قابلية التسليم، لأن الحزمة مربحة لهم. ويتعين على المشغلين كشف المشكلة بأنفسهم، عادة عبر تقارير DMARC أو ملاحظة انخفاض معدل الرد.

تزداد ضرورة المراجعة لدى المشغلين الذين يملكون عدة مواقع على حساب الاستضافة المشتركة نفسه. فبريد كل موقع الصادر يشارك عنوان IP نفسه وضعف المصادقة نفسه. ويفصل المضيف المتخصص الذي يدور DKIM لكل عميل سمعة كل علامة تجارية، ما قد يمنع انتقال أثر حادثة تخص علامة واحدة إلى بقية العلامات في حساب المشغل نفسه.

ملاحظة أخيرة: نادرا ما ينبه المسجل الذي باع الحزمة في البداية إلى مشكلة قابلية التسليم من تلقاء نفسه. فالحزمة مربحة والخروج منها ينطوي على احتكاك. وعلى المشغلين كشف المشكلة بأنفسهم من خلال تقارير DMARC أو ملاحظة انخفاض معدل الرد. وتبدأ المعالجة عادة من المشغل بدلا من توصية المزود. ضع تذكيرا في التقويم لفحص تقارير DMARC كل ثلاثة أشهر إذا لم تفعل ذلك بعد.