وصول البريد إلى صندوق الوارد: SPF وDKIM وDMARC وشروط جوجل

وصول البريد إلى صندوق الوارد: SPF وDKIM وDMARC وشروط جوجل

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

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

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

الخلاصة السريعة

  • وصول البريد (Deliverability) هو قدرة رسائلك على الوصول إلى صندوق الوارد لا إلى مجلد السبام، وهو مختلف عن مجرد قبول الخادم للرسالة.
  • المرسل بالجملة عند جوجل هو من يرسل قرابة 5,000 رسالة أو أكثر إلى حسابات Gmail الشخصية خلال 24 ساعة، وهذا التصنيف لا ينتهي بانتهاء الحملة.
  • نسبة البلاغات يجب أن تبقى أقل من 0.3% بحسب جوجل وياهو، وتوصي جوجل بإبقائها تحت 0.1%.
  • المرسلون بالجملة مطالبون بإعداد SPF وDKIM معا، ونشر سجل DMARC ولو بسياسة p=none، ومطابقة نطاق المرسل في الحقل From.
  • إلغاء الاشتراك بنقرة واحدة شرط للرسائل التسويقية، وتطلب ياهو تنفيذ طلبات الإلغاء خلال يومين، وتوصي جوجل بالمهلة نفسها تقريبًا (48 ساعة).

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

نرسل حملات بريدية من [اسم منصة البريد] باسم نطاقنا [example.com]، ونرجو: (1) إضافة المنصة إلى سجل SPF الحالي بالقيمة التي تعطيها [include:…] دون إنشاء سجل SPF ثان. (2) نشر سجلات DKIM التي ترسلها المنصة بنطاقنا، بمفتاح 2048 بت إن أمكن. (3) نشر سجل DMARC في _dmarc.[example.com] بسياسة p=none وعنوان تقارير rua=mailto:[بريد التقارير].

ما المقصود بوصول البريد إلى صندوق الوارد؟

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

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

ما هي سجلات SPF وDKIM وDMARC؟

ثلاثة سجلات نصية تضيفها في إعدادات النطاق (DNS)، ولكل واحد منها وظيفة مختلفة. الأفضل أن تتخيلها ثلاث طبقات من التحقق، لا ثلاثة بدائل تختار منها واحدًا.

SPF: من يحق له الإرسال باسم نطاقك؟

سجل SPF قائمة بالخوادم والخدمات المسموح لها بالإرسال باسم نطاقك. بحسب المعيار RFC 7208، يتحقق خادم المستلم من هوية المرسل في أمر MAIL FROM ومن اسم الخادم في التحية HELO، ثم يقارنهما بالقائمة المنشورة.

نقطتان تقنيتان تسببان مشكلات متكررة. الأولى أن المعيار يحدد 10 عمليات بحث DNS كحد أقصى أثناء تقييم السجل، وتجاوزها ينتج خطأ دائمًا (permerror)، وهذا يحدث عادة عندما تضيف أداة بعد أخرى عبر include. والثانية الفرق بين نهاية السجل -all التي تعني تصريحا واضحًا بأن أي خادم غير مدرج غير مخول بالإرسال، و~all التي تعني أن الخادم غالبًا غير مخول دون جزم، ولا ينبغي رفض الرسالة بناء عليها وحدها.

DKIM: توقيع رقمي على كل رسالة

يضيف DKIM توقيعا مشفرا إلى الرسالة يثبت أن النطاق الموقع يتحمل مسؤوليتها وأن محتواها لم يتغير في الطريق. يوضح المعيار RFC 6376 أن المفتاح العام ينشر في DNS تحت اسم فرعي بصيغة selector._domainkey، وأن الوسم d= في التوقيع يحدد النطاق الموقع. ووجود المحدد (selector) يتيح لك نشر أكثر من مفتاح في الوقت نفسه، فتستطيع تغيير المفاتيح دون توقف الإرسال.

