سجلات DNS المطلوبة: MX وSPF وDKIM وDMARC

للعمل على نطاقك، يبحث TrekMail عن أربعة سجلات DNS أساسية. انسخ القيم الدقيقة من لوحة التحكم إلى إعدادات مزود DNS. وإذا غاب سجل أو لم تتطابق قيمته، فسيعرض TrekMail ما يلزم تصحيحه.

إذا كان البريد الوارد للنطاق سيبقى لدى مزود آخر، وكنت تريد استخدام عناوينه في الإرسال فقط، فلا تغير سجل MX. راجع الإرسال من نطاق لا تستضيفه في TrekMail. عندما تختار هذا الوضع، تحذف لوحة التحكم MX تلقائيا من قائمة المتطلبات.

لمن أعد هذا الدليل؟

• لمسؤولي الأنظمة الذين يضبطون DNS.
• للمستخدمين الذين يعالجون مشكلات التسليم أو ظهور حالة DNS باللون الأحمر.

الركائز الأربع لنظام DNS الخاص بالبريد

1. سجل MX لاستقبال البريد

المضيف: @ أو جذر النطاق

القيمة: mail.trekmail.net.

الأولوية: 10

يوجه هذا السجل البريد الوارد إلى خوادمنا.

• خطأ شائع: إبقاء سجلات MX القديمة، مثل سجلات Google أو GoDaddy، بجانب سجل TrekMail. يؤدي ذلك إلى توزيع البريد بين عدة مزودين وقد تضيع بعض الرسائل. احذف جميع سجلات MX الأخرى.
• هل ستستخدم النطاق للإرسال فقط؟ اترك MX كما هو. افتح النطاق، واستخدم خيار البريد الوارد أسفل اسمه، ثم اختر إبقاء الاستقبال لدى المزود الحالي. ستطلب لوحة التحكم بعد ذلك SPF وDKIM وDMARC فقط، وتتوقف عن التحذير من سجل MX الذي عثرت عليه. يستطيع النطاق الإرسال، لكنه لا يستطيع استضافة صناديق بريد في TrekMail.

2. سجل SPF للمرسلين المصرح لهم

المضيف: @

عبارة include المطلوبة: include:spf.trekmail.net

SPF، أو Sender Policy Framework، هو قائمة بعناوين IP والخدمات المسموح لها بالإرسال باسم نطاقك.

• إذا لم يكن لديك SPF: أنشئ سجل TXT بالقيمة v=spf1 include:spf.trekmail.net -all.
• إذا كان لديك SPF: عدل السجل الحالي لإضافة عبارة include الخاصة بنا، واحتفظ بآلية النهاية المستخدمة حاليا.
  • خطأ: إنشاء سجلين منفصلين من نوع TXT.
  • صحيح: v=spf1 include:spf.google.com include:spf.trekmail.net -all.
  • صحيح أيضا: v=spf1 include:spf.google.com include:spf.trekmail.net ~all.

حول آلية النهاية: يقبل TrekMail كلا من -all و~all. المطلوب أن تظهر include:spf.trekmail.net قبل آلية النهاية التي تختارها. استخدم ~all مؤقتا بحذر ما دمت تحصر جميع خدمات الإرسال المشروعة. لا تنتقل إلى -all إلا بعد تضمينها جميعا في SPF. إعادة توجيه البريد مسألة مستقلة وقد تتسبب في فشل SPF مع أي من الخيارين، ولهذا تهم محاذاة DKIM. لا نقبل ?all ولا +all: تعامل ?all كما لو لم ينشر SPF، بينما تسمح +all للجميع بالإرسال.

ملاحظة حول فشل SPF: إذا أظهرت تقارير DMARC فشل SPF مع نجاح DKIM، فهذا أمر طبيعي في حالات كثيرة. غالبا ما تكون الرسالة قد أعيد توجيهها، مثل إعادة التوجيه التلقائي في Gmail، أو مرت عبر بوابة أمنية. ينبغي أن ينجح DMARC بفضل محاذاة DKIM. لا تحقق في الأمر إلا إذا فشل SPF وDKIM معا.

3. سجل DKIM للتوقيع الرقمي

المضيف: dkim._domainkey

القيمة: سلسلة طويلة وفريدة تبدأ بـv=DKIM1...

يتيح DKIM، أو DomainKeys Identified Mail، للخادم المستقبل التحقق من النطاق الذي وقع الرسالة ومن أجزائها المشمولة بالتوقيع.

