قابلية تسليم البريد الإلكتروني: دليل المصادقة والسمعة

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

هذه هي المشكلة الفعلية في قابلية تسليم البريد الإلكتروني. لا يتعلق الأمر بالأخطاء الإملائية أو العناوين وحدها، بل بالبنية التحتية أيضا. تؤثر طبقات لا يفحصها كثير من المرسلين في النتيجة. منذ تشديد المتطلبات مطلع 2024، فرضت Google وYahoo شروطا إضافية على فئات من مرسلي البريد الجماعي، بينما تتبع Microsoft متطلبات وجدولا مختلفين. قد تؤدي أخطاء DNS وسوء السمعة إلى التصفية أو الرفض بحسب سياسة الجهة المستقبلة.

هذا الدليل موجه للمؤسسين الذين يرسلون عشر رسائل مهمة يوميا، ولمزودي الخدمات المدارة الذين يديرون خمسمئة نطاق. سنترك نصائح كتابة العناوين الجذابة جانبا ونركز على تشخيص السبب: لماذا يفشل البريد، وكيف تعالج الخلل، وما ملامح الإعداد المناسب في 2026؟

قبول الرسالة وقابلية التسليم: الفرق بينهما

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

يمكن تمييز المصطلحات الثلاثة على النحو التالي:

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

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

نموذج التشخيص: المصادقة → السمعة → المحتوى → التصنيف

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

1. المصادقة (إثبات الهوية): ما هوية الإرسال التي يستطيع المستقبل التحقق منها؟ يشكل SPF وDKIM وDMARC الأساس. قد تؤدي الأخطاء إلى الرفض أو التصفية بحسب السياسة ونتائج المصادقة الأخرى الصحيحة.
2. السمعة (سجل الإرسال): هل يرتبط نطاقك أو عنوان IP برسائل مرغوبة أم برسائل مزعجة؟ تستخدم Google وMicrosoft إشارات داخلية مختلفة. يعد معدل شكاوى 0.3% مستوى تحذير مهما ضمن القواعد المنطبقة، وليس حظرا فوريا عاما.
3. المحتوى والسلوك (الرسالة وطريقة إرسالها): يؤثر الجمهور والسرعة والمحتوى. إرسال 10,000 رسالة من عنوان IP جديد في الساعة الأولى قد يكون محفوفا بالمخاطر. افحص الروابط المعطلة والتنسيق، لكن لا تفترض أن كلمة معينة أو نسبة الصور إلى النص قاعدة عامة للتصفية.
4. التصنيف (النتيجة): الوارد الأساسي أو العروض الترويجية أو الرسائل المزعجة أو الحجر. يتخذ المستقبل القرار النهائي، والعروض الترويجية ليست مرادفا للرسائل المزعجة.

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

خريطة الأعراض: قراءة الأخطاء

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

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

المرحلة 1: أساس SPF وDKIM وDMARC

تشكل المصادقة أساسا في قابلية تسليم البريد الإلكتروني. منذ مطلع 2024 تطبق Google وYahoo متطلبات إضافية على فئات من المرسلين الجماعيين، ومنها SPF وDKIM وDMARC. تتبع Microsoft متطلبات ومواعيد خاصة. تحقق من القواعد الحالية المنطبقة على جمهورك وحجم إرسالِك؛ فالامتثال لا يضمن الوصول إلى الوارد.

راجع شرح مصادقة البريد باستخدام SPF وDKIM وDMARC لترتيب الإعداد الكامل. وتوضح وثائق سجلات DNS المطلوبة إعدادات TrekMail الخاصة.

SPF (Sender Policy Framework)

يستخدم SPF سجل DNS من نوع TXT لتفويض أنظمة الإرسال لنطاق الظرف MAIL FROM، أو لهوية HELO في الحالات المنطبقة. لا يساوي ذلك تلقائيا نطاق From الظاهر. يقيّم المستقبل عنوان IP المرسل ويقرر التعامل مع النتيجة وفقا لسياسته.

يبدأ سجل SPF بـ v=spf1. تنتهي سجلات كثيرة بـ ~all (softfail) أو -all (fail)، لكن ذلك ليس الشكل الوحيد الممكن. تحدد الآليات والمعدلات بينهما الأنظمة المسموح بها. تحقق من قيم المزود الحالية قبل النشر.

يتكرر هذان النوعان من المشكلات وقد يؤثران في قابلية التسليم:

