سجلّات SPF وDKIM وDMARC: اضمن وصول بريدك

لماذا قد يذهب بريدك الشرعي إلى السبام؟

تخيّل أنك أرسلت رسالة من نطاقك example.com إلى عميل على Gmail. قبل أن يقرّر Gmail وضع رسالتك في الوارد، يطرح سؤالًا بسيطًا لكنه حاسم: «هل هذه الرسالة فعلًا من example.com، أم أن أحدهم ينتحل اسم النطاق؟». المشكلة الجوهرية أن بروتوكول البريد الأصلي (SMTP) صُمّم في زمن لم تكن فيه الثقة موضع شكّ، فهو يسمح لأي خادم بأن يكتب في خانة المُرسِل أي عنوان يريده — تمامًا كما يمكن لأي شخص أن يكتب اسمك على ظرف بريدي دون أن يكون أنت.

هذا الخلل البنيوي هو ما يستغلّه المهاجمون في رسائل التصيّد: يرسلون رسالة تبدو وكأنها من بنكك أو من شركتك، فيُخدع المستلم ويسلّم بياناته. وفي المقابل، يعاقب مزوّدو البريد (Gmail، Outlook، Yahoo) أي نطاق لا يثبت هويته بأن يدفعوا رسائله إلى السبام أو يرفضوها أصلًا. لذلك فإن مصادقة البريد ليست رفاهية أمنية فحسب، بل شرط أساسي لوصول بريدك الشرعي (Deliverability). إن لم تضبط هذه السجلّات، فقد تكون رسائلك المشروعة تمامًا — فواتير، تأكيدات طلبات، رسائل ترحيب — تختفي في السبام دون أن تدري.

الحلّ يأتي عبر ثلاث طبقات تتكامل: SPF الذي يقول «هذه الخوادم فقط مسموح لها بالإرسال باسمي»، وDKIM الذي يضيف ختمًا رقميًا لا يمكن تزويره يثبت أن الرسالة لم تُعبَث بها في الطريق، وDMARC الذي يجمع الإشارتين معًا ويصدر القرار النهائي ويرسل لك تقارير عمّا يجري. هذه السجلّات الثلاثة كلّها تُكتب كسجلّات DNS من نوع TXT، لذا يُستحسن أن تكون على دراية بأساسيات سجلّات DNS ببساطة قبل أن نغوص في التفاصيل. إن لم تكن قد أنشأت بريدك الاحترافي بعد، فابدأ من دليل إعداد بريد احترافي بنطاقك ثم عُد إلى هنا لتأمينه.

أين تعيش هذه السجلّات في الـDNS؟

قبل التعمّق، من المفيد أن ترسم في ذهنك خريطة لمكان كل سجلّ. السجلّات الثلاثة كلّها من نوع TXT (نصّي) داخل منطقة DNS لنطاقك، لكنها تختلف في «الاسم» (Host/Name) الذي توضع تحته. هذه الخريطة وحدها تحلّ نصف المشاكل التي يقع فيها المبتدئون حين يضعون السجلّ في الاسم الخطأ.

السجلّ الأول، SPF، يوضع على «جذر» النطاق نفسه — أي الاسم @ أو اسم النطاق المجرّد example.com. السجلّ الثاني، DKIM، لا يوضع على الجذر بل تحت اسم خاصّ يسمّى «المُحدِّد» (Selector) متبوعًا بالجزء الثابت ._domainkey، مثل mail._domainkey.example.com. أما DMARC، فيوضع دائمًا تحت الاسم المخصّص _dmarc.example.com. الجدول التالي يلخّص أين يعيش كل سجلّ:

ملاحظة مهمّة: سجلّ SPF واحد فقط مسموح لكل نطاق (سنفصّل لماذا لاحقًا)، بينما يمكن أن يكون لديك عدّة سجلّات DKIM بمحدِّدات مختلفة (واحد لكل خدمة إرسال)، وسجلّ DMARC واحد فقط لكل نطاق. كل سجلّ يُكتب كسلسلة نصّية بصيغة محدّدة من «الوسوم» (Tags) المفصولة بفواصل منقوطة، وسنشرح صيغة كل واحد على حدة.

