استضافة البريد الإلكترونيّ: بريدٌ باسم نطاقك يصل إلى صندوق الوارد

منذ 1 فبراير 2024 تطلب Google من كلّ من يرسل رسالةً إلى حسابات Gmail أن يثبت أنّها من نطاقه فعلًا، بسجلٍّ واحدٍ على الأقلّ من سجلّين اسمهما SPF وDKIM.^[1] والرسالة التي لا تثبت ذلك قد تُرفض أو تذهب إلى البريد المزعج، مهما كانت مهمّة. ولهذا صار البريد باسم نطاقك مسألةً تقنيّةً قبل أن يكون مسألة مظهر: عنوانٌ جميلٌ على نطاقك لا يفيدك إن كانت رسائله لا تصل.

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

لماذا بريدٌ باسم نطاقك

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

وللعنوان على النطاق فائدةٌ ثانيةٌ أقلّ ظهورًا: أنت تتحكّم في من يرسل باسمه. السجلّات التي ستراها في هذا المقال تسمح لك أن تقول للعالم أيّ الخوادم مخوّلةٌ بالإرسال باسم نطاقك، وماذا يفعل المستقبِل برسالةٍ تدّعي أنّها منك وهي ليست كذلك. وهذا لا تملكه على عنوانٍ مجّانيّ، لأنّ النطاق ليس نطاقك.

والبريد المجّانيّ العامّ مناسبٌ تمامًا لحياتك الشخصيّة، ولمشروعٍ في أسبوعه الأوّل يختبر فكرة. لكن حين تبدأ مراسلة عملاء أو شركاء، أو تضع عنوانًا في أسفل موقعك، فاجعله على نطاقك. رأيي أنّ هذه من أرخص الخطوات التي تجعل مشروعك يبدو جادًّا، ومن أصعبها تغييرًا بعد سنواتٍ من استعمال عنوانٍ آخر.

الموقع في سجلٍّ، والبريد في سجلٍّ آخر

رأيت في مقال نظام أسماء النطاقات أنّ نطاقك مجموعة سجلّات، لكلٍّ منها وظيفة. سجلّ العنوان يقول للمتصفّح أين يجد موقعك. وسجلٌّ آخر اسمه سجلّ تبادل البريد، واختصاره MX، يقول لخوادم البريد في العالم أين تسلّم الرسائل المرسلة إلى عناوين نطاقك. والسجلّان مستقلّان تمامًا: يمكن أن يشير الأوّل إلى استضافة موقعك، والثاني إلى شركة بريدٍ في قارّةٍ أخرى.

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

شكل 1

وفي سجلّ تبادل البريد رقمٌ صغيرٌ يستحقّ أن تفهمه، لأنّك ستراه في كلّ إعدادٍ تنسخه. يسمح النطاق بأكثر من سجلّ بريد، لكلٍّ منها رقم أفضليّة، ويقول معيار البريد إنّ الخادم المرسِل يرتّب السجلّات بهذا الرقم ويجرّب أصغرها أوّلًا.^[2] فإن لم يردّ الخادم الأوّل جرّب الذي يليه. هكذا يبدو سجلّان من هذا النوع:

example.com.   MX   10   mx1.mail.example.net.
example.com.   MX   20   mx2.mail.example.net.

الخادم ذو الرقم 10 هو الأساسيّ، وذو الرقم 20 احتياطيٌّ يُجرَّب إن تعطّل الأوّل. والأسماء هنا أمثلة، فخدمة البريد التي تشترك فيها تعطيك أسماء خوادمها وأرقامها، وعملك أن تنسخها كما هي.

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

أربعة خيارات لاستضافة بريدك

