شرح SPF وDKIM وDMARC: لماذا يذهب بريد شركتك إلى السبام

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

الخلاصة السريعة

SPF يعدّد الخوادم المسموح لها بالإرسال باسم نطاقك. DKIM يضيف توقيعاً تشفيرياً يُثبت أن الرسالة منك فعلاً وأنها لم تُعدَّل في الطريق. DMARC يخبر الخوادم المستقبِلة بما تفعله حين يفشل أحد الأولين، ويرسل إليك تقارير تُظهر من يرسل باسم نطاقك. وتحتاج الثلاثة معاً: الأولان فحصان، وDMARC هو السياسة والرؤية. اضبطها بهذا الترتيب، وابدأ DMARC بـp=none، واقرأ التقارير من أسبوعين إلى أربعة، ثم شدّد إلى quarantine فـreject.

ما الذي يُثبته كل سجلّ فعلاً

‏SPF — أي الخوادم يجوز لها الإرسال باسمك

‏SPF (إطار سياسة المرسِل) سجلّ TXT واحد في DNS يعدّد خوادم البريد المسموح لها بالإرسال باسم نطاقك. فحين يصل الخادم المستقبِل رسالةٌ تدّعي أنها من you@yourcompany.ae، يقرأ سجلّك ويتحقق مما إذا كان الخادم المتصل مدرجاً فيه.

والسجلّ المعتاد يبدو هكذا:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

اقرأه من اليسار: هذه النسخة الأولى من SPF، ولخوادم Google أن ترسل، ولخوادم Microsoft أن ترسل، وما عداها يُعامَل بريبة (~all، أي «فشل ليّن»). والمُعامل الأخير أهمّ ممّا يُظنّ — انظر قسم الأخطاء.

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

‏DKIM — الرسالة منك ولم تُعدَّل

‏DKIM (البريد المُعرَّف بمفاتيح النطاق) يوقّع الرسائل الصادرة بمفتاح خاص لدى مزوّد بريدك، ويوضع المفتاح العام المقابل له في DNS. فيجلب الخادم المستقبِل المفتاح العام، ويتحقق من التوقيع، فيعرف أمرين معاً: أن الرسالة صادرة من نظام مخوَّل بالتوقيع باسم نطاقك، وأن الأجزاء الموقَّعة لم تُعدَّل في الطريق.

و‏DKIM أقوى من SPF لأنه ينجو من إعادة التوجيه. فحين يعيد المستقبِل توجيه رسالتك آلياً يتغيّر الخادم المتصل فينكسر SPF — أمّا توقيع DKIM فيسافر مع الرسالة ويبقى صالحاً. وإن سبق أن رُفض بريدك عند إعادة توجيهه فقط، فهذا سببه.

ومدخلك في DNS سجلّ TXT على مُحدِّد، مثل google._domainkey.yourcompany.ae. واسم المُحدِّد يأتي من مزوّدك، لا تخترعه أنت.

‏DMARC — السياسة والتقارير

‏SPF وDKIM يجيبان «هل نجح؟» ولا يقول أيّهما ما ينبغي فعله حين تكون الإجابة لا. وDMARC يقول ذلك، ويضيف ما يتخطّاه الجميع تقريباً: التقارير.

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.ae; adkim=r; aspf=r

‏p هي السياسة: none (مراقبة فقط)، أو quarantine (إلى البريد غير الهام)، أو reject (رفض التسليم). وrua وجهة التقارير المجمّعة — ملخّصات XML يومية من كل مزوّد كبير تُظهر بالضبط من أرسل مدّعياً نطاقك وهل نجح.

ويُدخل DMARC كذلك مفهوم المحاذاة، وهو ما يتعثّر فيه الأكثرون. فلا يكفي أن ينجح SPF أو DKIM؛ بل يجب أن يطابق النطاقُ الناجح النطاقَ في عنوان «من» الظاهر. فقد تنجح رسالة في SPF لنطاق مزوّد النشرات لديك وتفشل في DMARC، لأن العنوان الذي يراه المستقبِل عنوانك أنت لا عنوانه هو.

لماذا لا يكفي واحد منها

كلٌّ منها يسدّ ثغرةً يتركها الآخران.

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

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

الضبط، بالترتيب

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

ثانياً: انشر سجلّ SPF واحداً. واحداً — انظر الأخطاء أدناه. أدرج كل خدمة مرسِلة بآلية include: التي يوثّقها مزوّدها، واختم بـ~all ما دمت تختبر.

ثالثاً: فعّل DKIM مع كل مزوّد. يولّد كلٌّ منهم مفتاحاً ويعطيك مُحدِّداً وقيمة تنشرها. ولا تُفعّل التوقيع إلا بعد أن يستجيب سجلّ DNS، وإلّا وقّعتَ بمفتاح لا يستطيع أحد التحقق منه.

رابعاً: انشر DMARC بـp=none. هذا لا يغيّر شيئاً في التسليم؛ إنما يطلب من المستقبِلين أن يبدأوا الإبلاغ. ووجّه rua إلى صندوق ستقرؤه فعلاً، أو الأفضل إلى خدمة تقارير DMARC تحوّل الـXML إلى شيء مقروء.

خامساً: اقرأ التقارير من أسبوعين إلى أربعة. تبحث عن مرسِلين شرعيين يفشلون — نظام الفوترة الذي لم يتذكّره أحد، وإضافة النماذج التي ترسل من خادم الموقع. خوّل كلاً منها. ولا تنتقل إلى p=quarantine ثم p=reject إلا حين تنظف التقارير.

