لماذا DMARC p=none غير كافٍ في 2026
يُصادق SPF وDKIM على الإرسال: يُثبتان أن خادمًا كان مُخوَّلًا وأن الرسالة لم تُعدَّل. لكنهما لا يُعطيان أي تعليمات للخادم المُستقبِل. DMARC هو من يقرّر: ماذا يفعل الخادم المُستقبِل برسالة تفشل في SPF أو DKIM؟ في p=none الجواب هو «لا شيء» — تُسلَّم الرسالة بشكل اعتيادي ويتلقى صاحب النطاق تقارير. كان هذا الوضع الاستطلاعي منطقيًا في مرحلة النشر الأولى. في 2026، غيّرت Google وMicrosoft القواعد: تقرأان بنشاط سياسة DMARC للمُرسِلين أكثر من 100 رسالة يوميًا. النطاق الباقي على p=none يُعامَل كنطاق بلا سياسة. النتيجة: معدلات تسليم متدهورة، وتصنيف تفضيلي في البريد المزعج، وبمجرد تجاوز معدل الشكاوى 0.3% يُطبَّق تقييد فوري. الهدف الموصى به من Google Postmaster Tools للبقاء تحت العتبة هو أقل من 0.1%.
ما تخاطر به بالبقاء على p=none بعد 2026
- تقييد صامت — تُحدّد Google وMicrosoft معدل قبول رسائلك اعتبارًا من 0.3% شكاوى، دون أي bounce صريح.
- تصنيف منهجي في البريد المزعج — بلا سياسة نشطة، تُعامِل خوارزميات صناديق البريد الكبرى إرسالك كغير موثّق.
- انتحال هوية النطاق دون حماية — يمكن لطرف ثالث الإرسال باسمك؛ بلا DMARC نشط لا يستطيع المُستلِمون التمييز.
- تقارير rua غير مستغلة — في p=none تصل التقارير لكن لا شيء يُحظر: تراقب الإساءة دون إيقافها.
- فقدان سمعة المُرسِل — السمعة المتدهورة تحتاج أسابيع للتعافي حتى بعد تصحيح السياسة.
- حجب حملات البريد الإلكتروني — ترفض ESPs مثل Mailchimp وBrevo وSendGrid الإرسال لنطاقات ذات سمعة مُعلَّمة.
- خطر التصعيد القسري إلى p=reject — قد تُطبّق Google سياسة أكثر صرامة من جانب واحد إن ارتبط النطاق بالتصيد.
السياسات الثلاث لـ DMARC: p=none وp=quarantine وp=reject
| السياسة | التأثير على الرسائل الفاشلة | حالة الاستخدام |
|---|---|---|
| p=none | تُسلَّم بشكل اعتيادي — لا إجراء على الرسالة. تُرسَل تقارير rua. | مرحلة الاستطلاع الأولية (أسبوعان إلى أربعة كحد أقصى). لم تعد مناسبة للمُرسِلين النشطين في 2026. |
| p=quarantine | تُوجَّه إلى مجلد البريد المزعج/الحجر الصحي عند المُستلِم. تُرسَل تقارير rua. | الخطوة الوسيطة الموصى بها: حماية نشطة، لكن الإيجابيات الكاذبة تبقى في البريد المزعج قابلة للاسترجاع. |
| p=reject | رفض نهائي بـ SMTP 554 من الخادم المُستقبِل. تُرسَل تقارير rua. | الهدف النهائي: أقصى حماية. يُبلَغ بعد أسبوعين إلى أربعة في الحجر الصحي دون إيجابيات كاذبة. |
قائمة مراجعة SPF + DKIM + DMARC + List-Unsubscribe: 8 خطوات
التحقق من سجل SPF
تأكد من وجود سجل TXT في جذر yourdomain.com يدرج جميع مصادر إرسالك النشطة. مثال: v=spf1 include:_spf.your-provider.com include:sendgrid.net ~all. سجل SPF واحد فقط لكل نطاق — سجلان متزامنان يُبطلان الاثنين. تحقق بـ dig TXT yourdomain.com أو MXToolbox.
التحقق من توقيع DKIM
يجب أن تُوقّع كل مصدر إرسال (خادم رئيسي، ESP، أداة تسويق) الرسائلَ بمفتاح DKIM منشور في DNS. مثال على السجل: mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0…". أرسل رسالة اختبارية وافحص الترويسات: ابحث عن dkim=pass في Authentication-Results.
نشر سجل DMARC مع عنوان rua
أنشئ سجل TXT على _dmarc.yourdomain.com. إن كنت لا تزال على p=none، القيمة الابتدائية: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100. إن كنت مستعدًا لـ p=quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100. حقل rua هو العنوان الذي يتلقى التقارير الإجمالية اليومية.
قراءة تقرير DMARC الإجمالي (تنسيق rua)
تصل التقارير كملفات XML مضغوطة. الحقول الرئيسية: source_ip (الخادم المُرسِل)، count (عدد الرسائل)، disposition (none / quarantine / reject)، dkim وspf (pass أو fail لكل تحقّق). تقرير يُظهر source_ip مجهولة مع dkim=fail وspf=fail يُشير إلى انتحال هوية نشط لنطاقك.
الانتقال إلى p=quarantine بعد أسبوعين إلى أربعة من الاستطلاع
لا تنتقل مباشرةً إلى p=reject. تُستخدَم مرحلة 2-4 أسابيع لتحديد المصادر الشرعية المنسية: قائمة بريدية خارجية، أداة CRM، نشرة إخبارية من نطاق فرعي. حدّث DNS: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100.
إضافة رأسية List-Unsubscribe one-click (RFC 8058)
منذ 2026، تشترط Gmail وOutlook على المُرسِلين أكثر من 100 بريد/يوم تضمين رأسية HTTP List-Unsubscribe-Post: List-Unsubscribe=One-Click في رسائل القوائم. الرأسية الكاملة جزءان: List-Unsubscribe: <https://yourdomain.com/unsubscribe?id=abc123> وList-Unsubscribe-Post: List-Unsubscribe=One-Click. تتولى معظم ESPs هذا تلقائيًا؛ تحقق من تفعيله في إعداداتك.
مراقبة معدل الشكاوى في Google Postmaster Tools
توفّر Google Postmaster Tools (postmaster.google.com) معدل البريد المزعج وسمعة المُرسِل والتسليم. أنشئ حسابًا، وتحقق من نطاقك عبر سجل TXT، وراقب لوحة «Spam rate» يوميًا. الهدف: البقاء تحت 0.1%. بين 0.1% و0.3% خطر تقييد. فوق 0.3% تقييد فوري.
الانتقال إلى p=reject حين يستقر الحجر الصحي
بعد أسبوعين إلى أربعة في p=quarantine دون إيجابيات كاذبة ودون مصادر شرعية مجهولة في تقارير rua، انتقل إلى p=reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100. استمر في مراقبة Google Postmaster Tools أسبوعيًا خلال الشهر الأول.
قراءة تقرير DMARC الإجمالي وتحليله
تقرير DMARC الإجمالي ملف XML يُرسَل يوميًا إلى عنوان rua= في سجلك. كل تقرير يغطي 24 ساعة من الإرسال باسم نطاقك كما يراه الخادم المُستقبِل (Gmail وOutlook وغيرهما).
بنية سجل في التقرير:
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>1247</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>اقرأ التقارير بحثًا عن ثلاثة حالات:
- dkim=pass + spf=pass على IPs معروفة: إرسالك الشرعي يمر بنجاح.
- dkim=fail + spf=fail على IPs مجهولة: انتحال هوية نشط — تقاريرك توثّق إرسال شخص ما باسمك دون إذن.
- dkim=fail على IP معروفة: هذه المصدر يُرسِل باسمك لكن غير مغطى بمفتاح DKIM — صحّح قبل الانتقال إلى p=quarantine.
أدوات مثل dmarcian.com أو MXToolbox DMARC Analyzer تقرأ هذه الملفات تلقائيًا وتُجمّعها.
اختبر قبل تغيير السياسة
mail-tester.com يُرسِل بريدًا اختباريًا ويُعيد نقاطًا من 10 مع تقرير تفصيلي: SPF وDKIM وDMARC والقوائم السوداء ونقاط المحتوى. استخدمه قبل كل تغيير في السياسة وبعده. MXToolbox DMARC Check يتحقق من سجل DNS مباشرةً دون إرسال.
استكشاف الأخطاء: أربع حالات شائعة
DMARC يفشل لكن SPF وDKIM يجتازان منفردَين. يشترط توافق DMARC أن يتطابق النطاق في رأسية From مع النطاق الذي تحقّق منه SPF أو DKIM. إن أرسلت من sender@yourdomain.com لكن ESP الخاص بك يُوقّع DKIM بـ otherdomain.com، يجتاز كل من SPF وDKIM — لكن DMARC يفشل بسبب عدم التوافق. الحل: اضبط ESP ليُوقّع DKIM بنطاقك yourdomain.com أو أضف IP الـ ESP إلى SPF نطاقك المُرسِل.
تقرير rua فارغ بعد 48 ساعة. تحقق أن عنوان rua ينتمي لنفس نطاق سجل DMARC. لا تُرسِل Gmail وOutlook تقارير إلا إذا كان نطاقك يُرسِل حجمًا كافيًا إليهما.
معدل شكاوى في ارتفاع رغم تفعيل DMARC. DMARC يحمي المصادقة لا المحتوى. إن نقر المُستلِمون على «بريد مزعج»، لا تستطيع سياسة DMARC فعل شيء. تحقق من تكرار الإرسال وملاءمة المحتوى وحالة رأسية List-Unsubscribe one-click.
List-Unsubscribe one-click غير معترف به من Gmail. تشترط Gmail نموذج HTTP POST (RFC 8058): يجب أن ترافق رأسية List-Unsubscribe-Post: List-Unsubscribe=One-Click عنوانَ URL. رابط إلغاء الاشتراك المجرد في mailto: أو HTTPS دون List-Unsubscribe-Post غير معترف به بوصفه one-click.
من p=quarantine إلى p=reject: المسار
الانتقال من p=quarantine إلى p=reject هو الخطوة الأخيرة — والأسهل إن نُفِّذت السابقات بشكل صحيح. في هذه المرحلة، تجتاز جميع إرسالاتك الشرعية SPF وDKIM، ولا تُظهر تقارير rua مصادر مجهولة، ومعدل شكاواك أقل من 0.1%.
التغيير مجرد استبدال قيمة في سجل DNS: p=quarantine تصبح p=reject. TTL القياسية لسجلات DNS TXT هي 3600 ثانية (ساعة واحدة): توقع انتشارًا من ساعة إلى أربع ساعات.
لماذا لا تنتقل مباشرةً إلى p=reject دون p=quarantine؟ في p=quarantine تصل الإيجابيات الكاذبة إلى البريد المزعج — يمكن الوصول إليها واسترجاعها. في p=reject تُرفض نهائيًا في SMTP: لا المُرسِل ولا المُستلِم يستطيع استرجاعها. المرحلة الوسيطة شبكة أمان لتحديد آخر المصادر الشرعية سيئة التكوين.
بعد الانتقال إلى p=reject، استمر في فحص Google Postmaster Tools أسبوعيًا خلال الشهر الأول ثم شهريًا.