الخيار الأوّل هو البريد الذي يأتي مع استضافة موقعك. كثيرٌ من الخطط المشتركة تسمح لك بإنشاء صناديق بريدٍ من لوحة التحكّم، وقد رأيت ذلك في مقال لوحة التحكّم. هذا الخيار سهلٌ ولا يكلّف إضافة، لكنّ حدوده ضيّقة. تقول صفحة حدود البريد في Hostinger مثلًا إنّ البريد التجريبيّ الذي يأتي لسنةٍ مع بعض خطط الاستضافة يعطي كلّ صندوقٍ 1 غيغابايت و100 رسالةٍ في اليوم.^[3] مئة رسالةٍ تكفي شخصًا يراسل قليلًا، ولا تكفي متجرًا يرسل تأكيد طلبٍ لكلّ زبون. وتقول الصفحة نفسها إنّ خطّة البريد المدفوعة الأولى عند الشركة ترفع الحدّ إلى 1000 رسالةٍ في اليوم و5 غيغابايت لكلّ صندوق. والحدّ هنا لكلّ صندوقٍ على حدة لا للنطاق كلّه، والرسائل الواردة تُحسب منفصلةً عن الصادرة، فلا يأكل ما يصلك من حصّة ما ترسله.^[3]

والخيار الثاني خدمة بريدٍ متخصّصة، مثل Google Workspace وMicrosoft 365 وZoho Mail. هذه شركاتٌ صنعتها الأساسيّة البريد، فتعطيك تصفيةً أقوى للمزعج ومساحةً أكبر وحمايةً أفضل للحساب، وتسعّر عادةً لكلّ مستخدمٍ في الشهر. وبعضها يبدأ مجّانًا: تقول صفحة أسعار Zoho Mail إنّ خطّتها المجّانيّة تكفي حتى 5 مستخدمين، لكلٍّ منهم 5 غيغابايت، لنطاقٍ واحد. وفي الخطّة المجّانيّة قيدٌ يجب أن تعرفه قبل أن تعتمد عليها: لا تسمح بقراءة البريد عبر بروتوكولات الاستقبال المعتادة في برامج البريد، فتقرأ رسائلك من موقع الخدمة وتطبيقها.^[4]

والأسعار في هذا الخيار تتغيّر كثيرًا، فلن أكتب هنا رقمًا سيصير قديمًا بعد أشهر. افتح صفحة الأسعار الحاليّة للخدمة التي تفكّر فيها، واحسب السعر لكلّ مستخدمٍ حقيقيٍّ عندك فقط. فليس كلّ عنوانٍ يحتاج صندوقًا مدفوعًا: عنوان المبيعات وعنوان الدعم يمكن أن يكونا اسمين مستعارين يصبّان في صندوقٍ واحد، حتى يكبر فريقك ويحتاج كلٌّ منهما شخصًا.

والخيار الثالث التحويل وحده. بعض مزوّدي النطاقات وبعض الخدمات تنشئ لك عنوانًا على نطاقك لا صندوق له، يحوّل كلّ ما يصله إلى بريدك الشخصيّ القائم. تقول وثائق Cloudflare إنّ خدمة توجيه البريد عندها تعالج الرسائل الواردة وتوجّهها إلى العناوين التي تحدّدها، وإنّها متاحةٌ في الخطط المجّانيّة والمدفوعة.^[5] هذا حلٌّ جيّدٌ لمن يريد أن يستقبل على نطاقه دون تكلفة. لكنّه يحلّ نصف المسألة، لأنّ الردّ من العنوان نفسه يحتاج خادم إرسالٍ مخوّلًا في سجلّات نطاقك، وإلّا ردّ من عنوانه الشخصيّ.

والخيار الرابع أن تشغّل خادم بريدك بنفسك على خادمٍ افتراضيّ. أذكره لأنّه ممكن، ولا أنصح به لمن يقرأ هذه السلسلة. خادم البريد يحتاج سمعة إرسالٍ تُبنى في شهور، ويحتاج إعداداتٍ تطلبها الخدمات الكبرى صراحةً. من ذلك مثلًا أن يكون لعنوان الخادم سجلٌّ عكسيٌّ صحيح يطابق اسمه، وهو شرطٌ في إرشادات Google لكلّ المرسلين.^[1] وخطأٌ واحدٌ في هذه الإعدادات يجعل رسائلك كلّها مشبوهة.

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

متى تفصل البريد عن الاستضافة

رأيي واضح: افصل البريد عن استضافة الموقع في اللحظة التي يصير فيها البريد أداة عمل. المدوّنة الشخصيّة التي تستقبل رسالتين في الأسبوع تكفيها صناديق الاستضافة. أمّا المشروع الذي يعيش على مراسلاته، فأسبابه ثلاثة، وكلّ واحدٍ منها يكفي وحده.

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

