أزالت جوجل بصمت _netblocks3.google.com من سلسلة سجل SPF الخاصة بها في أوائل 2026 دون إعلان رسمي. بالنسبة لمعظم مستخدمي Google Workspace، لا يتغير شيء. لكن بالنسبة لمالكي النطاقات أو فرق تكنولوجيا المعلومات الذين قاموا بترميز بنية SPF الداخلية لجوجل يدويًا، هذا التحديث إشارة لتدقيق سجلاتهم الآن، قبل أن يسبب تكوين فوضوي مشكلة في القابلية للتسليم.
ما الذي غيرته جوجل فعليًا
عندما تنظر داخل مرجع جوجل _spf.google.com، يشير إلى سجلات فرعية داخلية تحتوي على نطاقات IP لجوجل لإرسال البريد الإلكتروني. في السابق، كانت السلسلة تتضمن ثلاثة من هذه السجلات الفرعية. أزالت جوجل الآن بصمت _netblocks3.google.com من هذه السلسلة، مما يعني أن السجل الفرعي لم يعد يحتوي على عناوين إرسال نشطة. بعبارة بسيطة، قامت جوجل بتنظيف بنية SPF الخاصة بها.
لم تقم جوجل بإعلانات عالية الصوت عن هذا لأن معظم النطاقات لا تتأثر. تظهر المشكلة فقط إذا قمت بنسخ بنية جوجل الداخلية يدويًا، مما قد يترك سجل SPF الخاص بك غير صالح أو يشير إلى مرجع غير ضروري. قد لا تقطع البريد الإلكتروني فورًا، لكنها تجعل إعداد SPF أصعب في الصيانة.
من يواجه خطرًا فعليًا
معظم مستخدمي Google Workspace لا يحتاجون إلى القلق بشأن هذا التغيير. يعتمدون على إدخال include:_spf.google.com القياسي، وجوجل تدير كل شيء خلف الكواليس. السجلات بهذا الصيغة تستمر في العمل كما هو متوقع تماما.
من يستخدم include الموصى به من جوجل لن يواجه مشاكل. ومع ذلك، قد يواجه مالكو النطاقات الذين نسخوا بنية جوجل الداخلية يدويًا مشاكل. يحدث هذا عادة عندما حاولت فرق تقنية تجاوز حد البحث عن DNS 10 مرات وحاولت حله بترميز مراجع netblock الفردية بدلاً من استخدام أداة تسطيح SPF.
حد البحث هذا ليس مصدر قلق طفيف. وفقًا لـ RFC 7208، يتم تغطية تقييم SPF بـ 10 عمليات بحث آلية DNS كحد أقصى و 2 عملية بحث فارغة لكل فحص. تجاوز أي منهما ينتج PermError يفشل المصادقة لكل رسالة من النطاق. وهذا الفشل صامت: رسائلك الإلكترونية لا ترتد، بل تهبط في البريد العشوائي أو يتم رفضها دون أي خطأ واضح يمكن للمرسل رؤيته.
مشكلة ميزانية بحث DNS
يسلط هذا التحديث الضوء أيضًا على مشكلة أوسع للشركات التي تستخدم أدوات إرسال متعددة. وحده include:_spf.google.com من جوجل يستخدم 4 من 10 عمليات بحث متاحة لديك، تاركًا فقط 6 لجميع المرسلين الآخرين. إذا كنت تستخدم أيضًا SendGrid، الذي يستهلك 5 عمليات بحث، فإن المجموع المدمج يصل إلى 9، وإضافة مرسل واحد فقط يضرب الجدار.
نطاق يتضمن جوجل وMicrosoft وSendGrid وMailchimp معًا يصل إلى 12 عملية بحث. RFC 7208 يحد التقييم من 10. يرجع خادم البريد الموصول PermError وكل رسالة من النطاق تفشل مصادقة SPF، بغض النظر عن المرسل الذي جاءت منه فعليًا.
بالنسبة لفرق النمو التي تشغل الحملات عبر منصة التسويق أثناء إرسال رسالة بريد معاملات من خدمة جهة خارجية، هذا فخ حقيقي وشائع.
ما يجب التحقق منه في سجل SPF الخاص بك
إذا رأيت إدخالات netblock فردية مثل _netblocks.google.com أو _netblocks2.google.com أو _netblocks3.google.com في السجل الخاص بك، أزلها. استبدل جميعها بإدخال include واحد يشير إلى _spf.google.com، والذي يحافظ على تكوينك نظيفًا ويتم تحديثه تلقائيًا بواسطة جوجل.
إذا كنت تستخدم Google Workspace فقط لإرسال البريد الإلكتروني، فالسجل الصحيح هو: v=spf1 include:_spf.google.com ~all
يساعد التحقق من إعداد SPF كل بضعة أشهر لاكتشاف الإدخالات القديمة أو المراجع المكررة أو الـ includes المعطلة في منع مشاكل المحاذاة والقابلية للتسليم.
لماذا يهمك هذا لـ ROI التسويق عبر البريد الإلكتروني
SPF ليست مجرد مهمة صيانة تقنية. إنها تقع في أساس سمعة المرسل الخاصة بك. بدون سجل SPF محكم التكوين لـ Google Workspace، قد يتم وضع علامة على رسائلك الإلكترونية كرسائل عشوائية من خلال خوادم الاستقبال التي لا يمكنها التحقق من نطاقك. يمكن إدراج نطاقك أو عنوان IP الخاص بك في قائمة سوداء، مما يجعل استرجاع القابلية للتسليم أصعب بكثير من إعداد المصادقة بشكل صحيح من البداية. وتتراكم سمعة نطاقك الأضرار مع مرور الوقت مع تضاعف شكاوى البريد العشوائي.
متطلبات المرسلين بالجملة من جوجل، المعلنة في أكتوبر 2023 والمطبقة من فبراير 2024، تتطلب أي نطاق يرسل 5000 رسالة أو أكثر يوميًا إلى عناوين Gmail للمصادقة باستخدام كل من SPF و DKIM وتنشر سجل DMARC بـ p=none على الأقل وإبقاء معدلات شكاوى البريد العشوائي أقل من 0.3% وتضمين رأس إلغاء الاشتراك بنقرة واحدة على بريد التسويق. تنطبق هذه القواعد على كل نطاق في رأس From، وجوجل الآن ترفض أو توجه إلى البريد العشوائي أي رسالة من مرسل بالجملة غير متوافق.
القيام بهذا بشكل خاطئ يقطع مباشرة نطاق التسليم الخاص بك، مما يعني معدلات فتح أقل ومعدلات نقر أقل وعودًا أقل على كل حملة ترسلها.
ثلاث خطوات يجب اتخاذها الآن
SPF وحده ليس كافيًا. إن دمجه مع DKIM و DMARC يمنح خوادم الاستقبال القدرة على التحقق من الرسائل بشكل صحيح وحجب محاولات التصيد الاحتيالي باستخدام نطاقك. تساعدك الأدوات مثل فحوصات بحث SPF أو محللات DMARC أو لوحات معلومات أمان البريد الإلكتروني على مراقبة التغييرات واكتشاف مشاكل التكوين مبكرًا.
للتصرف بناءً على هذا التحديث:
- ابحث عن سجل SPF الحالي باستخدام أداة مثل MXToolbox أو Google's Admin Toolbox.
- إذا كان سجلك يحتوي فقط على
include:_spf.google.com، فلا توجد تغييرات مطلوبة. جوجل تدير التحديثات لك. - إذا رأيت أي إدخالات
_netblocksفردية، دمجها والتحقق من أن إجمالي عدد عمليات البحث يبقى أقل من 10.
تنظيف جوجل الصامت لسلسلة SPF الخاصة بها يذكر بأن بنية المصادقة البريد الإلكتروني تتغير بدون تحذير. ستستمر النطاقات التي تعتمد على سجلات مبنية يدويًا في الوقوع في هذه المشكلة. استخدام مراجع include الرسمية ومراجعة الإعداد الخاص بك بانتظام هو الطريقة المباشرة للبقاء محميًا.
