الأدلةالمصادقة

No DMARC record found: السطر الوحيد الذي ينقص نطاقك

ليس لنطاقك سجل DMARC بعد. إليك السطر الذي تضيفه، وأين يوضع في DNS، وما الذي يتغير في بريدك بعد إضافته. رُوجع على RFC 9989 وقواعد المرسلين لدى Gmail وYahoo وOutlook.com.

آخر تحديث: 5 أكتوبر 2026مدة القراءة بالدقائق: 10

باختصار

الرسالة تعني أنه لا يوجد سجل TXT عند _dmarc.yourdomain.com. خادم بريدك ليس معطّلًا.
أضف سجل TXT واحدًا بالمضيف _dmarc والقيمة v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. مع p=none يبقى التسليم كما كان تمامًا.
Gmail وYahoo وOutlook.com تشترط السجل على المرسلين بكميات كبيرة فقط. أضفه على أي حال: Google تحتسب النطاق كله ولا ترفع صفة المرسل بكميات كبيرة أبدًا، والتقارير لا تبدأ إلا بعد وجود سجل.
إذا ظلت أداة الفحص لا تجد شيئًا، فابحث عن مزود DNS خاطئ، أو اسم مضيف مكرر، أو سجلَّي DMARC. السجلان يلغي أحدهما الآخر.
تغيّر المعيار في مايو 2026 مع RFC 9989: الوسم pct أُزيل، والوسمان t وnp جديدان. ومساعدة Google ما زالت تصف pct حتى أكتوبر 2026.

«No DMARC record found» (لم يُعثر على سجل DMARC) تعني أن أداة فحص طلبت من DNS سجل TXT عند _dmarc.yourdomain.com ولم تتلقَّ شيئًا. لا شيء معطّل في خادم بريدك. الإصلاح سجل TXT واحد بالمضيف _dmarc والقيمة v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. مع p=none يُسلَّم بريدك كما كان تمامًا. أنت فقط تخبر المستقبِلين بأنك تشارك، وتبدأ في تلقي التقارير.

DMARC هو ثالث سجلات البريد الثلاثة، بجانب SPF وDKIM. SPF يعدّد الخوادم التي يحق لها الإرسال باسم نطاقك. DKIM يوقّع كل رسالة. وDMARC يخبر المستقبِل بما يفعله حين لا يشهد أي من الاثنين للنطاق الذي في عنوان From، وإلى أين يرسل ملخصًا يوميًا. ومنذ مايو 2026 يعرّفه RFC 9989، الذي حل محل RFC 7489 الأقدم. أدلة كثيرة ما زالت تصف النسخة الأقدم، وكذلك صفحة المساعدة لدى Google حتى أكتوبر 2026.

السجل الذي تضيفه

سجّل الدخول حيث يُدار DNS نطاقك. وهي الشركة التي تشير إليها خوادم الأسماء (nameservers) لنطاقك، وليست دائمًا الشركة التي اشتريت منها النطاق. أضف سجلًا جديدًا بهذه القيم:

