إعداد SPF و DKIM و DMARC 2026: الدليل الشامل لمنع spoofing

أصبح البريد الإلكتروني في عام 2026 أحد أكثر القنوات استهدافًا من قِبَل المهاجمين، فحوالي 90% من هجمات الـ phishing تبدأ من رسالة بريدية مزيّفة تنتحل اسم نطاق مشروع. ولأن البريد التقليدي صُمِّم في الأصل دون آليات تحقق صارمة، ظهرت ثلاثة بروتوكولات تكميلية تُشكّل اليوم خط الدفاع الأول لأي نطاق احترافي: SPF و DKIM و DMARC. في هذا الدليل الشامل، سنشرح بالتفصيل كل ما تحتاج لمعرفته عن إعداد SPF و DKIM و DMARC من الصفر حتى الإتقان، مع أوامر عملية، وأمثلة على سجلات DNS حقيقية، وحلول للأخطاء الشائعة التي يقع فيها مشرفو السيرفرات.

لماذا تحتاج إعداد SPF و DKIM و DMARC في 2026

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

تخيّل سيناريو شائعًا: شركة تستخدم نطاق example.com دون أي حماية بريدية. يأتي مهاجم، يرسل من سيرفره الخاص رسالة يدّعي فيها أنها من [email protected] يطلب فيها من المحاسب تحويل مبلغ مالي عاجل. بدون SPF و DKIM و DMARC، لن يجد سيرفر بريد المحاسب أي طريقة للتأكد من عدم صحة المرسل، وستصل الرسالة إلى صندوق الوارد بكل سهولة. هذا النوع من الهجمات يُعرف بـ “Business Email Compromise” أو BEC، وكلّف الشركات في 2025 وحدها ما يقارب 4.5 مليار دولار حول العالم.

الإعداد الصحيح لهذه البروتوكولات الثلاثة لا يحمي نطاقك فقط، بل يحمي عملاءك وموظفيك أيضًا. كذلك يحسّن سمعة نطاقك (sender reputation) بشكل ملحوظ، مما يرفع من معدل التسليم (deliverability). كل بروتوكول من الثلاثة يقوم بمهمة مختلفة لكنها متكاملة: SPF يحدد من يحق له الإرسال نيابة عنك، DKIM يضع توقيعًا رقميًا غير قابل للتزوير، و DMARC يربطهما معًا ويفرض السياسة على الرسائل التي تفشل في التحقق.

• زيادة معدل تسليم الرسائل بنسبة 20-40% في المتوسط بعد الإعداد الكامل.
• منع المهاجمين من انتحال نطاقك في حملات الـ phishing.
• الالتزام بسياسات Google و Yahoo و Microsoft الجديدة.
• الحصول على تقارير DMARC تفصيلية تكشف من يحاول انتحال نطاقك.
• تحسين سمعة الـ IP الخاص بك أمام مزودي البريد الكبار.

ما هو SPF (Sender Policy Framework)؟

SPF اختصار لـ Sender Policy Framework، وهو أقدم البروتوكولات الثلاثة، تم اعتماده رسميًا في 2014 من خلال RFC 7208. الفكرة من ورائه بسيطة لكنها قوية: صاحب النطاق يُعلن في سجل DNS عن قائمة الـ IPs والـ hosts المسموح لها بإرسال البريد نيابة عن نطاقه. عندما يستقبل سيرفر بريد رسالة، يقوم بفحص الـ IP الذي أتت منه، ثم يقارنه بقائمة SPF الخاصة بالنطاق المُدّعى في الـ Envelope Sender (المعروف بـ Return-Path). إن لم يكن الـ IP ضمن القائمة، يفشل التحقق ويتعامل السيرفر مع الرسالة وفق السياسة المحددة.

يُكتب سجل SPF كنوع TXT في DNS، ويبدأ دومًا بـ v=spf1. ثم تأتي بعده مجموعة من “الميكانيزمات” (mechanisms) التي تحدد المسموح لهم بالإرسال، مثل ip4 وip6 وa وmx وinclude. وفي النهاية يأتي “المُعدِّل النهائي” (qualifier) الذي يحدد كيفية التعامل مع الرسائل التي لا تتطابق مع أي ميكانيزم سابق.

