الانترنت والشبكات

كيف يعمل البريد الإلكتروني

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

  • الدرس 9 من 12
  • متوسط
  • مجاني، دون تسجيل

خمس محطات بين زر الإرسال وصندوق المستلم

لا تتصل أجهزتك في أي موضع من هذا المسار بجهاز المستلم مباشرة.

  1. 1

    تكتبها وتضغط إرسال

    بريد على الويب أو تطبيق على الهاتف، لا فرق

  2. 2

    التسليم إلى خادم بريدك

    ببروتوكول SMTP. ومن هنا يخرج الأمر من يدك.

  3. 3

    سؤال DNS: أين خادم بريد المستلم

    سجل MX. والنطاق الذي لا يقبل بريدا يعلن ذلك هنا.

  4. 4

    الاتصال بذلك الخادم وتسليم الرسالة

    وإن لم يجب، بقيت الرسالة في الطابور وأُعيدت المحاولة لاحقا

  5. 5

    قرار خادم المستلم

    صندوق الوارد أو مجلد السبام أو الرفض في الحال

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

آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.

حين تضغط زر الإرسال، بأي المحطات تمر الرسالة؟

خمس محطات، وليست واحدة منها اتصالا مباشرا بينك وبين المستلم. أولا يسلّم البرنامج الذي تكتب فيه، سواء كان بريدا على الويب أو تطبيقا على الهاتف، الرسالة إلى خادم البريد عندك. ويجري هذا التسليم ببروتوكول اسمه SMTP، والبروتوكول نفسه يُستعمل لاحقا بين الخوادم؛ أما قراءة البريد فعمل آخر يجري بـ IMAP أو POP، وكثيرون يخلطون بين الاثنين.

والمحطة الثانية أطرفها. فالخادم المرسِل لا يعرف أين تُسلَّم رسائل example.ir، فيسأل نظام DNS ويقرأ سجلا اسمه MX. وذلك السجل يسمّي خادم بريد النطاق. ونطاقنا يحمل هذا: 10 mail.rgb.ir، أي أن رسائل rgb.ir تُسلَّم إلى جهاز بهذا الاسم.

أما النطاق الذي لا يقبل بريدا أصلا فيعلن ذلك صراحة. فـ example.com ينشر سجل MX فارغا، وهو ما سمّاه RFC 7505 بـ null MX، ومعناه لا تحاول. وسجل خادمنا يُظهر هذا بعينه: رسالة إلى عنوان على ذلك النطاق ارتدّت في الحال دون أي محاولة اتصال، وبالسبب Domain example.com does not accept mail (nullMX).

والمحطتان الثالثة والرابعة هما الاتصال بذلك الخادم وتسليم الرسالة. والخامسة قرار خادم المستلم، وبقية هذا الدرس عن ذلك القرار وحده.

كيف يعمل البريد الإلكتروني؟ من زر الإرسال إلى الصندوق

ما الفرق بين «ذهبت إلى السبام» و«لم تصل أصلا»؟

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

وسجل خادمنا يُظهر الحالات الأربع كلها في بضع ساعات. القبول يبدو هكذا: status=sent (250 2.0.0 OK). والطابور هكذا: status=deferred مع الرسالة 452-4.2.2 The recipient's inbox is out of storage space، وقد تكرر ذلك لإحدى رسائلنا يومين وبعض اليوم. والرفض هكذا: status=bounced. وألا تخرج أصلا هي حالة null MX في القسم السابق.

والآن أهم سطر. رفض جيميل إحدى رسائل هذا الخادم بهذا الجواب: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. ثم كتب النتيجة: DKIM = did not pass وSPF [] with ip: [65.109.218.65] = did not pass.

وفي الدقائق نفسها، ومن الخادم نفسه وعنوان الـ IP نفسه، قُبلت رسائل عادية بـ 250 2.0.0 OK. فلم يكن الخادم هو المشكلة ولا العنوان. تلك الرسالة الواحدة كانت إشعار ارتداد، ومُرسِل مظروفها فارغ، وهو from=<> الذي يظهر في السجل؛ وحين لا يحمل المظروف اسما فلا شيء لدى SPF ليفحصه، وبغياب توقيع DKIM أيضا تصير الرسالة بلا هوية في نظر جيميل. وهنا بالضبط يبدأ حديث التوثيق.

ماذا يفعل كل من SPF وDKIM وDMARC؟

