عميلك يتصل بك يسأل ليش ما استلم فاتورة الشهر الماضي. تروح تشيك في Odoo، الإيميل ظاهر إنه "مُرسَل". لكنه نزل في مجلد Spam، أو الأسوأ، ما وصل أصلاً. إذا كنت تشغّل Odoo أو أي نظام CRM أو أي رسائل تلقائية من دومينك الخاص، وما لمست SPF أو DKIM أو DMARC خلال السنة الماضية، فهذا يصير معك الحين، وأنت لسا ما تدري.

ليش الموضوع صار مهم هالفترة

لسنوات طويلة، كان SPF وDKIM شي "زين لو موجود". Gmail وYahoo كانوا يكتفون بوضع علامة على الرسائل المشبوهة كـ spam ويمشون. هذا انتهى. التطبيق تحول من فلترة سلبية إلى رفض فعلي — الرسائل غير الملتزمة الآن تُرفض على مستوى SMTP قبل ما توصل لأي صندوق، سواء الوارد أو حتى الـ spam. سيرفر البريد عندك يستلم bounce، والفاتورة ببساطة ما تصل خلاص.

إرشادات Gmail الرسمية واضحة: المرسِلون لازم يهيّئوا الرسائل حسب RFC 5322 ويحافظوا على معدل شكاوى spam المسجّل في Google Postmaster Tools تحت 0.30%. Yahoo سارت على نفس الاتجاه، وتطلب سجلات SPF وDKIM وPTR صحيحة مع TLS من كل مرسِل، مع اشتراط توافق DMARC لمرسلي البريد الجماعي (bulk senders)، ونفس سقف 0.30% لمعدل الـ spam، وخاصية إلغاء الاشتراك بنقرة واحدة. إذا كان Odoo عندك يرسل عروض أسعار أو فواتير أو تذكيرات دفع أو كشوف حساب مباشرة لعناوين Gmail أو Yahoo — وهذا حال أغلب الشركات — فهذه القواعد تنطبق عليك سواء ترسل عشرة إيميلات باليوم أو عشرة آلاف.

الأركان الثلاثة — كل واحد يتحقق من إيش فعلياً

SPF (Sender Policy Framework) هو سجل DNS من نوع TXT يحدد أي سيرفرات بريد مسموح لها ترسل إيميلات باسم دومينك. لما سيرفر الاستقبال يستلم رسالة، يتحقق هل الـ IP المُرسِل موجود في هالقائمة المعتمدة. ما فيه تطابق، ما فيه قبول.

DKIM (DomainKeys Identified Mail) يرفق توقيع تشفيري لكل رسالة صادرة، يتولد من مفتاح خاص على سيرفر البريد عندك ويتم التحقق منه مقابل مفتاح عام منشور في DNS. Yahoo Sender Hub يشترط طول مفتاح لا يقل عن 1024 بت لهذا التوقيع، والغرض منه تحديداً إنه يخلي سيرفر الاستقبال يتأكد إن محتوى الرسالة ما تغيّر أثناء النقل.

DMARC (Domain-based Message Authentication, Reporting and Conformance) يربط الاثنين مع بعض. يخبر سيرفرات الاستقبال إيش يسوّون لو فشلت الرسالة في SPF أو DKIM، والأهم — يتحقق من التوافق (alignment): هل الدومين الظاهر في هيدر "From:" يطابق فعلاً الدومين اللي نجح في SPF أو DKIM؟ Google واضحة بهالخصوص: بالنسبة للبريد المباشر، الدومين في هيدر From: للمرسِل لازم يكون متوافق مع دومين SPF أو دومين DKIM، وإلا تتفعّل سياسة الحجر الاحترازي (quarantine) عند Gmail.

مرسِل عادي أو bulk sender — أي القواعد تلزمك؟