; مثال على سجل SPF بسيط
example.com.    IN    TXT    "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all"

في المثال أعلاه، يُسمح للـ IP 192.0.2.10 بالإرسال نيابة عن النطاق، كما يُسمح لكل سيرفرات Google التي يحدّدها سجل _spf.google.com. أما -all فهي السياسة الصارمة التي تخبر سيرفر الاستقبال أن يرفض أي رسالة لا تأتي من هذه المصادر.

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

عملية التحقق من SPF تتم في خطوات منظمة. أولًا، يستقبل سيرفر البريد الرسالة ويقرأ الـ Envelope Sender وهو غالبًا ما يكون موجودًا في حقل MAIL FROM أثناء جلسة SMTP. ثانيًا، يستخرج اسم النطاق من هذا العنوان، ثم يستعلم عن سجل TXT الخاص بـ SPF لذلك النطاق. ثالثًا، يأخذ الـ IP الذي يتواصل معه (الـ Connecting IP) ويبحث عنه ضمن الميكانيزمات المُعرَّفة في السجل. أخيرًا، تُرجع نتيجة على شكل: pass, fail, softfail, neutral, none, temperror, أو permerror.

هذه النتائج تستخدمها سيرفرات الاستقبال بطرق مختلفة. بعضها قد يقبل الرسالة في حالة softfail لكن يضع علامة عليها، وبعضها يرفضها مباشرة في حالة fail. هنا تكمن أهمية الجمع بين SPF و DKIM و DMARC، لأن SPF وحده لا يكفي إذا أعادت الرسالة توجيهها (forwarding)، إذ تتغير الـ IP المرسلة ويُكسر التحقق من SPF تلقائيًا.

من الجوانب التقنية المهمة في SPF، أن البروتوكول يفرض حدًا أقصى يبلغ 10 استعلامات DNS لتقييم سجل واحد. كثير من النطاقات الكبيرة التي تستخدم خدمات مثل Google Workspace و Mailchimp و Zoho في وقت واحد تتجاوز هذا الحد دون أن تشعر، فينتج عن ذلك خطأ permerror، وتفشل كل عمليات التحقق. لذلك من الضروري اختبار السجل دوريًا والتأكد من أن عدد الـ DNS lookups أقل من 10.

ميكانيزمات SPF الشائعة

• ip4: يحدد عنوان IPv4 معينًا أو نطاق IPs.
• ip6: مثل ip4 ولكن لـ IPv6.
• a يستخدم سجل A للنطاق نفسه.
• mx يستخدم كل سيرفرات الـ MX المعرفة في النطاق.
• include: يشمل سياسة SPF لنطاق آخر.
• all يطبق على جميع الـ IPs الأخرى، ويأتي عادة في النهاية مع qualifier.

إعداد SPF Record خطوة بخطوة

الآن لنبدأ في الجزء العملي من إعداد SPF و DKIM و DMARC. سنبدأ بـ SPF لأنه الأساس. الخطوة الأولى أن تجمع قائمة بكل الجهات والخدمات التي ترسل بريدًا نيابة عن نطاقك. مثلًا، لو كنت تستخدم سيرفر استضافة مرام لإرسال البريد، بالإضافة إلى Google Workspace للإيميلات الشخصية، و Mailchimp للنشرات الإخبارية، يجب أن تكون كل هذه الجهات مذكورة في السجل.

الخطوة الثانية: ادخل إلى لوحة إدارة DNS الخاصة بنطاقك (سواء كانت في cPanel أو في مسجّل النطاق مباشرة)، وأنشئ سجل TXT جديدًا. اسم السجل يكون النطاق نفسه (أو @ في معظم اللوحات)، والقيمة تبدأ بـ v=spf1.

; مثال متكامل لـ SPF لنطاق يستخدم عدة خدمات
example.com.    IN    TXT    "v=spf1 ip4:203.0.113.5 ip4:203.0.113.10 include:_spf.google.com include:servers.mcsv.net include:_spf.mailchimp.com -all"

; التحقق باستخدام dig
dig +short TXT example.com

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