الثلاثة كلها سجلات نصية في DNS نطاقك، وكلها تجيب سؤالا واحدا من ثلاث زوايا: هل هذه الرسالة من هذا النطاق حقا؟

SPF هو قائمة الخوادم المسموح لها بالإرسال باسم نطاقك. وسجلنا هو: v=spf1 +mx +a ~all، أي أن خادم بريد النطاق وخادم الموقع نفسه مسموحان وما عداهما مشبوه. وذلك ~all في آخره هو الإعداد الوسط لا الرفض القاطع؛ والأشد منه -all ولم نختره عمدا، لأن نسيان خدمة مرسِلة واحدة يكفي لرفض رسائل حقيقية.

DKIM توقيع يضعه الخادم المرسِل على الرسالة نفسها. يبقى المفتاح الخاص على الخادم ويُنشر المفتاح العام في DNS تحت اسم يسمّى السلكتور. ومفتاحنا تحت default._domainkey.rgb.ir ومفتاحه الخاص على هذا الجهاز؛ وقد تحققنا الآن أن المفتاح المنشور هو عينه المفتاح الذي على القرص. ونقول حدا بصراحة: مفتاحنا بطول ١٠٢٤ بت، وهو ما جعله RFC 8301 حدا أدنى بينما يوصي بـ ٢٠٤٨. أي أن ثمة مجالا للتحسين.

DMARC لا يفحص شيئا بنفسه. بل يخبر خادم المستلم بما يفعله حين يخفق الاثنان الآخران، وأين يرسل التقارير. وسجلنا هو v=DMARC1;p=quarantine;rua=mailto:admin@rgb.ir، أي ضع الرسالة المشبوهة في الحجر وأرسل التقرير.

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

السجلات الثلاثة التي تصنع قرار خادم المستلم

العمود الثالث لا يفحص شيئا؛ إنما يقول ما العمل حين يخفق الأولان.

رسالة تُصدَّقالثلاثة كلها سجلات نصية في DNS النطاق نفسه

  • SPF

    أي الخوادم مسموح لها بالإرسال باسم هذا النطاق. يفحص العنوان على المظروف.

  • DKIM

    توقيع على الرسالة نفسها، يُتحقق منه بالمفتاح العام المنشور في DNS.

  • DMARC

    ما العمل حين يخفق الاثنان أعلاه، وأين يُرسل التقرير. وسجلنا على الحجر.

والثلاثة معا ليست ضمانا لصندوق الوارد. فسمعة عنوان المرسِل ونص الرسالة نفسها لهما أثر، ولا يصلحهما سجل DNS.

أيها لديك من الثلاثة؟ طريقة الفحص

ثلاثة استعلامات DNS تجيب عن الأولين، والثالث يحتاج شيئا آخر. فلـ SPF اقرأ السجلات النصية للنطاق نفسه، ولـ DMARC السجل النصي للنطاق الفرعي _dmarc:

dig +short example.ir TXT
dig +short _dmarc.example.ir TXT

أما DKIM فلا يُسأل على غير هدى، لأنك تحتاج معرفة اسم السلكتور ولكل خدمة بريد سلكتورها. خذه من لوحة خدمة بريدك ثم نفّذ dig +short SELECTOR._domainkey.example.ir TXT. وإن كنت تفضّل ألا تعمل بالأوامر، فـأداتنا المجانية لفحص سجلات DNS وسلامة البريد تعرض هذه الثلاثة في مكان واحد، وتقول بصدق إنها لا تفحص DKIM دون معرفة السلكتور.

على أن شيئا من ذلك لا يثبت أن رسالتك تُقبل عمليا. فالدليل الوحيد هو حكم المستلم. أرسل رسالة إلى عنوان تملكه وابحث في تلك الخدمة عن الخيار الذي يعرض ترويسات الرسالة الخام؛ اسمه في جيميل Show original. وجد السطر المسمّى Authentication-Results واقرأ ما كُتب بجانب الثلاثة.

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

لماذا لا تثبت حالة «أُرسلت» شيئا؟

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

وموضع الجواب الحقيقي هو سجل خادم البريد، وفيه لكل رسالة سطر ينتهي بـ status= وينقل جواب خادم المستلم حرفا بحرف. والفجوة بين النظرتين تظهر في أرقام هذا الخادم: في المدة التي يغطيها السجل الحالي، نالت ٤٤ رسالة status=sent ونالت ٢٤ رسالة status=bounced. وبعض تلك الأربع والعشرين كان البرنامج المرسِل قد قال عنها إنها أُرسلت.

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

