شرح DMARC: لماذا بريدكم عرضة للخطر وكيف تصلحونه في 24 ساعة

شرح DMARC: لماذا بريدكم عرضة للخطر وكيف تصلحونه في 24 ساعة

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

نستهل كل مهمة OSINT دفاعية بفحص DMARC وSPF وDKIM على النطاقات الرئيسية للعميل. وفي 2025 والنصف الأول من 2026، كان لدى الشركة الأوروبية المتوسطة النموذجية التي حلّلناها واحد على الأقل من هذه الضوابط الثلاثة سيئ الإعداد. وأكثرها شيوعاً كان DMARC على p=none منذ يوم نشره، دون أن يراقب أحد التقارير المجمَّعة التي يفترض أن يولّدها.

هذا المقال خطة تشغيلية للانتقال من "لدينا DMARC على الورق" إلى "نحن محميون عند المستوى الذي يتوقعه التوجيه". نفترض أن شركتكم تستخدم Microsoft 365 أو Google Workspace كمنصة رئيسية؛ والخطوات متكافئة في الحالتين، مع تفاصيل خاصة بكل مزوِّد حيث تختلف.

ماذا يفعل DMARC وماذا لا يفعل

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

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

أما بالنسبة لاحتيال المدير التنفيذي أو اختراق البريد التجاري (BEC)، وهو أغلى تهديد عبر البريد للشركات الأوروبية المتوسطة في السنوات الأخيرة، فإن DMARC على p=reject يقطع واحدة من أكثر أربع ذرائع شيوعاً: الرسالة التي تدّعي القدوم من نطاق المدير التنفيذي نفسه، لا من نطاق مشابه.

لماذا معظم الشركات المتوسطة على p=none

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

الحل لهذا الخوف هو التقرير المجمَّع. فالوسم rua في DMARC يطلب من الخوادم المستقبِلة إرسال تقارير يومية تلخّص من حاول الإرسال من نطاقكم وما إذا اجتاز SPF وDKIM. وبأسبوعين من تلك التقارير يمكنكم بناء صورة كاملة عن كل مرسِل شرعي تحتاجون إلى التصريح له، قبل تشديد السياسة.

إصلاح الـ 24 ساعة، ساعة بساعة

نفترض أنكم نشرتم بالفعل سجل DMARC على p=none مع rua يعمل. وإن لم يكن كذلك، فأول إجراء هو القيام بذلك والانتظار أسبوعين. والخطة التالية تنطبق على المرحلة الثانية.

من الساعة 0 إلى 4 · جرد المرسِلين الشرعيين

اجمعوا تقارير آخر 14 يوماً المجمَّعة. صنّفوا عناوين IP المصدر إلى أربع مجموعات:

1. منصة بريدكم الرئيسية (M365 أو Google Workspace).

2. منصاتكم المعاملاتية والتسويقية (AWS SES وMailgun وSendGrid وMailchimp وAcumbamail، أو نسختكم الخاصة من Auctimail إن وُجدت).

3. أدوات الدعم وإدارة علاقات العملاء (CRM) التي ترسل بريداً نيابةً عنكم (Zendesk وHubSpot وIntercom وFront).

4. مصادر غير معروفة.

المجموعة الرابعة هي العمل. فكل IP فيها هو إما مرسِل شرعي غير موثَّق أو محاولة انتحال. تتبّعوا كلاً منها. وأكثر المفاجآت شيوعاً: خادم تطبيق محلي موروث لا يزال يرسل فواتير عبر مُرحِّل (relay) منسي، وأداة موارد بشرية اشتراها فريق العام الماضي دون التنسيق مع تكنولوجيا المعلومات، ومستشار خارجي أعدّ نطاقكم في عميل بريده الخاص لأن لا أحد أخبره ألّا يفعل.

من الساعة 4 إلى 8 · تنظيف SPF

سجل SPF لديكم قائمة بالمرسِلين الذين تصرّحون لهم. حرّروه بحيث:

• يكون كل مرسِل شرعي من الجرد مُدرَجاً عبر آلية include: المناسبة (مثلاً include:_spf.google.com، include:amazonses.com).
• تُحذَف عناوين IP الثابتة إلا إذا كانت تخص مرسِلاً تتحكمون به وتريدون الاحتفاظ به.
• لا يتجاوز السجل 10 استعلامات DNS (سبب صامت شائع للفشل). وإن تجاوزها، سطِّحوه عبر خدمة أو أعيدوا هيكلته حسب النطاقات الفرعية.
• تكون الآلية النهائية -all (فشل صارم)، لا ~all (فشل ليّن).

سجل SPF نظيف لشركة متوسطة على Google Workspace وAWS SES وHubSpot يُقرأ هكذا تقريباً: v=spf1 include:_spf.google.com include:amazonses.com include:_spf.hubspot.com -all. وأي شيء أعقد جوهرياً من ذلك هو عَرَض لتراكم انحراف متراكم.

من الساعة 8 إلى 12 · التحقق من DKIM

لكل مرسِل شرعي يدعم توقيع DKIM نيابةً عنكم، تحققوا من أن المُحدِّد (selector) منشور وأن المفتاح العام محدَّث. يستخدم Microsoft 365 المُحدِّدين selector1 وselector2. ويستخدم Google Workspace مُحدِّداً قابلاً للضبط، عادةً google. ويستخدم AWS SES ثلاثة سجلات CNAME تشير إلى بنيته التحتية لتوقيع DKIM.

الفحص بسيط: أرسلوا رسالة اختبار من كل منصة إلى صندوق بريد يكشف الترويسات الخام (mailtester.com، أو صندوق اختبار dmarcian.com، أو حساب Gmail مع تفعيل "إظهار الأصلي") وتحققوا من spf=pass وdkim=pass للمحاذاة ذات الصلة.