dig +short TXT example.com | grep spf1
nslookup -type=TXT example.com

تأكد من أن لديك سجل SPF واحد فقط لكل نطاق. وجود أكثر من سجل TXT يبدأ بـ v=spf1 سيؤدي إلى خطأ permerror، وستفشل كل عمليات التحقق. لو كنت تحتاج إلى دمج عدة خدمات، اجمعها داخل سجل واحد باستخدام include.

ما هو DKIM (DomainKeys Identified Mail)؟

DKIM اختصار لـ DomainKeys Identified Mail، وهو بروتوكول أكثر تطوّرًا من SPF لأنه يستخدم التشفير الرقمي بدلًا من قائمة IPs. الفكرة الأساسية: عند إرسال أي رسالة، يُضاف إليها توقيع رقمي مشفّر باستخدام مفتاح خاص (private key) موجود فقط على سيرفر المرسل. ويمكن لسيرفر الاستقبال التحقق من هذا التوقيع عن طريق المفتاح العام (public key) المنشور في سجل DNS الخاص بالنطاق.

الميزة الأهم في DKIM أنه يضمن عدم تعديل الرسالة في الطريق. لو حاول أي طرف تغيير المحتوى أو حتى إضافة مسافة واحدة، فإن التوقيع لن يتطابق وستفشل عملية التحقق. كما أن DKIM يعمل مع إعادة التوجيه بعكس SPF، لأن التوقيع يبقى ساريًا حتى لو تغيّر الـ IP المرسل.

سجل DKIM في DNS يكون من نوع TXT، ويستخدم selector لتمييز المفاتيح المختلفة. اسم السجل يأخذ الشكل التالي: selector._domainkey.example.com. الـ selector يمكن أن يكون أي اسم تختاره (مثل default أو mail أو 2026)، وهو يُمكِّنك من تدوير المفاتيح دوريًا دون انقطاع الخدمة.

; مثال على سجل DKIM
default._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDJK..."

كيف يعمل DKIM في إعداد SPF و DKIM و DMARC والتشفير الرقمي

عندما يصل سيرفر الاستقبال إلى الرسالة الموقعة بـ DKIM، يقوم بالخطوات التالية: أولًا، يقرأ ترويسة DKIM-Signature الموجودة في الرسالة، ويستخرج منها اسم النطاق الموقّع (d=) والـ selector (s=) واسم خوارزمية التشفير (a=) ومجموع الترويسات الموقّعة (h=). ثانيًا، يستعلم عن سجل DKIM في DNS لاستخراج المفتاح العام. ثالثًا، يفك تشفير التوقيع الرقمي بهذا المفتاح ويقارنه بالـ hash الذي يحسبه محليًا للرسالة.

إن تطابق التوقيع، يُعتبر التحقق ناجحًا (pass)، وهذا يعني أمرين: أن الرسالة جاءت فعلًا من نطاق الموقّع، وأن المحتوى لم يتغير بعد التوقيع. أما إن فشل التطابق، تعود نتيجة fail، وقد تُعتمد سياسة DMARC للتعامل مع الرسالة. الجدير بالذكر أن DKIM لا يفرض في حد ذاته أن تُرفض الرسالة إن فشلت، فالقرار يعود إلى DMARC.

طول مفتاح DKIM المُستخدم اليوم يجب أن يكون 2048 bits على الأقل. كان المعيار سابقًا 1024 bit، لكن في 2026 يُعتبر هذا الحجم ضعيفًا أمام قدرات الحساب الحديثة. إذا كنت لا تزال تستخدم مفتاحًا بطول 1024 bit، يجب أن تجدّده فورًا. في cPanel و Plesk، عملية إعادة توليد المفتاح بسيطة، وسنشرحها بعد قليل.

الترويسات التي يوقّعها DKIM عادة

• From – عنوان المرسل، يُوقَّع دائمًا.
• To – عنوان المستلم.
• Subject – موضوع الرسالة.
• Date – تاريخ الإرسال.
• Message-ID – المعرّف الفريد للرسالة.
• Content-Type – نوع المحتوى.
• Body – جزء أو كامل من نص الرسالة.

