قد تكتب نشرة بريدية ممتازة، وتجمع مشتركين وافقوا على تلقيها، ثم تكتشف أن رسائلك لا تصل إلى البريد الوارد كما تتوقع. أحيانًا يكون السبب سمعة النطاق وجودة القائمة، وأحيانًا توجد مشكلة فنية في مصادقة البريد الإلكتروني. هنا تظهر ثلاثة اختصارات مهمة: SPF وDKIM وDMARC. تساعد هذه الآليات مزوّدي البريد على التحقق من أن الرسالة أُرسلت من جهة مخوّلة باستخدام نطاقك، وأن اسم المرسل الظاهر متوافق مع آليات التوثيق.
الخلاصة المباشرة: إعداد SPF وDKIM وDMARC يحسن التوثيق ويقلل انتحال النطاق، وهو جزء من متطلبات Gmail للمرسلين خصوصًا عند إرسال نحو 5,000 رسالة يوميًا إلى حسابات Gmail الشخصية. لكنه لا يضمن وصول جميع الرسائل إلى Inbox؛ تبقى موافقة المشتركين ومعدل الشكاوى والارتدادات والتفاعل وسمعة النطاق عوامل أساسية. سنشرح هنا معنى كل سجل، والفرق بين الإعداد العام والربط مع منصة Kit، وطريقة التحقق دون تعديل DNS عشوائيًا.
اعتمد هذا الدليل على إرشادات Google ومركز مساعدة Kit الرسمية المتاحة في 19 أكتوبر 2026. قيم DNS الواردة في الأمثلة توضيحية وليست قيماً صالحة لنسخها في نطاقك؛ يُستخرج كل سجل حقيقي من مزود البريد أو منصة النشرات نفسها. لم نعدّل إعدادات موقع أو نختبر وصول رسائل من نطاق حقيقي لإعداد هذا الشرح.
ما الفرق بين Inbox وSpam ونجاح تسليم البريد؟
هناك فرق بين إرسال الرسالة من منصة النشرات، وقبول خادم المستلم لها، وعرضها في Inbox. قد تسجل المنصة الرسالة Delivered لأنها وصلت إلى خادم البريد، لكن الخادم قد يعرضها في Promotions أو Spam أو يصنفها بطريقة لا تستطيع منصة الإرسال التحكم فيها. لذلك من الخطأ أن تقول «أصلحت DNS، إذن سأصل دائمًا إلى البريد الوارد».
تعتمد الأنظمة الحديثة على مجموعة مؤشرات، منها التحقق من هوية المرسل، ومصدر الاشتراك، وسجل الشكاوى، ومعدل الارتداد، وانتظام الإرسال، وروابط الرسالة وسياقها. التوثيق شرط تقني مهم، لكنه ليس أداة لتجاوز قرارات المستخدمين أو تصفية الرسائل المزعجة.
ما هو SPF؟ وكيف يعمل؟
يرمز SPF إلى Sender Policy Framework، وهو سجل في DNS يعلن الخوادم أو الخدمات المسموح لها بإرسال بريد باسم نطاق معين في طبقة عنوان الإرجاع التقني (Envelope From / Return-Path). عند استلام الرسالة يستطيع خادم الوجهة التحقق مما إذا كان الخادم المرسل يتوافق مع سياسة SPF المنشورة.
يُكتب SPF عادةً كسجل TXT في DNS. من أمثلته التعليمية v=spf1 include:_spf.example.net ~all، لكن هذا المثال غير صالح للنشر كما هو، لأن نطاق المثال ليس مزود بريدك الحقيقي. لا تنسخ سجل SPF عُثر عليه في مقال أو فيديو؛ احصل على سلسلة include أو IP المعتمدة من خدمة البريد التي تستخدمها.
الأهم أيضًا أن SPF الناجح وحده لا يكفي بالضرورة لاجتياز DMARC؛ يحتاج نطاق Return-Path المستخدم لفحص SPF إلى علاقة محاذاة مع نطاق From المرئي، أو تحتاج إلى توقيع DKIM صالح ومحاذٍ. هذه نقطة تربك أصحاب المواقع الذين يرون SPF PASS في رسالة الاختبار ثم يكتشفون DMARC FAIL.
ما هو DKIM؟ ولماذا يختلف عن SPF؟
يرمز DKIM إلى DomainKeys Identified Mail. يضيف خادم الإرسال توقيعًا رقميًا إلى ترويسات الرسالة باستخدام مفتاح خاص يحتفظ به مزود الإرسال، وينشر مفتاحًا عامًا في DNS حتى يتحقق خادم المستلم من صحة التوقيع. يساعد ذلك في معرفة أن أجزاء من الرسالة لم تتغير بعد توقيعها وأن الجهة التي وقّعت مخولة بإرسال البريد باستخدام نطاق التوقيع.
غالبًا يتضمن عنوان سجل DKIM مُحدِّدًا يسمى Selector، ويظهر وفق صيغة شبيهة بـselector1._domainkey.example.com. قد يستخدم المزود TXT يحوي المفتاح العام، أو يطلب CNAME يشير إلى سجل مُدار من جانبه. لا تُحوّل CNAME إلى TXT بنفسك، ولا تُنشئ مفتاح توقيع من عندك إذا كانت منصة Kit أو غيرها توفر سجلات DKIM الجاهزة.
وجود DKIM لا يجعل محتوى الرسالة صادقًا أو مشروعًا تلقائيًا؛ إنه يتحقق من توقيع الجهة التي أرسلتها ومن سلامة الأجزاء المشمولة بالتوقيع، وليس مراجعة تحريرية للمعلومات أو الروابط.
ما هو DMARC؟ وما معنى محاذاة النطاق Alignment؟
DMARC اختصار Domain-based Message Authentication, Reporting and Conformance. يربط نتائج SPF وDKIM باسم النطاق الذي يراه القارئ في حقل From، ويسمح لمالك النطاق بنشر سياسة للتعامل مع الرسائل التي تفشل الفحص، إلى جانب استقبال تقارير تساعد على اكتشاف إساءة استخدام النطاق.
لا يشترط DMARC أن ينجح SPF وDKIM معًا كي يمر الفحص الأساسي؛ يكفي نجاح أحدهما بمحاذاة صحيحة مع نطاق From، وفق القواعد المعتمدة. لكن توصي Google بإعداد الاثنين بصورة جيدة، ويُطلب كلاهما من فئة مرسلي الكميات الكبيرة. مثال: قد يظهر عنوان المرسل news@example.com وتوقيع DKIM من نطاق آخر لا يطابقه؛ هنا لا تكفي عبارة DKIM=pass دون فحص المحاذاة.
سياسات DMARC الثلاث: none وquarantine وreject
تحدد قيمة p= مستوى السياسة المنشورة: none تعني مراقبة الإخفاقات دون مطالبة المستلم بحظرها بسبب سياسة DMARC؛ وquarantine تطلب معاملة الرسائل غير المتوافقة بحذر، مثل توجيهها إلى Spam؛ وreject تطلب رفض الرسائل الفاشلة. يظل التنفيذ الفعلي خاضعًا لقرارات مزود الاستقبال.
قد تبدأ سياسة مراقبة تعليمية بسجل مثل v=DMARC1; p=none; rua=mailto:dmarc@example.com. هذه قيمة توضيحية فقط، وليست إذنًا بنسخ عنوان بريد غير مملوك لك. استخدم صندوق تقارير تملكه أو خدمة مختصة تقبل رسائل التقارير، وتحقق من تنسيق السجل لدى مزودك. لا تقفز إلى p=reject قبل حصر جميع الخدمات التي ترسل باسم نطاقك وإصلاح أي رسائل شرعية فاشلة، وإلا قد تتسبب في رفض بريدك الصحيح.
متطلبات Gmail للمرسلين في 2026
بحسب إرشادات Google الرسمية لمرسلي البريد، يجب على المرسلين إلى حسابات Gmail الالتزام بتوثيق أساسي، مثل SPF أو DKIM، وإعدادات اتصال وأسماء نطاقات سليمة، ومعدل منخفض للرسائل المبلغ عنها كرسائل مزعجة. وتوجد متطلبات أشد لمن يرسل نحو 5,000 رسالة أو أكثر خلال 24 ساعة إلى حسابات Gmail الشخصية، منها إعداد SPF وDKIM وDMARC، ومحاذاة نطاق From مع SPF أو DKIM، ودعم إلغاء الاشتراك بنقرة واحدة للرسائل التسويقية أو الاشتراكات حيث ينطبق ذلك.
تؤكد الأسئلة التوضيحية الرسمية من Google أن حساب 5,000 يكون على مستوى النطاق التنظيمي الرئيسي، حتى لو وزّعت الرسائل على نطاقات فرعية. كما توصي بالإبقاء على نسبة بلاغات Spam أقل من 0.1% وتجنب بلوغ 0.3% أو تجاوزها. هذه أرقام عن مؤشرات الشكاوى داخل خدمات Google وليست معيارًا يقول إن رسالة بنسبة فتح عالية ستصل حتمًا إلى Inbox.
منذ نوفمبر 2025 شددت Gmail تطبيق شروط المرسلين غير المتوافقين تدريجيًا، وقد تواجه الرسائل غير المطابقة رفضًا مؤقتًا أو دائمًا. لذلك لا تجعل إصلاح سجلات DNS مسألة تجميلية تُؤجل إلى أن تنمو قائمتك كثيرًا.
خطوات إعداد SPF وDKIM وDMARC بصورة صحيحة
الخطوة الأولى: جرد جميع خدمات الإرسال
اكتب قائمة كاملة بالخدمات التي ترسل باستخدام نطاقك: منصة النشرات مثل Kit، وبريد الاستضافة، وGoogle Workspace إن كنت تستخدمه، وإضافة نماذج WordPress، ونظام الفواتير أو المتجر، وأي CRM. يجب ألا تزيل سجل خدمة قديمة قبل التأكد من توقفها؛ فقد تكون ترسل فواتير أو رسائل استعادة كلمة مرور حتى لو لم تستخدمها للنشرات.
إذا لم تعرف ما الخدمات الحالية، ابدأ من إعدادات الاستضافة وصفحة DNS وسجل الرسائل الصحيحة في بريدك، ويمكنك الاستعانة بمسؤول النظام. لا تنشر لقطة شاشة تحتوي مفاتيح تحقق أو معلومات غير ضرورية عن خدماتك في منتدى عام.
الخطوة الثانية: تحديد مكان إدارة DNS
لا تُضاف السجلات بالضرورة في لوحة الشركة التي اشتريت منها النطاق. موقع إضافة السجل هو مزود DNS الفعّال الذي تشير إليه Nameservers: قد يكون Cloudflare أو Namecheap أو شركة الاستضافة أو منصة أخرى. افحص خوادم الأسماء أولًا، ثم انتقل إلى منطقة إدارة DNS المناسبة. تعديل سجل في لوحة غير مسؤولة عن النطاق لن ينعكس على الاستعلامات العامة.
احتفظ بنسخة من السجلات ذات الصلة قبل التغيير، مع نوع كل سجل والاسم والقيمة وTTL. لا تمسح سجلات MX أو DNS أخرى لا علاقة لها بالمشكلة؛ فالتوثيق خاص بالإرسال، بينما سجلات MX توجه البريد الوارد وقد يؤدي العبث بها إلى فقدان استقبال الرسائل.
الخطوة الثالثة: إعداد SPF وفق تعليمات كل مزود
افتح دليل خدمة البريد الأساسية ثم انسخ سجل SPF الذي توصي به، أو نفّذ طريقة دمج المرسلين المسموحين عندما يكون هناك أكثر من مزود. لا تنشئ سجلين مستقلين يبدأ كل منهما بـv=spf1 للنطاق نفسه؛ فوجود أكثر من سياسة SPF في موضع الفحص قد يسبب أخطاء، كما ينبغي الانتباه إلى حدود البحث عن النطاقات داخل سياسة SPF.
لا تعد بتوثيق Kit عبر إضافة صيغة SPF عامة من الإنترنت؛ توضح وثائق Kit أن إنشاء Verified Sending Domain يطلب سجلات محددة، غالبًا CNAME، لتمكين SPF وDKIM على نطاقك. انسخ القيم المولّدة لحسابك لا قيمة مستخدم آخر.
الخطوة الرابعة: نشر DKIM من مزود الإرسال
من لوحة مزود البريد ابحث عن Authentication أو DKIM أو Verified Sending Domain. سيعرض المزود اسم السجل وقيمته. أضف النوع الصحيح كما يظهر: TXT أو CNAME. إذا كانت الخدمة توفر اسم Selector محددًا فلا تستبدله باسم عشوائي، ولا تضف اسم النطاق مرتين إذا كانت لوحة DNS تلحقه تلقائيًا بحقل Host.
قد تستغرق تحديثات DNS وقتًا حتى تصل لخوادم الاستعلام المختلفة. تحقق من صحة المفتاح أو CNAME بعد النشر، ثم أرسل رسالة اختبار وافحص ترويساتها للتأكد من أن الرسالة تُوقّع بالفعل بالنطاق المطلوب. نشر سجل DKIM في DNS وحده لا يكفي إذا كان خادم الإرسال لم يُفعّل التوقيع.
الخطوة الخامسة: إضافة DMARC للمراقبة والتدرج
يُنشأ DMARC عادةً كسجل TXT باسم يبدأ بـ_dmarc للنطاق. استخرج القيمة المعتمدة من المنصة أو أداة إدارة DMARC موثوقة، وابدأ بوضع مراقبة مناسب عندما تكون منظومتك غير مختبرة. راجع التقارير التي تصل، واكشف عن رسائل شرعية من خدمات لم تُضاف إلى الجرد، ثم قرر إن كانت هناك ضرورة لرفع السياسة تدريجيًا إلى quarantine أو reject.
لا ترفع مستوى الحظر لإظهار «درجة أمان 100%» على أداة اختبار. المعيار الحقيقي هو أن تمر الرسائل الشرعية بالمصادقة، وتُكتشف محاولات الانتحال، ويظل التسليم القانوني والموثوق مستمرًا.
إعداد Verified Sending Domain داخل Kit خطوة بخطوة
توفر Kit دليلًا رسميًا للتحقق من نطاق الإرسال. من لوحة الحساب اختر اسم الحساب → Settings → Email، ثم داخل قسم Verified Sending Domains اضغط إعداد نطاق إرسال أو إضافة نطاق آخر. اكتب نطاقك أو النطاق الفرعي الذي ستستخدمه، ثم تابع خطوات المعالج.
تنصح Kit بتجربة Automatic setup عندما تكون متاحة، وإلا اختر Manual setup. سيعرض Kit سجلات DNS اللازمة، وقد تشمل CNAME يتصل بتوقيع DKIM ومسار Return-Path. انسخ الاسم والهدف كما يظهران في حسابك، ثم انتقل إلى مزود DNS الفعلي وأنشئ السجلات من النوع المحدد. عد إلى Kit واضغط Validate، ولا تفترض نجاح التحقق لمجرد الضغط على Save في لوحة النطاق.
تنبه الشركة إلى أن بعض مزودي DNS يطلبون اسم المضيف مختصرًا، مثل cka._domainkey بدل الاسم الكامل الذي يتضمن النطاق. لا تقم بالتخمين؛ استخدم ما تعرضه لوحة المزود وراجع الاستعلام النهائي. كما تتيح Kit إضافة سجل DMARC من قسم البريد نفسه، وقد تقترح سياسة p=none كبداية، مع إمكان أن يكون هناك سجل سابق بالفعل يجب عدم تكراره. راجع خطوات DMARC لدى Kit قبل أي تغيير.
تحذير: إذا كان نطاقك يستخدم بريدًا تجاريًا آخر، فلا تحذف سجل SPF أو DKIM السابق كي «تجعل Kit يعمل». ينبغي أن تعمل جميع خدمات الإرسال معًا بصورة متوافقة. إذا لم تكن متأكدًا من أثر تغيير DNS، استعن بمسؤول البريد أو الدعم التقني.
مثال تطبيقي افتراضي لموقع WordPress ونشرة Kit
افترض أن لديك مدونة example.com وتستخدم عنوان الإرسال newsletter@example.com عبر Kit، بينما يصدر WordPress إشعارات التواصل من مزود SMTP مختلف. هنا تحتاج إلى معرفة ما إذا كان كل مزود يوقع البريد باسم النطاق، وهل Return-Path الخاص به يمر SPF، وهل يوجد محاذاة DMARC مع From الظاهر. قد تنجح نشرات Kit وتفشل رسائل النماذج، أو العكس، لأن المسارين التقنيين مختلفان.
في سيناريو توضيحي لا يمثل نتائج حقيقية، تلاحظ أن رسائل Kit تحمل DKIM=pass مع نطاقك بعد التوثيق، بينما إشعارات WordPress تأتي بتوقيع آخر غير محاذٍ. الحل ليس تعديل Kit حتى يغيّر كل بريد الموقع؛ بل فحص إعداد خدمة SMTP في WordPress وتصحيحها بمعزل عن النشرة. أعد الاختبار من المسارين بعد التغيير.
كيف تتأكد من نجاح المصادقة دون الاعتماد على لون أيقونة؟
- أرسل رسالة اختبار من منصة النشرات إلى حساب بريد تملكه. لا ترسل إلى أشخاص لم يوافقوا على الرسائل.
- افتح تفاصيل الرسالة أو Show original / عرض الرسالة الأصلية في Gmail عندما تتوفر.
- ابحث عن نتائج
spf=passوdkim=passوdmarc=passفي ترويسات Authentication-Results، ولا تكتفِ بوجود اسم السجل في DNS. - قارن اسم النطاق في From المرئي بنطاقات SPF وDKIM للتحقق من محاذاة DMARC.
- إذا كانت النتيجة Fail، افحص أولًا السجل الصحيح والمزود الذي أرسل بالفعل، ثم انتظر انتشار DNS إن كنت أضفت السجل حديثًا.
- كرر الاختبار بعد الإصلاح، وسجّل نتيجة كل خدمة إرسال على حدة.
إذا ظهر PASS في الثلاثة وما زالت الرسائل تنتقل إلى Spam، فقد تجاوزت مشكلة التوثيق الأساسية لكنك لم تحل تلقائيًا مشكلات السمعة أو الموافقة أو المحتوى أو الروابط. انتقل إلى فحص أسباب الشكاوى ونظافة القائمة وإرسال الرسائل إلى جمهور يتفاعل طوعًا، بدل إضافة سجلات DNS جديدة بلا حاجة.
ماذا تفعل إذا لم يصل بريدك رغم SPF وDKIM وDMARC؟
ابدأ بمراجعة تقارير الارتداد داخل Kit، وتحقق من أن البريد غير محظور أو مرفوض بسبب أسباب تقنية واضحة. ثم راجع مصدر المشتركين: هل اشتركوا فعليًا أم استوردت قائمة قديمة غير نشطة؟ وتأكد أن لديك عنوان From معروفًا، ورسالة قصيرة مفيدة، وروابط واضحة غير مختصرة بطريقة مشبوهة، ورابط إلغاء اشتراك يعمل.
يمكن لمستخدم النطاق مع حجم إرسال مناسب مراجعة Google Postmaster Tools لقياس مؤشرات السمعة والشكاوى والالتزام التي توفرها Google عند كفاية البيانات. إذا كان الإرسال قليلًا فقد لا تظهر كل التقارير؛ غياب المؤشر ليس دليلًا على سلامة مثالية أو خلل بحد ذاته. احذر من خدمات تعدك بضمان دخول Inbox بنسبة 100% مقابل دفعة مالية.
أخطاء DNS الشائعة التي يجب تجنبها
من أكثر الأخطاء نشر سجلَي SPF منفصلين للنطاق نفسه، ونسخ DKIM Selector خاطئ، وإضافة اسم النطاق مرتين إلى حقل Host، وخلط CNAME بنوع TXT، وكتابة سياسة DMARC صارمة قبل معرفة جميع مزودي الإرسال. وقد يحدث خلل أيضًا عند إدخال سجلات جديدة في لوحة تسجيل النطاق رغم أن Nameservers الفعالة تشير إلى Cloudflare أو استضافة أخرى.
من الأخطاء الأمنية استخدام p=none للأبد دون مراجعة أي تقارير إذا كانت لديك حاجة لمنع الانتحال، أو الانتقال سريعًا إلى reject على نطاق يرسل من خدمات متعددة غير مدققة. اختر خطة تدريجية تعتمد على نتائج حقيقية، ولا تغيّر MX أو إعدادات استقبال البريد ظنًا أنها مطلوبة لتوثيق رسائل النشرات.
كيف تحسّن وصول النشرات على المدى الطويل؟
التوثيق يُمكّن المنصات من معرفة مصدر الرسالة، أما الثقة فتُبنى بالتزام الوعد التحريري. أرسل فقط إلى من وافقوا على الاشتراك، وفعّل تأكيد البريد عندما يناسب نوع قائمتك، ولا تغيّر الموضوع أو تكرار الإرسال فجأة. إذا بدأت بنطاق إرسال جديد أو غيّرت التوقيع، تقترح Kit إرسال النشرات أولًا إلى المشتركين الأكثر تفاعلًا وزيادة الحجم تدريجيًا بدل إرسال حملة ضخمة مباشرة بعد التبديل.
راجع العناوين والمحتوى بالعربية، ولا تكرر رسائل الاختبار للقراء الحقيقيين دون ضرورة. لزيادة التفاعل بطريقة سليمة، يمكنك تحسين موضوع الرسالة بناء على اختبار منضبط؛ اقرأ على AIFekra كيفية اختبار A/B لعناوين النشرات في Kit باستخدام الذكاء الاصطناعي. ولتجهيز أصل النشرة من البداية راجع دليل إنشاء نشرة بريدية عربية بالذكاء الاصطناعي وشرح Kit للمبتدئين.
إذا كنت لا تزال تقارن خدمات إرسال النشرات قبل إعداد السجلات، ابدأ من المقال الأساسي لمقارنة Kit وbeehiiv وMailchimp ثم طبّق تعليمات التوثيق الخاصة بالمزود الذي تختاره؛ فقيم DNS تختلف من خدمة لأخرى.
قائمة مراجعة سريعة قبل إرسال النشرة القادمة
- تحققت من نطاق From والجهة التي ترسل الرسالة فعليًا.
- أضفت سجلات مزود الإرسال الفعلية، ولم تنسخ قيمًا عامة من دليل.
- اختبرت SPF وDKIM وDMARC من رسالة حقيقية وتحققت من Alignment.
- احتفظت بسجلات البريد الشرعية الأخرى عند إدخال Kit أو مزود جديد.
- راجعت إعداد الاشتراك وإلغاء الاشتراك ونظافة الجمهور.
- راقبت المرتدات والشكاوى والنتائج دون ادعاء ضمان دخول Inbox.
إذا أردت تحسين وصول النشرات البريدية، ابدأ بإعداد إرسال صحيح: SPF يحدد جهات الإرسال المسموح بها، وDKIM يضيف توقيعًا يُتحقق منه، وDMARC يربط نتائج المصادقة باسم النطاق الظاهر ويتيح السياسة والتقارير. بعد ذلك يأتي دور سمعة النطاق وجودة المحتوى وموافقة المشتركين. وإذا كنت تستخدم Kit، اعتمد سجل Verified Sending Domain الذي يولده حسابك وخطوات التحقق الرسمية بدل تغيير DNS على أساس أمثلة عامة. الهدف هو وصول مشروع وموثوق، وليس التحايل على مرشحات Spam.