• مشكلة إعادة التوجيه: إذا أعاد Bob في Gmail توجيه رسالتك إلى Yahoo، فقد يرى Yahoo عنوان IP الخاص بـ Gmail بدلا من خادمك. قد يفشل SPF عندها. يمكن لتوقيع DKIM صحيح ومتوافق مع النطاق أن يسمح بنجاح DMARC، بشرط بقاء المحتوى الموقع صالحا بعد التوجيه.
• حد 10 عناصر DNS: يحد SPF الآليات والمعدلات ذات الصلة التي تستدعي DNS إلى 10 أثناء التقييم، بما يشمل العناصر المتداخلة على المسار المنفذ فعليا. وجود Gmail وOutlook وMailchimp وZendesk وCRM وخدمة معاملات لا يثبت وحده تجاوز الحد. قد ينتج عن التجاوز PermError، كما قد تسببه أخطاء أخرى. راجع حد عمليات البحث في SPF وإعداد سجل SPF للفحص والإصلاح.

DKIM (DomainKeys Identified Mail)

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

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

انتبه لطول مفتاح RSA: تذكر Google حدا أدنى قدره 1024 بت وتوصي بـ 2048 بت. المفاتيح القديمة بطول 512 بت لا تستوفي ذلك. عند التدوير، انشر مفتاح محدد جديد أولا ثم بدّل التوقيع، واحتفظ بالمفتاح العام القديم ما دامت الرسائل قيد النقل قد تحتاجه. راجع إعداد DKIM.

DMARC (سياسة معالجة المصادقة)

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

ينشر سجل DMARC من نوع TXT على _dmarc.yourdomain.com. الخيارات هي:

• p=none: لا يطلب الحجر أو الرفض بسبب فشل DMARC. تضبط التقارير بشكل منفصل وقد تكون غير مكتملة، ولا تضمن هذه السياسة تسليم الرسالة.
• p=quarantine: يطلب وضع الرسائل الفاشلة في الحجر أو معاملتها كرسائل مزعجة، مع بقاء القرار للمستقبل. راجعه بعد حصر مسارات الإرسال الشرعية ومراقبتها واختبارها.
• p=reject: يطلب رفض الرسائل الفاشلة. طبقه بحذر مع المراقبة وخطة للتراجع؛ ليس هدفا غير مشروط لكل بيئة.

من العقبات الشائعة مطابقة نطاق DMARC. لدى ESP مثل Mailchimp قد يستخدم Return-Path النطاق mailchimp.com. قد ينجح SPF لذلك النطاق دون مطابقته لنطاق From الخاص بك. يفشل DMARC عندها فقط إن لم يوجد أيضا توقيع DKIM صحيح ومتوافق.

راجع مصادقة النطاق المخصص لدى ESP: قد يتيح Return-Path الخاص بك مطابقة SPF، ويمكن أن توفر مطابقة DKIM مسارا آخر. راجع شرح مطابقة DMARC وإعداد DMARC للإعداد والتحقق.

قد يساعد معالج DNS في TrekMail، بحسب الميزات الحالية، في صياغة سجلات SPF وDKIM وDMARC بناء على إعداد إرسالِك. راجع جميع الخدمات والقيم المنشأة والنشر وذاكرة DNS المؤقتة. لا يغني المعالج عن تقييم حد 10 عناصر SPF ذات الصلة.

المرحلة 2: قابلية التسليم وأثر السمعة

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

مستوى التحذير 0.3%

تنشر Google وYahoo حدودا للشكاوى ضمن قواعد المرسلين المنطبقة. يعادل 0.3% حسابيا 3 شكاوى لكل 1,000 رسالة في المقام المستخدم. تحقق من تعريف المزود والفترة؛ فالمؤشرات اليومية ليست ببساطة جميع الرسائل المرسلة. قد يؤثر هذا المستوى في التصفية وأهلية إجراءات التخفيف، لكنه لا يعني حظرا فوريا أو دائما لدى كل جهة.

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

تصنيف المرسل الجماعي

تستخدم Google نحو 5,000 رسالة يوميا إلى حسابات Gmail الشخصية، مع التجميع على مستوى النطاق الأساسي. وفقا للقواعد الموصوفة، لا يزول التصنيف بمجرد تقليل الحجم لاحقا. تحقق من القواعد الحالية واعتنِ بـ سمعة نطاق البريد قبل التوسع. تدعم سمعة المرسل الجيدة الوصول إلى الوارد دون ضمانه.