إعداد DKIM في cPanel و WHM

إعداد DKIM في cPanel أصبح في الإصدارات الحديثة عملية شبه آلية. ادخل إلى لوحة cPanel الخاصة بنطاقك، ثم ابحث عن قسم “Email Deliverability” أو “Email Auth”. ستجد فيه قائمة بنطاقاتك مع حالة كل من SPF و DKIM. اضغط على “Manage” أمام النطاق الذي تريد ضبطه، ثم اختر “Generate Local DKIM Key” إن لم يكن المفتاح موجودًا.

بعد التوليد، سيُنشئ cPanel تلقائيًا سجل DKIM في DNS إن كانت إدارة DNS من خلاله. أما إن كانت إدارة DNS من خلال مسجّل خارجي مثل Cloudflare، فستحتاج لنسخ المفتاح يدويًا. اضغط على زر “Show TXT Record” أو “View Record” لرؤية القيمة الكاملة، ثم انسخها وأضفها كسجل TXT في DNS الخارجي. اسم السجل سيكون default._domainkey غالبًا.

# في WHM، توليد مفتاح DKIM لنطاق محدد عبر السطر
/usr/local/cpanel/bin/dkim_keys_install example.com

# عرض المفتاح بعد التوليد
cat /var/cpanel/domain_keys/private/example.com

# إعادة توليد المفتاح بطول 2048 bit
/usr/local/cpanel/bin/dkim_keys_install --force --bits=2048 example.com

بعد إضافة السجل، يجب الانتظار 15 دقيقة إلى ساعة لانتشاره. ثم اختبر التحقق من سيرفر بريد خارجي. أرسل رسالة من بريدك إلى عنوان Gmail أو Outlook أو Yahoo، ثم افتح الرسالة المستلمة وانظر في الترويسات. ستجد سطرًا يقول dkim=pass إن كان كل شيء صحيحًا.

إن كنت تستخدم Postfix مع OpenDKIM على سيرفرك الخاص، فالخطوات تختلف قليلًا. سنشرحها لاحقًا، لكن الفكرة هي تثبيت OpenDKIM، إنشاء المفتاح، إضافة الـ public key إلى DNS، وتعديل ملف main.cf ليتكامل مع OpenDKIM milter. لمزيد من التفاصيل حول إدارة سيرفرك، يمكنك مراجعة مقال تأمين سيرفر Linux على مدوّنة مرام.

ما هو DMARC؟

DMARC اختصار لـ Domain-based Message Authentication, Reporting and Conformance، وهو البروتوكول الذي يربط بين SPF و DKIM ويفرض السياسة. لولا DMARC، فإن SPF و DKIM يعطيان نتائج فقط، لكن لا توجد جهة تخبر سيرفر الاستقبال بما يجب فعله بالضبط في حالة الفشل. هنا يأتي دور DMARC، فهو يخبر السيرفر: “إن فشل التحقق من SPF و DKIM لرسالة تدّعي أنها من نطاقي، اتبع هذه السياسة (none, quarantine, reject)”.

أيضًا، يقدّم DMARC خاصية مهمة جدًا: التقارير (Aggregate Reports و Forensic Reports). يستطيع صاحب النطاق طلب تقارير دورية من سيرفرات الاستقبال الكبرى، تحوي إحصائيات عن كل الرسائل التي تدّعي أنها من نطاقه، مع نتائج التحقق ومعدلات التسليم. هذه التقارير تكشف بشكل دقيق إن كان أحد ما يحاول انتحال نطاقك من سيرفرات في دول معينة.

سجل DMARC يكون من نوع TXT أيضًا، يُوضع تحت subdomain خاص اسمه _dmarc. اسم السجل الكامل يكون _dmarc.example.com، وقيمته تبدأ بـ v=DMARC1.

; مثال على سجل DMARC
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; pct=100; adkim=s; aspf=s"

سياسات DMARC في إعداد SPF و DKIM و DMARC: none, quarantine, reject

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

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

