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

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

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

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

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

لمواجهة ذلك، يفحص كبار المزوّدين مثل Gmail وOutlook وYahoo كل رسالة واردة: هل هذا الخادم مسموح له بالإرسال نيابةً عن هذا النطاق؟ هل تغيّرت الرسالة أثناء النقل؟ وماذا يريد مالك النطاق أن يُفعل بالرسائل التي تفشل في هذه الفحوصات؟ والإجابات عن هذه الأسئلة الثلاثة هي SPF وDKIM وDMARC.

المصادقة ليست العامل الوحيد؛ فسمعة عنوان IP المُرسِل، والقوائم السوداء، والمحتوى، ومدى تكرار تصنيف المستلمين لرسائلك كبريد عشوائي، كلها عوامل مؤثرة. لكن من دون إعداد صحيح لـ SPF وDKIM وDMARC، تبقى قابلية التسليم ضعيفة حتى لو كان كل شيء آخر سليمًا.

SPF: من يحق له الإرسال نيابةً عني؟

SPF (Sender Policy Framework) قائمة بالخوادم المسموح لها بإرسال البريد نيابةً عن نطاقك، وتُنشر كسجل TXT في DNS الخاص بنطاقك. ويتحقق الخادم المستقبل مما إذا كان الخادم الذي أرسل الرسالة مدرجًا في القائمة.

يبدو مثال سجل SPF على هذا النحو:

companyname.com TXT "v=spf1 mx include:spf.provider.com ip4:203.0.113.10 ~all"

• v=spf1: يحدد أن هذا سجل SPF.
• mx: يُسمح لخوادم MX الخاصة بالنطاق بالإرسال.
• include: يضمّ قائمة مزوّد آخر، مثل خدمة البريد الإلكتروني أو النشرات الإخبارية لديك.
• ip4: يسمح بعنوان IP محدد، مثل خادم تطبيقات في مكتبك.
• ~all: يعني "تعامل مع أي مصدر غير مدرج على أنه مشبوه". أما -all فتعني "ارفضه".

DKIM: هل تغيّرت هذه الرسالة أثناء النقل؟

يضيف DKIM (DomainKeys Identified Mail) توقيعًا رقميًا إلى كل رسالة ترسلها. ويُنشأ التوقيع بمفتاح خاص محفوظ على خادم البريد لديك، بينما يُنشر المفتاح العام المقابل في DNS. ويتحقق الخادم المستقبل من التوقيع باستخدام المفتاح العام، فيعرف أن الرسالة صادرة فعلًا من خادمك ولم تُعدَّل في الطريق.

مثال على سجل DKIM:

mail2026._domainkey.companyname.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...long-public-key..."

• mail2026: المحدِّد (selector)، ويتيح لك استخدام أكثر من مفتاح للنطاق نفسه.
• k=rsa: نوع المفتاح.
• p=: المفتاح العام نفسه. يُنشئ مزوّد البريد هذه القيمة، وما عليك سوى إضافتها إلى DNS.

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

DMARC: ماذا يحدث عند فشل الفحوصات؟

DMARC (Domain-based Message Authentication, Reporting and Conformance) هو طبقة السياسات التي تربط SPF وDKIM معًا، ويؤدي مهمتين:

• يخبر الخوادم المستقبلة بما يجب فعله مع الرسائل التي تفشل في المصادقة.
• يرسل إليك تقارير توضح من يرسل بريدًا باسم نطاقك.

يتحقق DMARC أيضًا من التوافق (alignment): إذ يجب أن يطابق النطاق الذي تحقق منه SPF أو DKIM النطاقَ الظاهر في عنوان "From" الذي يراه المستلم. وبذلك لا يستطيع أحد اجتياز SPF بنطاق مختلف ثم انتحال عنوانك.

مثال على سجل DMARC:

_dmarc.companyname.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@companyname.com"

سياسات DMARC

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

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

1. أجرِ حصرًا شاملًا. أدرج كل ما يرسل بريدًا باسم نطاقك: البريد الإلكتروني للأعمال، وبرنامج الفوترة الإلكترونية، وCRM، وخدمة النشرات الإخبارية، ونماذج الموقع، والطابعات والماسحات الضوئية.
2. أنشئ سجل SPF واحدًا. اجمع كل هذه المصادر في سجل واحد وابدأ بـ ~all.
3. فعّل DKIM. احصل على مفاتيح DKIM من مزوّد البريد وخدمات الإرسال الأخرى وأضفها إلى DNS.
4. انشر DMARC في وضع المراقبة. ابدأ بـ p=none وحدد عنوانًا لاستقبال التقارير.
5. راجع التقارير لبضعة أسابيع. ستظهر في هذه التقارير مصادر إرسال نسيتها، فأضفها إلى SPF وDKIM.
6. شدّد السياسة تدريجيًا. بعد أن تجتاز كل الرسائل المشروعة الفحوصات، انتقل إلى quarantine ثم إلى reject لاحقًا. ولتخفيف حدة الانتقال، يمكنك استخدام المعامل pct في DMARC لتطبيق السياسة على نسبة من الرسائل فقط في البداية.