سمعة النطاق وسمعة IP

قد يؤثر العاملان معا، ويجمع المستقبل إشاراتهما بطريقته.

• سمعة النطاق: ترتبط بنطاق الإرسال وربما بالنطاق التنظيمي. فصل التسويق يسهل الإدارة، لكنه لا يعزل النطاق الرئيسي عن كل أثر محتمل.
• سمعة IP: ترتبط بعنوان الإرسال. في استضافة مشتركة، مثل إعدادات cPanel أو GoDaddy، قد تؤثر حركة مرسلين آخرين. ليس ذلك دليلا على أن كل منصة مشتركة محظورة تلقائيا؛ تختلف الإدارة والبنية التحتية.

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

المرحلة 3: سلامة البنية التحتية

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

سجلات PTR وDNS العكسي

تحقق من سجل DNS عكسي (PTR) مناسب لعنوان الإرسال. يتطلب DNS العكسي المؤكد أماميا (FCrDNS) أن يعود اسم المضيف عبر A أو AAAA إلى عنوان IP المعني أيضا. عادة يدير مزود عنوان IP سجل PTR لخادم VPS الخاص بك. قد يوصف ذلك بإصلاح يستغرق 10 دقائق، لكن التشخيص والنشر قد يحتاجان مدة أطول.

تشفير TLS

تحقق من TLS على اتصالات SMTP وفقا لمتطلبات المستقبل وخدمة الإرسال. يحمي TLS النقل بين طرفي الاتصال، وليس تشفير الرسالة من طرف إلى طرف. لا تفترض إلزامه على جميع المسارات، حتى في TrekMail. راجع الإعداد الحالي واستعن بدليل فحص حالة DNS للسجلات، وافحص حماية النقل بصورة مستقلة.

الفروق بين Gmail وOutlook وYahoo

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

Google (Gmail)

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

يوفر Google Postmaster Tools معلومات عن معدلات الشكاوى وفئات السمعة (High / Medium / Low / Bad) للحركة المدعومة. هو أداة موصى بها، لا شرط إلزامي ولا سجل كامل لكل رسالة. راعِ التغطية وتأخر البيانات وحدود ظهورها.

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

راجع إرشادات Google لمرسلي البريد للمتطلبات الحالية ونطاق تطبيقها.

Microsoft (Outlook / Office 365)

تستحق المطابقة التقنية ومنع إساءة الاستخدام الاهتمام. إرسال 1,000 رسالة في اليوم 1 من عنوان جديد مثال على مخاطرة، وليس قاعدة حظر عامة. رد 451 أو 421 مؤقت وقد ينتج عن أسباب عديدة. اقرأ التفاصيل وارفع الحجم المناسب تدريجيا وفقا للنتائج.

يعرض Microsoft SNDS (Smart Network Data Services) بيانات متاحة لعناوين IP التي تملك صلاحية الاطلاع عليها، ومنها مؤشرات الشكاوى والحركة غير المرغوبة.

انتبه إلى كشف تخمين عناوين البريد (namespace mining). قد يكون الإرسال المكثف إلى عناوين غير موجودة إشارة ذات صلة. القائمة القديمة مخاطرة، لكنها لا تثبت هذا النشاط أو حظرا أسرع من Google. صنف أسباب الرفض الدائم قبل استبعاد العناوين.

راجع قواعد إحماء النطاق في TrekMail لمزيد من التوجيه التشغيلي.

Yahoo / AOL

للشكاوى أهمية لدى Yahoo. قد يجعل المقام المستخدم المعدل أعلى من حساب يعتمد على جميع الرسائل المرسلة.

المصدر الرسمي هو Yahoo Sender Hub.

تصف Yahoo مقام الشكاوى بأنه الرسائل المسلمة إلى الوارد، لا مجموع المرسل. مثال مبسط: ترسل 1,000 رسالة، تذهب 900 إلى الرسائل المزعجة و100 إلى الوارد، ويبلغ 1 مستلم عنها. النسبة حينئذ 1% (1/100)، لا 0.1% (1/1000). يوضح ذلك أثر المقام، وليس دوامة حتمية أو تنبؤا دقيقا بطريقة معالجة Yahoo لكل رسالة.

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

استجابة سريعة: الفحص الأولي خلال 24 ساعة