Google تفصل بين المرسِلين "العاديين" و"مرسِلي البريد الجماعي" (bulk senders) — وهم تقريباً أي جهة ترسل كمية كبيرة من البريد لحسابات Gmail الشخصية، وهذا عملياً يشمل أغلب أنظمة Odoo اللي ترسل فواتير لصناديق العملاء بشكل واسع. مرسلو البريد الجماعي مُلزَمون بإعداد SPF وDKIM وDMARC — مو خيار ولا توصية. إرشادات Google تقولها صراحة: bulk senders مطالبون بإعداد SPF وDKIM وDMARC. إذا كان Odoo أو CRM أو أداة التسويق عندك يرسل حملات ترويجية بالإضافة للفواتير من نفس الدومين، افترض إنك bulk sender واضبط إعداداتك على هالأساس. ما فيه خسارة إنك تتجاوز الحد الأدنى المطلوب هنا، وبيوفر عليك مشكلة الـ bounce.

خطوة بخطوة: نشر SPF وDKIM بشكل صحيح

ابدأ بـ SPF. في منطقة DNS عندك، أضف سجل TXT واحد فقط على جذر الدومين المُرسِل. إذا كنت ترسل عبر Google Workspace، غالباً يكون شكله كذا:

v=spf1 include:_spf.google.com ~all

إذا كان Odoo يرسل عبر relay SMTP خاص فيه، أو relay من طرف ثالث (SendGrid، Mailgun، إلخ)، أو سيرفر بريد خاص بك، لازم تدمج كل هالمصادر في سجل واحد — وهنا بالضبط أغلب المسؤولين يغلطون (نتكلم عنها بعد شوي). بعد ما تنشر السجل، انتشار DNS ممكن ياخذ حتى 48 ساعة، فما تستعجل لو فشل اختبار بعد ساعة من حفظ السجل — انتظر قبل ما تكمل استكشاف الخلل.

بعدين، DKIM. ولّد زوج مفاتيح على سيرفر البريد أو عبر لوحة تحكم مزودك (Google Workspace Admin > Apps > Gmail > Authenticate email)، وبعدين انشر المفتاح العام كسجل TXT تحت subdomain خاص بالـ selector، شي مثل google._domainkey.yourdomain.com. إذا كان Odoo يمرر عبر خدمة SMTP منفصلة، هذي الخدمة لازم يكون لها selector DKIM خاص بها ومنشور — Odoo نفسه ما يوقّع الرسائل؛ اللي يوقّعها هي الجهة اللي ترسل نيابة عنه. فعّل توقيع DKIM من المصدر، مو بس في DNS.

إعداد DMARC بدون ما تكسر تدفق بريدك

انشر سجل DMARC من نوع TXT تحت _dmarc.yourdomain.com. ابدأ بشكل متحفظ:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

سياسة p=none تخبر جهات الاستقبال إنهم ما يسوّون أي إجراء عقابي حالياً — بس تطلب منهم يرسلون لك تقارير تجميعية (aggregate) عشان تشوف إيش ناجح وإيش لا. شغّل هذي الإعدادات لمدة أسبوعين لثلاثة أسابيع على الأقل. راقب التقارير. لما تشوف SPF وDKIM ناجحين بثبات ومتوافقين مع دومين From:، انتقل للسياسة p=quarantine (البريد المشبوه يروح للـ spam)، وأخيراً p=reject (البريد المشبوه يُرفض كلياً). القفز مباشرة لـ reject بدون مراقبة التقارير أولاً هو أسرع طريقة تخسر فيها حركة الفواتير الشرعية — لا تسويها.

وضع التوافق (alignment mode) مهم هنا بردو. افتراضياً، DMARC يتحقق من التوافق على مستوى الدومين التنظيمي (organizational domain)، وGoogle FAQ تؤكد إن البريد المباشر لحسابات Gmail الشخصية يحتاج إن الدومين التنظيمي في هيدر From: يكون متوافق مع دومين SPF التنظيمي أو دومين DKIM التنظيمي. إذا كان Odoo يرسل باسم invoices@yourcompany.com لكن الـ relay الأساسي يوثّق باسم دومين مختلف تماماً، التوافق يفشل حتى لو نجح SPF وDKIM كل واحد لحاله. هذي بالضبط الثغرة اللي توقع فيها إعدادات Odoo المستضافة (hosted) اللي تستخدم mail relay عام بدون إعداد خاص بالدومين.

إلغاء الاشتراك بنقرة واحدة، وليش فواتيرك مستثناة