والسبب الثاني السمعة. في الاستضافة المشتركة يرسل موقعك البريد من خادمٍ يشاركه مئات المواقع، وعنوان الخادم واحدٌ لهم جميعًا. فإن أرسل أحدهم مزعجًا، تضرّرت سمعة العنوان الذي ترسل منه أنت أيضًا. ومن رسائل الخطأ التي تشرحها Google رفضٌ برمز 550 5.7.1، وتقول إنّه قد يظهر حين ترسل من عنوانٍ مشتركٍ سمعته سيّئة.^[1]

والسبب الثالث أمنيّ. البريد هو الباب الذي تمرّ منه استعادة كلمات المرور في كلّ حساباتك الأخرى، فمن يدخل بريدك يستطيع أن يدخل ما بعده واحدًا بعد الآخر. والخدمات المتخصّصة تعطيك التحقّق بخطوتين وتنبيهات الدخول الغريب، وتراقب الحسابات على مدار الساعة، وقد رأيت في مقال الأمان والنسخ الاحتياطيّ لماذا يستحقّ كلّ حسابٍ مهمٍّ هذه الطبقة.

رسائل موقعك نفسه: نموذج التواصل وتأكيد الطلب

هنا فخٌّ يقع فيه أكثر أصحاب مواقع ووردبريس. يملأ زائرٌ نموذج التواصل، فيرسل الموقع رسالةً إليك، ولا تصل. أو يشتري زبونٌ من متجرك، ولا تصله رسالة تأكيد الطلب. والسبب في الغالب أنّ الموقع يرسل البريد بأبسط طريقةٍ متاحة: دالّةٌ في لغة PHP اسمها mail()، ترسل الرسالة من خادم الاستضافة مباشرةً دون أن تثبت أنّها من نطاقك.

تشرح Hostinger في صفحة دعمٍ خاصّةٍ بهذه المشكلة أنّ الرسائل المرسلة بهذه الدالّة تفتقد غالبًا ترويسات التحقّق، فتُعدّ مزعجًا أو تُرفض. ولهذا تحدّها بعشر رسائل في الدقيقة ومئةٍ في اليوم، وتنصح بالإرسال عبر بروتوكول إرسال البريد مع تسجيل دخول، بإضافةٍ مثل WP Mail SMTP في ووردبريس.^[6] والفكرة من الإضافة أن يرسل الموقع رسائله من صندوق بريدٍ حقيقيٍّ على نطاقك، باسم مستخدمٍ وكلمة مرور، فتمرّ بالسجلّات التي ستراها بعد قليل كأيّ رسالةٍ ترسلها أنت بيدك.

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

ثلاثة سجلّاتٍ تثبت أنّ الرسالة منك

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

الأوّل SPF، وهو قائمةٌ بالخوادم المسموح لها أن ترسل باسم نطاقك. يقرأها الخادم المستقبِل، فإن جاءت الرسالة من خادمٍ ليس في القائمة عرف أنّها مشبوهة. ولهذا السجلّ قاعدتان يكسرهما كثيرون. يقول معياره إنّ النطاق يجب ألّا يحمل أكثر من سجلٍّ واحدٍ منه، ويحدّ عدد الإحالات التي تحتاج استعلامًا في نظام الأسماء بعشر.^[7] فحين تضيف خدمةً جديدةً ترسل باسمك، كخدمة نشراتٍ بريديّة، أضفها إلى السجلّ القائم ولا تنشئ سجلًّا ثانيًا، وتذكّر أنّ كلّ خدمةٍ تضيفها تستهلك من الإحالات العشر.

والثاني DKIM، وهو توقيعٌ رقميٌّ يضيفه خادم الإرسال إلى كلّ رسالة. يصف معياره الأمر بأنّ صاحب النطاق يتحمّل مسؤوليّة الرسالة بتوقيعٍ مشفّر، يتحقّق منه المستقبِل بمفتاحٍ عامٍّ ينشره صاحب النطاق في نظام الأسماء.^[8] فإن عُدّلت الرسالة في الطريق، أو جاءت من خادمٍ لا يملك المفتاح الخاصّ، فشل التحقّق.

