يتطلب إعداد DNS للبريد إنشاء ستة سجلات أو سبعة. يحتوي بعضها على سلاسل طويلة، وقد يؤدي حرف واحد خاطئ إلى عطل لا تبدو أسبابه كخطأ مطبعي. مفتاح DKIM سلسلة من بضع مئات من المحارف بصيغة base64. وسجل SPF قائمة آليات يؤثر ترتيبها في التقييم، كما يغير ختامها معنى السياسة. أما DMARC فيستخدم اسما لنطاق فرعي يسهل إدخاله بشكل خاطئ.
عند إعداد نطاق واحد، قد تنجز المهمة بلا أخطاء. لكن مع أربعين نطاقا للعملاء، تزيد احتمالات أن يفوتك خطأ. وربما لا تكتشفه إلا بعد شهر، حين تصل فاتورة إلى مجلد الرسائل المزعجة.
الإعداد التلقائي يغنيك عن نسخ القيم يدويا. هناك طريقتان: الموافقة لدى مزود DNS على تغيير نطاق واحد ثم العودة إلى TrekMail، من دون تسليم رمز وصول، أو استخدام رمز وصول لواجهة API بصلاحيات محدودة لإعداد مئة نطاق على دفعات. تتيح الطريقتان مراجعة التغييرات قبل تطبيقها.
ما سجلات DNS المطلوبة للبريد؟
| السجل | النوع | الوظيفة | هل هو مطلوب؟ |
|---|---|---|---|
| MX | MX | يحدد وجهة تسليم البريد الوارد | نعم، لتوجيه الاستقبال إلى خدمة البريد المعدة |
| SPF | TXT في جذر النطاق | يصرح للخوادم بالإرسال لنطاق مرسل مغلف SMTP، وفقا لـ RFC 7208 | نعم، للمصادقة عبر SPF |
| DKIM | TXT تحت اسم المحدد | ينشر المفتاح العام للتحقق من توقيع البريد الصادر | مطلوب في كثير من حالات الإرسال |
| DMARC | TXT تحت _dmarc | يحدد السياسة عندما لا تنجح مصادقة SPF أو DKIM مع محاذاة النطاق، ووجهات التقارير | مطلوب في كثير من حالات الإرسال |
| MTA-STS | TXT + سياسة مستضافة | يلزم خوادم الإرسال الداعمة باستخدام TLS عند التسليم الوارد، وفقا للسياسة المنشورة | موصى به |
| TLS-RPT | TXT تحت _smtp._tls | يطلب تقارير عن مشكلات التسليم المتعلقة بـ TLS | موصى به |
| autoconfig / autodiscover | CNAME | يساعد تطبيقات البريد الداعمة على العثور على الإعدادات انطلاقا من العنوان | اختياري، وقد يقلل طلبات الدعم |
عبارة «مطلوب في كثير من حالات الإرسال» لا تعني أن وثائق RFC تلزم كل نطاق بنشر DKIM وDMARC. أدخلت Google وYahoo متطلبات لمرسلي البريد بكميات كبيرة في 2024، لكن التطبيق يعتمد على فئة المرسل والقواعد السارية. وقد تضع جهات الاستقبال المؤسسية متطلبات خاصة بها. غياب السجلات لا يجعل كل إرسال مستحيلا تلقائيا، لكنه قد يصعب المصادقة وقبول الرسائل.
أربعة أخطاء شائعة عند إعداد DNS يدويا
نشر سجلين لـ SPF. خطأ شائع وله آثار مهمة. يجب أن يوجد سجل SPF واحد فقط للاسم الذي يجري تقييمه. إضافة سجل ثان لخدمة إرسال جديدة لا توسع السياسة؛ فالتقييم المطابق للبروتوكول يعيد permerror. يجب جمع الآليات في سجل واحد. راجع أمثلة سجلات SPF.
إتلاف مفتاح DKIM عند لصقه. يتجاوز التمثيل النصي لمفتاح بطول 2048 بت حد 255 محرفا لكل سلسلة TXT. لذلك يحتوي السجل على عدة سلاسل تجمع عند قراءته. تعالج بعض لوحات DNS ذلك تلقائيا، بينما تتطلب أخرى إعداد التقسيم، وقد تقتطع بعض اللوحات القيمة. المفتاح غير المكتمل يمنع التحقق من التوقيع، وقد لا يظهر السبب مباشرة.
نشر DMARC تحت الاسم الخطأ. مكانه هو _dmarc.example.com. إذا وضع في جذر النطاق، فلن تجده جهة الاستقبال عند البحث عن سياسة DMARC لذلك النطاق.
تجاوز حد استعلامات SPF. يحدد SPF عدد العناصر التي تتطلب استعلامات DNS أثناء التقييم بعشرة. يحتسب كل include: يجري تقييمه، بما في ذلك العناصر المتداخلة. قد تتجاوز خدمة البريد ونظام CRM وأداة التسويق ونظام الدعم الحد معا، بحسب سياساتها. تصبح النتيجة عندئذ permerror. وقد تظهر المشكلة بعد أشهر من الإعداد الأول، حين تضاف أداة أخرى. راجع حد استعلامات DNS في SPF.
تقلل الأتمتة أخطاء النسخ وتكشف التعارضات، لكنها لا تغني عن مراجعة النتيجة. دمج SPF يتجنب إنشاء سجل ثان، ولا يثبت أن السياسة النهائية تلتزم بحد التقييم.
الطريقة 1: إعداد DNS بنقرة واحدة، من دون رمز وصول
هذه الطريقة المباشرة لنطاق تدير Cloudflare خدمة DNS الخاصة به. لا تحتاج إلى تسليم TrekMail رمز وصول لواجهة API أو بيانات تسجيل الدخول إلى حسابك.
- افتح علامة تبويب DNS والحالة للنطاق.
- انقر على إعداد DNS تلقائيا.
- تعرض Cloudflare تغييرات السجلات المقترحة قبل الموافقة.
- انقر على السماح.
- تعود إلى TrekMail ويطلب التحقق. العودة وحدها لا تؤكد أن السجلات نشرت بشكل صحيح.
يستخدم المسار Domain Connect، وهو بروتوكول مفتوح لهذا التبادل: تصف الخدمة السجلات المطلوبة، ويعرض مزود DNS التغييرات على مالك النطاق، ثم يوافق المالك. لا ينشأ رمز وصول لواجهة API قابل لإعادة الاستخدام ولا يخزن. تتعلق الموافقة بالعملية المقترحة لذلك النطاق.
يجب أن تشير خوادم أسماء النطاق إلى Cloudflare. إذا كان النطاق مسجلا لديها فقط، لكن DNS مستضاف في مكان آخر، فلن يتاح هذا المسار. يجب تعديل السجلات لدى الجهة التي تدير منطقة DNS فعليا.
الطريقة 2: إعداد DNS برمز وصول لواجهة API محدود الصلاحيات
عند إعداد عدة نطاقات، أو إذا لم يتوفر Domain Connect، يسمح رمز الوصول بإعداد المناطق المصرح بها في الحساب.
أنشئ الرمز في Cloudflare باستخدام قالب Edit zone DNS وصلاحية Zone → DNS → Edit. في موارد المناطق، اختر All zones لجميع المناطق أو Specific zone لتقييد الوصول. تحقق من أن قيود IP ومدة الصلاحية تسمحان بالاستخدام المقصود، ولا حاجة إلى تغييرهما من دون سبب. انسخ الرمز عند عرضه ثم الصقه في TrekMail.
المهم هو معرفة ما تسمح به هذه الصلاحيات وما تستبعده:
| يستطيع الرمز | لا يستطيع الرمز |
|---|---|
| قراءة سجلات DNS وتعديلها في المناطق المختارة | تغيير خوادم الأسماء |
| إدارة الفوترة أو WAF أو قواعد الصفحات أو Workers أو إعدادات SSL | |
| نقل نطاق أو حذفه | |
| الوصول إلى مناطق لم تشملها الموافقة |
يخزن TrekMail الرمز مشفرا ويتجنب تسجيل قيمته في السجلات. يمكنك فصل اتصاله بنطاق في TrekMail أو إبطاله في Cloudflare لمنع الطلبات اللاحقة به. فصل نطاق واحد لا يبطل بالضرورة رمزا مشتركا مع نطاقات أخرى. كما أن الإبطال لا يتراجع عن تغييرات سبق تطبيقها.
بعد الاتصال تظهر مناطق Cloudflare المتاحة مع العملية المقترحة: إعداد DNS لنطاق موجود بالفعل في حساب TrekMail، أو إضافة + DNS لإضافته وإعداده في المسار نفسه. النطاقات التي تستضيف DNS خارج Cloudflare لا تظهر كمناطق قابلة للإعداد عبر هذا التكامل.
المعاينة وحالاتها الخمس
يمكنك مراجعة كل سجل قبل تطبيق الإعداد. تستخدم المعاينة خمس حالات:
| الحالة | المعنى | هل تحتاج إلى قرار؟ |
|---|---|---|
| سيضاف | السجل غير موجود ويقترح إنشاؤه | لا يوجد تعارض لحله |
| سيدمج | يوسع SPF الحالي ليشمل TrekMail، مع الحفاظ على آلياته | لا يوجد تعارض لحله |
| معد بالفعل | القيمة المتوقعة موجودة | لا يوجد تعارض لحله |
| سيستبدل | يوجد تعارض، مثل سياسة DMARC مختلفة أو CNAME لـ autodiscover يشير إلى المزود السابق | نعم: اختر الاستبدال أو الإبقاء |
| متجاوز | أزلت تحديد السجل | اتخذت القرار بالفعل |
لكل سجل مربع اختيار. يمكنك تطبيق MX وSPF الآن وترك DKIM لاحقا، أو استبعاد سجل تديره بطريقة أخرى. السجلات غير المحددة لا تطبق في تلك العملية.
اقرأ التعارضات بدلا من الموافقة عليها مباشرة. سياسة DMARC بقيمة p=none ليست خاطئة، فقد تكون مرحلة مراقبة مقصودة. استبدالها بـ p=quarantine قبل قراءة التقارير قد يضر بالرسائل المشروعة التي لا تصادق بشكل صحيح بعد. أبقها عند الحاجة، وأكمل النشر، ثم شدد السياسة. راجع كيفية اختيار سياسة DMARC.
لماذا يدمج سجل SPF الحالي
يستحق SPF عناية خاصة لأن سياسة واحدة قد تصرح لعدة خدمات إرسال. استبدال السجل من دون مراجعة تلك الخدمات قد يحذف صلاحيات ما زلت تحتاج إليها.
لنفترض أن نطاقك ينشر بالفعل:
v=spf1 include:_spf.google.com ~allهذه السياسة تصرح لبنية Google، مثل Workspace أو أداة ترسل من خلالها. استبدالها بسجل لا يشمل إلا TrekMail لا يضيف مرسلا فحسب، بل يزيل التصريح السابق. وقد تبدأ الرسائل التي تعتمد عليه بالفشل في تحقق SPF.
لذلك يدمج سجل SPF الحالي الصالح عادة:
v=spf1 include:_spf.trekmail.net include:_spf.google.com ~allتبقى الخدمتان مصرحا لهما في سجل واحد، مع الحفاظ على المعامل الختامي. بهذه الطريقة يضاف TrekMail من دون إزالة التصريح السابق. لكن ذلك لا يعني أن الاستبدال لا يحدث أبدا: السجلات المكررة أو غير الصحيحة قد تتطلب حل تعارض. ويجب مراجعة السياسة النهائية.
راجع بعد ذلك أمرين. يحتسب include: الجديد ضمن حد العناصر العشرة التي تتطلب استعلامات DNS، وقد يسبب استعلامات متداخلة، لذا قيم السياسة كاملة. إذا كان المزود السابق قد توقف فعلا عن الإرسال لنطاقك، فاحذف تصريحه يدويا بعد التأكد. غياب النشاط فترة لا يثبت أن الخدمة لم تعد مستخدمة.
إعداد DNS على دفعات
برمز مصرح له لجميع المناطق، يستطيع المعالج المرور على النطاقات المتوافقة، وإضافة الجديد منها، وإعداد السجلات، وعرض النتيجة لكل نطاق. الحد هو 50 نطاقا في الدفعة. تحتسب النطاقات الجديدة ضمن حد الخطة: 10 في Nano، و50 في Starter، و100 في Pro، و1,000 في Agency، وفقا للإعداد الموصوف في المقال الأصلي. تحقق من حدود حسابك الحالية قبل البدء.
لوكالة تستقبل عميلا لديه نحو اثني عشر نطاقا، قد يوفر العمل على دفعات كثيرا من الإعداد اليدوي. وتصبح المعاينة أكثر أهمية. تصور اثني عشر نطاقا: اثنان لديهما سياسة DMARC متعارضة، وواحد يحتفظ بسجل autodiscover CNAME يشير إلى مزود تركوه في 2023. هذا مثال لما ينبغي البحث عنه، لا معدل حدوث مضمون.
نطاق تأثير التغييرات
سؤال مشروع قبل منح تطبيق صلاحية الكتابة في DNS.
صمم التكامل لإدارة سجلات البريد: MX وSPF وDKIM وDMARC وMTA-STS وTLS-RPT وسجلات CNAME للإعداد التلقائي. يفترض ألا يغير سجلات A أو CNAME للموقع أو TXT لخدمات أخرى. لكن صلاحية DNS للرمز تسمح بتعديل سجلات المناطق المصرح بها، لا سجلات البريد وحدها. لذلك تعتمد سلامة السجلات الأخرى أيضا على سلوك التطبيق. هذه الصلاحية لا تسمح بتغيير خوادم الأسماء.
استبدال سجل متعارض قد يزيل إعدادا سابقا، ولهذا يتطلب التأكيد. راجع التغييرات الأخرى وأي تنظيف للسجلات المكررة مرتبط بالعملية؛ لا تفترض أن كل ما عدا الاستبدال بلا أثر. احتفظ بالقيم السابقة إذا كنت تحتاج إلى استعادتها.
قد تنتج حالة الانتظار عن ذاكرة DNS المؤقتة، لكن أيضا عن سجل خاطئ أو عملية لم تكتمل. يذكر الأصل مدة تصل إلى 48 ساعة، وهي ليست مهلة عامة، إذ يؤثر TTL وظروف المزود في ظهور التغييرات. يعاد التحقق تلقائيا، ويطلب زر التحقق من DNS فحصا آخر. إذا استمر الفشل في اليوم التالي، فراجع القيم المنشورة واستعن بـ استكشاف أخطاء DKIM عندما تتعلق المشكلة بالتوقيع.
الأسئلة الشائعة
هل أحتاج إلى حساب Cloudflare للإعداد بنقرة واحدة؟
يجب أن تدير Cloudflare خدمة DNS لنطاقك، وأن تتمكن من الوصول إلى الحساب المعني للموافقة على التغيير. لا تحتاج إلى تسليم TrekMail رمز وصول لواجهة API، إذ توافق في واجهة Cloudflare ولا يخزن رمز قابل لإعادة الاستخدام.
ماذا لو لم يكن DNS لدى Cloudflare؟
هذا التكامل التلقائي لا يعد المزود الآخر. يجب إنشاء السجلات يدويا. تعرض صفحة DNS للنطاق القيم مع أزرار للنسخ، وتوجد خطوات خاصة بالمزودين في إعداد DNS لدى المزودين الشائعين.
هل يمكن أن يؤثر الإعداد التلقائي في موقعي؟
صمم التكامل لتعديل سجلات البريد والإبقاء على A وCNAME للموقع وTXT غير المرتبطة بالبريد. هذا لا يعني أن الرمز عاجز تقنيا عن تعديلها؛ فصلاحياته تشمل سجلات DNS في المناطق المصرح بها. راجع التغييرات المقترحة. الصلاحية الموصوفة لا تسمح بتغيير خوادم الأسماء.
ماذا يحدث لسجل SPF الحالي؟
يدمج عادة بإضافة include الخاص بـ TrekMail والحفاظ على المعامل. بذلك لا تزال تصريحات خدمات أخرى عن طريق الخطأ. وقد تتطلب السجلات المكررة أو غير الصحيحة استبدالا مؤكدا. تحقق أيضا من حد استعلامات السياسة النهائية.
هل يمكنني تطبيق بعض السجلات فقط؟
نعم. لكل سجل مربع اختيار في المعاينة. أزل تحديد ما تديره بطريقة أخرى لاستبعاده من هذه العملية.
كم نطاقا يمكن إعداده في عملية واحدة؟
حتى 50 في الدفعة، ضمن الحد الإجمالي للنطاقات في خطتك. تحتسب النطاقات الجديدة التي يضيفها المعالج ضمن ذلك الحد.
هل رمز الوصول لواجهة API محمي؟
يخزنه TrekMail مشفرا ويتجنب تسجيل قيمته. بالصلاحيات الموصوفة يمكنه تعديل DNS في المناطق المختارة، لكن لا يمكنه إدارة الفوترة أو WAF أو خوادم الأسماء أو نقل النطاقات. أبطله في Cloudflare لمنع الطلبات اللاحقة، مع العلم أن ذلك لا يعيد التغييرات السابقة. اقتصر في التفويض على المناطق المطلوبة.
لماذا يظهر سجل لم أنشئه بحالة «معد بالفعل»؟
ربما أنشأه مزود سابق، أو نفذ إعداد تمت الموافقة عليه من قبل. قارن القيمة المنشورة بالقيمة المقترحة. إذا تطابقتا فلا حاجة إلى الاستبدال، لكن تحقق من أن السجل ما زال مناسبا لإعدادك الحالي.