وماذا عن طول المفتاح؟ تذكر جوجل في إرشادات المرسلين أن الإرسال إلى حسابات Gmail الشخصية يتطلب مفتاح DKIM بطول 1024 بت أو أكثر، وتوصي باستخدام مفتاح 2048 بت إن كان مزود النطاق يدعم ذلك. ويتفق هذا مع المعيار RFC 8301 الذي يوجب على الموقعين استخدام مفاتيح RSA بطول 1024 بت على الأقل، ويوصي بطول 2048 بت، ولا يعد التوقيعات بمفاتيح أقصر من 1024 بت صالحة. لذلك اختر 2048 بت عند توليد المفتاح في منصة الإرسال إن أتاحت ذلك، وإن لم يدعمه مزود النطاق فلا تنزل عن 1024 بت.

DMARC: السياسة التي تربط كل شيء

DMARC يجيب عن سؤال لا يجيب عنه SPF ولا DKIM وحدهما: هل النطاق الذي تم التحقق منه هو نفسه النطاق الظاهر للقارئ في حقل From؟ هذا ما يسمى المطابقة (Alignment). في مايو 2026 صدر المعيار RFC 9989 ليحل محل RFC 7489 الذي عرف به DMARC منذ 2015 (ومعه RFC 9091)، وينشر السجل في اسم فرعي هو _dmarc.example.com.

ومن أبرز ما تغير في نص RFC 9989 أنه يستخدم آلية «DNS Tree Walk» لتحديد النطاق التنظيمي بدل الاعتماد على قائمة اللواحق العامة (Public Suffix List)، ويضيف الوسمين psd وnp، ووسم اختبار جديدًا هو t يطلب من المستقبل تطبيق سياسة أخف بدرجة واحدة عندما تكون قيمته y. ويحمل المعيار ملحقا بعنوان «Removal of the pct Tag»، أي أن الوسم pct أزيل منه، فلا تبن خطة التدرج في سياستك على pct، وراجع الملحق نفسه إن كان إعدادك الحالي يعتمد عليه.

السياسة تحدد عبر الوسم p بثلاث قيم: none ولا تطلب أي إجراء، وquarantine وتعني أن الرسائل الفاشلة مشبوهة، وreject وتعني أن فشلها دليل واضح على إساءة استخدام النطاق. أما الوسم rua فيحدد عنوانًا تصلك عليه تقارير مجمعة عن كل من يرسل باسم نطاقك، وهي أداة كشف قبل أن تكون أداة حماية.

أرقام شروط جوجل وياهو لوصول البريد إلى صندوق الوارد
المصدر: إرشادات المرسلين في Gmail وYahoo Sender Hub

ماذا تشترط جوجل وياهو على المرسلين؟

بدأت جوجل وياهو تطبيق متطلباتهما في فبراير 2024. وتنص إرشادات المرسلين في مركز مساعدة Gmail على أن الشروط تبدأ من 1 فبراير 2024، مع شروط أساسية لكل من يرسل إلى حسابات Gmail، وشروط إضافية للمرسلين بالجملة. وتوضح جوجل في أسئلتها الشائعة أن المتطلبات وإجراءات التطبيق تخص الرسائل المرسلة إلى حسابات Gmail الشخصية، لا الرسائل الواردة إلى حسابات Google Workspace.

المتطلبجوجل (Gmail)ياهو
التوثيق لكل المرسلينSPF أو DKIMSPF أو DKIM كحد أدنى
التوثيق للمرسلين بالجملةSPF وDKIM معًا + DMARCSPF وDKIM معًا + DMARC
سياسة DMARC المقبولةيمكن أن تكون nonep=none على الأقل، ويجب أن ينجح DMARC
مطابقة نطاق Fromمع نطاق SPF أو DKIMمع نطاق SPF أو DKIM، والمطابقة المرنة مقبولة
نسبة البلاغاتأقل من 0.3%، والموصى به أقل من 0.1%أقل من 0.3%
إلغاء الاشتراكنقرة واحدة للرسائل التسويقيةترويسة List-Unsubscribe، ويفضل أسلوب POST وفق RFC 8058
مهلة تنفيذ الإلغاءتوصية بالتنفيذ خلال 48 ساعةخلال يومين
البنية التقنيةسجلات DNS أمامية وعكسية (PTR) واتصال TLSسجلات DNS أمامية وعكسية

