الخلاصة

  • يثبت DMARC pass أن استعمال Author Domain مُجاز؛ ولا يثبت صدق الرسالة أو سلامتها أو نية مرسلها أو قيمتها.
  • p=reject تفضيل يعلنه Domain Owner، أما التصرف النهائي وسبب الاستثناء فيبقيهما RFC 9989 لدى Mail Receiver.

قد تمر رسالة صادرة من بنية مخولة بينما تكشف إشارات المستقبِل إساءة فيها. وقد تفشل رسالة مشروعة لأن قائمة بريدية غيّرت مسارها. تحويل pass إلى «آمن» وfail إلى «احتيال» يخطئ في الحالتين.

صدر RFC 9989 في مايو 2026 ضمن Standards Track في IETF وألغى RFC 7489 و9091. يثبت سجل النشر وDatatracker وصفحة التصويبات هوية المعيار، لا نتيجة تشغيله.

يربط SPF مصدراً SMTP بهوية مأذونة، ويتحقق DKIM من توقيع نطاق. ثم يطلب DMARC محاذاة هوية موثقة واحدة على الأقل مع Author Domain الظاهر. المحاذاة الناجحة تنتج pass، وغيابها ينتج fail.

يقصر RFC 9989 معنى pass على الإذن باستعمال النطاق، وينفي أي حكم قيمي على الرسالة. يستطيع المستقبِل رفضها لأدلة أخرى. كما لا يثبت fail التزوير؛ يشرح RFC 7960 كيف تكسر التحويلات والأسماء البديلة والقوائم محاذاة بريد مشروع.

يسجل IANA DMARC قيم none وquarantine وreject. تحمل هذه القيم معرفة مالك النطاق، لكنها لا تحتوي سمعة المستقبِل أو سياق المستخدم أو كلفة الخطأ لديه.

لذلك تجعل الفقرتان 5.3.6 و5.4 المعالجة خاضعة للسياسة المحلية. قد يقبل المستقبِل fail رغم p=reject أو يحجب pass. ويوصي المعيار بألا يكون p=reject السبب الوحيد للرفض، حمايةً للمسارات غير المباشرة. لكن الاستثناء قد يسمح بإساءة حقيقية؛ لذا يلزم سبب قابل للمساءلة.

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

يوفر RFC 9990 PolicyOverride لتسجيل الانحراف وسببه، ويحفظ RFC 8601 Authentication-Results. أما RFC 9991 فينظم تقرير فشل تفصيلياً اختيارياً؛ الإفصاح لا يمنح سلطة التصرف.

تسمح المواصفة الأولية الدنيا لدى Heng Lu بالتنسيق دون مصادرة القرار المحلي. تفصل طبقات الواقع الرمز عن التنفيذ، وتطالب أولوية الكود العامل بإثبات ما طبقه المستقبِل فعلاً.

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