بريد من نطاقك الخاص

يستطيع البوت مراسلة عملائك بالبريد الإلكتروني — من عنوان على نطاقك أنت، مثل noreply@example.com. غير أن الرسالة نفسها يرسلها خادمنا. لذلك عليك قبل أول إرسال أن تضيف مرة واحدة ثلاثة سجلات إلى DNS نطاقك. فيما يلي: لماذا يلزم ذلك، وما الذي يُضاف بالضبط، وماذا يحدث بعدها.

لماذا لا تصل الرسائل بلا سجلات DNS

انظر إلى الأمر بعين الطرف المستقبِل — Gmail أو Outlook أو خادم بريد عميلك. تصلهم رسالة تدّعي أنها من نطاقك، لكنها آتية من خادم لا يملكه نطاقك. هذه بالضبط صورة التزوير: هكذا يعمل التصيّد.

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

وما دام هذا الجواب غائباً، فإن خادم بريد أميناً ملزَم باعتبار الرسالة مشبوهة. في أفضل الأحوال تذهب إلى «غير المرغوب فيه»، وفي أسوئها تُرفض ولا يعلم المستلم أنها وُجدت أصلاً.

لذلك السجلات الثلاثة أدناه ليست إجراءً شكلياً ولا علامة صح في الواجهة. هي إذنك نفسه.

السجلات الثلاثة ووظيفة كل منها

DKIM — التوقيع الذي يثبت الأصالة

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

بلا DKIM: لا شيء يمكن التحقق به من التوقيع. تبدو الرسالة غير موقَّعة وغير جديرة بالثقة، ولا يعوّض ذلك أي إعداد آخر. DKIM أهم السجلات الثلاثة.

SPF — أي الخوادم يجوز لها الإرسال باسمك

يجيب SPF عن سؤال آخر: من أي خوادم يُقبل أصلاً بريدٌ من هذا النطاق. إنه قائمة مصادر — خوادم بريد استضافتك، وخدمات الإرسال التي تستخدمها فعلاً، وخوادم الإرسال لدينا كي يتمكن البوت من الكتابة.

بلا SPF: تصل الرسالة من خادم «لا يعرفه» نطاقك. وهذه علامة تزوير كلاسيكية بالنسبة للمرشِّح، تُضاف إلى كل الشبهات الأخرى.

DMARC — ماذا يفعل المستقبِل إذا أخفقت الفحوص

يجيب DKIM وSPF عن سؤال «هل الرسالة أصلية». ويجيب DMARC عن السؤال التالي: ماذا نفعل إن لم تكن كذلك. إنه تعليمتك للمستقبِل — لا تفعل شيئاً واكتفِ بتقرير، أو ضعها في البريد المزعج، أو ارفضها. وDMARC كذلك العنوان الذي يرسل إليه المستقبِلون تقارير مجمّعة عن البريد الصادر باسمك، بما فيها محاولات الآخرين لانتحال نطاقك.

ابدأ بأخفّ سياسة، أي «تقارير فقط». وشدّدها لاحقاً حين تتأكد أن كل مرسِليك الشرعيين (المحاسبة، CRM، النشرات، هذا البوت) يجتازون الفحوص. السياسة الصارمة إن فُعِّلت مبكراً بدأت تقضم بريدك أنت.

بلا DMARC: كل مستقبِل يقرر على هواه، ولا تعرف أنت أبداً ما يجري للبريد الصادر باسمك.

ما السجلات التي تُضاف

أضف النطاق أولاً في لوحة التحكم: قسم Email ← «Sending domains» ← زر «Add domain». في النافذة ثلاثة حقول: النطاق نفسه (مثل shop.example.com)، والجزء المحلي من العنوان (ما قبل @، وعادةً noreply)، واسم المرسِل الذي يراه المستلم بدل العنوان. وبعد الحفظ تظهر سجلات DNS الخاصة بك على الشاشة.

الثلاثة كلها سجلات من نوع TXT في DNS نطاقك. تُضاف حيث تدير نطاقك: لوحة المُسجِّل أو مزوّد DNS.

القيم أدناه مكتوبة على مثال example.com — ضع نطاقك مكانه. القيم الدقيقة لنطاقك معروضة على بطاقة النطاق في لوحة التحكم، فانسخها من هناك، وخصوصاً DKIM: قيمته تتضمن مفتاحك العام الخاص، وهو مختلف لكل نطاق ولا يمكن أخذه من التوثيق.

