تخطَّ إلى المحتوى

دليل إجرائي

حين يقع بريد شركتك في المزعج: SPF وDKIM وDMARC

المشكلة ليست في الصياغة غالبًا، بل في سجلات DNS الثلاثة التي تقول من يحقّ له الإرسال نيابةً عن نطاقك. وهذه هي، بالترتيب.

كُتب لـ: الشركات التي لا تصل عروضها وفواتيرها وإشعاراتها إلى الطرف الآخرآخر تحديث: 9 دقيقة قراءة

باختصار

لماذا تقع الرسائل التي أرسلها في مجلد البريد المزعج؟

لا يقع بريدك في المزعج بسبب صياغته عادةً، بل لأنّ السجلات التي تحدّد من يحقّ له الإرسال نيابةً عن نطاقك غائبة. والمطلوب ثلاثة: SPF يُدرج خوادم الإرسال، وDKIM يوقّع الرسالة، وDMARC يقول ماذا يُفعل حين لا يتطابق الاثنان. وتُعِدّ Neuros الثلاثة معًا في إعدادات البريد المؤسسي؛ فإن غاب واحد لم يكفِ الآخران وحدهما.

الخطوات

0 / 7 خطوات

  1. أدرِج من يرسل نيابةً عنك

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

    تنبيه: كلّ إعداد يتخطّى هذه الخطوة تقريبًا يعود بعد أسبوعين بجملة «الفواتير لا تخرج».

  2. اكتب سجلّ SPF

    يُضاف إلى DNS نطاقك سجلّ TXT واحد يُدرج الخوادم المصرّح لها بالإرسال باسمك. ويجب أن يكون سجلًّا واحدًا: فسجلّان لـSPF على النطاق نفسه يُبطلان الفحص.

  3. فعّل توقيع DKIM

    يولّد مزوّد بريدك زوج مفاتيح؛ تنشر أنت المفتاح العام في DNS، ويوقّع المزوّد كلّ رسالة صادرة بالمفتاح الخاص. ويتحقّق المستقبِل من التوقيع فيرى أنّ الرسالة لم تُعدَّل في الطريق.

  4. ابدأ DMARC في وضع الإصغاء

    انشر سجلّ DMARC الأول بـ`p=none` وبعنوان للتقارير. هذا لا يحجب شيئًا لكنّه يبلّغك بمن يرسل باسمك. والمصادر التي فاتتك في الجرد تظهر هنا.

    تنبيه: أصغِ أسبوعين على الأقل. وإن كان شيء ما يرسل شهريًا، فانتظر شهرًا.

  5. اقرأ التقارير وأغلِق الثغرات

    تُظهر التقارير مصادر مشروعة تفشل في التوثيق. أضِف كلًّا منها إلى قائمة SPF أو فعّل لها توقيع DKIM. والهدف قائمةُ تقارير لا تضمّ إلّا مصادر تعرفها.

  6. شدّد على مراحل

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

    تنبيه: `p=reject` هو الوجهة لا نقطة البداية. والبدء منه يرفض بريدًا مشروعًا أيضًا.

  7. ضَع التسليم تحت المراقبة

    راقب معدّل شكاوى الإزعاج في Postmaster Tools؛ فيجب أن يبقى دون عتبة 0.3٪. وحتى مع سجلات صحيحة، يتدهور التسليم حين يرتفع هذا المعدّل.

هل تغيير نصّ الرسالة يمنعها من الوقوع في البريد المزعج؟

حين يقع بريد الشركة في مجلد المزعج، يكون ردّ الفعل الأول تغيير الصياغة: حروف كبيرة أقلّ، وحذف كلمة «مجاني»، وتقليل الروابط. وقد يُحدث ذلك فرقًا صغيرًا أحيانًا، لكنّ القرار يُتَّخذ قبل ذلك بكثير. فالخادم المستقبِل يسأل أولًا: هل تأتي هذه الرسالة فعلًا من هذا النطاق؟

وجواب هذا السؤال يعيش في DNS لا في النصّ. وبغياب الجواب تُعامَل الرسالة كأنّها من مرسِل غير موثَّق مهما كان محتواها نظيفًا — ومعظم المستقبِلين المؤسسيين يضعون هذه الرسائل إمّا في المزعج أو في سلة المهملات مباشرة.