إذا كان أحد المرسِلين الشرعيين لا يدعم DKIM نيابةً عنكم، فأمامكم قرار استراتيجي. فإما أن تقبلوا أن تلك الرسائل ستفشل في محاذاة DMARC (وتطلبوا من المرسِل التحديث أو تستبدلوه)، أو تبقوا السياسة على p=quarantine بدلاً من p=reject حتى تسدّوا الفجوة. وقد توقفنا عن التوصية بالخيار الثاني؛ فالمزوِّدون الذين لا يوقّعون بـ DKIM نيابةً عنكم في 2026 هم مزوِّدون ينبغي أن تبتعدوا عنهم.

من الساعة 12 إلى 16 · الانتقال إلى p=quarantine، pct=100

حدّثوا سجل DMARC إلى p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s. والوسوم الصارمة (adkim=s; aspf=s) ليست لازمة دائماً؛ فالوضع المرن الافتراضي مقبول لمعظم الشركات المتوسطة. المهم هو الالتزام بإجراء حجر حقيقي والمراقبة.

راقبوا التقارير المجمَّعة الـ 24 ساعة التالية. وإذا بدأ مرسِل شرعي غير مُعرَّف يفشل، أضيفوه إلى إعداد SPF أو DKIM قبل الانتقال إلى الخطوة التالية.

من الساعة 16 إلى 24 · الانتقال إلى p=reject

حدّثوا سجل DMARC إلى p=reject; pct=100; rua=...; ruf=...; sp=reject; adkim=s; aspf=s. وأبلغوا إدارتكم بأن البريد الذي ينتحل نطاقكم سيُرفَض من الخوادم المستقبِلة التي تحترم DMARC، وهي تشمل جوهرياً مجموع كبار مزوِّدي البريد.

حدّدوا موعداً في تقويمكم بعد 14 يوماً لمراجعة التقارير المجمَّعة من جديد بحثاً عن أي مرسِل شرعي كسره التغيير. وعندها تكون المفاجآت عادةً صغيرة وسهلة الإصلاح.

عن BIMI

BIMI (مؤشرات العلامة التجارية لتعريف الرسائل) ضابط تكميلي يتيح ظهور شعاركم المُتحقَّق منه بجانب الرسائل المُصادَق عليها في عملاء البريد المتوافقين. ويتطلب DMARC على p=quarantine أو p=reject مع pct=100، وملف SVG مُتحقَّق منه للشعار، وشهادة علامة مُتحقَّق منها (Verified Mark Certificate) صادرة عن سلطة مُخوَّلة.

بالنسبة لشركة متوسطة، BIMI مكمّل لا ضرورة أمنية. والترتيب الصادق هو DMARC أولاً، ثم BIMI بعده، وفقط إذا كان تعرّض العلامة التجارية يبرّر تكلفة الشهادة والعبء التشغيلي لصيانة الـ VMC.

مطبّات صادقة

• النطاقات الفرعية الموروثة. تشدّد كثير من الشركات DMARC على النطاق الجذر وتنسى marketing.sudominio.com أو mail.sudominio.com. فالسجلات الصريحة لـ DMARC لكل نطاق فرعي إلزامية، أو sp=reject صارم في الجذر.
• أدوات "DMARC" من أطراف ثالثة. ستدير عدة خدمات SaaS لكم DMARC. وهي مريحة، وهي أيضاً طرف ثالث يرى البيانات الوصفية (metadata) لكل رسالة تدّعي القدوم من نطاقكم. اقرؤوا اتفاقية معالجة البيانات قبل التوقيع.
• الاندماجات والاستحواذات. عند الاستحواذ على شركة، ترثون وضع DMARC لديها. اجعلوه بنداً من بنود اليوم الأول في قائمة التكامل.

> "قِسنا الزمن من DMARC على p=none حتى وضع p=reject تشغيلي في شركات متوسطة، حين يتولى العمل مهندس واحد بتغطية تنفيذية. الوسيط 28 ساعة. والغرض من خطة الـ 24 ساعة أن يكون اليوم الثاني للصقل، لا للذعر." — مذكرة ميدانية من IBL، 2026

ماذا نفعل في IBL

سباق DMARC لدينا مهمة ثابتة: يومان عمل، ويوم مراقبة، ويوم صقل. والمُسلَّم هو سجل DMARC التشغيلي، وسجل SPF، وتوثيق إعداد DKIM، وجرد لكل مرسِل مُصرَّح له، ودليل تشغيل (runbook) من صفحة واحدة للمهندس الذي سيصون الضابط لاحقاً.

إذا أردتم الحديث عن وضع DMARC الحالي لديكم، فاكتبوا إلى [email protected]. نرد خلال يوم عمل.

---

OCIRIA شركة استشارية متخصصة (boutique) في الأمن السيبراني، مقرها في مالقة وفريقها التشغيلي في رومانيا. نعمل مع شركات أوروبية متوسطة تفضّل الصدق التقني على التغليف التجاري. تأسسنا في 2026؛ لا نختلق تاريخاً أطول.

قراءات ذات صلة

• OSINT 101: 7 أشياء يكتشفها مهاجم عن شركتكم في 30 دقيقة (cluster pillar Q4)
• التقييم الذاتي لـ NIS2: 25 سؤالاً لمعرفة ما إذا كانت شركتكم ممتثلة (cluster pillar Q3)
• ماسح تعرّض البريد: كيف تقرؤون التقرير دون الدخول في ذعر (cluster Q4)

الوسوم: dmarc, spf, dkim, seguridad-correo, anti-suplantación, bec, cumplimiento