سياسة DMARC: اختيار none وquarantine وreject

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

المشكلة غالبا ليست تعقيد DMARC، بل نقص التحضير. تترك بعض الفرق p=none دون تحليل مستمر، أو تنتقل إلى p=reject قبل التحقق من جميع المرسلين الشرعيين. وقد يؤدي ذلك إلى رفض بريد حقيقي.

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

ما هي سياسة DMARC؟

تطلب سياسة DMARC معاملة محددة حين تفشل رسالة تستخدم نطاقك في From. الخيارات هي none وquarantine وreject. يعتمد الاختيار على مصادقة المرسلين الشرعيين وتوافق نطاقاتهم.

يفحص المستقبل SPF وDKIM ويقارن النطاقات المستخدمة بنطاق From الظاهر. لا يكفي التوافق وحده، بل يجب أن تنجح المصادقة المرتبطة به أيضا.

إذا نجح SPF وكان متوافقا، نجح DMARC.

إذا نجح DKIM وكان متوافقا، نجح DMARC.

إذا لم ينجح أي منهما مع التوافق، فشل DMARC، وتؤخذ السياسة المنشورة في الحسبان عند اتخاذ قرار الاستقبال.

أي سياسة تختار أولا؟

ابدأ عادة بـ p=none، إلا إذا كانت لديك بيانات ممثلة وتأكدت من نجاح SPF أو DKIM المتوافق لدى جميع المصادر الشرعية. تتيح المراقبة تقييم أثر التطبيق قبل تشديد السياسة.

مثال لسجل البداية:

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

لا يطلب هذا الوضع وحده حظر الانتحال. قد توفر التقارير رؤية مفيدة، لكن ليس كل مستقبل يرسل تقارير، وقد تكون البيانات غير مكتملة.

مصادر إرسال قد تنسى:

1. برامج المحاسبة التي ترسل الفواتير.
2. أدوات الموارد البشرية والتوظيف التي ترسل العروض.
3. منصات CRM والتسويق التي ترسل الحملات.
4. أدوات الدعم التي ترد باسم نطاقك الأساسي.
5. قواعد إعادة التوجيه التي قد تؤثر في SPF عند المرحلة التالية.

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

قد يكون نشر DMARC مطلوبا لمرسلي البريد الجماعي، ومنها متطلبات Google للمصادقة والتوافق. راجع الشروط المطبقة على حجم إرسالكم وتدفقاته. يشرح المعيار RFC 7489.

كم تبقى السياسة على none؟

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

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

ينبغي أن يشمل الفحص:

1. بريد العمل المعتاد.
2. الإرسال التسويقي.
3. دورات الفوترة.
4. تصعيد طلبات الدعم.
5. البريد المعاد توجيهه.
6. أتمتة الأطراف الخارجية.

حلل التقارير التجميعية وافحص ما يعود إلى أنظمة شرعية تحتاج إلى إصلاح وما يحمل دلائل إساءة استخدام. ضع في الحسبان المصادر المجهولة والتقارير المفقودة ومشكلات التوجيه؛ التصنيف ليس حاسما دائما.

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

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

لماذا تؤثر إعادة التوجيه في DMARC؟

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

قد يفوت هذا الفرق حتى على مسؤولين متمرسين.

عنوان From الظاهر ليس هوية مرسل المغلف المستخدمة للارتدادات. يفحص SPF عنوان الإرسال ونطاق المغلف، ثم يتحقق DMARC من توافق نطاق SPF الناجح مع From.

يتغير عنوان الإرسال عند إعادة التوجيه، فلا تنطبق أحيانا صلاحيات SPF الأصلية. قد يبقى DKIM صالحا ما دامت الترويسات والمتن الموقعان لا يتغيران بطريقة تؤثر في التحقق.

لذلك قد يصح الأمران معا:

1. يفشل SPF بعد إعادة التوجيه.
2. ينجح DMARC لأن DKIM ينجح ويتوافق.

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

ينقل ARC سياق المصادقة عبر الوسطاء والقوائم البريدية. يقرر المستقبل ما إذا كان يثق به ويستخدمه، ولا يحل محل إعداد التوافق لديك. يصفه RFC 8617.

متى تنتقل إلى quarantine؟

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

مثال للسجل:

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

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

يمكن الاستجابة كما يلي:

1. يبلغ المستخدم عن بريد مفقود.
2. تفحص المرسل والتوافق.
3. تصلح SPF أو DKIM أو كليهما.
4. تختبر مجددا قبل التفكير في reject.

تستخدم بعض الفرق pct=25 أو pct=50 للتدرج. لكن دعم النسبة وتطبيقها يختلفان بين المستقبلين، فلا تعدها تقسيما دقيقا للتدفق أو ضمانا للأمان. وتطبيق quarantine على 100% يحتاج أيضا إلى تقييم مدروس.

مع SMTP المدار في TrekMail، افحص إعداد DKIM لنطاقك ونتائج الرسائل الفعلية. قد يفشل SPF في التوجيه بينما يبقى DKIM صالحا ومتوافقا. راجع رسائلي تصل إلى البريد المزعج.

متى تنتقل إلى reject؟

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

مثال للسجل:

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