ما هو SPF وكيف يعمل؟

SPF اختصار لـ Sender Policy Framework — «إطار سياسة المُرسِل». فكرته بسيطة وأنيقة: تنشر في DNS قائمة بيضاء بكل الخوادم (عناوين IP والنطاقات) المسموح لها بإرسال بريد باسم نطاقك. حين يستقبل خادم البريد رسالة تدّعي أنها من example.com، يفحص عنوان IP الخادم الذي أرسلها فعلًا، ثم يقرأ سجلّ SPF لنطاقك ويسأل: «هل هذا العنوان موجود في القائمة المسموح بها؟». إن كان موجودًا، نجح SPF؛ وإن لم يكن، فشل.

كيف يجري الفحص خطوة بخطوة؟

عند وصول رسالة، ينظر الخادم المستقبِل إلى عنوان «المُرسِل المغلَّف» (Envelope From، ويسمّى أيضًا MAIL FROM أو Return-Path) — وهو ليس بالضرورة نفس العنوان الذي تراه في خانة «From» المرئية. يستخرج الخادم اسم النطاق من هذا العنوان، ثم يستعلم عن سجلّ TXT الذي يبدأ بـ v=spf1 لذلك النطاق. بعدها يقارن عنوان IP للخادم المُرسِل بالآليات (Mechanisms) المذكورة في السجلّ واحدة تلو الأخرى حتى يجد تطابقًا. أول آلية تتطابق تحدّد النتيجة.

هذه نقطة دقيقة وكثيرًا ما تُهمَل: SPF يفحص نطاق Return-Path لا نطاق From المرئي. هذا بالضبط سبب وجود DMARC لاحقًا، لأن المهاجم يمكنه أن يضبط Return-Path لنطاق يملكه (وينجح SPF) بينما يضع في From المرئي نطاقك أنت. SPF وحده لا يحمي العنوان الذي يراه المستخدم.

صيغة سجلّ SPF وآلياته

سجلّ SPF نموذجي يبدو هكذا:

example.com.   IN   TXT   "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 mx ~all"

كل جزء بعد v=spf1 يسمّى «آلية» (Mechanism)، وتُقرأ من اليسار إلى اليمين. الجدول التالي يشرح أكثر الآليات استخدامًا:

أما الرمز الذي يسبق all فيُسمّى «المُؤهِّل» (Qualifier) وهو الذي يحدّد كيف يعامل الخادم العناوين غير المدرجة في القائمة. هذه الفروق تبدو صغيرة لكنها تحدّد سلوك بريدك بالكامل:

التوصية العملية: ابدأ بـ ~all أثناء الإعداد كي لا تُرفض رسائل شرعية إن نسيت خادمًا، ثم انتقل إلى -all بعد أن تتأكّد عبر تقارير DMARC أن قائمتك شاملة. واحذر تمامًا من +all لأنه يلغي الحماية كلّها ويفتح نطاقك للانتحال.

الحدّ الحاسم: 10 استعلامات DNS

هنا يكمن أحد أخطر القيود في SPF، وكثيرون يقعون فيه دون أن يفهموا سبب فشل بريدهم فجأة. تنصّ المواصفة على أن تقييم سجلّ SPF لا يجوز أن يتجاوز 10 استعلامات DNS. كل آلية تتطلّب بحثًا في DNS — وهي include وa وmx وptr وexists — تُحسب ضمن هذا الحدّ. والآليات التي لا تتطلّب استعلامًا — مثل ip4 وip6 وall — لا تُحسب.