استعلامات تجيب عنها هذه الصفحة

  • رسائلي تذهب إلى البريد المزعج ماذا أفعل
  • ما هو spf dkim dmarc وكيف يتم إعداده
  • بريد الشركة لا يصل
  • جيميل يحجب رسائلي
  • ماذا يعني dmarc p=none
  • بريد الفاتورة لا يصل إلى العميل
  • شخص يرسل رسائل من نطاقي
  • كيف أتحقق من سجل spf

ما هي SPF وDKIM وDMARC وما الفرق بينها؟

SPF وDKIM وDMARC — ماذا يقول كلّ منها
السجلّماذا يقولماذا يحدث بدونه
SPFهذه الخوادم مصرّح لها بالإرسال نيابةً عن هذا النطاقلا يستطيع المستقبِل معرفة ما إذا كان خادم الإرسال مصرّحًا له
DKIMوُقِّعت هذه الرسالة بالمفتاح الخاص للنطاق ولم تُعدَّل في الطريقلا يمكن إثبات سلامة الرسالة عند إعادة توجيهها أو العبث بها
DMARCإذا فشل SPF أو DKIM، فافعل هذا بالرسالة وأبلِغنيلا يُحجب انتحال هويّتك، ولا ترى أبدًا من يرسل باسمك

لا بدّ أن تعمل الثلاثة معًا. فالشركة التي تملك SPF وحده تفقد التوثيق كلّما أُعيد توجيه رسالة. والتي تملك DKIM وحده لا تعرف أبدًا من يرسل باسمها. أما الإعداد الخالي من DMARC فأعزل أمام انتحال اسمك — وهو الشكل الأكثر شيوعًا لاحتيال الفواتير.

ماذا يشترط Gmail على المرسِلين بكميات كبيرة؟

رفعت Google العتبة بمتطلبات للمرسِلين دخلت حيّز التنفيذ في شباط/فبراير 2024. فيُتوقَّع من كلّ من يرسل إلى حسابات Gmail الشخصية أن يملك SPF أو DKIM، وسجلات DNS أمامية وعكسية صالحة، وإرسالًا عبر TLS، ومعدّل شكاوى إزعاج دون 0.3٪.

ولمن يرسل أكثر من 5٬000 رسالة يوميًا ترتفع العتبة: SPF وDKIM معًا، إضافةً إلى DMARC (وقد تكون السياسة `p=none`)، ومواءمة بين النطاق في ترويسة From: وبين نطاق SPF أو DKIM، وإلغاء اشتراك بنقرة واحدة في الرسائل التسويقية. والشركة التي تتجاوز تلك العتبة بسجلات ناقصة قد تفقد قابلية التسليم بين ليلة وضحاها.

ما أكثر الأخطاء شيوعًا في سجلّ SPF؟

  • وجود سجلّي SPF على النطاق نفسه — فيُعدّ السجلّ غير صالح ويفشل التوثيق.
  • تجاوز حدّ عمليات الاستعلام عند إضافة مصدر إرسال جديد؛ فمع طول السلسلة يتوقّف السجلّ عن العمل بصمت.
  • بدء DMARC مباشرةً بـ`p=reject` فتُسكَت مصادر مشروعة لم يكن أحد يعلم بها.
  • نشر DMARC دون عنوان للتقارير — أي ألّا تُجمع أبدًا البيانات اللازمة لتشديد السياسة.
  • نسيان النطاقات الفرعية: فإن كان البريد يخرج عبر `invoices.company.com`، فذلك المضيف يحتاج سجلاته الخاصة.

لماذا لا تصل رسائل الفواتير إلى العملاء؟

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

والثاني: جانب الإرسال بالجملة، فإن كنت ترسل رسائل إلكترونية تجارية، فإنّ التزامات إدارة الرسائل الوطنية منفصلة عن التسليم التقني لكنّها تمسّ الإرسال نفسه. ورابط إلغاء الاشتراك يجب أن يعمل بنقرة واحدة تقنيًا وأن يُعالَج في النظام كسجلّ؛ وإن تُتبِّع على حدة أو لم يُتتبَّع أصلًا، ارتفع معدّل الشكاوى وتدهور التسليم حتى مع سجلات صحيحة.