أما ياهو فتذكر في صفحة أفضل الممارسات على Yahoo Sender Hub أن التطبيق بدأ في فبراير 2024 بشكل تدريجي، وتشترط الالتزام بالمعيارين RFC 5321 وRFC 5322، وتنبه إلى أن نسبة البلاغات تحسب على الرسائل التي وصلت فعلًا إلى صندوق الوارد.

ويغطي هذا الدليل جوجل وياهو فقط. أما بريد Outlook فنشرت مايكروسوفت بشأنه مقالة بعنوان Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders في مدونة Microsoft Defender for Office 365 عن متطلبات جديدة للمرسلين بكميات كبيرة، وتشير المقالة إلى تحديث بتاريخ 29 أبريل 2025 غير الإجراء المتخذ مع الرسائل غير المطابقة. ارجع إلى المقالة نفسها للاطلاع على الحد اليومي وتاريخ التطبيق والإجراء المتخذ حاليًا قبل أي حملة كبيرة إلى عناوين Outlook.

من هو المرسل بالجملة؟ ولماذا يهمك هذا التصنيف؟

قد تظن أن متجرك الصغير بعيد عن هذا التصنيف. لكن الحساب بسيط: قائمة فيها 20 ألف مشترك، ثلثهم تقريبًا على Gmail، تعني قرابة 6,700 رسالة إلى Gmail في حملة واحدة. هذا مثال افتراضي، لكنه يوضح كيف يتجاوز متجر متوسط الحد في يوم إرسال واحد.

بحسب صفحة الأسئلة الشائعة لإرشادات جوجل، المرسل بالجملة هو من يرسل قرابة 5,000 رسالة أو أكثر إلى حسابات Gmail الشخصية خلال 24 ساعة. والأهم نقطتان: الرسائل الصادرة من النطاق الرئيسي نفسه تجمع معا، فنطاق المتجر ونطاقه الفرعي للعروض يحسبان مرسلا واحدًا. وتصنيف المرسل بالجملة ليس له تاريخ انتهاء، فلن يزول إذا خفضت الإرسال لاحقًا.

ماذا تغير في التطبيق منذ 2024؟

لم تطبق الشروط دفعة واحدة. في فبراير 2024 دخلت متطلبات المرسلين بالجملة حيز التنفيذ. ومنحت جوجل، بحسب أسئلتها الشائعة، من لديهم رابط إلغاء اشتراك في الرسائل مهلة حتى 1 يونيو 2024 لإضافة الإلغاء بنقرة واحدة. ومنذ يونيو 2024 صار المرسل بالجملة الذي تتجاوز نسبة البلاغات عنده 0.3% غير مؤهل لطلب معالجة مشكلات التسليم، ولا يستعيد الأهلية إلا بعد بقاء النسبة تحت 0.3% لمدة 7 أيام متتالية.

ثم أعلنت جوجل في أسئلتها الشائعة أنها بدأت من نوفمبر 2025 تشديد التطبيق على الرسائل غير الملتزمة. والنتيجة قد تكون رفضا مؤقتا أو دائمًا. وتذكر جوجل في الصفحة نفسها أن الأخطاء المؤقتة تحمل رموزا مثل 4.7.23 و4.7.27 تشير إلى الشرط الذي فشلت فيه الرسالة، وأن الحظر يحمل رموزا مثل 5.7.27 لفشل SPF و5.7.30 لفشل DKIM. لذلك إن رأيت هذه الرموز في تقارير منصة الإرسال فلا تتجاهلها.

كيف يعمل إلغاء الاشتراك بنقرة واحدة؟