ماذا يقبع تحت رسالة «أُرسلت»

فوق الخط ما يعرضه لك البرنامج. وتحته المصائر الأربعة الممكنة فعلا.

أُرسلت

أي أن الرسالة سُلّمت إلى خادم البريد المحلي. ولا تقول شيئا عن المستلم.

ما يقوله لك البرنامج المرسِل

  • قُبلت

    أجاب خادم المستلم بـ 250. وفي السجل: status=sent

  • بقيت في الطابور

    جواب مؤقت. تُعاد المحاولة؛ وقد بقيت إحدى رسائلنا يومين في الطابور.

  • رُفضت في الحال

    جواب دائم ورسالة ارتداد. وفي السجل: status=bounced

  • لم تُرسل أصلا

    أعلن نطاق المستلم أنه لا يقبل بريدا. فلا يجري أي اتصال.

وحتى الحالة الأولى لا تقول في أي مجلد استقرت الرسالة. فالقبول يعني أن خادم المستلم أخذها، لا أن المستلم رآها.

المسار السريع مع الذكاء الاصطناعي

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

  1. خذ الدليل. إما النص الكامل لرسالة الارتداد، وإما سطر <code>Authentication-Results</code> من رسالة أرسلتها إلى عنوان خارج نطاقك. وبدون أحدهما تصير بقية الخطوات تخمينا.
  2. خذ سجلاتك الحالية: المخرجات الخام لـ <code>dig +short DOMAIN TXT</code> و<code>dig +short _dmarc.DOMAIN TXT</code>. وإن كنت تعرف سلكتور DKIM فخذه أيضا.
  3. سلّم الاثنين معا إلى نموذج من الصف الأول، الفئة التي تُستعمل للحكم لا للعمل الكمّي، واطلب منه التشخيص فقط لا كتابة سجل.
  4. غيّر سجلا واحدا في كل مرة وأرسل رسالة حقيقية أخرى. فـ DNS يخزّن مؤقتا، وإن غيّرت شيئين معا فلن تعرف أبدا أيهما نفع.

وصفة جاهزة للنسخ

دورك خبير تسليم بريد إلكتروني. احكم من البيانات أدناه وحدها ولا تضف أي سجل من الذاكرة.

نطاقي: {النطاق}
الخدمة التي أرسل البريد عبرها: {مثلا خادم الاستضافة، أو اسم خدمة}

المخرجات الخام لـ dig +short {النطاق} TXT:
{المخرجات الخام}

المخرجات الخام لـ dig +short _dmarc.{النطاق} TXT:
{المخرجات الخام}

الدليل من جهة المستلم (نص الارتداد أو سطر Authentication-Results):
{النص الخام}

اكتب أربعة أشياء:
١. أي الفحوص الثلاثة أخفق: SPF أو DKIM أو محاذاة DMARC. بناء على الدليل أعلاه وحده، وقل أي جزء من النص يُظهر ذلك.
٢. السبب المرجّح، في جملة واحدة.
٣. أي سجل بالضبط يجب أن يتغير وما الذي يتغير فيه. لا تكتب نص السجل النهائي؛ قل فقط ما الناقص أو الزائد.
٤. إن لم تكفِ البيانات للتشخيص، فاكتب ما الذي يلزم أيضا.

القواعد: إن لم ترَ سلكتور DKIM في البيانات فلا تقل ليس لديّ DKIM؛ اكتب أنه غير قابل للفحص. وعُدّ استعلامات DNS داخل سجل SPF وإن تجاوزت العشرة فأعلن ذلك. ولا تقترح أي سجل جاهز.

قبل أن تثق بالناتج: شيئان لا يُلصَقان: الرسالة الخام كاملة، وأي سجل كتبه النموذج بنفسه. فالرسالة الخام تحمل عناوين المستلمين وأحيانا روابط استعادة كلمة مرور تُستعمل مرة واحدة؛ خذ سطر <code>Authentication-Results</code> ونص الارتداد فقط. أما السجل المُختلَق فقد يبدو سجل SPF بلا عيب ولا يعمل، لأن RFC 7208 وضع سقفا بعشرة استعلامات DNS لتقييم سجل واحد، وبعدها تكون النتيجة إخفاقا دائما. ولا يترك هذا الخطأ أثرا على نص السجل؛ ولا يظهر إلا بمدقق SPF أو بالعدّ اليدوي.