على الشاشة يُقسَم كل سجل إلى حقلين منفصلين — «Host» و**«Value»** — ولكلٍّ زر «Copy» خاص به. انسخهما واحداً تلو الآخر إلى الحقول المقابلة لدى مزوّد DNS: فالجزءان لا يُلصَقان ككتلة واحدة.

أكثر موضعين يقع فيهما الخطأ:

• كثير من اللوحات تُلحق النطاق باسم السجل تلقائياً. إذا كان حقل الاسم يعرض «.example.com» فاكتب mybot._domainkey فقط لا الاسم الكامل، وإلا صار mybot._domainkey.example.com.example.com.
• قيمة DKIM طويلة ولا يجوز أن تتضمن فواصل أسطر أو مسافات داخل المفتاح. انسخها بالزر لا بالتحديد بالفأرة.

إذا كان للنطاق سجل SPF أصلاً

لا يجوز أن يكون للنطاق سوى سجل SPF واحد. فإن كنت ترسل البريد عبر الاستضافة أو CRM أو خدمة نشرات أخرى فالسجل موجود لديك. لا تضف ثانياً — أضف include آخر إلى السجل القائم، قبل ~all في نهايته:

v=spf1 include:spf.yourprovider.com include:esp.getmybot.dev ~all

وجود سجلَي SPF على نطاق واحد خطأ يعادل عدم وجود أي سجل: لا ينجح الفحص، لأن المستقبِل لا يعرف أيهما يصدّق.

انتبه: «التغطية» عبر سجل غيرك لا تكفي. حتى لو كان مزوّدك الحالي يتضمّننا في سجل SPF الخاص به، يجب أن يكون include الخاص بنا في سجلك مباشرةً — والسبب في قسم التحقق من النطاق أدناه.

لماذا include في SPF لا عنوان IP

أشيع خطأ هو لصق عنوان IP رآه المرء في ترويسة رسالة أو في منشور بمنتدى. لا تفعل ذلك.

include:esp.getmybot.dev إحالة إلى قائمتنا الخاصة بخوادم الإرسال، وهي قائمة نتولى صيانتها. اليوم يقف خلف هذا الاسم خادم تحويل واحد. وغداً قد يزيد عددها أو تنتقل أو تُستبدل. وحين يحدث ذلك نحدّث القائمة عندنا، ويظل سجلك يعمل دون أن تمس شيئاً. هذا هو المعنى كله: العنوان يتغير في مكان واحد لا في DNS كل عميل.

أما عنوان IP مكتوب باليد فيتوقف ببساطة عن مطابقة الواقع في تلك اللحظة. تبدأ الرسائل بالإخفاق في SPF بلا أي إنذار — لا خطأ في لوحة التحكم ولا إشعار. وستعرف بالأمر من عملاء يقولون إنهم «لم يستلموا شيئاً».

اكتب include:esp.getmybot.dev تماماً ولا تضف إليه شيئاً.

التحقق من النطاق

التحقق من النطاق يعني أن المنصة تنظر بنفسها في DNS نطاقك وتتأكد أن السجلات الثلاثة سليمة. فإن نجحت الثلاثة صار النطاق مُتحقَّقاً منه وسُمح بالإرسال. وما دام أحدها لم ينجح بقي النطاق في الانتظار.

ما يُفحص أكثر من مجرد «السجل موجود»:

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

include غيرك لا يُحتسب

يجب أن يكون include:esp.getmybot.dev في سجل SPF الخاص بك أنت. فإذا كان SPF لديك يتضمّن مزوّداً آخر وكان سجل ذلك المزوّد يتضمّننا بدوره، فلن يقبل التحقق ذلك: المنصة لا تتتبّع سلاسل include الخاصة بالآخرين. والسبب بسيط — هكذا يبقى الجواب عن سؤال «هل أذن لنا هذا النطاق تحديداً» قاطعاً بلا لبس.

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

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

ومع ذلك لا داعي للانتظار السلبي. تفحص المنصة النطاقات المنتظرة تلقائياً مرة كل ساعة، لكن في بطاقة النطاق زر «Verify now» — وهو الفحص نفسه يُنفَّذ فوراً وتظهر نتيجته على الشاشة مباشرة. اضغطه فور حفظ السجلات: إن وقع خطأ طباعي عرفته خلال ثانية لا بعد ساعة. ويمكنك الضغط كما تشاء من المرات.

