هل تستحق استضافة بريدك بنفسك في 2026؟

الإجابة المختصرة

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

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

الجزء الأصعب في الاستضافة الذاتية للبريد الإلكتروني هو قابلية التسليم

يستغرق تثبيت خادم بريد عطلة نهاية أسبوع من العمل. توفّر الحزمة الحديثة SMTP (بروتوكول نقل البريد البسيط) لنقل البريد، وIMAP (بروتوكول الوصول إلى رسائل الإنترنت) لقراءته، وتصفية الرسائل المزعجة، وواجهة webmail من ملف compose واحد، كما يغطي تثبيت خادم Mailcow للبريد على VPS هذه الجوانب. لا تكمن الصعوبة في عملية التثبيت.

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

سترى رسالة الرفض. يرسل Gmail رفضاً نهائياً بهذا الشكل:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

ويرسل Microsoft رسالة مختلفة تنتهي برمز قائمة حظر يتغير حسب الحالة:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

اقرأ الرقم الأول قبل أي شيء آخر. يكون الرمز الذي يبدأ بالرقم 4 مؤقتاً، لذلك يحتفظ خادمك بالرسالة ويعيد محاولة تسليمها. ويكون الرمز الذي يبدأ بالرقم 5 نهائياً، لذلك تعود الرسالة إلى المرسل مباشرة. يشير التأجيل برمز 4xx الذي لا ينتهي إلى حد لمعدل الإرسال أو إلى مشكلة في السمعة، وقد تُحل المشكلة تلقائياً. أما رمز 5xx فهو قرار نهائي، ولن يتغير.

لماذا تصل رسائل البريد من خادم جديد إلى مجلد البريد العشوائي؟

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

تحقق من العنوان قبل أن تبني أي شيء عليه. تستجيب القوائم العامة لحظر البريد عبر DNS، باستخدام الأجزاء الأربعة للعنوان بترتيب معكوس:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

تعني الاستجابة الفارغة أن العنوان غير مدرج. أما وجود استجابة داخل 127.0.0.0/8 فيعني أنه مدرج، ويحدد الجزء الأخير رقم القائمة التي طابقت العنوان. توجد حالة خاصة في هذا الاختبار: يرفض Spamhaus الاستعلامات التي تصل عبر محللات DNS العامة الكبيرة، لذلك يعيد البحث نفسه عبر 8.8.8.8 الرمز 127.255.255.254 مهما تكن الحالة الفعلية. يعني هذا الرمز أن الاستعلام رُفض، وليس أن العنوان مدرج. نفّذ البحث عبر محلل DNS الخاص بخادمك، أو استخدم البحث عبر الويب بدلاً من ذلك.

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

ويُحتسب جيرانك أيضاً، لأن بعض الجهات المستقبلة تقيّم السمعة على مستوى كتلة شبكة كاملة، وليس على مستوى عنوان واحد فقط. عندما يبدأ عميل آخر ضمن نطاق /24 نفسه بإرسال رسائل عشوائية، قد تتباطأ رسائلك بسبب الارتباط به. ويوضح التقييم على مستوى الكتلة أيضاً سبب وصول شكاوى إساءة الاستخدام إلى صندوق وارد VPS بشأن حركة مرور لم يرسلها صاحب الحساب مطلقاً: فالشكوى تتبع نطاق العناوين.

ما يجب تأكيده قبل البدء: المنفذ 25 وسجل PTR

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

اختبر المسار من الخادم نفسه:

nc -vz gmail-smtp-in.l.google.com 25

يعرض المسار المفتوح succeeded! خلال ثانية واحدة. أما المسار المحظور فيظل معلقاً ثم تنتهي مهلته دون رسالة تحدد سبب الحظر، لأن الحزمة التي أُسقطت بصمت تبدو تماماً كأنها مشكلة عادية في الشبكة.

المتطلب الثاني هو سجل PTR، ويُسمى أيضاً DNS العكسي. يأخذ الطرف المستقبل عنوان IP الذي اتصل به، ويبحث عن سجل PTR الخاص به للحصول على اسم، ثم يبحث عن ذلك الاسم للحصول على عنوان مرة أخرى. عندما يتطابق العنوانان، يُسمى ذلك DNS العكسي المؤكد أمامياً، وهو فحص بسيط يثبت أن المضيف المتصل تابع للجهة التي يدّعي أنه تابع لها.