أخطاء شائعة

أكثر من سجل SPF

لا يمكن أن يكون للنطاق سوى سجل SPF واحد. وإضافة سجل "v=spf1" ثانٍ لخدمة جديدة بدلًا من تحديث السجل الحالي خطأ شائع جدًا، ويجعل السجلين كليهما غير صالحين.

حد الاستعلامات العشرة في DNS

يمكن لفحص SPF إجراء 10 استعلامات DNS كحد أقصى. وتُحتسب كل آلية include وmx وa ضمن هذا الحد، وكذلك عمليات include المتداخلة. ومع إضافة المزيد من الخدمات يُتجاوز الحد ويُرجع فحص SPF خطأً. أزل الخدمات التي لم تعد تستخدمها، وأدرج عناوين IP الثابتة عبر ip4 حيثما كان ذلك مناسبًا.

بدء DMARC بسياسة reject

الانتقال إلى سياسة reject قبل اكتمال الحصر قد يؤدي إلى رفض رسائل مشروعة مثل الفواتير أو الإشعارات. ابدأ دائمًا بوضع المراقبة.

تفعيل DKIM على المزوّد الرئيسي فقط

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

لا أحد يقرأ عنوان التقارير

تصل تقارير DMARC بصيغة XML وقد تكون كثيرة. لذا تحتاج إلى أداة تجعلها مقروءة، أو إلى شخص مسؤول عن مراجعتها بانتظام.

المصادقة وحدها لا تكفي

حتى مع الإعداد الصحيح لـ SPF وDKIM وDMARC، قد تصل الرسائل أحيانًا إلى البريد العشوائي. انتبه أيضًا إلى النقاط التالية:

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

قواعد المرسلين لدى كبار المزوّدين

منذ مطلع عام 2024، تطبّق Google وYahoo قواعد أكثر صرامة على المرسلين، وأعلنت Microsoft عن متطلبات مماثلة لـ Outlook.com. والإطار العام كما يلي:

• يُتوقع من جميع المرسلين استخدام SPF أو DKIM على الأقل، وامتلاك سجل DNS عكسي صالح، والاتصال عبر TLS.
• يجب على المرسلين بكميات كبيرة (وفق تعريف Google، من يرسلون أكثر من 5,000 رسالة يوميًا إلى عناوين Gmail) امتلاك SPF وDKIM وسجل DMARC بسياسة p=none على الأقل، مع توافق عنوان "From".
• يجب أن توفر الرسائل التسويقية إلغاء الاشتراك بنقرة واحدة، وأن تحافظ على معدلات منخفضة لشكاوى البريد العشوائي.

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

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

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

هل يكفي إعداد واحد فقط من SPF وDKIM وDMARC؟

لا. الثلاثة تعمل معًا؛ إذ يتحقق SPF وDKIM من الهوية، ويضمن DMARC تطابق هذا التحقق مع عنوان "From" ويحدد ما يحدث عند فشله.

أضفت السجلات. متى تسري التغييرات؟

تنتشر سجلات DNS عادةً خلال دقائق إلى بضع ساعات. وقد تستغرق سمعة النطاق وقتًا أطول قليلًا للتعافي؛ ومع الإرسال المنتظم والنظيف، سترى تحسنًا عادةً خلال أيام أو أسابيع.

كيف أتحقق من صحة سجلاتي؟

أرسل رسالة إلى عنوان Gmail خاص بك واستخدم خيار "show original" لرؤية نتائج SPF وDKIM وDMARC. كما ستكشف أدوات فحص DNS المتاحة عبر الإنترنت عن الأخطاء النحوية في سجلاتك.

هل ستحجب سياسة reject في DMARC رسائلي المشروعة؟

لا، إذا كان الحصر مكتملًا وكان كل مصدر إرسال متوافقًا عبر SPF أو DKIM. ولهذا فإن مراجعة التقارير في وضع المراقبة قبل الانتقال إلى reject أمر ضروري.

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

قد يبدو إعداد SPF وDKIM وDMARC مجرد بضعة سجلات DNS، لكن التفاصيل هي التي تحدد قابلية التسليم. مع البريد الإلكتروني للأعمال من CloudRUX، يضبط مهندسونا هذه السجلات ضمن عملية الإعداد، ويرشدونك خلال تطبيق DMARC، وعندما يحدث خلل تجد على الطرف الآخر مهندسًا يتحدث العربية والتركية. تبدأ الخطط من 1.19 USD لكل مستخدم شهريًا (غير شاملة ضريبة القيمة المضافة)، مع إعداد وترحيل مجانيين. اطّلع على صفحة البريد الإلكتروني للأعمال لمزيد من التفاصيل، أو تواصل معنا لنبحث معًا مشكلات تسليم بريدك الإلكتروني.