اعتراض شائع: عندي رابط إلغاء اشتراك في أسفل كل رسالة، فلماذا أحتاج شيئًا آخر؟ لأن المقصود هنا ترويسة تقنية في الرسالة، يقرؤها Gmail وYahoo ليتيحا للمشترك إلغاء الاشتراك مباشرة من واجهة البريد. وبحسب المعيار RFC 8058 تحتاج الرسالة إلى ترويستين: List-Unsubscribe وتحتوي على رابط HTTPS، وList-Unsubscribe-Post بالقيمة List-Unsubscribe=One-Click، ويجب أن يغطي توقيع DKIM الترويستين معًا.

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

خطوات إعداد SPF وDKIM وDMARC لتحسين وصول البريد
مبني على إرشادات Gmail ومعايير IETF

كيف تجهز نطاقك خطوة بخطوة؟

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

  1. اجرد كل من يرسل باسم نطاقك: منصة البريد التسويقي، ومتجرك الإلكتروني، ونظام خدمة العملاء، وبريد الموظفين. أي خدمة تنساها ستفشل لاحقًا في التحقق.
  2. انشر سجل SPF واحدًا فقط: اجمع كل الخدمات في سجل واحد، وراقب ألا تتجاوز 10 عمليات بحث DNS.
  3. فعل DKIM من داخل كل منصة: انسخ السجلات التي تعطيك إياها المنصة إلى DNS، واستخدم نطاقك أنت لا النطاق الافتراضي للمنصة، حتى تتحقق المطابقة.
  4. ابدأ DMARC بسياسة p=none مع تقارير rua: راقب التقارير بضعة أسابيع لتكتشف أي خدمة نسيتها قبل تشديد السياسة.
  5. انتقل تدريجيًا إلى quarantine ثم reject: بعد التأكد أن كل مصادر الإرسال الشرعية تنجح في التحقق.
  6. سجل نطاقك في Google Postmaster Tools: لأن جوجل تقيس نسبة البلاغات من خلال هذه الأداة، فهي المكان الذي تتابع فيه الرقم الذي ستحاسب عليه.
  7. اختبر رسالة حقيقية: أرسلها إلى حساب Gmail، وافتح خيار عرض المصدر الأصلي، وتأكد أن SPF وDKIM وDMARC كلها بنتيجة PASS.

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

كيف تحافظ على نسبة البلاغات تحت الحد؟

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

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

ولا تنس أن البريد قناة ضمن منظومة أكبر، وتجد الصورة الكاملة في دليل التسويق الإلكتروني الشامل.

أخطاء شائعة تسقط رسائلك في السبام

  • سجلا SPF للنطاق نفسه: يضيف أحدهم سجلا جديدًا بدل تعديل القديم، فيفشل التحقق كله.
  • DKIM باسم المنصة لا باسم نطاقك: الرسالة موقعة، لكن التوقيع لا يطابق نطاق From فيفشل DMARC.
  • القفز إلى reject مباشرة: ترفض فجأة رسائل الفواتير أو الدعم لأن أداتها لم تضف إلى السجلات.
  • نشر DMARC دون قراءة التقارير: السجل موجود شكليا، ولا أحد يعرف من يرسل باسم النطاق.
  • إرسال حملة ضخمة من نطاق جديد: قفزة مفاجئة بلا تاريخ إرسال، وهي عكس ما توصي به جوجل.
  • الاكتفاء بنسبة الفتح لقياس الوصول: نسبة الفتح لم تعد مؤشرا دقيقا، والأدق متابعة Postmaster Tools ورموز الرفض.
  • قائمة قديمة لم تنظف: عناوين لم تتفاعل منذ مدة وأخرى لم تعد صالحة قد تزيد البلاغات والارتداد، فاحرص على تسجيل حالة كل مشترك واشتراكه في نظام إدارة علاقات العملاء CRM بدل ملفات متفرقة.

هل يكفي الالتزام بهذه الشروط لضمان صندوق الوارد؟

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

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