الحقل	ما تدخله
النوع (Type)	`TXT`
المضيف أو الاسم (Host أو Name)	`_dmarc`
القيمة أو المحتوى (Value أو Content)	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`
TTL	اترك القيمة الافتراضية

وإذا كُتب سطرًا في ملف منطقة (zone file)، يبدو السجل الجاهز هكذا:

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

ضع نطاقك مكان example.com. وهذا ما تفعله الأجزاء الثلاثة:

v=DMARC1 يعلّم السطر كسجل DMARC. يجب أن يأتي أولًا، مع DMARC1 بأحرف كبيرة. وإلا تجاهل المستقبِلون السجل كله.
p=none هو السياسة: عاملوا بريدي كما كنتم ستعاملونه على أي حال. لا شيء يُحظر أو يُنقل إلى البريد المزعج بسبب هذا السجل.
rua=mailto:… هو عنوان التقارير اليومية. أنشئ ذلك العنوان، أو عنوانًا بديلًا يعيد التوجيه إليك، قبل نشر السجل.

تذكر Google الحقول الثلاثة نفسها في Set up DMARC (إعداد DMARC). وتطلب أيضًا أن يكون SPF وDKIM يعملان منذ 48 ساعة قبل إضافة DMARC. وإذا كانت أداة الفحص تشير إلى هذين أيضًا، فأصلحهما أولًا.

كيف تتحقق من أنه نجح

اسأل DNS بنفسك. في macOS أو Linux، افتح الطرفية واستخدم dig. وفي Windows، استخدم nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

إذا كان السجل فعّالًا، يعود السطر بين علامتَي اقتباس. وهذا ما أجاب به نطاق Google نفسه في 5 أكتوبر 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

الجواب الفارغ يعني أن السجل ليس موجودًا بعد، أو ليس حيث يبحث عنه المستقبِلون. وحين يُظهر استعلامك السطر، شغّل من جديد أداة الفحص التي أعطتك الرسالة. MXToolbox مثلًا تصوغ المشكلة هكذا: «No DMARC Record found»، وتشرح أن «نطاقك ليس له سجل DMARC منشور».

ماذا يعني كل جزء من سجل DMARC

السجل قائمة من أزواج tag=value تفصل بينها فواصل منقوطة. الوسم v وحده إلزامي في المعيار، ويجب أن يكون أولًا. ضع p ثانيًا: تنص مساعدة Google على أنه «يجب إدراج الوسمين v وp أولًا»، والمعيار الأقدم كان يتوقع الترتيب نفسه. وهذه وسوم RFC 9989، القسم 4.7:

الوسم	ما يقوله	إذا تركته
`v=DMARC1`	هذا سجل DMARC.	يُتجاهل السجل.
`p`	ما يُفعل بالبريد الذي يفشل: `none` أو `quarantine` أو `reject`.	يُعامل كأنه `none` إذا وُجد `rua` صالح. وإلا لا يُطبَّق السجل. اضبطه دائمًا.
`rua`	إلى أين تذهب التقارير المجمّعة اليومية. وتُفصل العناوين المتعددة بفواصل.	لا تُرسل تقارير.
`sp`	سياسة مستقلة للنطاقات الفرعية الموجودة، مثل `news.example.com`.	تحصل النطاقات الفرعية على السياسة التي في `p`.
`np`	سياسة مستقلة للنطاقات الفرعية غير الموجودة. أُضيف مع RFC 9989.	تحصل على `sp`، وإلا على `p`.
`adkim` و`aspf`	مدى التطابق المطلوب بين نطاقَي DKIM وSPF ونطاق From لديك: `r` للمتساهل و`s` للصارم.	متساهل.
`t`	`t=y` يعلّم سياسة أشد كاختبار: يُطلب من المستقبِلين تطبيق مستوى أدنى بدرجة. أُضيف مع RFC 9989.	`t=n`، أي أن السياسة مقصودة كما كُتبت.
`ruf` و`fo`	تقارير عن رسائل فاشلة بعينها.	لا يُرسل شيء منها. Gmail لا يدعم `ruf`، و لا تخطط لإرسال تقارير كهذه.

السجلات الأقدم تنتهي كثيرًا بالوسم pct=100. كان الغرض منه تطبيق السياسة على نسبة من البريد الفاشل. أزاله RFC 9989، مع rf وri، ويذكر السبب:

أظهرت الخبرة العملية أن الوسم «pct» لم يكن يُطبَّق بدقة في العادة، إلا إذا كانت القيمة المحددة 0 أو 100 (الافتراضية)، وأن عدم الدقة مع القيم الأخرى كان يتفاوت كثيرًا من تطبيق إلى آخر.

على المستقبِلين أن يتجاهلوا الوسوم التي لا يعرفونها، فوجود pct=100 قديم لا يضر. وسجلا yahoo.com وmicrosoft.com كانا ما زالا يحملانه في 5 أكتوبر 2026، وصفحة المساعدة لدى Google ما زالت توصي بالوسم pct للتطبيق التدريجي. أما في سجل جديد فاتركه.

هل تحتاج إلى DMARC إذا كنت ترسل بضع رسائل يوميًا فقط؟

بحسب القواعد المنشورة لدى كبار مزودي البريد، سجل DMARC مطلوب حين ترسل بكميات كبيرة. ودون ذلك هو توصية.

المستقبِل	كل مرسل	المرسلون بكميات كبيرة
Gmail، الحسابات الشخصية	SPF أو DKIM	من 5,000 رسالة يوميًا: SPF وDKIM وسجل DMARC. والسياسة «يمكن ضبطها على none». ويجب أن يطابق نطاق From نطاق SPF أو نطاق DKIM.
Yahoo	«طبّق SPF أو DKIM على الأقل»	SPF وDKIM، مع «سياسة DMARC صالحة لا تقل عن ». صفحة Yahoo لا تعطي رقمًا لمعنى «بكميات كبيرة».
Outlook.com	لا متطلب مذكور	النطاقات التي ترسل أكثر من 5,000 رسالة يوميًا: SPF وDKIM وDMARC بسياسة لا تقل عن `p=none`.

المصادر هي إرشادات مرسلي البريد الإلكتروني لدى Google، وSender Best Practices لدى Yahoo، وإعلان Microsoft لكبار المرسلين، كلها حتى أكتوبر 2026. إذا كنت ترسل ثلاثين رسالة يوميًا من صندوق بريد واحد، فلا أحد منهم يشترط السجل. ومع ذلك هناك ثلاثة أسباب لإضافته الآن.

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

وللمرسلين بكميات كبيرة عواقب لغياب السجل. أسئلة المرسلين الشائعة لدى Google تذكر له الخطأ المؤقت 4.7.31: «النطاق المرسِل ليس له سجل DMARC، أو سجل DMARC لا يحدد سياسة DMARC». وتقول الصفحة نفسها إن البريد الذي لا يستوفي المتطلبات يواجه منذ نوفمبر 2025 «حالات رفض مؤقتة ودائمة».

أضفت السجل وأداة الفحص ما زالت لا تجد شيئًا؟

إذن فالسبب في العادة واحد من هذه. راجعها باستعلام dig المذكور أعلاه.

عدّلت DNS في المكان الخطأ. إذا كانت خوادم الأسماء لديك عند شركة غير مسجّل النطاق، فالسجلات المُدخلة عند المسجّل لا يُستعلم عنها أبدًا. الأمر dig +short NS example.com يبيّن من يجيب عن نطاقك.
المضيف خاطئ. السجل موضوع على example.com نفسه، أو على اسم مكرر كما وُصف أعلاه. والمستقبِلون لا يطلبون إلا _dmarc.example.com.
يوجد سجلا DMARC. المعيار صارم هنا: «إذا أُعيدت عدة سجلات لسياسة DMARC لهدف واحد، فإنها تُهمل كلها». ادمجهما في سجل واحد. وعنوانا التقارير يوضعان في rua واحد، تفصل بينهما فاصلة.
الوسم الأول ليس v=DMARC1 بالضبط. الأحرف الصغيرة، أو خطأ مثل DMARC 1، أو وجود p= قبله، كلها تجعل السجل غير صالح.
نوع السجل ليس TXT، أو أُلصقت القيمة بعلامات اقتباس مائلة من مستند. اكتب القيمة نصًا عاديًا، دون علامات اقتباس إلا إذا طلبتها مساعدة مزود DNS لديك.
جواب قديم ما زال مخزّنًا مؤقتًا. المحلِّلات (resolvers) تتذكر «لا يوجد سجل كهذا» مدة من الوقت. اسأل أحد خوادم الأسماء لديك مباشرة بإضافة اسمه إلى الاستعلام، مثل dig +short TXT _dmarc.example.com @ns1.example.net. فإن ظهر السجل هناك، فأدوات الفحص ستتبعه.

أين تذهب التقارير، وماذا تفعل بها

كل مستقبِل تلقى بريدًا يحمل نطاقك في سطر From يرسل تقريرًا إلى عنوان rua. وبحسب صفحة Google About DMARC reports (عن تقارير DMARC)، فهي «تُرسل عادة مرة واحدة يوميًا بالبريد الإلكتروني». التقرير ملف XML، مضغوط في العادة، مرفق برسالة. وRFC 9990 يصف التنسيق.

ثلاثة نوارس تحمل لفافات ورقية صغيرة إلى حامل رسائل خشبي على جدار مكتب في الميناء — كل مستقبِل تلقى بريدًا باسمك يرسل تقريرًا قصيرًا واحدًا يوميًا إلى العنوان الذي في `rua`.

تحذّر Google من أن المؤسسات الكبيرة «قد تتلقى مئات أو حتى آلاف التقارير يوميًا» وتوصي بمجموعة أو صندوق بريد مخصص. العدد يتوقف على مقدار ما ترسله وإلى كم نطاق، فصندوق بريد أو اثنان ينتجان أقل من ذلك بكثير. ويكفي عنوان بديل مثل dmarc@ مع فلتر إلى مجلد خاص به.

ينبغي أن يكون العنوان على نطاق السجل نفسه. وإن أردت التقارير في مكان آخر، فعلى النطاق الآخر أن يوافق بنشر سجل من عنده. ومن دونه يجب على المستقبِلين تجاهل العنوان (RFC 9990، القسم 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

ولهذا لا يصلح عنوان Gmail مجاني عنوانًا للتقارير: gmail.com لم يكن ينشر سجلًا كهذا حين تحققنا في 5 أكتوبر 2026.

في الملف، كل كتلة record تمثل خادمًا مرسِلًا واحدًا: عنوان IP الخاص به، وعدد الرسائل، وتحت policy_evaluated هل نجح DKIM وSPF لنطاقك. أنت تبحث عن أمرين. الخوادم التي تعرفها وتُظهر fail تحتاج إلى إصلاح، ودليل فشل DMARC مع نجاح SPF وDKIM يشرح الطريقة. والخوادم التي لا تعرفها إما أداة نسيتها أو شخص يستخدم اسمك.

بعد : متى تشدّد السياسة

p=none وضع مراقبة. يستوفي الحد الأدنى الذي يطلبه مزودو البريد، ولا يمنع أحدًا من تزوير عنوانك. لا يفعل ذلك إلا p=quarantine، الذي يطلب من المستقبِلين معاملة البريد الفاشل كمشبوه، وp=reject، الذي يطلب منهم رفضه.

قبل أن تشدّد، يجب أن ينجح كل مصدر مشروع لبريدك. يقول RFC 9989 إن مثل هذه الثغرات «يجب أن تُعالج قبل أي محاولة» للتطبيق، وإنه بحسب وتيرة إرسالك «قد يستغرق الأمر شهورًا كثيرة» من التقارير للتأكد. وصفحة التطبيق التدريجي لدى Google ترى أن أسبوعًا واحدًا من التقارير «يكفي عادة». مع صندوق بريد واحد وأداة أو أداتين أنت أقرب إلى رقم Google، لكن أمهل الأمر بضعة أسابيع ليظهر أيضًا إصدار الفواتير الشهري ونموذج الاتصال.

وفي الخطوة نفسها يختلف المصدران. Google ما زالت تقترح p=quarantine; pct=5 ثم رفع الرقم. والمعيار أسقط pct ويقدّم هذا بدلًا منه:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y يطلب من المستقبِلين معاملة حالات الفشل بمستوى أدنى بدرجة في الوقت الحالي، أي كأنها none. وحين تبقى التقارير نظيفة، احذف t=y. وانتبه إلى أن المستقبِل الذي لا يعرف الوسم يتجاهله ويطبّق quarantine كاملًا، وأن صفحات Google لا تذكر t حتى أكتوبر 2026. وإن كانت سياسة أشد ستصيب بريدًا لا تستطيع إصلاحه بعد، فابقَ على p=none.

أين يأتي دور WarmupBay

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

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

أسئلة شائعة

هل يشمل سجل DMARC على example.com النطاقات الفرعية أيضًا، مثل news.example.com؟

نعم. يطلب المستقبِل أولًا سجلًا عند _dmarc.news.example.com. وإن لم يوجد، يرجع إلى سجل النطاق التنظيمي، example.com. والسياسة المطبّقة على النطاق الفرعي هي التي في sp إن ضبطتها، وإلا فالتي في p.

هل أستطيع نشر v=DMARC1; p=none دون عنوان rua؟

نعم. هذا سجل صالح، ويُعد سياسة منشورة. لن تصلك تقارير، فلن ترى هل ينجح بريدك أنت ولا من غيرك يستخدم نطاقك. Yahoo تصف وجود عنوان rua يعمل بأنه موصى به بشدة، وGoogle توصي بتضمينه دائمًا.

هل أحتاج إلى سجل DMARC لنطاق ثانٍ أستخدمه للمراسلة فقط؟

نعم. يبحث المستقبِلون عن النطاق الوارد في عنوان From لكل رسالة، فالسجل على نطاقك الرئيسي لا يشمل نطاقًا آخر. استخدم السطر نفسه على النطاق الثاني. وإن أردت أن تذهب تقاريره إلى عنوان على نطاقك الرئيسي، فعلى النطاق الرئيسي أن ينشر سجل التفويض الموصوف تحت «أين تذهب التقارير».

ماذا ينبغي أن ينشر نطاق لا يرسل بريدًا أبدًا؟

الزوج الصارم. توصي M3AAWG بسجل SPF v=spf1 -all وبسجل DMARC فيه p=reject للنطاقات التي لا ترسل بريدًا أبدًا، حتى لا يستطيع أحد استخدامها في عنوان From. وفي DMARC هذا هو السطر v=DMARC1; p=reject عند _dmarc.

هل p=none أسوأ لبريدي من p=quarantine أو p=reject؟

قواعد المرسلين المنشورة لدى Gmail وYahoo وOutlook.com تطلب p=none على الأقل ولا شيء أشد. السياسة تحدد ما يحدث للبريد الذي يفشل في DMARC، ومنه البريد المزوّر باسمك. ميزة واحدة تحتاج إلى أكثر: BIMI، وهو الشعار بجانب رسائلك، يشترط quarantine أو reject بحسب مساعدة Google.