المشكلة أن كل include قد يستورد سجلًّا فيه include آخر، فتتراكم الاستعلامات بسرعة. لو أضفت Google وMailchimp ومزوّد فوترة وأداة دعم فني، قد تتجاوز العشرة بسهولة. وعند تجاوز الحدّ، تكون النتيجة permerror (خطأ دائم)، وقد يعامله الخادم المستقبِل كأنه فشل، فيسقط بريدك الشرعي. الجدول التالي يوضّح أيّ الآليات تستهلك الحدّ:

الحلّ العملي عند الاقتراب من الحدّ: استبدل بعض آليات include بعناوين ip4 صريحة إن كانت ثابتة، أو استخدم تقنية «تسطيح SPF» (SPF Flattening) التي تحوّل الـinclude إلى قائمة IP مباشرة عبر أداة متخصّصة تحدّثها دوريًا. الأهمّ: لا تضف خدمات لا ترسل منها فعلًا، ونظّف سجلّك من بقايا خدمات قديمة.

بريد العمل الاحترافي من wpressly

بريد باسم نطاقك (name@yourdomain) مع إعداد SPF وDKIM وDMARC جاهز، حماية من السبام، ومساحة سخيّة ودعم عربي — انطباع احترافي في كل رسالة.

احصل على بريد العمل

ما هو DKIM وكيف يوقّع رسائلك؟

إذا كان SPF يجيب على «من أين أُرسلت الرسالة؟»، فإن DKIM يجيب على سؤال أعمق: «هل هذه الرسالة فعلًا من النطاق الذي يدّعي إرسالها، وهل وصلت كما أُرسلت دون تعديل؟». DKIM اختصار لـ DomainKeys Identified Mail، ويعتمد على التشفير غير المتماثل (المفتاح العام والخاصّ) — نفس المبدأ الذي تقوم عليه شهادات SSL.

كيف يعمل التوقيع؟

لديك زوج مفاتيح: مفتاح خاصّ (Private Key) يبقى سرًّا على خادم البريد المُرسِل، ومفتاح عام (Public Key) تنشره علنًا في DNS. حين يرسل خادمك رسالة، يأخذ أجزاء محدّدة منها (ترويسات مختارة مثل From وSubject ومتن الرسالة)، يحسب منها «بصمة» مشفّرة، ثم يوقّعها بالمفتاح الخاصّ ويضيف التوقيع إلى ترويسة الرسالة باسم DKIM-Signature.

عند الاستلام، يقرأ الخادم المستقبِل هذه الترويسة، يستخرج منها اسم المحدّد (Selector) واسم النطاق، ثم يستعلم في DNS عن المفتاح العام المنشور تحت selector._domainkey.example.com. باستخدام المفتاح العام، يتحقّق من أن التوقيع صحيح. إن نجح التحقّق، فهذا يثبت أمرين: أن الرسالة وُقِّعت بالمفتاح الخاصّ المقابل (أي صادرة عن جهة تملك الخادم)، وأن محتواها لم يتغيّر منذ التوقيع. لو عبث أحدهم بكلمة واحدة في المتن أثناء الطريق، يفشل التحقّق فورًا.

المُحدِّد (Selector) ولماذا هو مهمّ

«المُحدِّد» هو اسم اختياري تختاره أنت (أو تختاره خدمة الإرسال) ليتيح وجود عدّة مفاتيح DKIM للنطاق نفسه. هذا مفيد لأن لكل خدمة إرسال مفتاحها: Google قد تستخدم محدّدًا مثل google، وMailchimp تستخدم محدّدًا آخر، وخادمك الخاصّ ثالثًا. فبدل أن يتزاحم الجميع على اسم واحد، يضع كلٌّ مفتاحه تحت محدّده الخاصّ، ويذكر اسم المحدّد داخل توقيع كل رسالة فيعرف المستقبِل أين يبحث.

سجلّ DKIM في DNS يبدو هكذا (المفتاح العام طويل عادةً، وقد قُصِّر هنا للتوضيح):

mail._domainkey.example.com.   IN   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7n2x...IDAQAB"

أما داخل الرسالة نفسها، فتبدو ترويسة التوقيع شيئًا كهذا:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=mail; h=from:subject:date:to; bh=...; b=...