والثالث DMARC، وهو الذي يربط الاثنين ويقول للمستقبِل ماذا يفعل بالرسالة الفاشلة. يعرّف معياره ثلاث سياسات: لا إجراء، أو العزل في المزعج، أو الرفض.^[9] وتشترط Google لكبار المرسلين أن يطابق النطاق في خانة المرسِل نطاق أحد السجلّين الآخرين، وهذا ما يسمّى المحاذاة.^[1] هكذا يبدو سجلّان من هذه السجلّات لنطاقٍ تجريبيّ:

example.com.          TXT   "v=spf1 include:_spf.mail.example.net ~all"
_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

السطر الأوّل يقول إنّ خوادم خدمة البريد مسموحٌ لها بالإرسال، وما عداها مشبوه. والعلامة قبل كلمة all في آخره تحدّد قوّة هذا الحكم: علامة التلدة ~ تعني في المعيار أنّ الخادم غير المذكور «غالبًا غير مخوّل»، والشرطة – تعني أنّه غير مخوّلٍ صراحة.^[7] فابدأ بالتلدة حتى تتأكّد أنّ قائمتك كاملة، ثمّ انتقل إلى الشرطة. والثاني يطلب سياسة «لا إجراء» مع إرسال تقارير إلى عنوانٍ تحدّده. وسجلّ DKIM لا تكتبه بيدك، لأنّ فيه مفتاحًا طويلًا تولّده خدمة البريد وتعطيك إيّاه لتلصقه. ونصيحتي أن تبدأ سجلّ DMARC بسياسة «لا إجراء» أسابيع، وتقرأ التقارير لترى هل ترسل خدمةٌ تنساها باسمك، ثمّ ترفع السياسة إلى العزل، ثمّ إلى الرفض حين تطمئنّ.

ما تطلبه Gmail وOutlook في 2026

الخدمتان الأكبر للبريد الشخصيّ حوّلتا هذه السجلّات من نصيحةٍ إلى شرط. في إرشادات Google المعمول بها منذ فبراير 2024 شروطٌ لكلّ مرسِل: سجلّ SPF أو DKIM، وسجلٌّ عكسيٌّ صحيحٌ لعنوان الخادم، واتّصالٌ مشفّر، ونسبة إبلاغٍ عن المزعج تبقى تحت 0.3% في أداة مراقبة المرسلين. ومن يرسل أكثر من 5000 رسالةٍ في اليوم إلى حسابات Gmail تلزمه السجلّات الثلاثة، مع المحاذاة، ورابط إلغاء اشتراكٍ بنقرةٍ واحدةٍ في الرسائل التسويقيّة.^[1]

وMicrosoft سارت في الطريق نفسه لخدمتها الشخصيّة التي تشمل عناوين outlook.com وhotmail.com وlive.com. أعلنت في أبريل 2025 أنّ النطاقات التي ترسل أكثر من 5000 رسالةٍ في اليوم تحتاج السجلّات الثلاثة ناجحة. وفي تحديثٍ للإعلان نفسه قالت إنّ الرسائل غير المستوفية تُرفض منذ 5 مايو 2025 برمز خطأ 550 5.7.515.^[10]

قد تقول إنّك لا ترسل خمسة آلاف رسالةٍ في اليوم، فلا يعنيك هذا. لكنّ Google نفسها توصي في الصفحة ذاتها بأن تضبط السجلّات الثلاثة دائمًا، أيًّا كان حجم إرسالك.^[1] والسبب عمليّ: السجلّات الثلاثة تحمي نطاقك من الانتحال قبل أن تحمي رسائلك من المزعج، والمحتال الذي يرسل باسمك لا يهتمّ بحجم إرسالك أنت.

نقل البريد دون أن تضيع رسالة

إن قرّرت أن تنقل بريدك من الاستضافة إلى خدمةٍ متخصّصة، أو من خدمةٍ إلى أخرى، فالترتيب يشبه ترتيب نقل الموقع، مع فرقٍ واحد: للرسائل القديمة أرشيفٌ يجب أن ينتقل. أنشئ الصناديق في الخدمة الجديدة بالأسماء نفسها أوّلًا. ثمّ انقل الرسائل القديمة إليها، ومعظم الخدمات تعطيك أداة استيرادٍ تسحب الرسائل من الصندوق القديم ما دام يعمل، فلا تلغِ القديم قبل أن تنتهي.