كم يستغرق إعداد SPF وDKIM وDMARC؟

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

هل أستطيع الإرسال من نطاق جديد تمامًا؟

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

هل إرسال بريد العمل من Gmail شخصي مشكلة؟

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

هل أستخدم نطاقًا منفصلًا للإرسال بالجملة؟

إن كان حجم التسويق معتبرًا، فنعم — لكن كنطاق فرعي. فحين يُفصل النطاق الرئيسي الحامل للفواتير والعروض عن النطاق الفرعي الحامل للنشرة البريدية، لا تضرّ شكوى على النشرة سمعةَ النطاق الرئيسي. أما في الشركات التي لا تفصل، فحملة واحدة سيئة ترسل إشعارات الفواتير إلى المزعج أيضًا.

ومن سيقرأ تقارير DMARC؟

التقارير الخام بصيغة XML وليست مصمّمة لتُقرأ يدويًا؛ واستخدام خدمة لمعالجة التقارير يكاد يكون إلزاميًا. والباقات المجانية تكفي عند الحجم المنخفض. والتقرير غير المقروء يعادل غياب السجلّ: فإن لم يرَ أحد البيانات اللازمة لتشديد السياسة، صار `p=none` دائمًا ولم يقدّم أيّ حماية من الانتحال.

هل تتسبّب صورة في التوقيع بالوقوع في المزعج؟

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

مشكلة البريد المزعج لا تكون في النصّ إلّا نادرًا؛ فالخادم المستقبِل يتحقّق من الهوية قبل أن يقرأ كلمة واحدة.

المصادر

  1. 01RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in EmailIETF · 2014
  2. 02RFC 6376 — DomainKeys Identified Mail (DKIM) SignaturesIETF · 2011
  3. 03RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)IETF · 2015
  4. 04Email sender guidelinesGoogle Workspace Admin Help · 2026
  5. 05e-Fatura, e-Arşiv ve e-İrsaliye teknik kılavuzlarıGelir İdaresi Başkanlığı · 2024

الأسئلة الشائعة

أسئلة تتكرّر علينا

تؤدّي الثلاثة وظائف مختلفة ولا يغني أحدها عن الآخر. فـSPF يوثّق خادم الإرسال لكنّه ينكسر عند إعادة التوجيه. وDKIM يثبت سلامة الرسالة لكنّه لا يربط الإرسال بسياسة. وDMARC يجمع الاثنين في قاعدة مصحوبة بتقارير. ومتطلبات Gmail للمرسِلين بالجملة تطلب الثلاثة كذلك.

تقنيًا نعم، وعمليًا لا. فلدى كل شركة تقريبًا مصادر إرسال مشروعة لا تعلم بها: إضافة نماذج قديمة، أو برنامج محاسبة، أو مُكامِل فاتورة إلكترونية، أو نظام حجز تابع لطرف ثالث. والبدء بـ`p=reject` يُسكِتها جميعًا بين ليلة وضحاها، والخسارة تظهر عادةً بعد أيام حين يقول عميل: «راسلتكم ولم يردّ أحد».

ثلاثة أسباب شائعة. الأول المواءمة: السجلات موجودة لكنّ نطاق From: غير متوائم مع نطاق SPF أو DKIM، فيبقى التوثيق محسوبًا فاشلًا. والثاني السمعة: فإن تجاوز معدّل شكاوى الإزعاج عتبة 0.3٪ تدهور التسليم حتى مع سجلات صحيحة. والثالث تاريخ النطاق: فإرسال جماعي مفاجئ من نطاق جديد أو خامل منذ زمن يبدو مريبًا.

من تقارير DMARC. فما إن تنشر سجلّ DMARC بعنوان للتقارير حتى تُلخّص الخوادم المستقبِلة كلّ محاولة إرسال باسمك — أيّ عنوان IP، وكم رسالة، وهل نجح التوثيق. وإن كان مهاجم يرسل فواتير مزوّرة باسمك، فأول دليل يظهر هنا، ولا يظهر في مكان آخر.

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

لنمرّ بهذه الخطوات معًا

نقف إلى جانبك بينما تطبّق أيًا من هذا على مشروعك.