ترتيب حذر لإعداد SPF وDKIM وDMARC

قد تؤثر مصادقة البريد عبر SPF وDKIM وDMARC في كيفية تقييم جهات الاستقبال للرسالة. فإذا عجز نطاقك عن إثبات هوية المرسل، قد تتعامل معه بحذر. وهذه مسألة تشغيلية يومية.

لا تأتي المشكلة دائما من إغفال الآليات الثلاث، وقد تنشأ من ترتيب غير مناسب أو سياسة صارمة تُنشر مبكرا فتؤثر في البريد المشروع. إن كنت لا تزال تحسم قرارات بريد الأعمال الأساسية، فأكملها أولا، ثم عد لنشر المصادقة تدريجيا.

يعرض هذا الدليل تسلسلا حذرا: جرد المرسلين، ثم SPF، ثم DKIM، وأخيرا DMARC. فالفرض المبكر قد يؤثر في البريد المعاد توجيهه وأدوات التسويق ورسائل الدعم.

إذا كنت تستخدم TrekMail، فراجع الوثائق والشروط الحالية لمعرفة إمكانات DNS والنطاقات المخصصة وصناديق IMAP وcatch-all وإعادة التوجيه والترحيل وخيارات SMTP المتاحة. ابدأ من دليل إعداد النطاق، أو راجع كيفية إنشاء بريد باستخدام نطاق للأساسيات.

ماذا تفعل SPF وDKIM وDMARC فعليا؟

هذه ثلاث طبقات ثقة: يتحقق SPF من تفويض خادم الإرسال بالنسبة إلى MAIL FROM، ويتحقق DKIM من سلامة الأجزاء الموقعة، ويحدد DMARC التعامل المطلوب عندما تفشل الفحوص أو لا تتوافق مع نطاق From الظاهر.

البروتوكول	المهمة	الفحص	سبب الفشل الشائع
SPF	التفويض	هل عنوان IP مصرح له بالنسبة إلى نطاق envelope؟	استعلامات كثيرة أو مرسل مفقود أو إعادة توجيه
DKIM	السلامة	هل تطابق الترويسات والمحتوى التوقيع؟	محدد خاطئ أو مفتاح مفقود أو توقيع بنطاق المورّد
DMARC	السياسة والمحاذاة	هل يتوافق SPF أو DKIM مع From؟	الفرض قبل التحقق من SPF وDKIM

فكر في SPF كقائمة ضيوف، وDKIM كختم عبث، وDMARC ككتاب قواعد. تحتاج إلى الطبقات المنطبقة على مساراتك، وهذا تسلسل حذر لا مسار وحيد لكل بيئة.

ترتيب إعداد حذر

التسلسل العملي هو جرد المرسلين، ونشر SPF، وتمكين DKIM حيث يُدعم، وجمع بيانات DMARC، ثم فرضها تدريجيا. يساعد ذلك على تجنب رفض بريد مشروع قبل معرفة كل مصادر الإرسال.

احصر كل نظام يرسل باسم نطاقك.
انشر سجل SPF واحدا لكل المرسلين المشروعين.
فعّل DKIM لكل مرسل يدعمه.
انشر DMARC مع p=none واجمع التقارير.
عالج فشل المحاذاة.
انتقل إلى p=quarantine ثم p=reject إذا دعمت الأدلة ذلك.

هذه هي الخطة الأساسية. الصعوبة ليست طول السجلات، بل تعقيد منظومة الإرسال الفعلية.

المرحلة 1: الجرد وSPF

يصلح SPF كتغيير أول لأنه يوضح عناوين IP المصرح لها ضمن مسار MAIL FROM. لا يحل كل شيء، لكنه يوفر نقطة بداية ويكشف خدمات قديمة ما زالت مفوضة.

قبل تعديل DNS، دوّن كل مرسل: بريد الشركة والفوترة وCRM والدعم والتسويق ونماذج الموقع والطابعات. وكل ما يرسل باستخدام @yourdomain.com يحتاج إلى مراجعة مساره الفعلي.

انشر سجل SPF واحدا، لا سجلا لـ Google وآخر للتسويق. وجود عدة سجلات SPF TXT للنطاق نفسه يؤدي إلى نتيجة خطأ، كما توضحه أمثلة DNS في وثائق TrekMail.

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

قد يناسب ~all سياسة مرحلة التحقق. ولا تستخدم -all إلا بعد التحقق من اكتمال جميع مسارات الإرسال وملاءمة السياسة.

الخطر الأبرز هو حد الاستعلامات. وفقا لـ RFC 7208، يحد تقييم SPF من عمليات بحث DNS المعنية عند 10. وقد يؤدي تراكم include: وa وmx المتداخلة إلى permerror.

قد تضيف Google وHubSpot وZendesk وQuickBooks وMailchimp ونظام تذاكر قديما. يبدو SPF مكتملا، ثم تبلغ جهة استقبال حد الاستعلامات فتعد التقييم خاطئا.

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

المرحلة 2: DKIM والمحاذاة

يأتي DKIM ثانيا لأن SPF يتأثر بالمسار. فقد تكسر إعادة التوجيه SPF، بينما قد يبقى DKIM صالحا إن ظلت البيانات الموقعة بعد canonicalization سليمة.

