سجل DMARC وسياساته: الإعداد والمطابقة والتقارير

يستحق سجل DMARC الصحيح الاهتمام في 2026، خاصة ضمن شروط المرسل المنطبقة. لدى Google وYahoo قواعد لفئات من المرسلين الجماعيين، ولـ Microsoft شروطها. قد يؤثر نقص المصادقة في التصفية أو الرفض، لكنه لا يجعل كل إرسال معطلا أو خفيا تلقائيا.

سجل DMARC (Domain-based Message Authentication, Reporting, and Conformance) سجل DNS TXT يطلب طريقة التعامل مع رسالة تستخدم نطاق From الظاهر دون مصادقة صحيحة ومتوافقة. يستند إلى SPF وDKIM مع بقاء سياسة المستقبل. ينشر على اسم _dmarc لنطاق From الفعلي؛ تعدد سياسات DMARC على الاسم نفسه غير صحيح، بخلاف سجلات TXT غير المرتبطة.

قد يواجه مؤسس مشاكل في وصول بريد المستثمرين، أو مزود خدمات يدير 500 نطاق استفسارات عن فواتير QuickBooks المفقودة. افحص السبب الفعلي؛ المصادقة لا تضمن الوصول إلى الوارد بأي حجم.

يشرح الدليل عمل سجل DMARC والأخطاء والانتقال من عدم وجود سياسة إلى مراجعة p=reject. يقلل الحصر والاختبار وخطة التراجع المخاطر دون ضمان انتقال بلا خلل.

وظيفة سجل DMARC

ينشر سجل DMARC سياسة المصادقة وطلبات التقارير، ولا يفحص المحتوى أو يحظر كل الرسائل المزعجة. السؤال هو: «كيف أطلب من المستقبل معالجة بريد يستخدم نطاق From الخاص بي دون نجاح مصادقة متوافقة؟»

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

يوضح سجل DMARC لـ Gmail وOutlook السياسة المطلوبة عند فشل المطابقة. لا يلزمهما بمعالجة موحدة، كما لا يضمن النجاح التسليم أو الوصول إلى الوارد.

السياسات الثلاث: وسم p=

يحمل p= السياسة المطلوبة لفشل DMARC. تؤثر الحقول الأخرى، مثل المطابقة والنطاقات الفرعية والتقارير، في الإعداد أيضا.

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

حضّر الانتقال أولا. الأقسام التالية مسار ممكن، لا جدول مضمون لكل بيئة.

المصادقة بـ SPF وDKIM وDMARC

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

تعمل العناصر الثلاثة هكذا:

SPF (Sender Policy Framework)

وظيفته: يفوض أنظمة الإرسال لنطاق الظرف MAIL FROM أو HELO في الحالات المعنية، لا عنوان From الظاهر بمفرده.

حدوده: قد يفشل مع التوجيه إذا بقي مرسل الظرف الأصلي ولم يكن عنوان خادم التوجيه مفوضا. ليست كل إعدادات التوجيه كذلك.

راجع إعداد SPF وأساسيات SPF للبريد ومعالجة حدود البحث في SPF للخطوات والتقييم.

DKIM (DomainKeys Identified Mail)

وظيفته: توقيع في رأس الرسالة يغطي رؤوسا مختارة وجسم الرسالة ضمن التغطية. يتحقق المستقبل بالمفتاح العام في DNS وفقا للتسوية المستخدمة.

ميزته: قد يبقى صحيحا مع التوجيه إذا بقي المحتوى والمفتاح وبقية الشروط صالحين. يمكن لتغيير الرؤوس أو الجسم إبطاله؛ ويحتاج DMARC المطابقة أيضا.

DMARC (طبقة السياسة)

القاعدة: ينجح DMARC إذا نجح SPF وكان متوافقا مع Header From، أو وجد توقيع DKIM صحيح واحد على الأقل ومتوافق. إعداد الطريقتين مفيد لكن نجاح طريقة متوافقة واحدة يكفي.

راجع ترتيب إعداد SPF وDKIM وDMARC للعلاقة الكاملة.

شرح المطابقة ببساطة

قد ينجح SPF وDKIM منفردين ويفشل DMARC رغم صحة صياغة السجل. المهم هو النطاق الذي صودق عليه فعليا.

للبريد هويتا مرسل من ضمن هوياته التقنية:

• Header From: ما يراه المستلم مثل support@yourcompany.com.
• Envelope From (Return-Path): عنوان الارتدادات التقني الذي قد تديره خدمة خارجية.