وحالة النطاق ظاهرة على البطاقة: «Pending verification» أو «Verified» أو «Not verified». وما دام غير متحقَّق منه، يظهر على البطاقة أيضاً التنبيه «Sending from this domain is disabled until it is verified.»

النتيجة ليست مجرد «لم ينجح». لكل من السجلات الثلاثة حالته الخاصة على الشاشة — «Passing» أو «Not passing» أو «Not checked yet» — وسطر خاص يوضّح ما الخلل.

وفي حالة SPF تميّز الشاشة بين وضعين، وهذا أهم تمييز في المسار كله:

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

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

إذا لم ينجح التحقق:

1. اقرأ أي السجلات الثلاثة يحمل «Not passing» وما المكتوب في توضيحه، ثم تصرّف بموجبه.
2. تأكد أن السجلات منشورة فعلاً — كثير من اللوحات تتطلب ضغط «تطبيق التغييرات» بشكل منفصل.
3. افحص اسم السجل بحثاً عن تكرار النطاق (انظر أعلاه).
4. تأكد أن سجل SPF واحد فقط وأن include الخاص بنا داخل ذلك السجل نفسه.
5. انتظر قليلاً ثم أعد الفحص: قد لا يكون التغيير قد انتشر بعد.

قبل التحقق لا يعمل الإرسال — وهذا مقصود

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

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

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

إلغاء الاشتراك والشكاوى وإخفاقات التسليم

ثلاث قواعد تفاجئ من لا يعرفها مسبقاً.

كل رسالة تسويقية تحمل إلغاء اشتراك بنقرة واحدة. تضيف المنصة بنفسها رابط الإلغاء في تذييل الرسالة والترويسات التقنية التي يرسم بها برنامج البريد زر «إلغاء الاشتراك» بجوار عنوان المرسِل. لا يمكن إزالة ذلك — لا بإعداد ولا بتصميم الرسالة. يسري الإلغاء فوراً، دون فتح الرسالة ودون خطوة تأكيد. وهذا ما تشترطه Gmail وسائر مزوّدي البريد الكبار على المرسِلين بالجملة: الرسالة الخالية منه تذهب إلى المزعج حتماً.

إلغاء الاشتراك نهائي ولا يمكن التراجع عنه من الواجهة. العنوان الذي ألغى الاشتراك لا يتلقى بريد هذا البوت بعد ذلك. لا زر «استعادة» ولا التفاف عبر إعادة استيراد قائمة: لا يُلغى القرار من فوق رأس صاحبه. ولا يعود إلا هو بنفسه — بترك عنوانه من جديد في نموذج الاشتراك لديك.

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

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

أما الارتدادات المؤقتة (علبة ممتلئة، خادم متوقف مؤقتاً) فلا تُغلق العنوان، ويستمر الإرسال.

لماذا تبدو «الفتحات» أقل من الحقيقة

في إحصاءات البريد رقم للفتحات، وهو دائماً أقل من الواقع. وليست المسألة خطأ في العدّ بل طريقة قياس الفتح نفسها.

يُسجَّل الفتح حين يحمّل برنامج البريد من خادم صورةً تتبعية صغيرة جداً أثناء عرض الرسالة. والبرامج الحديثة لا تحمّل الصور البعيدة افتراضياً؛ أما التي تحمّلها (Apple Mail وآليات الخصوصية المشابهة) فتفعل ذلك مسبقاً ونيابةً عن الجميع، بمن فيهم من لم يفتح الرسالة قط. في الحالة الأولى يضيع الفتح، وفي الثانية يُنسب إلى شخص لم يكن هناك. ولا سبيل إلى عدّ فتحات البريد بدقة أكبر — لا لدينا ولا لدى غيرنا.

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

وإن أردت مقياس تفاعل موثوقاً فانظر إلى «Link clicks». النقر على رابط فعل حقيقي من إنسان حقيقي، ولا أحد يؤديه عنه مسبقاً. كذلك تُحسب «Delivered» و**«Unsubscribes»** و**«Complaints»** و**«Bounces»** بدقة: فمصدرها خوادم البريد لا صورة داخل رسالة. وكل ذلك في كتلة «Sending stats» على شاشة Email نفسها.

ماذا بعد

• القنوات — تعدد القنوات وقدرات كل قناة.
• البث الجماعي — الإرسال إلى أعداد كبيرة.
• التحليلات — أين تُطالع الأرقام.