الجدول التالي يشرح أهمّ الوسوم في سجلّ DKIM المنشور في DNS:

نصيحة الخبير: استخدم مفاتيح بطول 2048 بِت متى أمكن بدل 1024 لأمان أقوى. وانتبه أن بعض لوحات DNS تقتصّ السلسلة الطويلة للمفتاح، فإن لاحظت أن DKIM يفشل رغم صحّة كل شيء، تحقّق من أن المفتاح العام كامل وغير مقطوع. الأمر الجيّد في DKIM أنه — على عكس SPF — يصمد عبر إعادة التوجيه (Forwarding) في كثير من الحالات، لأن التوقيع مرتبط بالمحتوى لا بعنوان IP المُرسِل.

ما هو DMARC وكيف يربط كل شيء؟

وصلنا الآن إلى قطعة الأحجية الأخيرة. لديك SPF يفحص الخادم المُرسِل، وDKIM يتحقّق من التوقيع — لكن من يقرّر ماذا يحدث إن فشل أحدهما؟ ومن يحمي العنوان المرئي From الذي يراه المستخدم فعلًا؟ هنا يأتي DMARC اختصار Domain-based Message Authentication, Reporting and Conformance. وظيفته ثلاثية: يربط نتائج SPF وDKIM بالعنوان المرئي عبر مفهوم «المحاذاة»، ويملي على المستقبِل سياسة التعامل مع الفشل، ويرسل لك تقارير دورية عن كل ما يجري.

المحاذاة (Alignment): جوهر DMARC

هذا أهمّ مفهوم في الموضوع كلّه. لكي ينجح DMARC، لا يكفي أن ينجح SPF أو DKIM فحسب، بل يجب أن يكون النطاق الذي نجح فيه محاذيًا للنطاق الظاهر في خانة From المرئية. تذكّر أن SPF يفحص نطاق Return-Path، وأن المهاجم قد يجعله مختلفًا عن From. المحاذاة تسدّ هذه الثغرة:

• محاذاة SPF (aspf): يجب أن يتطابق نطاق Return-Path (الذي نجح فيه SPF) مع نطاق From المرئي.
• محاذاة DKIM (adkim): يجب أن يتطابق النطاق الموقِّع في DKIM (الوسم d=) مع نطاق From المرئي.

ينجح DMARC إذا تحقّقت محاذاة واحدة على الأقلّ (SPF أو DKIM). أما درجة الصرامة فتُضبط بوسمي aspf وadkim: القيمة r (Relaxed) تقبل تطابق النطاق الأساسي والنطاقات الفرعية، والقيمة s (Strict) تتطلّب تطابقًا تامًّا. هذا المفهوم بالضبط هو ما يجعل DMARC قادرًا على إيقاف انتحال نطاقك بينما عجز SPF وDKIM منفردين عن ذلك.

صيغة سجلّ DMARC

سجلّ DMARC نموذجي ومتدرّج يبدو هكذا:

_dmarc.example.com.   IN   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1; adkim=s; aspf=s; pct=100"

الجدول التالي يشرح أهمّ وسوم DMARC وما يفعله كلّ منها:

السياسات الثلاث: none و quarantine و reject

الوسم p هو قلب DMARC، ويأخذ ثلاث قيم تمثّل مستويات تشديد متصاعدة. اختيار القيمة الخاطئة في الوقت الخاطئ قد يُسقِط بريدك الشرعي، لذا فهم الفرق ضروري:

التقارير: rua و ruf

ميزة DMARC الفريدة أنه يعيد إليك رؤية كاملة لما يجري. الوسم rua يحدّد عنوانًا يستقبل التقارير الإجمالية (Aggregate Reports): ملفّات XML دورية (عادةً يومية) من مزوّدي البريد تلخّص كم رسالة وصلت باسم نطاقك، من أيّ عناوين IP، وكم منها نجح أو فشل في SPF وDKIM والمحاذاة. هذه التقارير هي عينك على نطاقك: بها تكتشف خوادم شرعية نسيت إضافتها، وتكتشف من يحاول انتحال نطاقك.