dig -x 203.0.113.5 +short
dig +short mail.example.com

يجب أن يعيد الاستعلام الأول اسم مضيف البريد لديك. ويجب أن يعيد الثاني العنوان نفسه الذي بدأت به. لا يستطيع نشر سجل PTR إلا مالك عنوان IP، لذلك يضبطه لك مزوّد الاستضافة أو يتيحه من خلال لوحة تحكم. وغياب سجل PTR، أو استخدام سجل عام مثل 203-0-113-5.static.example-isp.net، إشارة سلبية قوية، لأن خوادم البريد الحقيقية تملك تقريباً دائماً اسماً مطابقاً، بينما غالباً لا تملكه مصادر الرسائل المزعجة واسعة النطاق.

إذا خصص لك المزوّد IPv6 أيضاً وكان خادمك يفضله، فتنطبق كل المتطلبات السابقة على عنوان IPv6 كذلك، ويكون Gmail أكثر تشدداً في هذه الحالة. يؤدي الإرسال عبر IPv6 من عنوان لا يملك سجل PTR إلى رفض يفيد بأن الرسالة لا تستوفي إرشادات الإرسال عبر IPv6 المتعلقة بسجلات PTR والمصادقة. إذا لم تستطع ضبط سجل PTR لـIPv6، فأرسل عبر IPv4 فقط. في Postfix، استخدم smtp_address_preference = ipv4 لتفضيل IPv4، أو inet_protocols = ipv4 لتعطيل IPv6 بالكامل.

الأسئلة الثلاثة التي يجب طرحها على أي مزوّد استضافة

1. هل منفذ TCP الصادر 25 مفتوح في الحساب الجديد؟ وإذا لم يكن مفتوحاً، فما الإجراء والمدة الزمنية المحددان لفتحه؟
2. هل يمكنني ضبط سجل PTR لعنوان IPv4 الخاص بي ولعنوان IPv6 الخاص بي؟ وأين أضبطه؟
3. إذا اتضح أن عنواني مدرج في قائمة حظر بسبب عميل سابق، فهل ستنقلني إلى عنوان مختلف؟

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

ما الذي يثبته SPF وDKIM وDMARC فعلياً

تثبت سجلات DNS الثلاثة أن الرسالة التي تدّعي أنها صادرة من نطاقك أُرسلت فعلاً وفق آليات المصادقة المعنية. يجيب كل سجل عن سؤال مختلف، ولا يعمل السجل الثالث إلا بعد فهم السجلين الأولين.

SPF (إطار سياسة المرسل) هو سجل TXT يحدد الخوادم المسموح لها بإرسال البريد نيابةً عن نطاقك. يتحقق الخادم المستقبِل منه مقابل مرسل الغلاف، وهو العنوان المحدد في أمر SMTP ‏MAIL FROM، وليس ترويسة From: التي يراها القارئ.

يضيف DKIM (البريد المعرّف بمفاتيح النطاق) توقيعاً تشفيرياً إلى ترويسات الرسالة، ويغطي نص الرسالة وقائمة تختارها من الترويسات. يوجد المفتاح العام المطابق في DNS ضمن selector تختاره. ويمكن لأي جهة بعد ذلك التحقق من أن الرسالة صدرت من مالك مفتاحك الخاص ولم تُعدّل أثناء النقل.

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

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

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

يوضح التوافق أيضاً سبب مشكلات إعادة التوجيه. عندما تعيد قائمة بريدية أو عنوان جامعي قديم توجيه رسالتك، يصبح خادم إعادة التوجيه هو عنوان IP المتصل، ولا يكون هذا العنوان موجوداً في سجل SPF الخاص بك، ولذلك يفشل SPF عند الوجهة النهائية. يستمر DKIM في العمل ما دامت الترويسات التي وقّعها لم تُعدّل. يجب أن ينجح DKIM.

انشر p=none مع عنوان إبلاغ rua= أولاً، واقرأ التقارير المجمّعة لمدة أسبوعين قبل تشديد السياسة. هذه التقارير هي المكان الوحيد الذي سترى فيه رسائل أُرسلت باسمك ولم ترسلها، والطريقة الوحيدة لاكتشاف خادم إعادة التوجيه الذي نسيت أمره. الانتقال مباشرة إلى p=reject يتجاوز هذه الخطوة ويعطّل البريد المشروع من دون أن يترك سجلاً بما تعطل.