إذا تراجعت قابلية التسليم، استخدم هذا الترتيب لبدء التحقيق اليوم. عدّل الأولويات بحسب الأخطاء الفعلية؛ لا يعد العنوان بإنجاز التشخيص أو الإصلاح ضمن هذه المدة.

راجع أيضا قائمة فحص تحسين قابلية التسليم في 30 دقيقة. فيما يلي مسار الفحص الأولي:

الخطوة 1: الحد من الضرر الإضافي

يستدعي معدل شكاوى أعلى من 0.3% مراجعة سريعة بحسب القواعد المنطبقة. أوقف التسويق المسبب للمشكلة وافحص الموافقة ومعالجة الشكاوى. تختلف رسائل استعادة كلمة المرور والفواتير وتأكيد الطلبات، لكنها يجب أن تكون مشروعة ومتوقعة وتظل خاضعة للسياسات. لا تستأنف الحملات لمجرد انخفاض النسبة.

الخطوة 2: فحص قوائم الحظر

افحص عنوان الإرسال في MXToolbox وأكد الإدراج مباشرة لدى Spamhaus. قد تؤثر قائمة SBL (Spamhaus Block List) في المرشحات التي تستخدمها، لكنها لا توقف كل الإرسال تلقائيا. تحقق من العنوان ونطاق الإدراج والسبب وشروط الإزالة؛ مجرد الطلب ليس ضمانا للحذف.

الخطوة 3: إصلاح DNS

استخدم أداة تحقق مثل Email Health Check من MXToolbox ثم راجع النتائج بنفسك:

• SPF PermError، بسبب تجاوز حد 10 عناصر DNS ذات الصلة أو أخطاء إعداد أخرى
• محدد DKIM مفقود أو غير صحيح
• سجل DMARC مفقود، أو p=none دون استراتيجية واعية للمراقبة والإنفاذ؛ ليست هذه السياسة خطأ بحد ذاتها
• فشل مطابقة DMARC في التقارير التجميعية المتاحة، مع مراعاة أن تغطية التقارير قد تكون جزئية

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

الخطوة 4: صيانة القائمة

صيانة الجمهور مهمة. استبعد العناوين المؤكد بطلانها الدائم، لكن لا تعتبر كل رفض دائم عنوانا غير صالح؛ فقد ينتج عن المصادقة أو السياسة. قيّم المشتركين غير النشطين باستخدام الموافقة والتفاعلات الموثوقة. غياب فتح مقاس طوال ستة أشهر لا يثبت وحده عدم الاهتمام، لأن قياس الفتح قد يكون ناقصا.

استراتيجية طويلة الأجل: الوقاية

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

تنظيم التسويق على نطاق فرعي

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

تساعد سياسات DMARC والتقارير المنفصلة في الإدارة. لكن المستقبل قد يجمع إشارات النطاق الفرعي والنطاق التنظيمي وعنوان IP المشترك. الفصل ليس جدار حماية للسمعة.

إحماء IP

يملك العنوان الجديد تاريخ إرسال محدودا. جدول مثل 20 رسالة في اليوم 1 و40 في اليوم 2، ثم مضاعفة الحجم كل بضعة أيام خلال 4-6 أسابيع، مثال توضيحي لا وصفة عامة. حدد السرعة وفقا للرسائل المرغوبة والردود والسياسات. ظهور مشكلة في اليوم 3 لا يعني تلقائيا تقييد Microsoft، ولا يضمن الجدول القبول.

راجع قواعد إحماء النطاق في TrekMail للسياق التشغيلي.

المراقبة الأسبوعية

راجع Google Postmaster Tools ومعدلات الشكاوى والسمعة المتاحة بانتظام. الانتقال من High إلى Medium يستحق التحقيق لكنه لا يتنبأ بحظر مؤكد. يشرح دليل مراقبة قابلية تسليم البريد روتينا يقارب 10 دقائق أسبوعيا؛ قد يتطلب الحجم والمشكلات وقتا أطول.

دور TrekMail في بنية البريد الإلكتروني

يقارن المسؤولون عادة بين خيارين من خيارات التسعير والبنية التحتية. لا يوجد نموذج سيئ أو جيد لكل مؤسسة دون النظر إلى احتياجاتها.