أما الوسم ruf فيستقبل التقارير الجنائية (Forensic/Failure Reports): نسخ شبه فورية عن الرسائل الفاشلة بتفاصيل أكثر. عمليًا، كثير من المزوّدين لا يرسلون تقارير ruf حفاظًا على الخصوصية، لذا اعتمد أساسًا على rua. وبما أن تقارير rua تأتي بصيغة XML خام يصعب قراءتها يدويًا، يُنصح باستخدام خدمة تجميع وتحليل DMARC تحوّلها إلى لوحات مفهومة.

بريد العمل الاحترافي من wpressly

بريد باسم نطاقك (name@yourdomain) مع إعداد SPF وDKIM وDMARC جاهز، حماية من السبام، ومساحة سخيّة ودعم عربي — انطباع احترافي في كل رسالة.

احصل على بريد العمل

الترتيب الصحيح للإعداد واستراتيجية التشديد التدريجي

أكثر الأخطاء كلفةً هو القفز مباشرة إلى p=reject قبل التأكّد من أن كل مصادر بريدك الشرعية تمرّ المصادقة — فتُرفض فواتيرك ورسائلك التسويقية ويختفي بريدك دون إنذار. الطريق الآمن تدريجي ومنهجي. إليك الترتيب الموصى به:

1. جهّز SPF أولًا: اجمع كل الخوادم والخدمات التي ترسل باسمك (خادم بريدك، أداة التسويق، نظام الفوترة، نظام الدعم)، واكتب سجلّ SPF واحدًا يشملها كلّها بمؤهِّل ~all مؤقّتًا.
2. فعّل DKIM لكل خدمة إرسال: لكل خدمة، أنشئ زوج مفاتيح وانشر المفتاح العام تحت محدّدها الخاصّ، وتأكّد أن الخدمة توقّع رسائلها فعلًا.
3. انشر DMARC بسياسة p=none: ابدأ بالمراقبة فقط مع rua لجمع التقارير، دون أيّ تأثير على التسليم.
4. حلّل التقارير لأسابيع: راقب حتى ترى أن كل مصادرك الشرعية تنجح في المحاذاة، واكتشف ما فاتك.
5. شدّد تدريجيًا: انتقل إلى quarantine مع pct منخفض، ثم ارفع النسبة، ثم انتقل إلى reject.

الوسم pct أداتك الذهبية في التشديد التدريجي: بدل أن تطبّق السياسة على 100% من البريد دفعة واحدة، طبّقها على نسبة صغيرة وراقب الأثر. الجدول التالي يقترح مراحل واقعية للانتقال من المراقبة إلى الحماية الكاملة:

لا تتعجّل بين المراحل. لكل مرحلة، انتظر حتى تستقرّ التقارير ولا تُظهر أي مصدر شرعي يفشل. وإن كانت لديك نطاقات فرعية، استخدم وسم sp لتطبيق سياسة منفصلة عليها. القاعدة العامة: الوصول إلى p=reject قد يستغرق من أسابيع إلى أشهر حسب تعقيد بنيتك، وهذا طبيعي وصحّي.

الأخطاء الشائعة وكيف تصلحها

بعد آلاف عمليات الإعداد، تتكرّر الأخطاء نفسها. معرفتها مسبقًا توفّر عليك ساعات من التشخيص. الجدول التالي يجمع أكثرها انتشارًا مع الحلّ المباشر لكلّ منها:

خطأ تعدّد سجلّات SPF يستحقّ توضيحًا خاصًّا لأنه الأكثر شيوعًا. المواصفة تنصّ على وجود سجلّ SPF واحد فقط لكل نطاق. لو أضفت Google فأنشأت سجلًّا، ثم أضفت أداة تسويق فأنشأت سجلًّا ثانيًا، يصبح لديك سجلّان يبدآن بـ v=spf1 — وهذا غير صالح، فيفشل التقييم. الحلّ أن تدمجهما في سطر واحد:

example.com.   IN   TXT   "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

خطأ متكرّر آخر هو الخلط بين المؤهِّلات وتوقّع أن ~all يوفّر حماية صارمة — وهو لا يفعل، فهو مجرّد «تساهل». لتفهم كيف ترتبط هذه الإعدادات بوصول بريدك إلى الوارد عمومًا، راجع دليل لماذا يذهب بريدك للسبام الذي يغطّي العوامل الأخرى خارج المصادقة مثل السمعة والمحتوى.

التحقّق والاختبار

لا تثق أبدًا بأن السجلّ يعمل لمجرّد أنك حفظته في لوحة DNS. تذكّر أن أي تغيير في DNS يحتاج وقتًا للانتشار حسب الـTTL، وقد تكون لوحتك تعرض شيئًا مختلفًا عمّا انتشر فعلًا. التحقّق العملي يتمّ من جهتين: قراءة السجلّ المنشور مباشرة من DNS، ثم إرسال رسالة اختبار وفحص نتيجة المصادقة فيها.

الفحص من سطر الأوامر

أسرع طريقة لقراءة السجلّ المنشور هي أداة dig. لقراءة سجلّ SPF:

dig TXT example.com +short

ولقراءة سجلّ DKIM (مع استبدال mail بمحدّدك الفعلي):

dig TXT mail._domainkey.example.com +short

ولقراءة سجلّ DMARC:

dig TXT _dmarc.example.com +short

على ويندوز، البديل المكافئ هو nslookup:

nslookup -type=TXT _dmarc.example.com

إن لم يُرجِع الأمر السجلّ الذي تتوقّعه، فإمّا أنه لم ينتشر بعد، أو أنه في الاسم الخطأ، أو أن لوحة DNS أضافت اقتباسات أو فراغات غير متوقّعة. قارن دائمًا ما يخرج من dig بما كتبته بالحرف.

أدوات الفحص والتقارير

إلى جانب سطر الأوامر، هناك أدوات وخدمات تختبر الإعداد كاملًا وتقرأ التقارير نيابة عنك. الجدول التالي يلخّص أنواعها:

الطريقة الأبسط والأوثق للتأكّد أن المصادقة تعمل من البداية للنهاية: أرسل رسالة من نطاقك إلى حسابك على Gmail، افتحها، اختر «إظهار الأصل» (Show original)، وستجد ملخّصًا واضحًا يقول SPF: PASS وDKIM: PASS وDMARC: PASS. إن رأيت PASS في الثلاثة مع محاذاة سليمة، فأنت في المسار الصحيح. وإن رأيت FAIL أو SOFTFAIL، فاقرأ التفاصيل لتعرف أيّ طبقة تحتاج إصلاحًا.

SPF وDKIM وDMARC في لمحة واحدة

بعد كل هذا التفصيل، من المفيد أن تجمع الصورة الكبرى في جدول واحد يوضّح كيف تتكامل الطبقات الثلاث ولماذا تحتاجها مجتمعة لا منفردة:

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

بريد العمل الاحترافي من wpressly

بريد باسم نطاقك (name@yourdomain) مع إعداد SPF وDKIM وDMARC جاهز، حماية من السبام، ومساحة سخيّة ودعم عربي — انطباع احترافي في كل رسالة.

احصل على بريد العمل

الأسئلة الشائعة

هل أحتاج السجلّات الثلاثة معًا أم يكفي واحد؟ تحتاجها مجتمعة. SPF يحدّد الخوادم المسموح بها لكنه يفحص Return-Path لا العنوان المرئي، وDKIM يوقّع المحتوى لكنه لا يملي سياسة عند الفشل، وDMARC يربط الاثنين عبر المحاذاة ويحمي العنوان المرئي ويرسل التقارير. الاكتفاء بواحد يترك ثغرة. مزوّدو البريد الكبار اليوم (Gmail، Yahoo) يطلبون الثلاثة فعليًا من المُرسِلين بكميات.