بعد ذلك، اختبر السلسلة كاملة من طرف إلى طرف. أرسل رسالة واحدة إلى حساب تملكه لدى مزود كبير، وافتح مصدرها الخام:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

يطبع swaks محادثة SMTP أثناء حدوثها. ينتهي سطر Postfix الخاص بالتسليم بـstatus=sent (250 2.0.0 OK ...) عندما يقبل الخادم المستقبِل الرسالة. أما أي نتيجة أخرى فتسجل نص الرفض حرفياً، وهذا هو النص الذي تبحث عنه. يحتوي المصدر الخام للرسالة التي تم تسليمها على ترويسة Authentication-Results: تذكر كل فحص، مع نتيجة pass أو fail، والنطاق الذي تمت مصادقته. يجب أن تظهر pass في الفحوص الثلاثة، ويجب أن يكون النطاق نطاقك.

كيف تعرف بوجود مشكلة في السمعة؟

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

تختلف هذه البرامج، ولا تناسبها جميعاً خادم VPS واحد بعنوان واحد. اعتباراً من August 2026، تدير Microsoft خدمة بيانات وشكاوى لكل عنوان، ويمكن لمالك العنوان التسجيل فيها. وتوفر Yahoo حلقة ملاحظات للشكاوى مرتبطة بنطاق توقيع DKIM. أما Google فتنشر بيانات مجمعة عن السمعة بدلاً من الشكاوى الفردية، ضمن لوحة معلومات تظل فارغة إلى أن ترسل حجماً يومياً معتبراً من الرسائل إلى مستخدميها. اقرأ الشروط الحالية لكل برنامج قبل الاعتماد عليه، لأن هذه البرامج تتغير، ولا يضمن أي منها إتاحة الوصول إليك.

تُعد متطلبات Google المنشورة لمرسلي الرسائل بالجملة، السارية منذ February 2024، أوضح بيان عام لما يتوقعه مستقبِل كبير حالياً. يجب على المرسل الذي يرسل أكثر من 5,000 رسالة يومياً إلى حسابات Gmail الشخصية استخدام SPF وDKIM للمصادقة، ونشر سياسة DMARC، وتوفير إلغاء اشتراك بنقرة واحدة في الرسائل الجماعية، والحفاظ على معدل شكاوى البريد المزعج دون 0.3 بالمائة. تبقى الرسائل الشخصية من خادم صغير أدنى بكثير من هذا الحد، لكن تُقرأ المؤشرات نفسها عند كل حجم إرسال، ومعدل الشكاوى هو المؤشر الذي لا يمكنك رؤيته من دون حلقة ملاحظات.

التقسيم العملي: استضافة البريد الوارد ذاتياً، وترحيل البريد الصادر

استقبال البريد هو الجزء الذي لا يترتب عليه أي ضرر تقريباً. لا يحتاج أحد إلى الوثوق بك لقبول البريد الموجّه إليك. يشير سجل MX، وهو سجل DNS الذي يحدد خادم البريد لنطاقك، إلى خادمك. يتصل بك المرسلون، وتصبح كل القرارات اللاحقة بيدك: ما الذي تحتفظ به، والمدة، وطريقة فهرسته، ومن يُسمح له بالبحث فيه. التخزين رخيص، ولا يمكن لقرار آلي صادر عن سياسة في مكان آخر إغلاق أرشيف تملكه. العمل فعلي ومحدود النطاق: حدّث عامل تصفية البريد المزعج، وجدّد شهادات TLS (أمان طبقة النقل)، واحتفظ بالنسخ الاحتياطية، وتأكد من عدم امتلاء القرص.

أما البريد الصادر، فهنا تتجنب المشكلة الصعبة باستخدام relay. اضبط خادمك لتسليم كل رسالة صادرة إلى relay موثّق على المنفذ 587، بدلاً من التحدث إلى العالم عبر المنفذ 25. في Postfix، عدّل main.cf:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

اكتب بيانات الاعتماد في /etc/postfix/sasl_passwd باستخدام محرر، حتى لا تظهر كلمة المرور في سجل أوامر shell. يجب أن تكون في سطر واحد، ويجب كتابة المضيف الموجود على اليسار تماماً كما يظهر في relayhost:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