الانتقال بين هذه السياسات يجب أن يكون تدريجيًا. ابدأ بـ p=none لمدة شهر تقريبًا، ثم راقب التقارير وتأكد من أن كل خدماتك المشروعة تنجح في SPF و DKIM. إن وجدت أن كل شيء يعمل، انتقل إلى p=quarantine لمدة شهر آخر، ثم انتقل أخيرًا إلى p=reject.

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

إعداد DMARC Record بأمان

عملية إعداد SPF و DKIM و DMARC ينبغي أن تتم بترتيب: SPF أولًا، ثم DKIM، ثم DMARC في النهاية. السبب أن DMARC يعتمد على نجاح أحد البروتوكولين السابقين (أو كليهما)، ولا يمكن إضافته دون أن يكونا جاهزين. عندما تكون السجلات السابقة جاهزة ومُختبَرة، أنشئ سجل DMARC أوليًا بسياسة none فقط للرصد.

; سجل DMARC أولي للرصد فقط
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; fo=1"

; بعد شهر، ترقية إلى quarantine
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25; fo=1"

; بعد شهرين، ترقية كاملة إلى reject
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; fo=1; adkim=s; aspf=s"

لاحظ المُعدِّلات الأخرى المهمة: rua هو عنوان البريد الذي ستُرسل إليه التقارير المجمّعة (Aggregate Reports) يوميًا، عادة على شكل XML داخل ZIP. ruf للتقارير التشخيصية الفورية. adkim=s يفرض المطابقة الصارمة بين النطاق في DKIM والنطاق في From. aspf=s يفعل نفس الشيء لـ SPF. fo=1 يطلب تقريرًا تشخيصيًا في حال فشل أي من البروتوكولات.

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

اختبار إعداد SPF و DKIM و DMARC

بعد الانتهاء من إعداد SPF و DKIM و DMARC، يجب اختبار كل شيء بدقة. أبسط طريقة: أرسل بريدًا اختباريًا إلى عنوان Gmail تابع لك، ثم افتح الرسالة، اضغط على القائمة المنسدلة بجانب اسم المرسل واختر “Show original” أو “إظهار الأصلي”. ستجد بأعلى الترويسات نتائج SPF و DKIM و DMARC. كل المؤشرات الثلاث يجب أن تكون pass.

هناك أدوات أكثر تقدمًا أيضًا. يمكنك إرسال بريد إلى عنوان مثل [email protected] وستحصل على رد آلي يحوي تقريرًا مفصلًا عن نتائج التحقق. كذلك أداة Mail Tester تفحص رسالتك من زوايا متعددة: SPF، DKIM، DMARC، blacklists، محتوى الرسالة، ودرجة السبام.

# فحص SPF عبر سطر الأوامر
dig +short TXT example.com | grep spf1

# فحص DKIM لـ selector اسمه default
dig +short TXT default._domainkey.example.com

# فحص DMARC
dig +short TXT _dmarc.example.com

# اختبار سجل SPF بأداة spfquery
spfquery --scope mfrom --identity [email protected] --ip-address 192.0.2.10

اختبار DKIM يحتاج خطوة إضافية: التأكد من أن الرسالة المرسلة فعلًا تحوي ترويسة DKIM-Signature. أحيانًا يُولَّد المفتاح وينشر السجل، لكن سيرفر البريد لا يوقّع الرسائل لسبب ما. اطلع على ملف اللوج الخاص بـ Postfix أو Exim للتأكد. في cPanel، يمكنك مشاهدة سجلات إرسال البريد من قسم “Track Delivery”.

أخطاء شائعة في إعداد SPF و DKIM و DMARC

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

الخطأ الثاني: تجاوز حد الـ 10 DNS lookups في SPF. كل include أو a أو mx يحسب كاستعلام. حل هذا الخطأ يكون عبر تقنية تُعرف بـ “SPF Flattening”، حيث يتم استبدال الـ includes بـ IPs مباشرة. هناك خدمات تقدم هذا الفلترة تلقائيًا.