إرشادات Google تشترط خاصية إلغاء الاشتراك بنقرة واحدة (one-click unsubscribe) على bulk senders — لكن فقط للرسائل التسويقية والترويجية. الرسائل التعاملية (transactional) مستثناة صراحة من هالشرط. Google تذكر إعادة تعيين كلمة المرور، تأكيدات الحجوزات، وتأكيدات إرسال النماذج كأمثلة على البريد التعاملي، والفواتير وإيصالات الدفع وكشوف الحساب تقع بالضبط في نفس التصنيف. مع هذا، لا تتكاسل: إذا كنت ترسل نشرات تسويقية من نفس نسخة Odoo أو نفس دومين الإرسال اللي ترسل منه فواتيرك، شرط إلغاء الاشتراك ينطبق تماماً على تلك الرسائل، وخلط حركة التسويق مع الحركة التعاملية تحت سمعة دومين واحد أصلاً مخاطرة ما تحتاجها. فكّر في فصل subdomain — مثلاً mail.yourcompany.com للتسويق، وyourcompany.com أو subdomain تعاملي مخصص للفواتير — عشان أي ارتفاع في شكاوى النشرة الإخبارية ما يأثر على وصول فواتيرك.

المراقبة: لا تعدّل الإعداد وتنساه

فعّل Google Postmaster Tools لدومين الإرسال عندك — مجاني، وهو المكان اللي Google فعلياً تعرض فيه معدل الـ spam عندك، وهو الرقم اللي يحدد هل تبقى تحت سقف 0.30% أو يتم تقييدك. تحقق منه أسبوعياً، مو مرة بالسنة. جنبه، اقرأ فعلياً تقارير DMARC التجميعية (عنوان الـ rua اللي ضبطته فوق). راح تخبرك أي مصادر إرسال تفشل في التوافق قبل لا Gmail أو Yahoo يبدأون برفض البريد كلياً. فيه عدة أدوات مجانية لتحليل تقارير DMARC تحوّل ملف XML الخام إلى جدول مقروء — استخدم وحدة منها، لأن قراءة XML خام يدوياً يصير مملّ بسرعة.

أخطاء الإعداد الشائعة اللي تعثّر المسؤولين باستمرار

فيه أخطاء معينة تتكرر ميدانياً بشكل مستمر:

• عدة سجلات SPF لنفس الدومين. DNS يسمح بسجل SPF واحد فقط من نوع TXT لكل دومين — إذا عندك اثنين، الاثنين يفشلون. ادمج كل مصادر الإرسال في سجل واحد فيه عدة عبارات include:.
• DKIM مفقود على الخدمات الفرعية. Odoo، أداة التسويق، وrelay الرسائل التعاملية ممكن كلهم يرسلون باسم نفس الدومين، لكن كل واحد فيهم يحتاج selector DKIM خاص فيه مُعد ويوقّع بشكل صحيح. خدمة واحدة معدّة ما تغطي البقية.
• ما فيه توافق بين هيدر From: والدومين الموثّق. SPF وDKIM ممكن ينجحون تقنياً بينما DMARC يفشل، لأن دومين المرسِل الظاهر ما يطابق أي من الدومينات الموثّقة. هذا هو القاتل الصامت — اختبره تحديداً.
• نسيان تأخير انتشار DNS. التغييرات ممكن تاخذ حتى 48 ساعة عشان تسري. اختبر، انتظر، وبعدين اختبر مرة ثانية قبل ما تفترض إن الحل ما اشتغل.
• القفز لـ p=reject بسرعة زيادة. امر دايماً على none ثم quarantine أولاً، مع تفعيل التقارير، قبل ما تفرض الرفض الكامل.

هذي خطوتك الجاية: افتح منطقة DNS لدومينك اليوم، تحقق هل عندك سجل SPF واحد بالضبط، تأكد إن DKIM فعلاً يوقّع بريد Odoo الصادر (شيك في هيدرات الرسالة، مو بس في DNS)، وإذا ما عندك سجل DMARC أصلاً، انشر واحد بـ p=none هالأسبوع. هذي الخطوة الوحيدة بتعطيك رؤية على مشكلة ما تقدر تشوفها حالياً — والحين، هالفاتورة الجالسة في spam عند عميلك تكلفك فلوس ما انتبهت لها بعد.

مصدر الصورة: hisperati — BY