تسجّل رسالة تُرسل بعد إعادة التحميل هذه الأحداث في relay=smtp.relay.example[...]:587 وstatus=sent. ويعني سطر السجل الذي يقرأ SASL authentication failed أن بيانات الاعتماد لم تُقبل. والسبب المعتاد هو كتابة اسم مضيف في sasl_passwd بطريقة مختلفة عن الاسم الموجود في relayhost، لأن عملية البحث تطابق السلسلة النصية تماماً.

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

من المفيد إجراء فصل إضافي في اليوم الأول. يجب أن يخرج كل ما هو جماعي من نطاق فرعي مستقل باستخدام مفتاح DKIM مستقل: news.example.com للنشرة البريدية وmail.example.com للبريد الشخصي. ترتبط السمعة بنطاق الإرسال، لذلك لا يمكن لمعدل الشكاوى في نشرة Listmonk مستضافة ذاتياً أن يؤثر سلباً في بريدك الشخصي.

متى يظل الاستضافة الذاتية الكاملة خياراً مناسباً؟

الحجم. تكون تكلفة الترحيل لكل رسالة مناسبة عند إرسال مئات الرسائل شهرياً، لكنها تصبح غير مناسبة عند إرسال ملايين الرسائل. عند هذا الحجم، يمكنك تحمّل عناوين مخصصة وجدول التهيئة التدريجية اللازم لعملها.

الاختصاص القضائي. عندما تنص لائحة أو عقد على أن البريد يجب ألا يُخزَّن على قرص تابع لجهة خارجية، لا تعود جودة التسليم هي العامل الحاسم. عندها لا يكون الترحيل متاحاً لك ببساطة.

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

البريد الذي لا يغادر شبكتك. لا تواجه التنبيهات وغيرها من رسائل البريد بين الآلات مشكلة في قابلية التسليم إطلاقاً، لأن الطرفين تابعان لك. يكون خادم SMTP محلي يسلّم الرسائل إلى صناديق بريدك هو الحل الكامل، وهو النمط نفسه المستخدم في منح مساعد صندوق بريد مستضاف ذاتياً عبر MCP (بروتوكول سياق النموذج).

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

ما تكلفة تشغيل خادم بريد خلال السنة الأولى؟

الأسبوع الأول مخصص للبناء: تثبيت الحزم، وإضافة سجلات DNS، وإعداد شهادات TLS، وإرسال أولى الرسائل الاختبارية، وضبط DMARC على p=none.

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

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

ثم يأتي الأسبوع الذي لا يمكنك جدولته. يُدرج عنوان من عناوينك في قائمة حظر بسبب أمر لم تفعله. يغيّر مستلم كبير إحدى قواعده، فتبدأ رسائلك بالوصول إلى مجلد البريد العشوائي مجدداً. الرسائل الموضوعة في قائمة الانتظار ليست رسائل مفقودة: يعيد Postfix محاولة تسليم الرسالة المؤجلة لمدة خمسة أيام افتراضياً، وفق الإعداد maximal_queue_lifetime = 5d، لذلك فإن انقطاعاً يستمر ساعات يسبب تأخيراً فقط ولا يسبب خسارة أخرى. أما انقطاع يستمر أسبوعاً فيؤدي إلى فقدان الرسائل.

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

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

FAQ

هل يمكنني استضافة البريد الإلكتروني ذاتياً إذا كان مزوّد VPS يحظر المنفذ الصادر 25؟

نعم، للاستقبال وللإرسال عبر relay. يصل البريد الوارد إلى المنفذ 25 على خادمك، ولا يؤثر الحظر الصادر فيه. يخرج البريد الصادر عبر relay موثّق على المنفذ 587، ولا يحظر المزوّدون هذا المنفذ عادةً. ما لا يمكنك فعله عند إغلاق المنفذ 25 هو التسليم مباشرةً إلى خوادم البريد الأخرى، لأن التسليم بين الخوادم يحدث عبر المنفذ 25 بحكم التعريف. اختبر ذلك باستخدام nc -vz gmail-smtp-in.l.google.com 25. يعني تعليق الاتصال ثم انتهاء المهلة أن المنفذ محظور.

لماذا يصل بريدي إلى مجلد الرسائل غير المرغوب فيها رغم نجاح SPF وDKIM وDMARC جميعاً؟

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

هل أحتاج إلى عنوان IP مخصص لخادم بريد مستضاف ذاتياً؟

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

هل من الآمن نقل عنواني الرئيسي إلى خادم مستضاف ذاتياً؟

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

ما أصغر إعداد يحافظ على التحكم في بريدي؟

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