ما الفرق بين ~all و-all في SPF؟ كلاهما يخصّ العناوين غير المدرجة في قائمتك. ~all (SoftFail) يعني «اقبلها لكن علّمها كمشبوهة»، وهو مناسب أثناء الإعداد كي لا تُرفض رسائل شرعية لو نسيت خادمًا. -all (Fail) يعني «ارفضها بوضوح»، وهو الأقوى ويُستخدم بعد التأكّد من اكتمال قائمتك عبر تقارير DMARC. ابدأ بـ ~all وانتقل إلى -all لاحقًا.

لماذا فشل SPF بعد إضافة خدمة جديدة؟ على الأرجح تجاوزت حدّ 10 استعلامات DNS، أو أنشأت سجلّ SPF ثانيًا بالخطأ. كل include يستهلك من الحدّ، وكل خدمة قد تستورد سجلّات داخلية إضافية. الحلّ: ادمج كل شيء في سجلّ TXT واحد، وقلّل عدد الـinclude، واستبدل بعضها بعناوين ip4 صريحة أو استخدم تسطيح SPF.

هل المحاذاة (Alignment) ضرورية لنجاح DMARC؟ نعم، وهي جوهر DMARC. لا يكفي أن ينجح SPF أو DKIM، بل يجب أن يكون النطاق الذي نجح فيه محاذيًا لنطاق From المرئي. ينجح DMARC إذا تحقّقت محاذاة واحدة على الأقلّ. القيمة r (Relaxed) تقبل النطاقات الفرعية، وs (Strict) تتطلّب تطابقًا تامًّا. المحاذاة هي ما يوقف انتحال نطاقك بينما عجز SPF وDKIM منفردين.

متى أنتقل إلى p=reject؟ فقط بعد أن تُظهر تقارير DMARC على مدى أسابيع أن كل مصادر بريدك الشرعية تمرّ المحاذاة بنجاح. ابدأ بـ p=none للمراقبة، ثم quarantine مع pct منخفض ترفعه تدريجيًا، ثم reject جزئيًا فكاملًا. التعجّل يُسقِط بريدك الشرعي. الوصول إلى reject قد يأخذ أسابيع إلى أشهر، وهذا طبيعي.

لماذا يفشل بريدي بعد إعادة توجيهه (Forwarding)؟ لأن SPF يفشل غالبًا عند إعادة التوجيه — الخادم المُعيد للتوجيه ليس في قائمتك البيضاء. لحسن الحظّ، DKIM يصمد عادةً عبر إعادة التوجيه لأن توقيعه مرتبط بالمحتوى لا بعنوان IP. لهذا تحديدًا يهمّ وجود DKIM إلى جانب SPF: حين يفشل SPF بعد التوجيه، تنقذ المحاذاة عبر DKIM نجاح DMARC.

هل يحميني DMARC من كل أنواع التصيّد؟ يحميك من انتحال نطاقك بالضبط (Exact-domain spoofing) — أي استخدام نطاقك في خانة From. لكنه لا يمنع «النطاقات المتشابهة» (مثل examp1e.com بدل example.com) لأنها نطاقات أخرى لا تملكها. لذا اجمع DMARC مع وعي المستخدمين ومراقبة النطاقات المتشابهة وتسجيلها استباقيًا متى أمكن.

كم يستغرق ظهور تغييرات هذه السجلّات؟ تخضع لانتشار DNS العادي حسب الـTTL، وعادةً من دقائق إلى بضع ساعات. لا تحكم على النتيجة فورًا بعد الحفظ؛ تحقّق بأمر dig أو nslookup أن السجلّ المنشور يطابق ما كتبته. أما تقارير DMARC الإجمالية فتأتي يوميًا تقريبًا، لذا امنح نفسك أيامًا قبل تقييم الصورة الكاملة.