ثمّ خفّض مدّة بقاء سجلّات البريد قبل التغيير بوقتٍ كاف، كما رأيت في مقال النقل، وغيّر سجلّ تبادل البريد إلى القيم التي تعطيك إيّاها الخدمة الجديدة. وأضف معه سجلّ DKIM الجديد، وحدّث سجلّ SPF ليضمّ خوادم الخدمة الجديدة. ثمّ أبقِ الصناديق القديمة تعمل أيّامًا، وافتحها مرّةً في اليوم، فقد تصلها رسائل من خوادم ما زالت تحفظ السجلّ القديم. وحين تمرّ أيّامٌ دون أن يصلها شيء، أغلقها.

أخطاء شائعة

الخطأ الأوّل سجلّا SPF على النطاق نفسه، واحدٌ للاستضافة وآخر لخدمة البريد. والمعيار يمنع ذلك صراحةً، فيفشل الفحص للسجلّين معًا. اجمعهما في سجلٍّ واحد. والخطأ الثاني أن تضيف خدمة نشراتٍ بريديّةٍ أو نظام فواتير يرسل باسمك، وتنسى أن تضيفه إلى السجلّ، فتذهب رسائله إلى المزعج أشهرًا دون أن تعرف لماذا.

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

والخطأ الخامس كلمة مرورٍ ضعيفةٌ للبريد، أو مكرّرةٌ من موقعٍ آخر. البريد مفتاح حساباتك الأخرى، فاجعل كلمة مروره قويّةً لا تستعملها في مكانٍ آخر، وفعّل عليه التحقّق بخطوتين قبل أيّ حسابٍ سواه. والخطأ السادس نسيان البريد في النسخ الاحتياطيّ، فالرسائل والمرفقات والعقود ذاكرة عملك، وتستحقّ أن تعرف أين تُحفظ نسختها.

جرّبه بنفسك

افتح الطرفيّة واسأل عن سجلّ تبادل البريد لنطاقك، ثمّ عن سجلّاته النصّيّة. ضع نطاقك مكان النطاق التجريبيّ:

nslookup -type=mx example.com
nslookup -type=txt example.com

الأمر الأوّل يخبرك أين يُسلَّم بريدك الآن، على استضافتك أم عند خدمةٍ أخرى. والثاني يعرض السجلّات النصّيّة، وبينها سجلّ SPF إن وُجد. فإن وجدت سجلّين يبدأ كلٌّ منهما بعبارة v=spf1، فقد وجدت الخطأ الأوّل في القائمة السابقة.

ثمّ أرسل رسالةً من عنوانك على نطاقك إلى حسابٍ لك على Gmail، وافتحها هناك، واختر من قائمة الرسالة عرض الرسالة الأصليّة. ستجد في أعلى الصفحة نتيجة كلّ سجلٍّ من السجلّات الثلاثة: نجح أو فشل. هذه الصفحة تريك بريدك كما يراه المستقبِل، وهي أسرع طريقٍ لتعرف أيّ السجلّات ينقص نطاقك.

فإن رأيت الفشل بجانب SPF، فارجع إلى السجلّ وتأكّد أنّ الخادم الذي أرسل الرسالة مذكورٌ فيه. وإن فشل DKIM، فالغالب أنّ السجلّ الذي أعطتك إيّاه الخدمة لم يُلصق كاملًا، لأنّ المفتاح طويل، وبعض لوحات النطاق تقطعه أو تضيف إليه مسافات. وإن نجح الاثنان وفشل DMARC، فانظر إلى المحاذاة: هل النطاق في خانة المرسِل هو نفسه النطاق الذي وقّع الرسالة؟

خلاصة عمليّة

اجعل عنوانك على نطاقك حين يبدأ مشروعك بالمراسلة، وافصل البريد عن الاستضافة حين يصير أداة عمل. تذكّر أنّ الموقع يعيش في سجلّ العنوان والبريد في سجلّ تبادل البريد، فتنقل أحدهما دون الآخر. ثمّ اضبط السجلّات الثلاثة على نطاقك، بسجلّ SPF واحدٍ لا اثنين، وابدأ سجلّ DMARC بلا إجراء. وأخيرًا اربط نموذج التواصل بصندوقٍ حقيقيٍّ عبر إضافة إرسال، وافحص النتيجة بصفحة الرسالة الأصليّة في Gmail.