الخطأ الثالث: وضع DMARC بـ p=reject منذ اليوم الأول. هذا قد يؤدي إلى فقدان رسائل مشروعة من خدمات لم تُذكر في SPF. ابدأ دائمًا بـ p=none ولا تنتقل للسياسة الصارمة إلا بعد التأكد. الخطأ الرابع: استخدام مفتاح DKIM ضعيف بطول 1024 bit، وهذا أمر يجب تصحيحه فورًا. الخطأ الخامس: نسيان إضافة mailto: في حقل rua و ruf، بدونها يفشل DMARC في إرسال التقارير.

• إنشاء سجلين SPF بدلًا من دمجهما.
• تجاوز 10 DNS lookups في سجل SPF.
• استخدام +all بدلًا من -all أو ~all.
• عدم تجديد مفتاح DKIM لأكثر من سنة.
• الانتقال المباشر إلى p=reject دون رصد.
• نسيان عنوان البريد في rua أو كتابته بصيغة خاطئة.
• عدم تفعيل سياسة subdomain (sp=).

كيف تتعامل مع تقارير إعداد SPF و DKIM و DMARC

تقارير DMARC المجمّعة تأتي على شكل ملفات XML داخل ZIP، وتُرسل عادة من Google و Yahoo و Microsoft و Mail.ru وغيرها يوميًا. قراءة هذه التقارير يدويًا أمر شاق، لذا يُفضّل استخدام أداة لتحليلها. هناك خدمات مجانية ومدفوعة تقوم بهذا، أو يمكنك بناء سكربت بسيط بنفسك يقوم بتحليل XML وعرض البيانات في شكل جدول.

<!-- مقتطف من تقرير DMARC -->
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>1234567890</report_id>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>15</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

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

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

أفضل الممارسات لإعداد SPF و DKIM و DMARC

للحصول على أقصى استفادة من إعداد SPF و DKIM و DMARC، اتبع هذه الممارسات الذهبية. أولًا، اعمل دائمًا جرد كامل لكل خدمات الإرسال قبل البدء. ثانيًا، استخدم selectors مختلفة لكل خدمة في DKIM، فهذا يسهّل تدوير المفاتيح وتعطيل خدمة معينة عند الحاجة. ثالثًا، فعّل الـ alignment الصارم (adkim=s و aspf=s) لمنع الالتفاف عبر النطاقات الفرعية.

رابعًا، جدِّد مفاتيح DKIM على الأقل سنويًا. خامسًا، احتفظ بمفتاحين فعّالين أثناء عملية التدوير لتجنب انقطاع التحقق. سادسًا، راقب التقارير دوريًا، خصوصًا في الأسابيع الأولى بعد ترقية السياسة. سابعًا، طبّق نفس السياسات على النطاقات الفرعية باستخدام sp=.

ثامنًا، إن كنت لا ترسل بريدًا من نطاق معين على الإطلاق، أنشئ له سجلات SPF و DMARC تمنع الإرسال تمامًا. هذا يحمي النطاقات الفرعية الفرعية مثل marketing.example.com من الانتحال. سجل SPF لنطاق غير مُرسل يكون v=spf1 -all فقط. كذلك يمكنك مراجعة الفرق بين WHM و cPanel لفهم لوحات التحكم بشكل أعمق.

• وثّق كل الـ selectors المستخدمة في DKIM لكل خدمة.
• استخدم سياسة subdomain منفصلة عن السياسة الرئيسية عند الحاجة.
• راقب تقارير DMARC أسبوعيًا في البداية ثم شهريًا.
• دوِّر مفاتيح DKIM كل 6 أشهر إلى 12 شهر.
• اشترك في خدمة DMARC analytics لتسهيل تحليل التقارير.
• طبّق نفس البروتوكولات على نطاقات الإرسال الإلكتروني (المعروفة بـ envelope domains).
• تكامل مع شهادة SSL لتأمين كامل لاتصالات الويب والبريد.

اقرأ أيضاً من مرام هوست: لتعزيز حماية موقعك بالكامل، اطلع على دليل حماية ووردبريس من 7 هجمات شائعة، ودليل شهادة SSL الشامل، وشرح ModSecurity للحماية من SQL Injection و XSS. كذلك يمكنك الاطلاع على خدمة الإيميل الاحترافي من مرام هوست التي تأتي مع SPF و DKIM و DMARC جاهزة.

الخلاصة

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