الخيار A: التسعير لكل مستخدم. توضح المقارنة Google Workspace أو Microsoft 365 بمبلغ $6-$30 للمستخدم شهريا. تحقق من الخطط الحالية والميزات المضمنة. مع 50 عميلا و10 مستخدمين لكل عميل قد تصبح التكلفة كبيرة، لكن الخدمات الأخرى المضمنة قد تغير المقارنة.

الخيار B: بريد الاستضافة المشتركة. مثل حلول cPanel وGoDaddy وBluehost. قد يستخدم البريد المضمن عنوان إرسال مشتركا فتؤثر حركة الآخرين فيه. لا يعني ذلك أن كل عرض مجاني أو محظور تلقائيا أو يؤدي حتما إلى خسارة الأعمال.

تستهدف TrekMail المسؤولين الراغبين في تنظيم نطاقات وصناديق متعددة على منصة واحدة. قيّم مدى ملاءمة الميزات الحالية لاستخدامك.

تسعير منصة ثابت وتخزين مشترك

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

• Free: موصوف بحد أقصى 10 نطاقات و10 مستخدمين لكل نطاق و5GB من التخزين المجمع، مع مزود SMTP خاص ودون اشتراط بطاقة ائتمان. تحقق من الشروط الحالية.
• Starter ($3.50/mo أو $42/year): موصوف بـ 50 نطاقا و100 مستخدم لكل نطاق و15GB من التخزين المجمع، وSMTP مدار وأداة ترحيل IMAP من جهة الخادم. تحقق من التوفر والحدود.
• Pro ($8/mo أو $96/year): موصوف بـ 100 نطاق و300 مستخدم لكل نطاق و50GB من التخزين المجمع، وحدود إرسال أعلى وتوجيه باستخدام SRS وأداة ترحيل ودعم ذي أولوية. تحدد الشروط والإعدادات الحالية ما ينطبق.
• Agency: موصوف بـ 1,000+ نطاق و200GB+ من التخزين المجمع لمزودي الخدمات المدارة ذوي المحافظ الكبيرة. تحقق من العرض المناسب.

استخدام SMTP خاص: اختيار البنية بوعي

يمكن أن تتولى TrekMail استضافة IMAP والتخزين وإدارة الصناديق، بينما تربط للإرسال مزود SMTP خاصا مدعوما مثل Amazon SES أو SendGrid أو Mailgun. تحقق من التكامل الحالي والإعداد والمسؤوليات.

عنوان الإرسال عامل سمعة إلى جانب النطاق وغيره. لا يمنح حساب SES مستقل تلقائيا مجموعة IP مخصصة أو عزلا كاملا أو تصنيفا أفضل أو تكلفة أقل. تغيير مفتاح API يغير بيانات الاعتماد، ولا يعالج تلقائيا العنوان المحظور أو سبب إساءة الاستخدام. حدد العنوان الفعلي والسبب وعالجهما؛ وقد يكون تغيير إعداد مزود مشروع مناسبا بعد الاختبار. يمكن إبقاء استضافة الصناديق منفصلة مع مراجعة المصادقة والتوجيه والسياسة.

راجع وثائق استخدام مزود SMTP خاص للإعداد.

معالج DNS إرشادي

يساعد معالج TrekMail الموصوف في صياغة سجلات SPF وDKIM وDMARC بناء على إجاباتك. تحقق من الميزات الحالية وكل مسار إرسال وقيم المزود والنشر الفعلي. يجب تقييم حد 10 عناصر SPF ذات الصلة أيضا؛ لا يوجد ضمان لتوفير الوقت أو تعويض ثمن الاشتراك.

الترحيل من جهة الخادم

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

التوجيه الشامل وإعادة التوجيه باستخدام SRS

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

عند إعادة التوجيه، يعيد SRS (Sender Rewriting Scheme) كتابة عنوان الظرف وReturn-Path بنطاق خدمة التوجيه، مما قد يسمح بنجاح SPF لهذه الخدمة. لا يستعيد ذلك تلقائيا مطابقة SPF لنطاق From الأصلي الظاهر. قد يحتاج DMARC توقيع DKIM صحيحا ومتوافقا بقي صالحا، وقد يطبق المستقبل سياسات محلية لمسارات توجيه موثوقة.

خلاصة قابلية تسليم البريد الإلكتروني

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

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

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

للمزيد عن هوية الإرسال، اقرأ دليلَي سمعة النطاق وسمعة المرسل. راجع عرض TrekMail المجاني الحالي وشروطه على trekmail.net.