أدرت استضافتك حتى الآن من واجهاتٍ رسوميّة: لوحة التحكّم، ولوحة ووردبريس، وإعدادات النطاق. وفي هذا المقال كتبت أوّل أوامرك في الطرفيّة لتسأل عن سجلّات نطاقك. الخطوة التالية أن تستعمل الطرفيّة للدخول إلى الخادم نفسه وإدارته بالأوامر، عبر اتّصالٍ مشفّرٍ اسمه SSH. ما هو، ومتى تحتاجه، وكيف تدخل به أوّل مرّةٍ دون أن تكسر شيئًا؟ هذا موضوع المقال التالي: ما هو SSH.

المصادر

1. ‏Google، «Email sender guidelines» (قُرئت في 25 سبتمبر 2026): منذ 1 فبراير 2024 يلزم كلَّ مرسِلٍ SPF أو DKIM وسجلٌّ عكسيٌّ صحيح واتّصال TLS ونسبة مزعجٍ تحت 0.3%؛ ومن يرسل أكثر من 5000 رسالةٍ يوميًّا يلزمه SPF وDKIM وDMARC مع المحاذاة وإلغاء الاشتراك بنقرة؛ التوصية بضبط الثلاثة دائمًا؛ الخطأ 550 5.7.1 قد يظهر مع عنوانٍ مشتركٍ سيّئ السمعة.
2. ‏IETF، «RFC 5321: Simple Mail Transfer Protocol» (2008)، القسم 5.1: ترتيب سجلّات MX بالأفضليّة، والأصغر رقمًا هو المفضّل.
3. ‏Hostinger، «Parameters and limits of Hostinger Mail» (قُرئت في 25 سبتمبر 2026): الحدود لكلّ صندوق؛ البريد التجريبيّ لسنةٍ مع بعض خطط الاستضافة 1 غيغابايت و100 رسالةٍ يوميًّا؛ Business Starter بخمسة غيغابايت و1000 رسالةٍ يوميًّا.
4. ‏Zoho، «Zoho Mail Pricing» (قُرئت في 25 سبتمبر 2026): الخطّة المجّانيّة حتى 5 مستخدمين، 5 غيغابايت لكلٍّ منهم، لنطاقٍ واحد، دون IMAP وPOP وActiveSync.
5. ‏Cloudflare، «Email Routing» (قُرئت في 25 سبتمبر 2026): معالجة الرسائل الواردة وتوجيهها إلى عناوين محدّدة، متاحةٌ في الخطط المجّانيّة والمدفوعة.
6. ‏Hostinger، «PHP Mail limitation explained: How to improve email delivery with SMTP» (قُرئت في 25 سبتمبر 2026): رسائل mail() تفتقد ترويسات التحقّق غالبًا؛ الحدّ 10 رسائل في الدقيقة و100 في اليوم؛ التوصية بالإرسال عبر SMTP بمكتبةٍ أو إضافةٍ مثل WP Mail SMTP.
7. ‏IETF، «RFC 7208: Sender Policy Framework (SPF)» (2014)، القسم 3.2: لا يحمل النطاق أكثر من سجلّ SPF واحد؛ والقسم 4.6.4: حدّ عشرة مصطلحاتٍ تحتاج استعلام DNS.
8. ‏IETF، «RFC 6376: DomainKeys Identified Mail (DKIM) Signatures» (2011)، الملخّص: توقيعٌ مشفّر يُتحقّق منه بمفتاحٍ عامٍّ يُسأل عنه نطاق الموقِّع.
9. ‏IETF، «RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)» (2015)، القسم 6.3: السياسات none وquarantine وreject.
10. ‏Microsoft Tech Community، «Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders» (نُشر في 2 أبريل 2025، وحُدّث في 29 أبريل 2025): يشمل outlook.com وhotmail.com وlive.com؛ للنطاقات التي ترسل أكثر من 5000 رسالةٍ يوميًّا؛ الرفض منذ 5 مايو 2025 بالرمز 550 5.7.515.