• إنشاء المفتاح: إذا ظهرت عبارة «جار الإنشاء...» مكان القيمة، فانتظر حتى يظهر المفتاح في لوحة التحكم. بعد ذلك انشر المضيف والقيمة كما يظهران تماما، ثم شغل التحقق من DNS.
• التنسيق: يطلب بعض مزودي DNS، مثل Route 53، تقسيم القيمة إلى أجزاء بين علامات اقتباس. ويقبل معظمهم السلسلة كاملة. الصقها كما تظهر تماما.
• يوجد سجل بهذا الاسم بالفعل؟ هذا يعني أن خدمة أخرى توقع البريد لهذا النطاق أيضا. لا تستبدل السجل. راجع لوحة التحكم: إذا كان الاسم المعتاد مستخدما، ننشئ المفتاح بمحدد آخر وتعرض علامة DNS الاسم الدقيق المطلوب. ويمكن للمفتاحين العمل معا.
• هل تستخدم SMTP خارجيا؟ قد يطلب المزود الخارجي سجل DKIM خاصا به بمحدد مختلف. انشر أيضا السجل الذي يمنحك إياه. لا يجعل مفتاح TrekMail رسائل المزود الخارجي تجتاز DKIM.

4. سجل DMARC لتطبيق السياسة

المضيف: _dmarc

القيمة: v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

يجمع DMARC نتائج SPF وDKIM.

• السياسات (p):
  • none: للمراقبة فقط. ابدأ بها إذا كنت لا تزال تحصر جميع المرسلين المشروعين.
  • quarantine: تطلب من خوادم الاستلام اعتبار الرسائل الفاشلة مشبوهة. وهي قالب TrekMail الافتراضي.
  • reject: تطلب من خوادم الاستلام رفض الرسائل الفاشلة. لا تنتقل إليها إلا بعد مراجعة التقارير والتأكد من المحاذاة.
• تحقق TrekMail: نبحث عن أي سجل صحيح يحتوي على v=DMARC1. يمكنك تخصيص وسوم مثل rua، الذي يحدد عنوان استقبال التقارير، بما يناسبك.

إذا كان TrekMail خدمة الإرسال الوحيدة لنطاق جديد، فقالب p=quarantine في لوحة التحكم نقطة بداية عملية. وإذا كان Google Workspace أو Microsoft 365 أو نظام الدعم أو أي خدمة أخرى يرسل أيضا باسم النطاق، فابدأ بـp=none. راجع التقارير وشدد السياسة تدريجيا حتى لا تدخل الرسائل المشروعة في الحجر الصحي بالخطأ.

5. حماية متقدمة موصى بها للتسليم

السجلات التالية ليست مطلوبة لتدفق البريد الأساسي، لكننا نوصي بها لتحسين الأمان وتقارير التسليم. راجع الدليل الكامل للسجلات الموصى بها.

تقارير TLS عبر TLS-RPT

المضيف: _smtp._tls

القيمة: v=TLSRPTv1; rua=mailto:tlsrpt@trekmail.net

• الغرض: تتيح لخوادم البريد الأخرى الإبلاغ عن أعطال التشفير عند الاتصال بنطاقك.

MTA-STS

سياسة MTA-STS من نوع TXT:

المضيف: _mta-sts

القيمة: انسخ قيمة v=STSv1; id=... من لوحة التحكم كما هي تماما. يتغير المعرف عندما تتغير السياسة المنشورة.

سجل CNAME الخاص بـMTA-STS:

المضيف: mta-sts

القيمة: mta-sts.trekmail.net.

• الغرض: يفرض تشفير TLS الصارم على البريد الوارد ويمنع هجمات خفض مستوى الحماية.

أخطاء شائعة وحلول سريعة

• العرض: حالة SPF هي «تعارض».
  • الحل: ابحث عن عدة سجلات TXT تبدأ بـv=spf1. لا يجوز وجود أكثر من سجل واحد.
• العرض: تغييرات DNS لا تظهر.
  • السبب المحتمل: قد يستغرق نشر DNS وتحديث ذاكرة التخزين لدى المحللات بعض الوقت.
  • الحل: تحقق من النوع والمضيف والقيمة وأولوية MX لدى مزود DNS. بعد أن ينشر المزود التغيير، شغل فحصا جديدا.