يقارن DMARC نطاق From بنطاق SPF أو DKIM. تستخدم المطابقة المرنة النطاق التنظيمي، والصارمة تطابقا كاملا. لا يفشل إلا عند غياب طريقة ناجحة ومتوافقة.

مثال Mailchimp أو خدمة تسويق

إعداد توضيحي للنشرة، وليس تأكيدا لقيم المزود الحالية:

• Header From: news@yourcompany.com
• Return-Path: مثال نطاق الارتداد mail12.mailchimp.com، لا عنوان بريد كامل
• توقيع DKIM: يستخدم d=mailchimp.com

التقييم المفترض لهذا المثال:

• يستخدم SPF سياسة نطاق الظرف الفعلي ضمن mailchimp.com؛ نفترض نجاحه هنا بعد التحقق من السياسة.
• نفترض نجاح DKIM لـ mailchimp.com.
• هل يطابق yourcompany.com النطاق mailchimp.com؟ لا.
• دون مصادقة متوافقة أخرى، نتيجة DMARC: فشل.

يوضح المثال نجاح الفحصين دون نجاح DMARC، ولا يعني أن كل بريد ESP الافتراضي يفشل.

المعالجة: مصادقة نطاق مخصص

احصر أدوات التسويق وCRM وخدمات رسائل المعاملات، واضبط المصادقة المدعومة على المسارات الفعلية:

• مطابقة SPF: اضبط نطاق ارتداد خاصا مثل bounces.yourcompany.com بسجلات TXT أو MX أو CNAME التي يطلبها المزود. النشر وحده لا يغير MAIL FROM. تحقق من نجاح SPF والمطابقة المرنة أو التطابق الكامل في الوضع الصارم.
• مطابقة DKIM: انشر المفتاح أو التفويض المطلوب، واضبط الخدمة لتوقع بـ d=yourcompany.com حيث تدعم ذلك. افحص توقيعات فعلية.

مع 100 نطاق عميل يلزم سجل لكل خدمة ونطاق. تساعد سجلات DNS المطلوبة في TrekMail في التوجيه، لكن تحقق من الميزات والنشر والمطابقة. لا تعدل اللوحة تلقائيا كل منطقة DNS خارجية أو ESP.

راجع أيضا مطابقة DMARC.

التطبيق المرحلي: نموذج الجسر

قد يؤثر الانتقال المبكر إلى p=reject في البريد الشرعي. وقد يكون البقاء على p=none اختيارا واعيا لكنه لا يطلب إنفاذ الرفض. حضّر الانتقال بالمراقبة والاختبار والتراجع.

المرحلة 1: نشر المراقبة (الأسابيع 1-4)

هذا مثال لا يطلب حجر DMARC أو رفضه. استبدل النطاق والوجهة بقيم فعلية متحقق منها:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

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

المرحلة 2: اكتشاف خدمات الإرسال غير المعروفة

استخدم أداة مناسبة، راجع قسم التقارير، وقسم الحركة إلى ثلاث مجموعات:

• مصرح ومتوافق: المنصات المعروفة التي يفترض نجاح DMARC لها. افحص الأخطاء قبل التشديد.
• مصرح وغير متوافق: أداة تسويق خارج علم IT أو دعم أو CRM يرسل منذ 2022. أكد الملكية وأصلح المسارات الشرعية.
• تهديدات محتملة: قد تعني العناوين المجهولة انتحالا أو خدمة منسية أو توجيها. تحقق؛ تحد p=reject من رسائل انتحال النطاق المباشر التي تفشل في المصادقة المتوافقة، حيث يطبق المستقبل الطلب.

أصلح واختبر جميع المسارات الشرعية المعروفة، حتى التي لم تظهر في التقارير، قبل المتابعة.

المرحلة 3: اختبار الحجر

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

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

كان pct= إعداد نسبة في المواصفة السابقة وأزيل من المواصفة الحالية. مثال pct=25 التاريخي يعني 25%، لكن التنفيذ والوثائق القديمة قد يختلفان. لا تقفز بعد المرحلتين 1 و2 مباشرة إلى 100% دون اختبار؛ راجع الدعم الفعلي وخطة التدرج والتراجع.

المرحلة 4: الإنفاذ

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

قد تحد p=reject من انتحال From المباشر دون مصادقة متوافقة لدى مستقبل يطبقها. لا توقف النطاقات المشابهة أو الأسماء الظاهرة أو الحسابات المخترقة أو كل التصيد، ولا تضمن سمعة أفضل أو وصولا إلى الوارد.