فعّل DKIM في كل خدمة ترسل باسم نطاقك وتدعم توقيعه: مزود الصندوق ومنصة المعاملات والتسويق والدعم. وعدم دعم نطاقك قيد تقني يستحق التقييم.

يبدو DNS المعتاد هكذا:

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

يستخدم بعض المورّدين CNAME بدلا من مفتاح TXT. اتبع القيم الحالية المفعلة في وثائق المورّد، فالطريقة تختلف والهدف واحد.

استخدم محددا منفصلا لكل مورّد حين يُدعم، ولا تبطل مفتاحه إلا بعد التأكد من توقف استخدامه.

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

إذا وقّعت Mailchimp بنطاقها واستخدمت return-path خاصا بها، قد تنجح فحوص لنطاقات أخرى ويفشل DMARC لعنوانك الظاهر. اضبط مصادقة النطاق المخصص لدى المورّد إن كانت مدعومة.

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

المرحلة 3: بدء DMARC بسياسة p=none

ابدأ عادة بطلب p=none لجمع بيانات المرسلين قبل طلب العزل أو الرفض. وتظل مرشحات جهات الاستقبال المحلية سارية.

ابدأ بسجل أساسي:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

قد تلائم المحاذاة المرنة بنية نطاقك، فالصارمة ليست أفضل دائما. ولا تنتقل إلى الرفض قبل التحقق من المرسلين والمحاذاة.

التقارير مفيدة، لكن XML الخام مرهق. استخدم محللا. قد يفشل SPF عند إعادة التوجيه بينما ينجح DKIM صالح ومتوافق فيمر DMARC. وفشل الاثنين دليل للتحقيق لا حكم آلي بالتزييف. ابدأ بـ دليل الرسائل غير المرغوبة في TrekMail.

هنا تظهر أنظمة منسية وماسحات سيئة الإعداد ونشرات قديمة وربما انتحال. استخدم التقارير مع السجلات والاختبارات، لأن تغطيتها قد تكون ناقصة.

المرحلة 4: معالجة نتائج التقارير

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

تقع معظم الحالات ضمن فئات قليلة:

مرسل مشروع غير مدرج في SPF.
مورّد يوقّع بـ DKIM لكن ليس بنطاقك.
منصة تسويق تستخدم نطاق ارتداد افتراضيا.
جهاز يرسل مباشرة بدلا من SMTP مصادق عليه.
مصدر غير مصرح قد ينتحل From من عناوين IP عشوائية.

كثيرا ما تسبب الطابعات والماسحات مشكلات. مررها عبر مرحّل SMTP مصادق عليه حيث يمكن. راجع شروط TrekMail الحالية لتوفر SMTP المدار أو خيارك الخاص. وتوثق إعدادات IMAP وSMTP المضيفات والمنافذ الحالية، وتشير إلى IMAP دون POP3.

بعد نتائج سليمة عبر فترات تمثيلية متعددة، تشمل التدفقات النادرة والحرجة، انتقل بحذر مع خطة تراجع.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

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

التحقق عبر سطر الأوامر

التحقق مهم لأن واجهات DNS ولوحات المورّدين قد تتأخر والتخزين المؤقت قد يستمر. استعلم من DNS ثم اختبر كل نظام يرسل باسم نطاقك.

تحقق من SPF:

dig txt example.com +short

تحقق من DKIM لمحدد:

dig txt trek._domainkey.example.com +short

تحقق من DMARC:

dig txt _dmarc.example.com +short

ابحث عن سجل SPF واحد ومفتاح DKIM صالح والسياسة المقصودة. وبعد أي تعديل، ضع TTL والتخزين المؤقت في الحسبان وقارن النتيجة عبر محلل DNS خارجي.

تحقق أيضا من DNS العكسي وTLS ومعدلات الشكاوى. المصادقة أساس وليست حلا سحريا، ولا تعوض عن قوائم رديئة أو إرسال متهور.

النهج القديم والجديد

كان نموذج شائع يفرض الدفع لكل صندوق مع إعدادات المزود. وتتيح نماذج أخرى تحكما أكبر بالنطاق ومسار SMTP والمصادقة. قارن المتطلبات والتكلفة الفعلية بدلا من افتراض أفضلية مطلقة.

يهم ذلك عند إدارة علامات أو عملاء أو صناديق مشتركة. تحقق من صفحة TrekMail الحالية من Starter بسعر يبدأ من $3.50 شهريا، وNano عند $0 مع BYO SMTP، وSMTP المدار في الخطط المدفوعة، إضافة إلى النطاقات وIMAP وcatch-all وإعادة التوجيه وترحيل IMAP من الخادم وAPI في الخطط المؤهلة. وقد تختلف الملاءمة حسب الاستخدام والميزات.

طبّق المصادقة بعناية وراقبها عند تغير المورّدين. اقرأ إعداد البريد على نطاقي ثم راجع أسعار TrekMail.

الخلاصة

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

باختصار: احصر المرسلين، وانشر SPF واحدا، وفعّل DKIM حيث يُدعم، واجمع بيانات DMARC، وعالج المحاذاة، ثم افرض تدريجيا. هذا مسار عملي في 2025 و2026. وللشروط الحالية زر TrekMail.