سجل TXT سجلّ DNS يخزّن نصًّا حرًّا مرتبطًا بنطاقك. تقرؤه الخدمات لإثبات ملكيتك للنطاق، وأهمّ استعمالاته اليوم مصادقة البريد: تُكتب SPF وDKIM وDMARC جميعها كسجلّات TXT.

سجلّات DNS اللازمة لبريد العمل حول النطاق: سجلّ MX يوجّه البريد لخادم المزوّد، وسجلّات TXT (SPF وDKIM وDMARC) تثبت أن الرسائل منك فلا تُرفض أو تذهب للسبام.سجلّات DNS التي يحتاجها بريد العملنطاقك (yourdomain)MXيوجّه البريدلخادم المزوّدSPFيحدّد خوادمالإرسال المخوّلةDKIMتوقيع رقمييثبت سلامة الرسالةDMARCسياسة التعاملمع فشل الفحصMX يستقبل البريد، وSPF/DKIM/DMARC تثبت أنّه منك فلا يُرفض أو يذهب للسبامتُضاف كلّها في إدارة DNS لنطاقك بعد تفعيل البريد عند المزوّد
بريد العمل يحتاج سجلّ MX (يوجّه البريد لخادم المزوّد) + ثلاثة سجلّات TXT للمصادقة: SPF (خوادم الإرسال المخوّلة)، DKIM (توقيع رقمي)، DMARC (سياسة الفشل).

نقاط أساسية

  • يحمل نصًّا عامًّا؛ لا يوجّه مرورًا بنفسه بل يحمل معلومات تقرؤها الخدمات.
  • استعمالات شائعة: التحقّق من الملكية (Google/Bing)، SPF (خوادم الإرسال)، DKIM (مفتاح التوقيع)، DMARC (سياسة الفشل).
  • يمكن وجود عدّة سجلّات TXT للنطاق، لكن سجل SPF واحد فقط لكل نطاق.
  • التغيير يخضع لـTTL وانتشار DNS. لتفاصيل مصادقة البريد راجع سجلّات SPF وDKIM وDMARC.
الاستخداممثال للقيمة
التحقّق من الملكيةgoogle-site-verification=...
SPFv=spf1 include:_spf.example.com ~all
DMARCv=DMARC1; p=quarantine; rua=mailto:...

كيف يعمل سجل TXT

في الأصل صُمِّم سجل TXT ليُتيح ربط نصّ حرّ بالنطاق دون أن يفرض تنسيقًا معيّنًا، لذلك صار وعاءً مرنًا تستعمله الخدمات لكتابة قيم تقرؤها برمجيًّا. هو لا يوجِّه أيّ مرور بنفسه ولا يخبر المتصفّح بمكان خادمك؛ بل يكتفي بحمل سلسلة نصّية تستعلم عنها جهة خارجية ثمّ تتصرّف بناءً عليها. عندما تطلب منك خدمة ما إثبات أنّك تملك النطاق، تعطيك قيمة فريدة تضعها في سجل TXT، ثمّ تستعلم عن النطاق وتتحقّق من وجود تلك القيمة بالضبط؛ هذا أساس التحقّق من ملكية النطاق في أدوات مثل Google Search Console وBing وغيرها.

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

أخطاء شائعة

أكثر خطأ يتكرّر هو تعدّد سجلّات SPF على نطاق واحد. القاعدة صريحة: يُسمَح بعدّة سجلّات TXT لأغراض مختلفة، لكن يجب ألّا يوجد إلّا سجل SPF واحد فقط لكل نطاق. عند وجود سجلَّيْن يبدآن بـ v=spf1 تعدّه كثير من الخوادم نتيجة غير صالحة (PermError)، فيسقط التحقّق كلّه ويتضرّر تسليم بريدك. الحلّ هو دمج كلّ مصادر الإرسال في سجل واحد عبر عدّة عبارات include: بدل إنشاء سجلّات منفصلة. خطأ آخر متعلّق بـطول القيمة: السلسلة الواحدة داخل TXT لا تتجاوز 255 محرفًا، فإذا كان مفتاح DKIM أطول وجب تقسيمه إلى عدّة مقاطع موضوعة بين علامتي اقتباس متتاليتين، ويتولّى الخادم تجميعها. وانتبه أيضًا إلى علامات الاقتباس الزائدة التي تضيفها بعض اللوحات تلقائيًّا فتُفسد القيمة.

كيف تتحقّق والانتشار

للتحقّق من سجلّات TXT لنطاق استعمل أداة dig بهذا الشكل:

dig TXT example.com +short
dig TXT _dmarc.example.com +short

ستظهر لك القيم النصّية الحالية كما تراها الخوادم في العالم. تذكّر أنّ أيّ تعديل لا يسري فورًا في كلّ مكان؛ فقيمة TTL المرتبطة بالسجل تحدّد كم تبقى النسخة القديمة مخزّنة مؤقتًا (cache) لدى محلِّلات DNS قبل أن تُجلَب القيمة الجديدة، وهذا ما نسمّيه الانتشار. لذا إن عدّلت سجل SPF أو DKIM فلا تتعجّب من بقاء السلوك القديم ساعاتٍ بحسب الـTTL، ويُستحسن خفض الـTTL قبل التغييرات الكبيرة ثمّ رفعه بعد استقرار القيم.