نطاق Return-Path ونطاق التتبع المخصصان هما إعدادان للهوية والمصادقة يتجاهلهما معظم المرسِلين، وهما مهمان لسببين مختلفين. فـ Return-Path المخصص يتيح لـ SPF أن يتواءم مع نطاق From لديك، فيصبح أمام DMARC طريقان للنجاح. ونطاق التتبع المخصص يضع اسمك أنت في روابط النقر والفتح. يشرح هذا الدليل كليهما، ويبيّن سجلات DNS المعنية، ويصف طريقة اختبارهما.
النطاقات الثلاثة في كل رسالة بريد
تحمل الرسالة الواحدة عدة أسماء نطاقات، يُستخدم كل منها في فحص مختلف. وفهم الفرق يفسر سبب وجود هذه الإعدادات.
| الاسم | أين يظهر | الاستخدام |
|---|---|---|
| نطاق From | العنوان الظاهر في ترويسة From | يقارن DMARC الفحوص الأخرى بهذا النطاق |
| نطاق Return-Path | مرسِل المظروف (MAIL FROM)، ويظهر في ترويسة Return-Path | يُفحص SPF هنا، وتُسلَّم الارتدادات هنا |
| نطاق توقيع DKIM (d=) | ترويسة التوقيع | التحقق من DKIM، والمواءمة مع نطاق From |
| نطاق التتبع | داخل الروابط وبكسلات التتبع في نص الرسالة | سمعة الروابط، والفحص الأمني، وثقة العلامة التجارية |
المواءمة: لماذا يهم نطاق Return-Path
يشترط DMARC أن ينجح SPF أو DKIM على الأقل، وأن يكون النطاق الناجح متواءمًا مع نطاق From. والمقصود بالمواءمة الارتباط: ففي المواءمة المرنة (relaxed)، وهي الافتراضية، يُحتسب النطاق الفرعي التابع للنطاق التنظيمي نفسه. فإذا استخدمت منصتك نطاقها الخاص بوصفه Return-Path، ينجح SPF لذلك النطاق لكنه لا يطابق نطاقك، ولذلك لا يفيد SPF في DMARC. أما مع Return-Path مخصص على نطاق فرعي يخصك، فينجح SPF ويتواءم.
| الإعداد | نتيجة SPF | نتيجة DMARC |
|---|---|---|
| Return-Path على نطاق المنصة، وDKIM متواءم | ناجح، غير متواءم | ينجح عبر DKIM فقط |
| Return-Path مخصص على نطاقك الفرعي، وDKIM متواءم | ناجح ومتواءم | ينجح عبر الاثنين؛ وأكثر مرونة |
| Return-Path مخصص، وDKIM منكسر أثناء النقل | ناجح ومتواءم | ما زال ينجح عبر SPF |
| Return-Path للمنصة، وDKIM منكسر أثناء النقل | ناجح، غير متواءم | يفشل |
SPF لا يصمد أمام إعادة التوجيه. عند إعادة توجيه البريد، يُفحص SPF مقابل الجهة التي أعادت التوجيه، ولذلك يفشل عادةً. أما DKIM فهو الإشارة التي تصمد. ولهذا فإن DKIM المتواءم هو الهدف الأول، وReturn-Path المخصص طبقة ثانية لا بديل.
إعداد Return-Path مخصص
- اختر نطاقًا فرعيًا. اختر اسمًا مثل bounce.mail.example.com يُستخدم للارتدادات فقط. وأبقِه منفصلًا عن النطاق الفرعي للتتبع.
- أضف السجل الذي تحدده منصتك. يكون عادةً سجل CNAME يشير إلى اسم لدى المنصة، أو سجل MX يوجّه الارتدادات إلى المنصة. انسخه كما هو بالضبط.
- افحص سجل SPF للنطاق الفرعي. تدير المنصة عادةً سياسة SPF خلف سجل CNAME. فإن لم تفعل، فانشر سجل SPF للنطاق الفرعي يخوّل المنصة.
- انتظر ثم تحقق. دع مدة TTL للسجل تنقضي، واستخدم منصتك للتحقق من النطاق كما يرد في دليلنا عن التحقق من نطاق الإرسال.
- أرسل رسالة اختبار واقرأ الترويسات. تأكد من أن ترويسة Return-Path تستخدم نطاقك الفرعي، وأن نتائج المصادقة تُظهر نجاح SPF مع هذا النطاق.
Return-Path: <bounce+abc123@bounce.mail.example.com>
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.mail.example.com;
dkim=pass header.d=mail.example.com;
dmarc=pass header.from=mail.example.comفي هذا المثال، نطاق Return-Path نطاق فرعي من نطاق From، ولذلك تتحقق المواءمة المرنة ويسهم SPF في نجاح DMARC.
إعداد نطاق تتبع مخصص
يعيد تتبع الروابط كتابة كل رابط في رسالتك ليمر عبر إعادة توجيه، حتى يمكن احتساب النقرات. ويضيف تتبع الفتح صورة صغيرة جدًا يُحتسب تحميلها. وكلاهما يستخدم نطاقًا. وبصورة افتراضية يكون ذلك النطاق ملكًا للمنصة ويشاركه كثير من العملاء. أما نطاق التتبع المخصص فيستبدل به نطاقًا فرعيًا يخصك.
- اختر نطاقًا فرعيًا. مثل links.example.com. واستخدم اسمًا يبدو طبيعيًا للمستلم.
- انشر سجل CNAME. وجّه النطاق الفرعي إلى الاسم الذي تعطيك إياه منصتك. ويجب أن يكون CNAME السجل الوحيد على ذلك الاسم.
- انتظر الشهادة. تطلب المنصة شهادة للنطاق الفرعي بمجرد أن يُحلّ سجل CNAME. وقد يستغرق ذلك دقائق أو ساعات.
- فعّله للإرسال. اختر نطاق التتبع في إعدادات الإرسال أو لكل مسار، حتى تستخدمه الرسائل الجديدة.
- انقر على رابط اختبار. افتح رسالة، وانقر على رابط متتبَّع، وتأكد من أنه يُحمَّل عبر HTTPS دون تحذير من المتصفح ويصل إلى الصفحة الصحيحة.
لماذا HTTPS ليس اختياريًا
الرابط المتتبَّع هو أول ما يلمسه المستلم والمتصفح والماسح الأمني. والرابط الذي يبدأ بـ http، أو الذي يعرض تحذير شهادة، يثير الريبة ويخسر النقرات. وبعض بوابات الشركات تعيد كتابة هذه الروابط أو تحجبها كليًا. تأكد من صلاحية الشهادة قبل تشغيل التتبع، وتحقق من أن التجديد تلقائي.
مزايا نطاق التتبع المخصص ومقايضاته
| الميزة | المقايضة |
|---|---|
| سمعة الروابط ملك لك وحدك، لا تشاركها مع مرسِلين مجهولين | أخطاؤك أنت أيضًا تقع على نطاقك، فحافظ على نظافته |
| تبدو الروابط متسقة مع علامتك التجارية | نطاق فرعي وشهادة إضافيان للصيانة |
| أسهل في فصل المسارات، بنطاق تتبع واحد لكل مسار | سجلات DNS أكثر تحتاج إلى توثيق |
| مفاجآت أقل إذا أُدرج مرسِل آخر على نطاق مشترك في قائمة حظر | النطاق الجديد بلا تاريخ، فقدّمه تدريجيًا |
قدّم نطاق التتبع الجديد تدريجيًا. فالنطاق الذي لم يظهر من قبل في الروابط لا سمعة له، لا جيدة ولا سيئة، وقد يبدو إرسال أحجام كبيرة به منذ اليوم الأول أمرًا غير معتاد. اتبع الزيادة الحذرة نفسها الموصوفة في دليل التسخين.
هل ينبغي إيقاف التتبع في بعض الرسائل؟
تتبع الفتح والنقر وسيلتا راحة لا شرطان. ففي رسائل إعادة تعيين كلمات المرور ورموز تسجيل الدخول والرسائل الأمنية المشابهة، يوقف كثير من الفرق التتبع. وينبغي أن تذهب الروابط مباشرة إلى موقعك، فالروابط المعاد كتابتها قد تجعل رسالة حقيقية تبدو كأنها تصيّد في نظر المستخدمين والمرشحات. ولاحظ أيضًا أن تتبع الفتح أصبح غير موثوق مع تحميل تطبيقات البريد الصور مسبقًا. تعامل مع الفتح بوصفه إشارة تقريبية، واعتبر النقرات والتحويلات هي المقاييس المهمة.
مثال تطبيقي: مساران على نطاق واحد
تخيّل متجرًا يرسل تأكيدات الطلبات وعروضًا ترويجية أسبوعية. يُبقي النطاق الجذر example.com لبريد الموظفين وينشئ نطاقين فرعيين للإرسال، واحدًا لكل مسار. ويحصل كل منهما على مجموعة سجلاته الخاصة، فلا تختلط السمعتان أبدًا.
| المسار | نطاق From | Return-Path | نطاق التتبع |
|---|---|---|---|
| معاملاتي | orders.example.com | bounce.orders.example.com | لا يوجد، والتتبع متوقف للرسائل الأمنية |
| ترويجي | news.example.com | bounce.news.example.com | links.news.example.com |
بهذا التصميم، فإن ارتفاع الشكاوى في المسار الترويجي يضر news.example.com ونطاق روابطه، بينما تحتفظ تأكيدات الطلبات بتاريخها النظيف. وكل Return-Path هو نطاق فرعي من نطاق From الخاص به، فيتواءم SPF في ظل المواءمة المرنة. ويوقّع كل مسار بمحدد DKIM خاص به، مما يسهّل أيضًا تدوير مفتاح واحد دون المساس بالآخر. والكلفة هي حفنة من سجلات DNS الإضافية، وهو ثمن صغير مقابل الفصل.
وحين تضيف مسارًا لاحقًا، انسخ النمط بدلًا من ابتكار نمط جديد. فالتسمية المتسقة توضح في الترويسة أو في تقرير DMARC أو في إشعار قائمة الحظر إلى أي مسار تنتمي الرسالة، وهذا يسرّع كل تحقيق.
استكشاف الأعطال
| المشكلة | السبب المرجح | الحل |
|---|---|---|
| ما زال Return-Path يعرض نطاق المنصة | لم يُفعَّل Return-Path المخصص للمسار | اختر النطاق في إعدادات الإرسال وأعد الإرسال |
| ينجح SPF لكن يفشل DMARC | نطاق Return-Path غير متواءم مع From | استخدم نطاقًا فرعيًا من نطاق From |
| تعذّر إضافة CNAME | يوجد سجل آخر على ذلك الاسم | استخدم نطاقًا فرعيًا جديدًا لسجل CNAME |
| الرابط المتتبَّع يعرض تحذير شهادة | الشهادة لم تصدر أو انتهت صلاحيتها | افحص CNAME وحالة النطاق في المنصة |
| الروابط المتتبَّعة تعيد خطأ | CNAME يشير إلى وجهة خاطئة | قارنه بالقيمة الموجودة في حسابك |
| حجب الروابط بواسطة بوابة لدى المستلم | نطاق تتبع جديد بلا سمعة | زِد الحجم تدريجيًا وتجنّب مختصرات الروابط |
أبقِه مُصانًا
- وثّق كل نطاق فرعي والغرض منه في مكان واحد.
- افحص السجلات بعد أي ترحيل لـ DNS أو تغيير لمسجِّل النطاقات.
- راقب انتهاء صلاحية الشهادات لنطاقات التتبع.
- أعد اختبار المواءمة بعد تغيير المنصات أو إضافة خدمة إرسال جديدة.
- راجع تقارير DMARC بحثًا عن المصادر التي تفشل في المواءمة.
هل تريد عينًا ثانية على إعدادات DNS لديك؟ أرسل لنا نطاق الإرسال الخاص بك وسنفحص سجلات Return-Path والتتبع.
مراجع ومصادر إضافية
الأسئلة الشائعة
ما هو عنوان Return-Path؟
هو عنوان مرسِل المظروف (envelope sender)، ويسمى أيضًا MAIL FROM أو Return-Path، وهو العنوان الذي تُرسل إليه الارتدادات. وهو منفصل عن عنوان From الذي يراه الناس. ويُفحص SPF مقابل النطاق الوارد في عنوان المظروف هذا، لا مقابل عنوان From الظاهر.
لماذا يهم Return-Path المخصص؟
ينجح DMARC حين ينجح SPF أو DKIM ويكون متواءمًا مع نطاق From. فإذا كان Return-Path يستخدم نطاق منصتك، ينجح SPF لكنه لا يتواءم مع نطاق From لديك. ويتيح Return-Path مخصص على نطاق فرعي يخصك مواءمة SPF، فيمنح DMARC طريقًا ثانيًا للنجاح إضافة إلى DKIM.
هل أحتاج إلى Return-Path مخصص إذا كان DKIM متواءمًا؟
يحتاج DMARC إلى نجاح متواءم واحد فقط، ولذلك يكفي DKIM المتواءم. ومع ذلك يستحق Return-Path المخصص أن يكون لديك بوصفه طبقة ثانية، لأنه يبقي DMARC ناجحًا إذا انكسر توقيع DKIM أثناء النقل، ويُبقي الارتدادات منسوبة إلى نطاقك.
ما هو نطاق التتبع؟
هو النطاق المستخدم في الروابط المعاد كتابتها وفي بكسلات تتبع الفتح. ومع نطاق تتبع مخصص تشير الروابط إلى نطاق فرعي يخصك مثل links.example.com بدلًا من نطاق مشترك للمنصة، فتبدو أكثر موثوقية وتبقى سمعة روابطك منفصلة عن المرسِلين الآخرين.
لماذا يحتاج نطاق التتبع إلى HTTPS؟
تحذّر المتصفحات وعملاء البريد من الروابط غير الآمنة أو تحجبها. فالروابط التي تبدأ بـ http قد تثير تحذيرات وتخفض معدل النقر، وبعض الماسحات الأمنية تنظر إليها بريبة. تأكد من أن المنصة تُصدر شهادة لنطاقك الفرعي للتتبع وتجددها.
هل يمكنني استخدام النطاق الفرعي نفسه للارتدادات وللتتبع؟
الأفضل ألا تفعل. فالدوران يستخدمان أنواع سجلات مختلفة وتعالجهما أنظمة مختلفة. واستخدام نطاقين فرعيين منفصلين يتجنب التعارضات، مثل تعارض سجل CNAME مع سجل MX على الاسم نفسه.
لماذا يعرض رابط التتبع لدي تحذيرًا بشأن الشهادة؟
لأن شهادة النطاق الفرعي للتتبع لم تُصدر بعد، أو انتهت صلاحيتها، أو أن سجل CNAME لا يشير إلى الوجهة التي تتوقعها المنصة. افحص السجل، وانتظر إصدار الشهادة، وتأكد من أن المنصة تعرض النطاق على أنه نشط.
هل سيحسّن نطاق التتبع المخصص قابلية التسليم؟
قد يساعد بصورة غير مباشرة. فنطاق الروابط ذو العلامة التجارية الذي يقوم على سمعتك الخاصة يتجنب مشاركة نطاق الروابط مع مرسِلين مجهولين، ويجعل الرسالة تبدو متسقة. لكنه لا يعوّض ضعف جودة القائمة أو الشكاوى.
هل يمكنني إيقاف تتبع الروابط؟
نعم، في معظم المنصات يمكنك تعطيل تتبع النقرات والفتح، لكل رسالة أو بصورة افتراضية. وفي الرسائل الحساسة مثل إعادة تعيين كلمات المرور، يشيع إيقاف التتبع لأن الروابط المعاد كتابتها قد تربك المستخدمين والأدوات الأمنية.