الذكاء الاصطناعي في هذا العمل

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

أدوات تساعد فعلا

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

اين ينقلب ضدك

للخطر الأصلي في هذا الموضوع شكل بعينه ونادرا ما يُقال: يكتب النموذج سجلا يبدو صحيحا تماما ولا يعمل. فقد يكون نص SPF بلا عيب ويُخفق مع ذلك، لأن RFC 7208 وضع سقفا بعشرة استعلامات DNS لتقييم سجل، وتجاوز ذلك السقف يجعل النتيجة إخفاقا دائما؛ ولا تراه العين. والخطر الثاني هو DMARC: فنموذج يقترح وضع p=reject من البداية، دون أن تراقب التقارير أولا لترى ما الذي يخفق، قد يقطع بريدك الحقيقي غدا. وأنثروبيك نفسها تسمّي هذا الاختراع الواثق هلوسة في وثائقها وتكتب عن تقليله، أي أن الصانع يعدّه ضعفا حقيقيا. وعن البيانات: صفحة مساعدة غوغل لجيميناي تقول صراحة ألا تُدخل معلومات سرية، والرسالة الخام هي ذلك بعينه. ولمعرفة شكل الدفع لهذه الأدوات من إيران، انظر دليل الشراء.

المصادر: RFC 7208: Sender Policy Framework, the DNS lookup limit Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available

حدود هذه النصيحة

هذا الدرس عن بريد يخرج من نطاقك ومن خادمك أو مستضيفك. فإن كان بريدك على خدمة مؤسسية مثل غوغل ورك سبيس أو مايكروسوفت ٣٦٥، فالسجلات الثلاثة نفسها لازمة لكن لوحة تلك الخدمة تبني أكثرها وسلكتور DKIM لها، فيختلف المسار العملي. والأهم أن التوثيق تذكرة دخول لا ضمانا لصندوق الوارد: فبعد هذه الثلاثة تقرر سمعة عنوان المرسِل ونص الرسالة نفسها، ولا يصلحهما سجل DNS. وتُرك أمران عمدا لأنهما غير لازمين للبداية ويستحقان درسا خاصا: BIMI وARC.

من عملنا نحن

كل رقم وسطر سجل في هذا الدرس مأخوذ من خادم بريدنا نحن في ٧ سبتمبر ٢٠٢٦. ثلاثة أمور تعلّمناها بثمن. أولا: في الدقائق نفسها، ومن خادم واحد وعنوان واحد، قُبلت رسائل عادية بـ 250 2.0.0 OK بينما رُفض إشعار ارتداد بـ 550-5.7.26 ... the sender is unauthenticated؛ والفارق الوحيد أن إشعار الارتداد مظروفه فارغ ولا شيء لدى SPF ليفحصه. ثانيا: خدمة بريدنا مضبوطة عمدا على IPv4 وحده (inet_protocols = ipv4)، لأن لهذا الجهاز عنوان IPv6 عاما بلا سجل عكسي وكثير من المستقبِلين لا يأخذون بريدا يأتي من عنوان كهذا. وتحققنا الآن مجددا: عنوان IPv6 لهذا الخادم ما زال بلا أي سجل عكسي. ثالثا: قارنّا مفتاح DKIM المنشور في default._domainkey.rgb.ir بالمفتاح الخاص على القرص فتطابقا بايتا ببايت، وأظهرت المقارنة نفسها أن المفتاح بطول ١٠٢٤ بت، أي على حد RFC 8301 الأدنى لا على قيمته الموصى بها.

اسئلة متابعة حقيقية

رسائل موقعي تذهب إلى السبام؛ ما أول ما أفعله؟

أرسل رسالة إلى عنوان تملكه على خدمة أخرى واقرأ سطر Authentication-Results فيها. فإن أخفق SPF أو DKIM هناك فهذا موضع العمل لا سواه. وإن نجح الاثنان وظلت الرسالة سبام فالمسألة سمعة المرسِل أو نص الرسالة، وعلاجها لا صلة له بـ DNS.

لماذا تصل رسالتي إلى شخص ولا تصل إلى آخر؟

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

هل يمكن أن يكون للنطاق سجلا SPF اثنان؟

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

واصل التعلم