مصادقة البريد الإلكتروني: SPF وDKIM وDMARC
طبّقوا سياسات Sender Policy Framework وDomainKeys Identified Mail وDMARC وتحقّقوا من صحتها لمنع انتحال النطاق والتصيّد الاحتيالي.
مصادقة البريد الإلكتروني: SPF وDKIM وDMARC درس مجاني في Security+ Academy على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Security+ Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Security+ Academy 4 دروس في المجموع.
مشكلة انتحال البريد الإلكتروني
لا يتضمن بروتوكول SMTP الأساسي (الذي صُمم في سبعينيات القرن العشرين) مصادقة مدمجة للمرسل. ويمكن لأي خادم بريد أن يدّعي إرسال بريد إلكتروني من أي نطاق — وهي تقنية تُسمى انتحال البريد الإلكتروني. ويستغل المهاجمون ذلك لإرسال رسائل تصيد تبدو وكأنها واردة من مؤسسات شرعية (مثل مصرفكم أو مديركم التنفيذي أو مورّد معروف). وقد وُضعت ثلاثة معايير لمصادقة البريد الإلكتروني تستند إلى DNS لمعالجة هذه المشكلة: SPF وDKIM وDMARC. ويعالج كل معيار جانبًا مختلفًا من مشكلة الانتحال، وتكون فاعليتها أكبر عند نشرها معًا.
Sender Policy Framework (SPF)
يمثل SPF سجل TXT في DNS يحدد خوادم البريد المصرح لها بإرسال البريد الإلكتروني نيابةً عن نطاق معين. وعندما يتلقى خادم بريد مستلم رسالة تدّعي أنها واردة من example.com، فإنه يبحث عن سجل SPF الخاص بـ example.com ويتحقق من إدراج عنوان IP لخادم الإرسال. وإذا لم يكن عنوان IP مصرحًا به، فيمكن وضع علامة على الرسالة كرسالة عشوائية أو رفضها. ويتحقق SPF من عنوان Envelope From (الأمر SMTP MAIL FROM)، وليس من ترويسة From المعروضة للمستخدمين.
# SPF DNS TXT record for example.com
# Authorize Google Workspace + SendGrid + company IP
example.com. TXT 'v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all'
# Mechanism meanings:
# include: authorize another domain's SPF record
# ip4: authorize specific IPv4 address/range
# ip6: authorize specific IPv6 address
# -all FAIL (reject) mail from non-listed sources
# ~all SOFTFAIL (accept but mark as spam)
# ?all NEUTRAL (no policy stated)قيود SPF
لدى SPF قيدان مهمان. أولًا، يؤدي إعادة التوجيه إلى كسر SPF؛ فعند إعادة توجيه البريد الإلكتروني، لا يكون عنوان IP لخادم إعادة التوجيه موجودًا في سجل SPF للنطاق الأصلي، مما يؤدي إلى فشل SPF في الرسائل المعاد توجيهها بشكل مشروع. ثانيًا، يصادق SPF على Envelope From فقط (وهو غير ظاهر للمستخدمين)، ولا يصادق على ترويسة From الظاهرة في عملاء البريد الإلكتروني. ولا يزال بإمكان المهاجمين انتحال ترويسة From الظاهرة مع استخدام Envelope From يجتاز فحص SPF، ولذلك لا يكفي SPF وحده. ويعالج DKIM وDMARC هاتين الثغرتين.
DomainKeys Identified Mail (DKIM)
يضيف DKIM توقيعًا تشفيريًا إلى رسائل البريد الإلكتروني الصادرة. ويستخدم خادم البريد المرسل مفتاحًا خاصًا لتوقيع ترويسات بريد إلكتروني محددة ونص الرسالة، ويضيف ترويسة DKIM-Signature. ويُنشر المفتاح العام كسجل TXT في DNS ضمن نطاق فرعي لمحدد. وتسترد الخوادم المستلمة المفتاح العام وتتحقق من التوقيع، مما يؤكد أن البريد الإلكتروني لم يُعدّل أثناء النقل وأنه صدر من خادم يملك إمكانية الوصول إلى المفتاح الخاص. وعلى خلاف SPF، تبقى توقيعات DKIM صالحة عند إعادة التوجيه لأنها تكون مضمنة في ترويسات البريد الإلكتروني.
# DKIM DNS TXT record (selector: 'google')
google._domainkey.example.com. TXT \
'v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...'
# DKIM-Signature header in email:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
s=google; h=from:to:subject:date;
bh=<body_hash>; b=<signature>
# Verification:
# 1. Extract 'b=' (signature)
# 2. Fetch public key at google._domainkey.example.com
# 3. Verify signature over 'h=' headers + body hashمحددات DKIM وتدوير المفاتيح
يستخدم DKIM المحددات للسماح بوجود عدة مفاتيح عامة في الوقت نفسه لنطاق واحد، وهو أمر مفيد عند تشغيل خدمات بريد متعددة (Google Workspace مع منصة تسويق) أو عند تدوير المفاتيح دون انقطاع. ويُضمَّن اسم المحدد في ترويسة DKIM-Signature حتى تعرف الخوادم المستلمة سجل DNS الذي ينبغي الاستعلام عنه. وينبغي للمؤسسات تدوير مفاتيح DKIM سنويًا أو عند الاشتباه في اختراق أحد المفاتيح. طول المفتاح: يوصى باستخدام مفاتيح RSA بطول 2048 بت كحد أدنى؛ أما المفاتيح بطول 1024 بت فقد أصبحت مهجورة ويمكن كسرها باستخدام قدرات الحوسبة الحديثة.
DMARC: مصادقة الرسائل المستندة إلى النطاق
يبني DMARC (مصادقة الرسائل المستندة إلى النطاق وإعداد التقارير والامتثال) على SPF وDKIM، وذلك بإضافة: فحص المحاذاة (يجب أن يتطابق النطاق الموجود في ترويسة From الظاهرة مع النطاق الذي تمت مصادقته عبر SPF أو DKIM)، وسياسة تحدد للخوادم المستلمة الإجراء الذي ينبغي اتخاذه عند فشل الرسائل. وسياسات DMARC هي none (مراقبة فقط)، وquarantine (التسليم إلى مجلد الرسائل العشوائية)، وreject (عدم التسليم). كما يتيح DMARC التقارير المجمعة (RUA) والتقارير الجنائية (RUF) التي تُرسل إلى مالك النطاق لتوفير رؤية حول الجهات التي ترسل نيابةً عنكم.
# DMARC DNS TXT record
_dmarc.example.com. TXT \
'v=DMARC1; p=reject; sp=reject; \
pct=100; \
rua=mailto:dmarc-reports@example.com; \
ruf=mailto:forensic@example.com; \
adkim=s; aspf=s'
# p=reject : reject failing messages (strongest)
# pct=100 : apply to 100% of messages
# adkim=s : strict DKIM alignment
# aspf=s : strict SPF alignment
# rua= : aggregate report destinationمحاذاة DMARC
المحاذاة هي ما يجعل DMARC فعالًا ضد انتحال رؤوس الرسائل. في محاذاة SPF، يجب أن يتطابق النطاق الموجود في حقل From ضمن غلاف SMTP مع النطاق الموجود في رأس From الظاهر. وفي محاذاة DKIM، يجب أن يتطابق نطاق التوقيع (الحقل d= في DKIM-Signature) مع نطاق رأس From. في الوضع الصارم، يجب أن تتطابق النطاقات تمامًا. أما في الوضع المرن، فتُقبل النطاقات الفرعية. تنجح الرسالة في DMARC إذا نجحت في SPF أو DKIM مع تحقيق المحاذاة الصحيحة — ولا يلزم أن تنجح في كليهما. ويغلق هذا الجمع الثغرة التي يتركها SPF وحده، والتي تسمح بانتحال رأس From الظاهر.
# DMARC alignment example
Envelope From: attacker@legit.com <- SPF may PASS for legit.com
From header : spoofed@example.com <- VISIBLE to user
# Without DMARC: SPF passes (envelope from legit.com)
# User sees spoofed@example.com and trusts it
# With DMARC on example.com:
# SPF alignment check: legit.com != example.com -> FAIL
# DKIM: attacker has no private key for example.com -> FAIL
# DMARC result: FAIL -> message rejected per policyنشر DMARC على مراحل
ينبغي للمؤسسات نشر DMARC تدريجيًا لتجنب تعطيل الرسائل المشروعة. المرحلة 1: نشر SPF وDKIM لجميع تدفقات البريد. المرحلة 2: نشر سجل DMARC يتضمن p=none مع تقارير RUA. تحليل التقارير (باستخدام أدوات مثل DMARC Analyzer وdmarcian) لاكتشاف جميع مصادر الإرسال المشروعة خلال فترة تتراوح بين أسبوعين وأربعة أسابيع. المرحلة 3: الانتقال إلى p=quarantine; pct=10، مع زيادة قيمة pct تدريجيًا حتى 100%. المرحلة 4: الانتقال إلى p=reject بعد التأكد من نجاح جميع التدفقات المشروعة. إن الانتقال السريع إلى الرفض قبل اكتشاف جميع تدفقات البريد يؤدي إلى رفض الرسائل المشروعة.
# DMARC rollout stages
Stage 1: p=none; pct=100 (monitoring only)
Stage 2: p=quarantine; pct=10 (10% to spam)
Stage 3: p=quarantine; pct=100 (all to spam)
Stage 4: p=reject; pct=100 (block at MTA)
# Monitor RUA reports between each stage
# Look for legitimate sources failing alignment
# Common gotchas:
# - Marketing platforms sending as your domain
# - IT ticketing systems
# - Automated notification services
# - Third-party CRM toolsBIMI: مؤشرات العلامة التجارية لتعريف الرسائل
يُعد BIMI معيارًا ناشئًا يعتمد على DMARC. عندما تكون سياسة DMARC لنطاق ما هي quarantine أو reject، يمكن لعملاء البريد الإلكتروني (Gmail وApple Mail) عرض الشعار الموثق للعلامة التجارية بجوار اسم المرسل في صندوق الوارد. يتطلب BIMI الحصول على شهادة العلامة الموثقة (VMC) من جهة إصدار معتمدة تؤكد ملكية العلامة التجارية المسجلة. ورغم أن BIMI لا يزال غير مشمول في اختبار Security+، فإنه يمثل الاتجاه الذي تتجه إليه مصادقة البريد الإلكتروني، إذ يجعل من السهل تمييز المرسلين الموثقين بصريًا عن المرسلين المنتحلين.
عمل SPF وDKIM وDMARC معًا
تشكل المعايير الثلاثة نظامًا متكاملًا لمصادقة البريد الإلكتروني. يتحقق SPF من أن خادم الإرسال مُصرح له من مالك النطاق. ويتحقق DKIM من سلامة الرسالة ومن امتلاك المؤسسة المرسلة للمفتاح الخاص. أما DMARC فيربط كليهما برأس From الظاهر، ويفرض سياسة عند حدوث الإخفاقات، ويوفر التقارير. لا يكفي أي معيار بمفرده: فلا يستطيع SPF وحده منع انتحال رأس From الظاهر، ولا يفرض DKIM وحده رفض الرسائل التي تفشل في التحقق، بينما لا يجد DMARC وحده ما يتحقق منه إذا لم يتوفر SPF أو DKIM. لذلك يجب نشر المعايير الثلاثة معًا لتوفير حماية كاملة من انتحال النطاقات.
# Email authentication check order
1. Receiving MTA receives message
2. SPF check: is sending IP authorized? (envelope From)
3. DKIM check: is signature valid? (using public key DNS)
4. DMARC check:
a. Did SPF pass with alignment? OR
b. Did DKIM pass with alignment?
-> If YES: PASS (deliver normally)
-> If NO: apply DMARC policy (none/quarantine/reject)
5. Reporting: send aggregate data to rua= addressلافتات البريد الإلكتروني الخارجي
من الإجراءات العملية للدفاع متعدد الطبقات ضد التصيد الاحتيالي واختراق البريد الإلكتروني للأعمال (BEC) إضافة لافتة تحذير من البريد الإلكتروني الخارجي إلى كل رسالة مصدرها خارج المؤسسة. تُدرج هذه اللافتة — عادةً بواسطة SEG — لتنبه الموظفين إلى أن الرسالة واردة من مرسل خارجي، حتى عندما يبدو اسم العرض اسم زميل أو مسؤول تنفيذي. وتكون اللافتات فعالة خصوصًا في كشف محاولات BEC التي يستخدم فيها المهاجم نطاقًا شبيهًا بالنطاق الأصلي أو ينتحل اسم العرض. وينبغي أن تكون اللافتة مميزة بصريًا (كرأس أو تذييل ملوّن)، وأن تتضمن تعليمات للإبلاغ عن الرسائل المشبوهة.
# Example external email banner (SEG inserts this)
# --- EXTERNAL EMAIL ---
# This message was sent from outside the organization.
# Do not click links or open attachments unless
# you expected this email and trust the sender.
# Report suspicious email: phishing@company.com
# ----------------------
# Proofpoint SEG: add disclaimer via content filter
# Match: Header 'X-MS-Exchange-Organization-SCL' absent
# Action: Prepend HTML banner to message bodyتحقق سريع
اختبروا مدى فهمكم لمفاهيم CompTIA Security+ (SY0-701) الواردة في هذا الدرس.
مراجعة الدرس
تعلمتم في هذا الدرس أن SPF يستخدم سجلات DNS TXT للسماح لعناوين IP المرسلة، لكنه يتحقق فقط من From الموجود في الغلاف، وليس من الرأس الظاهر؛ وأن DKIM يضيف توقيعات تشفيرية تتحقق من سلامة الرسالة وتستمر صلاحيتها بعد إعادة التوجيه؛ وأن DMARC يربط SPF وDKIM برأس From الظاهر من خلال فحوصات المحاذاة وسياسة قابلة للفرض (none/quarantine/reject)، إضافةً إلى التقارير. بعد ذلك سنستكشف بوابات البريد الإلكتروني الآمنة وعناصر التحكم في مكافحة البريد العشوائي.
الأسئلة الشائعة
هل درس «مصادقة البريد الإلكتروني: SPF وDKIM وDMARC» مجاني؟
نعم — نص درس «مصادقة البريد الإلكتروني: SPF وDKIM وDMARC» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Security+ Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Security+ Academy 4 دروس في المجموع.
ماذا ستتعلم في «مصادقة البريد الإلكتروني: SPF وDKIM وDMARC»؟
طبّقوا سياسات Sender Policy Framework وDomainKeys Identified Mail وDMARC وتحقّقوا من صحتها لمنع انتحال النطاق والتصيّد الاحتيالي. تتمرن على Security+ Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Security+ Academy؟
لا تُشترط خبرة سابقة. Security+ Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.
كم من الوقت يستغرق درس «مصادقة البريد الإلكتروني: SPF وDKIM وDMARC»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Security+ Academy هذا؟
نعم. كل درس في Security+ Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- مصادقة البريد الإلكتروني: SPF وDKIM وDMARC
- بوابات البريد الإلكتروني الآمنة وعناصر مكافحة البريد العشوائي
- تصفية محتوى الويب وحفر DNS السوداء
- فحص SSL/TLS وهجمات الوسيط داخل المتصفح