قد تكون هذه غاية مناسبة لكثير من النطاقات بعد التحضير الدقيق.

من الفوائد المحتملة:

1. تقليل الانتحال المباشر للنطاق لدى المستقبلين الذين يطبقون السياسة.
2. تقييد بعض محاولات التصيد والاحتيال باستخدام نطاقك.
3. توضيح المعاملة التي تطلبها عند فشل المصادقة.
4. المساهمة في حماية النطاق والعلامة التجارية دون توفير حماية كاملة.

تشرح Google الرفض وتقييد المعدل للبريد غير المصادق أو غير المتوافق. قد تظهر رموز مثل 4.7.31 لمشكلات DMARC و4.7.32 للتوافق، وكذلك 5.7.26 في ارتدادات Gmail. اقرأ الرسالة كاملة وراجع الأسئلة الشائعة حول إرشادات مرسلي البريد في Google.

تنبيه: قد ترفض فاتورة شرعية من برنامج قديم إذا غابت المصادقة الناجحة المتوافقة تحت reject. جهز الاختبارات والمراقبة وخطة الاستعادة.

أي سجل DMARC تنشر في DNS؟

انشر السياسة كسجل TXT عند _dmarc.yourdomain.com. استخدم سجل سياسة DMARC واحدا لكل نطاق؛ تعدد سجلات السياسة قد يبطل اكتشافها.

الأمثلة التالية بدائل، فلا تنشرها جميعا معا:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

قد يشمل إعداد نطاق TrekMail سجلات MX وSPF وDKIM وDMARC. النمط التالي توضيحي ولا يلائم كل مسار إرسال، وقيمة quarantine ليست نصيحة بتجاوز المراقبة:

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

لا تنشر SPF مكررا، واستخدم قيم DKIM الفعلية، وراجع MX القديم عند التغيير. مع مزود إرسال خاص بك اتبع تعليماته لـ SPF وDKIM؛ تضمين SPF الخاص بـ TrekMail لا ينطبق على كل مسار BYO. راجع SMTP خاص بك (BYO).

أخطاء سياسة DMARC الشائعة

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

انتبه إلى ما يلي:

1. إبقاء none دون مراجعة التقارير أو تقييم التطبيق؛ لا يطلب هذا الوضع الحظر.
2. تجاهل توافق DKIM لأن SPF يبدو ناجحا. قد تكشف إعادة التوجيه أثر ذلك.
3. نسيان النطاقات الفرعية. يحدد sp= السياسة التي ترثها.
4. تجاهل حدود SPF. تجاوز 10 عناصر تستدعي البحث في DNS أثناء التقييم قد ينتج PermError؛ ليس الحد عددا بسيطا لحزم استعلام DNS.
5. الثقة بمنصة ترسل باسم نطاقك دون التحقق من توقيعها.

مثال لسياسة النطاقات الفرعية:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

يطلب reject للنطاق الأساسي وnone للنطاقات الفرعية التي ترث السياسة. لا يقتصر على نطاق اختبار واحد، وقد يتقدم سجل سياسة صريح في نطاق فرعي على السياسة الموروثة.

كيف يساعد TrekMail في التحضير؟

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

تبدأ الخطط المدفوعة الموضحة هنا من $3.50 شهريا في Starter وتتضمن SMTP مدارا. توصف Nano كخيار مجاني مع SMTP خاص بك. تحقق من الأسعار والحدود والتوافر الحالي. يوفر TrekMail صناديق IMAP، وقد تتاح النطاقات المخصصة والاستقبال الشامل والتوجيه والترحيل وAPI بحسب الخطة.

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

بحسب إعدادك، يمكنك مع TrekMail:

1. إدارة نطاقات متعددة من لوحة واحدة.
2. فحص سجلات DNS المطلوبة قبل بدء الاستخدام.
3. استخدام SMTP المدار في الخطط المناسبة أو إعداد SES/SendGrid الخاص بك في Nano.
4. فصل استضافة الصناديق عن اختيار مزود الإرسال.
5. جلب البريد القديم بترحيل IMAP ضمن إمكانات المصدر وصلاحيات الوصول.

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

الخلاصة: انتقال تدريجي يستند إلى الأدلة

مسار شائع هو البدء بـ none، وتصحيح المصادقة والتوافق، ثم تقييم quarantine، وبعده النظر في reject. يحتاج DMARC إلى صيانة وقرارات مدروسة، لا مجرد علامة في قائمة.

باختصار:

1. استخدم p=none مثلا لمدة 2 إلى 4 أسابيع كفترة فحص أولية، ومددها بحسب دورات الإرسال.
2. اضبط كل مرسل شرعي لينجح SPF المتوافق، ويفضل أن ينجح DKIM أيضا.
3. طبق p=quarantine بعد تقييم التدفقات الشرعية والمخاطر.
4. فكر في p=reject بعد فحص الإخفاقات المتبقية وتقليل الآثار غير المقصودة بما يكفي.

قد يساعد هذا المسار على تقليل انتحال النطاق وإدارة مخاطر البريد الحقيقي، دون ضمان الوصول أو الحماية الكاملة. راجع وثائق TrekMail والميزات والتسعير الحالي في https://trekmail.net/pricing.