والقفز مباشرةً إلى reject بلا فترة المراقبة هذه أسرع طريقة لمنع فواتيرك أنت من الوصول.

الأخطاء التي تكسر كل شيء بصمت

أكثر من سجلّ SPF واحد

للنطاق سجلّ SPF واحد لا غير. ووجود سجلّين ليس «قائمتين تُدمجان» بل خطأ دائم، ويعامل المستقبِلون النتيجة على أنها غير صالحة. ويحدث هذا باستمرار حين يُضاف مزوّد ثانٍ فيُنشر سجلّه بجانب الأول بدل دمجه فيه. ادمج آليات include: في سجلّ واحد.

تجاوز عشر استعلامات DNS

كل include: وa وmx وredirect في سجلّك يكلّف استعلام DNS، والمواصفة تحدّ المجموع بعشرة. وتجاوزُها يُفشل السجلّ — لا المرسِل الحادي عشر وحده بل السجلّ كلّه. والمزوّدون الكبار يُضمّنون داخل مدخلاتهم مدخلات أخرى، فأربع أو خمس خدمات تكفي غالباً لتجاوز الحدّ. وإن كنت قريباً منه فقلّل المزوّدين أو استعمل خدمة «تسطّح» السجلّ لك.

الختام بـ+all

هذا يقول: «لأي خادم على الإنترنت أن يرسل باسم نطاقي». وهو نقيض غرض السجلّ. استعمل ~all أثناء الاختبار و-all حين تطمئنّ. وإن وجدت +all على نطاق تملكه فعامِله على أنه أمر عاجل.

ترك DMARC على p=none إلى الأبد

هذه أكثر الحالات التي نصادفها، وهي مفهومة: p=none آمن، لا شيء ينكسر، والتقارير تتراكم بلا قراءة. لكنه يأمر المستقبِلين بألّا يفعلوا شيئاً — أي أن أي أحد ما زال يستطيع الإرسال باسم نطاقك وستُسلَّم رسالته. المراقبة مرحلة لا محطّة.

نسيان النطاقات الفرعية

‏DMARC يسري على النطاقات الفرعية ما لم تقل غير ذلك بـsp=. فنطاق يفرض p=reject بلا سياسة للفرعية سيرفض أيضاً بريد notifications.yourcompany.ae — وهو غالباً بالضبط ما يرسل منه تطبيقك.

افتراض أن السجلات ما زالت صحيحة

المزوّدون يغيّرون بنيتهم، والخدمات تُستبدل، وأدوات التسويق تُجرَّب وتُنسى. وسجلّ SPF كُتب قبل ثلاث سنوات كثيراً ما يخوّل أنظمة لم تعد تستعملها ويغفل أخرى تستعملها. راجعه كلما تغيّر شيء في إعداد بريدك.

كيف تفحص سجلاتك في خمس دقائق

من أي طرفية:

dig +short TXT yourcompany.ae | grep spf1
dig +short TXT _dmarc.yourcompany.ae
dig +short TXT google._domainkey.yourcompany.ae

واقرأ النتائج بثلاثة أسئلة. هل هناك سجلّ SPF واحد بالضبط، وهل يختم بـ~all أو -all؟ وهل يوجد سجلّ DMARC، وهل سياسته شيء غير none؟ وهل يُرجع مُحدِّد DKIM مفتاحاً؟

والاختبار العملي أبسط: أرسل رسالة من عنوان عملك إلى حساب Gmail تملكه، وافتحها، واستعمل «إظهار الأصل». يعرض Gmail نتائج SPF وDKIM وDMARC بلغة واضحة في الأعلى. ثلاث نجاحات هي المطلوب، وما دونها يسمّي لك المشكلة.

التوثيق ضروري لا كافٍ

وهنا ما تُغفله أغلب الأدلّة، وهو يكلّف الشركات تسليماً حقيقياً.

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

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

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

ماذا يعني هذا لشركة في الإمارات

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

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

الأسئلة الشائعة

هل تمنع هذه السجلات انتحال نطاقي؟

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

كم تستغرق السجلات حتى تعمل؟

تغييرات DNS تنتشر خلال دقائق إلى ساعات حسب الـTTL. وتقارير DMARC تبدأ بالوصول خلال نحو 24 ساعة. أمّا فترة المراقبة قبل التشديد فهي الجزء الطويل، وتُقاس بالأسابيع — لا بسبب DNS بل لأنك تحتاج أن ترى دورة إرسال كاملة لمؤسستك.

أستعمل Microsoft 365 أو Google Workspace — أليس هذا مُدبَّراً لي؟

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

هل أضع p=reject مباشرةً؟

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

ما نسبة النجاح الواقعية في DMARC؟

بعد تخويل المرسِلين الشرعيين، ينبغي أن ينجح ما يزيد على 95٪ من بريدك. والباقي عادةً إعادة توجيه تكسر SPF لكن ينبغي أن تنجح على DKIM. وإن كانت نسبة كبيرة تفشل في الاثنين معاً، فلديك مرسِل لم تحسب حسابه.

تريد ضبط هذا كما ينبغي؟

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

تحدّث إلى فريقنا في دبي ونفحص ما ينشره نطاقك اليوم.