راجع إعداد DMARC وأمثلة السجلات، وتحقق قبل النشر.

إعادة التوجيه وARC وأهمية DKIM

«بريدي يعمل، لكنه يرتد عند إرساله للمحامي». قد يكون التوجيه سببا، لكن عبارة تسع حالات من عشر ليست إحصاء موثقا. افحص المسار الفعلي وسياسة المستقبل.

كيف قد يفشل SPF مع التوجيه؟

ترسل إلى contact@smallfirm.com الذي يحول إلى personal@gmail.com. يرى Gmail عنوان خادم smallfirm.com. إذا بقي MAIL FROM الأصلي ولم يفوض SPF smallfirm.com فقد يفشل.

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

متى يبقى DKIM صحيحا؟

يوجد التوقيع في رأس الرسالة ويغطي الرؤوس المختارة والأجزاء المشمولة من جسم الرسالة. قد يبقى صحيحا إذا بقيت التغطية وشروط التحقق سليمة. قد يبطله تعديل العنوان أو التذييل. يسمح توقيع صحيح ومتوافق بنجاح DMARC حتى مع فشل SPF.

لهذا DKIM مسار مكمل مهم وجزء من شروط المرسل المنطبقة، لا ضمانا لكل حالة توجيه.

ARC إذا تأثر DKIM أيضا

قد تضيف قائمة بريدية تذييلا أو تغير بوابة المحتوى، فتتأثر DKIM بحسب التغطية والتسوية. يتيح ARC (Authenticated Received Chain) تمرير نتائج مصادقة سابقة موقعة من الوسطاء. لا يحول فشل DMARC تلقائيا إلى نجاح.

قد تقيم Google وMicrosoft سلسلة ARC حسب صحتها والثقة بالوسيط والسياسة المحلية. يتولاها غالبا نظام التوجيه، لكن إدارة مرحل خاص قد تتطلب إعدادا. ظهور رؤوس ARC لا يثبت خطأ أو قبول الرسالة.

راجع فشل DMARC وإعادة التوجيه.

تقارير RUA وRUF: ما تحتاجه؟

يمكن طلب التقارير التجميعية، غالبا XML، باستخدام rua=. لا يبلغ كل مستقبل عن كل رسالة، وقد تحتاج وجهة خارجية تفويضا إضافيا. XML قابل للقراءة لكن أداة التحليل تساعد مع الحجم الكبير.

RUA: التقارير التجميعية

الوسم: rua=mailto:reports@yourdomain.com

تجمع النتائج غالبا مرة في اليوم، دون ضمان للتوقيت. مثال: أرسل IP 203.0.113.12 عدد 300 رسالة، نجحت 295 وفشلت 5. تختلف التغطية والتأخير، والنجاح والفشل لا يحددان وحدهما التصنيف النهائي.

تسرد dmarc.org أدوات؛ تحقق من وظائف Postmark وValimail الحالية. افحص المصادر المعروفة والمجهولة، فالعنوان المجهول ليس هجوما حتما وp=reject لا يثبت حظر كل رسالة فاشلة في التقرير.

توفر مقالات تقارير DMARC وRUA سياقا للتحليل الأعمق.

RUF: تقارير الفشل التفصيلية

الوسم: ruf=mailto:forensics@yourdomain.com

تطلب RUF معلومات فشل على مستوى الرسالة. قد تشمل رؤوسا أو محتوى بحسب المزود وحذف المعلومات الحساسة، وليست دائما نسخة كاملة أو شرحا لكل السبب.

قد يثير ذلك أسئلة خصوصية وامتثال عند الرسائل السرية. قيّم الوجهة والصلاحيات والاحتفاظ والأساس القانوني، واجمع أقل قدر لازم.

تختلف إتاحة RUF لدى المزودين الكبار، ولا يدعم Gmail إرسالها. تكون RUA لذلك بداية عملية غالبا. اختر التقارير التفصيلية مع حاجة موثقة وضوابط مناسبة؛ فائدتها وضجيجها يعتمدان على البيئة.

يناقش مقال DMARC RUF اعتبارات التحقيق التقني والخصوصية بتفصيل.

الحذر عند تقييم الضجيج

قد تتضمن التقارير توجيها قديما أو انتحالا، لكن لا تتجاهل IP مجهولا لقلة الحجم. قد تكون رسالة شرعية مهمة نادرة. أكد المصادر والمسارات والأنماط واجمع التقارير مع الحصر والاختبار.