وحملة الجمعة البيضاء على 40 ألف مشترك؟ حين تفتح «عرض الرسالة الأصلية» في رسالة اختبار تجد السبب في ثلاثة أسطر: SPF يفشل لأن أداة الحملات ليست في السجل، وDKIM موقع باسم المنصة لا باسم نطاقك، فيسقط DMARC. تضيف الأداة إلى السجل، وتفعل DKIM بنطاقك، وتنشر DMARC بسياسة p=none، ثم ترسل الاختبار مرة أخرى فتظهر الأسطر الثلاثة بنتيجة PASS. عندها فقط يصبح السؤال عن العرض والتصميم سؤالًا مفيدا.

أسئلة شائعة

هل أحتاج SPF وDKIM وDMARC إذا كنت أرسل عددا قليلًا من الرسائل؟

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

كم عدد الرسائل التي تجعلني مرسلا بالجملة عند جوجل؟

تعتبرك جوجل مرسلا بالجملة إذا أرسلت قرابة 5,000 رسالة أو أكثر إلى حسابات Gmail الشخصية خلال 24 ساعة. وتجمع الرسائل الصادرة من النطاق الرئيسي نفسه ونطاقاته الفرعية في عدد واحد. وهذا التصنيف لا ينتهي بمرور الوقت، فيبقى قائما حتى لو خفضت حجم الإرسال لاحقًا.

ما هي نسبة البلاغات المسموح بها في Gmail؟

تشترط جوجل إبقاء نسبة البلاغات المسجلة في Postmaster Tools أقل من 0.3%، وتوصي بإبقائها تحت 0.1%. وياهو تضع الحد نفسه 0.3%. ومنذ يونيو 2024 يفقد المرسل بالجملة الذي يتجاوز 0.3% أهلية طلب معالجة مشكلات التسليم، حتى تبقى النسبة تحت الحد 7 أيام متتالية.

هل يكفي DMARC بسياسة p=none؟

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

ما الفرق بين رابط إلغاء الاشتراك وإلغاء الاشتراك بنقرة واحدة؟

الرابط في أسفل الرسالة يأخذ القارئ إلى صفحة قد تطلب منه خطوات إضافية. أما الإلغاء بنقرة واحدة فهو ترويسة تقنية وفق المعيار RFC 8058 يقرؤها Gmail وYahoo ليتيحا للمشترك إلغاء الاشتراك من واجهة البريد نفسها، فيرسل الطلب إلى المرسل مباشرة دون صفحات إضافية. والمطلوب للرسائل التسويقية هو هذا النوع.

كيف أعرف أن رسائلي تجتاز التحقق؟

أرسل رسالة اختبار إلى حساب Gmail، ثم افتح خيار عرض الرسالة الأصلية، وستجد نتيجة SPF وDKIM وDMARC لكل منها. النتيجة المطلوبة هي PASS للثلاثة، وإن فشل أحدها فراجع السجل الخاص به قبل أي حملة. وبعدها سجل نطاقك في Google Postmaster Tools لتتابع نسبة البلاغات وحالة التوثيق بشكل مستمر.

اقرأ أيضًا

  1. سطر عنوان البريد: كيف تكتب عنوان إيميل يُفتح؟
  2. أتمتة التسويق: ما هي وكيف تبدأ بها في مشروعك
  3. التسويق عبر البريد الإلكتروني للمتاجر: دليل البداية

هل تصل حملاتك فعلًا إلى صندوق الوارد؟

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

اكتشف خدمة أتمتة التسويق ←

المصادر

  1. Email sender guidelines — Gmail Help (Google)
  2. Email sender guidelines FAQ — Gmail Help (Google)
  3. Sender Best Practices — Yahoo Sender Hub
  4. RFC 8058: Signaling One-Click Functionality for List Email Headers — IETF / RFC Editor
  5. RFC 7208: Sender Policy Framework (SPF) — IETF / RFC Editor
  6. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — IETF / RFC Editor
  7. RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) — IETF / RFC Editor
  8. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF / RFC Editor
  9. Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders — Microsoft Defender for Office 365 Blog (Microsoft Tech Community)

أضف تعليقا