متى تراجع p=reject؟

راجع p=reject بعد التحقق الكافي من المسارات الشرعية. تساعد القائمة التالية في القرار ولا تضمنه:

• مثال مراقبة 30 يوما: تحقق فعليا من الإرسال الشهري والفصلي؛ لا تضمن المدة التقاطهما، وأسبوع قد يكون أقل كفاية.
• مطابقة الإرسال الرئيسي: تحقق من نجاح DMARC الفعلي في TrekMail وGoogle Workspace وMicrosoft 365، لا SPF أو DKIM منفردين.
• فحص الخدمات الخارجية: لرسائل التسويق والمعاملات وCRM والدعم طريقة مصادقة صحيحة ومتوافقة.
• تأكيد فرق التسويق: اسأل جميع الفرق عن الأدوات الجديدة؛ خدمة بدأت الثلاثاء الماضي قد لا تظهر في التقارير بعد.
• سياسة النطاق الفرعي: راجع الاكتشاف والوراثة عند عدم وجود سياسة مستقلة. قد يحدد sp=none طلبا مختلفا للنطاقات المغطاة في المثال: v=DMARC1; p=reject; sp=none; rua=mailto:reports@yourdomain.com. راقب فجوة الحماية المخططة وافحص sp= والسجلات الفرعية بصورة منفصلة.

تابع المراقبة مع p=reject. عند زيادة الشكاوى، أكد فشل البريد الشرعي ثم استخدم خطة تراجع مؤقتة مناسبة، مثل p=quarantine، مع فحص DNS والمحللات. قد تؤخر الذاكرة التغيير، ولا يعيد الحجر الرسائل المرفوضة سابقا. يدعم DMARC حماية النطاق دون ضمان تحسين سمعة نطاق البريد.

راجع شرح reject وفشل DMARC: التشخيص والإصلاح.

إدارة نطاقات متعددة في TrekMail

حتى مع نطاق واحد، ليس DMARC عملا ينتهي مرة واحدة. شهر مراقبة مثال؛ احصر المصادر وأصلح المطابقة واختبر الإنفاذ وراجع التغييرات لاحقا.

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

يتطلب الدخول إلى مزودي DNS والنشر عملا متكررا. قضاء فترة ما بعد الظهر مع 50 نطاقا أو وضع سير عمل لـ 500 أمثلة توضح حجم العمل؛ تعتمد المدة وقابلية التوسع على الأدوات والإعداد.

قد تساعد سجلات DNS المطلوبة في TrekMail في الإعداد الأولي. افحص القيم والوجهة والنشر. قد يقدم فاحص حالة DNS عرضا للمجموعة بحسب الميزات الحالية، لكن وجود سجل لا يثبت نجاح كل بريد في DMARC.

قد تدعم SMTP المدارة توقيع النطاق. تحقق من المحدد وDNS والمطابقة لكل نطاق؛ يتطلب SMTP الخاص والخدمات الخارجية إعدادا آخر.

تذكر المقارنة التاريخية Pro بسعر $8 شهريا مع 100 نطاق و300 مستخدم لكل نطاق و50GB تخزين مجمع، مقابل $6-12 لكل مستخدم لدى خدمات أخرى. تحقق من العقود والأسعار والمزايا والحدود الحالية؛ لا يعني سعر المنصة توسعا بلا حد أو إعداد DNS الخارجي تلقائيا.

تصف Agency سعة 1,000+ نطاق. راجع الوظائف والقدرة والشروط في تفصيل الأسعار.

خلاصة سجل DMARC

أدر سجل DMARC المطلوب وافحص المصادقة الصحيحة والمتوافقة. تختلف متطلبات المستقبل ومرشحاته؛ لا يجعل غياب السياسة كل رسالة غير موثوقة تلقائيا لكنه قد يقلل الحماية والامتثال المعنيين.

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

قد يبدو إعداد نطاقك مهمة تنجز خلال فترة ما بعد الظهر، لكنه يحتاج صيانة. تتطلب مجموعة العملاء نظاما قابلا للتكرار؛ يمكن أن تساعد TrekMail بحسب الميزات الحالية وتكوين الإرسال.

راجع سياسة DMARC على p=reject عندما تدعمها الاختبارات والحصر وتقييم المخاطر. قارن التكلفة وعبء الإدارة بالشروط الحالية.

راجع عرض TrekMail المجاني وشروطه الحالية، وتحقق من وصف عدم اشتراط بطاقة ائتمان.