حل مشكلة وصول إيميلات متجرك إلى ملف الـ Spam (إعدادات SPF وDKIM وDMARC)

العميل يطلب من متجرك، عملية الدفع تنجح، ويظهر أمامه أن الطلب تم استلامه.

لكن رسالة تأكيد الطلب التي أرسلها المتجر تختفي داخل Spam.

وفي حالات أسوأ لا تصل الرسالة أصلًا.

أول شيء قد يخطر في بالك هو تغيير عنوان الرسالة أو إزالة كلمة تسويقية منها، لكن قبل تعديل المحتوى يجب معرفة شيء أهم:

هل خادم البريد الذي استقبل الرسالة يثق أصلًا بأنك مخول بإرسال Email باسم Domain الخاصة بك؟

هنا تدخل ثلاثة أسماء ستراها كثيرًا عند إعداد البريد:

SPF وDKIM وDMARC.

الثلاثة تعمل معًا، لكن كل واحدة منها تحل جزءًا مختلفًا من المشكلة.

ابدأ من الرسالة التي وصلت Spam

بدل تخمين المشكلة، افتح إحدى الرسائل التي وصلت بالفعل.

في Gmail يمكنك فتح الرسالة ثم اختيار:

Show original
إظهار النسخة الأصلية

ستظهر معلومات Authentication.

ابحث عن شيء قريب من:

SPF: PASS
DKIM: PASS
DMARC: PASS

أو داخل Headers:

Authentication-Results:
    spf=pass
    dkim=pass
    dmarc=pass

هذه أول نقطة تشخيص.

إذا وجدت:

spf=fail

فلا تبدأ بإصلاح DKIM.

وإذا كان:

spf=pass
dkim=pass
dmarc=fail

فقد لا تكون المشكلة في نجاح SPF أو DKIM نفسها، بل في DMARC Alignment، وسنصل إليها بعد قليل.

SPF: من المسموح له بإرسال البريد باسم Domain؟

SPF اختصار لـ:

Sender Policy Framework

فكرتها أن تنشر Domain سجلًا داخل DNS تقول فيه:

هذه هي Servers أو خدمات البريد المسموح لها بالإرسال لهذه Domain.

لنفترض أن متجرك يستخدم شركة خارجية لإرسال Email.

هذه الشركة قد تطلب منك إضافة SPF Record شبيهًا بهذا:

v=spf1 include:spf.mail-provider.example ~all

هذا مجرد مثال توضيحي، وليس Record يجب نسخه.

كل مزود Email يعطيك القيمة التي يجب استخدامها، ويجب أخذها من إعداداته أو Documentation الخاصة به.

أين تضع SPF؟

في معظم الحالات تكون TXT Record على Domain التي يستخدمها نظام الإرسال.

مثلًا:

Type: TXT
Name: @
Value: v=spf1 include:spf.mail-provider.example ~all

طريقة كتابة Name تختلف قليلًا بين لوحات DNS.

بعضها يستخدم:

@

وبعضها يطلب Domain نفسها أو يضيفها تلقائيًا.

المشكلة الشهيرة: إضافة SPF ثانية

لنفترض أن لديك Email الشركة على Google Workspace، ثم ركبت خدمة Transactional Email للمتجر.

تجد في DNS أصلًا:

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

فتضيف Record ثانية:

v=spf1 include:spf.transactional-provider.example ~all

النتيجة ليست «SPF أقوى».

وجود أكثر من SPF Record لنفس الاسم قد يؤدي إلى خطأ SPF.

قد يصبح الشكل مثلًا:

v=spf1 include:_spf.google.com include:spf.transactional-provider.example ~all

مرة أخرى: اسم مزود Transactional هنا مثال فقط.

ما معنى ~all و-all؟

في نهاية SPF سترى غالبًا واحدة من القيم التالية:

~all

أو:

-all

بصورة مبسطة:

~all تعني Soft Fail للمصادر غير المطابقة.

أما:

-all فهي سياسة أشد وتعلن أن المصادر غير المطابقة غير مخولة.

لا تغير هذه القيمة عشوائيًا.

إذا لم تكن متأكدًا من جميع الأنظمة التي ترسل بريدًا باسم Domain، قد يؤدي تشديد SPF قبل حصرها إلى كسر إرسال شرعي.

SPF لها حد يجب الانتباه له

SPF ليست قائمة تستطيع إضافة عدد غير محدود من:

include:

آليات SPF التي تحتاج إلى DNS Lookups تخضع لحد أثناء التقييم.

إذا أصبح SPF معقدًا جدًا بسبب كثرة مزودي الإرسال وIncludes المتداخلة، يمكن أن تحصل على:

PermError

لذلك لا تضف Services قديمة لم تعد تستخدمها، ولا تبنِ SPF من نسخ ولصق Records من الإنترنت.

SPF وحدها لا تكفي

قد تمر SPF، لكن الرسالة نفسها ما زالت تحتاج طريقة أقوى لإثبات أنها خرجت من نظام مخول ولم تتغير بطريقة تكسر التوقيع.

هنا يأتي DKIM.

DKIM: توقيع رقمي على الرسالة

DKIM اختصار لـ:

DomainKeys Identified Mail

الفكرة مختلفة عن SPF.

خدمة الإرسال تمتلك Private Key.

وعند إرسال Email تقوم بتوقيع أجزاء من الرسالة.

أنت تنشر Public Key المقابلة داخل DNS.

عندما تصل الرسالة إلى Gmail أو Outlook أو أي Receiver يدعم DKIM، يستطيع استخدام Public Key للتحقق من التوقيع.

إذا نجح:

dkim=pass

ما هو Selector؟

عند إعداد DKIM قد يعطيك المزود اسمًا مثل:

selector1._domainkey.example.com

الجزء:

selector1

يسمى Selector.

ويسمح بوجود أكثر من DKIM Key لنفس Domain، كما يجعل تدوير المفاتيح مستقبلًا أسهل.

قد يعطيك المزود TXT Record مثل:

Name:
selector1._domainkey

Value:
v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER

أو قد يطلب منك إنشاء CNAME بدل TXT.

استخدم النوع والقيمة التي يقدمها مزود Email تحديدًا.

لا تنشئ DKIM Key من عندك إذا كان المزود يعطيك واحدة

لكي تعمل DKIM، يجب أن تتطابق Public Key الموجودة في DNS مع Private Key التي يستخدمها نظام الإرسال.

إنشاء TXT Record عشوائية لا يحقق شيئًا.

داخل لوحة مزود Email ابحث عادة عن:

Domain Authentication
Email Authentication
DKIM
Sender Domain

ثم انسخ Records التي يعطيك إياها.

كيف تعرف أي DKIM استخدمت الرسالة؟

افتح Headers وابحث عن:

DKIM-Signature:

ستجد ضمنها عادة قيمة:

d=example.com
s=selector1

القيمة:

d=

توضح Domain التي وقعت الرسالة.

والقيمة:

s=

توضح Selector المستخدمة للعثور على Public Key في DNS.

وصلنا إلى DMARC

DMARC ليست بديلًا عن SPF أو DKIM.

هي الطبقة التي تقول:

هل طريقة توثيق هذه الرسالة متوافقة مع Domain التي يراها المستخدم في خانة From؟

DMARC اختصار لـ:

Domain-based Message Authentication,
Reporting and Conformance

لماذا قد تكون SPF PASS وDMARC FAIL؟

هذه واحدة من أكثر النقاط التي تربك الناس.

لنفترض أن العميل يرى:

From:
[email protected]

لكن خدمة الإرسال تستخدم Envelope Sender أو Return-Path على Domain مختلفة تمامًا:

[email protected]

يمكن أن تمر SPF بالنسبة إلى:

provider-example.net

لكن DMARC تهتم أيضًا بعلاقة Domain الموثقة مع Domain الظاهرة في:

From:

وهذا يسمى:

Alignment.

كيف تنجح DMARC؟

بصورة مبسطة، تحتاج الرسالة إلى طريق Authentication متوافق مع Domain الظاهرة للمستخدم.

يمكن أن يتحقق ذلك عبر SPF Alignment أو DKIM Alignment.

ليس مطلوبًا أن ينجح المساران المتوافقان معًا؛ يكفي وجود مسار صحيح ومتوافق وفق سياسة DMARC.

أين تضاف DMARC؟

تضاف عادة TXT Record على:

_dmarc.example.com

أبسط بداية قد تكون:

v=DMARC1; p=none;

لكن الأفضل في مرحلة المراقبة أن تضيف عنوانًا لاستقبال Aggregate Reports:

v=DMARC1; p=none; rua=mailto:[email protected]

يجب أن يكون عنوان التقارير صالحًا ومناسبًا لاستقبالها.

هذه التقارير ليست رسائل عادية سهلة القراءة دائمًا؛ غالبًا تصل في ملفات وتقارير مجمعة ويمكن استخدام أدوات متخصصة لتحليلها.

لماذا نبدأ غالبًا بـ p=none؟

لأن:

p=none

تسمح لك بمراقبة مصادر الإرسال ومعرفة ما يمر وما يفشل دون طلب Quarantine أو Reject للرسائل الفاشلة بسبب سياسة DMARC.

هذه مرحلة ممتازة لاكتشاف أنك نسيت مثلًا:

• منصة المتجر.
• CRM.
• برنامج Support.
• Newsletter.
• خدمة الفواتير.
• نظامًا قديمًا ما زال يرسل Email.

بعد التأكد أن المصادر الشرعية موثقة بصورة صحيحة، يمكن التفكير في سياسة أقوى.

ماذا تفعل p=quarantine؟

p=quarantine

تطلب من Receivers التعامل بحذر مع الرسائل التي تفشل DMARC، وقد يؤدي ذلك إلى وضعها في Spam أو عزلها بحسب نظام المستلم.

وماذا عن p=reject؟

p=reject

هي السياسة الأقوى.

تطلب رفض الرسائل التي تفشل DMARC.

لا تنتقل إليها لأن Tutorial قالت إنها «أفضل».

انتقل إليها عندما تعرف جميع مصادر الإرسال الشرعية لديك وتتأكد من Authentication وAlignment.

لا تستخدم DMARC لإصلاح Spam قبل إصلاح مصادر الإرسال

DMARC ليست زرًا يجعل Gmail تثق بك.

إذا كان متجرك يرسل من ثلاثة أنظمة مختلفة واثنان منها غير معدين بصورة صحيحة، وضع:

p=reject

قد يجعل جزءًا من بريدك الشرعي يفشل بدل تحسينه.

مثال عملي لمتجر يستخدم أكثر من نظام

لنفترض أن لديك:

Google Workspace
→ بريد الموظفين

Transactional Email Provider
→ الطلبات والفواتير

Newsletter Platform
→ الحملات التسويقية

يجب ألا تنظر فقط إلى Email الرئيسية للشركة.

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

افصل Transactional Email عن Marketing Email منطقيًا

رسالة:

تم استلام طلبك رقم 1254

ليست من النوع نفسه مثل:

خصم 40% هذا الأسبوع

الأولى Transactional.

والثانية Marketing.

في الأنظمة الأكبر قد يكون من المفيد فصل مسارات الإرسال أو Subdomains بحسب طبيعة البريد ومزود الخدمة.

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

لا ترسل Email المتجر من عنوان مجاني

إذا كان موقعك:

example.com

فمن الأفضل استخدام هوية بريد مرتبطة بـDomain مثل:

[email protected]
[email protected]
[email protected]

بدل جعل المتجر يرسل باسم:

[email protected]

استخدام Domain الخاصة بك يسهل بناء هوية إرسال صحيحة وإعداد Authentication بصورة منظمة.

استخدام From مزيفة لا يعمل كما تتوقع

أحيانًا يضع صاحب الموقع:

From: [email protected]

عندما يرسل العميل Contact Form.

المشكلة أن Server الخاصة بك لا تملك حق إرسال Gmail باسم العميل.

الأفضل أن ترسل الرسالة من Domain الخاصة بك:

From:
[email protected]

ثم تستخدم:

Reply-To:
[email protected]

بهذه الطريقة عندما يضغط الموظف Reply يرد على العميل، بينما تظل هوية الإرسال صحيحة.

PHP mail() ليست دائمًا الاختيار المناسب لمتجر حقيقي

يمكن لموقع بسيط أن يرسل البريد مباشرة من Server، لكن متجرًا يعتمد على Email للطلبات واستعادة Password والفواتير يحتاج إرسالًا يمكن مراقبته.

استخدام SMTP أو Transactional Email Service يوفر عادة أدوات أفضل مثل:

• Logs.
• Bounce Tracking.
• Delivery Status.
• Domain Authentication.
• Rate Controls.
• إدارة Reputation حسب نوع الخدمة.

إذا قال العميل:

«ما وصلتني رسالة الطلب»

تحتاج إلى معرفة هل التطبيق أرسلها فعلًا، وهل مزود البريد قبلها، وهل Receiver استلمها.

بعد تعديل DNS لا تختبر بإرسال عشر رسائل متتالية

DNS قد تحتاج بعض الوقت حتى تظهر القيمة الجديدة عبر Resolvers المختلفة بحسب TTL وحالة Cache.

يمكنك التحقق من Records مباشرة.

على Linux:

dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short
dig TXT _dmarc.example.com +short

وعلى Windows يمكن استخدام:

nslookup -type=txt example.com

nslookup -type=txt selector1._domainkey.example.com

nslookup -type=txt _dmarc.example.com

استبدل:

example.com

بـDomain الفعلية وSelector بالقيمة التي أعطاك إياها مزود البريد.

اختبار DNS ليس اختبار Email كاملًا

وجود TXT Record صحيحة لا يثبت أن البرنامج يستخدمها أثناء الإرسال.

بعد تعديل DNS أرسل رسالة جديدة ثم افتح Headers.

ما نريد رؤيته في النهاية:

spf=pass
dkim=pass
dmarc=pass

ولا تعتمد على فحص رسالة قديمة أرسلت قبل تغيير DNS.

الثلاثة PASS والرسائل ما زالت في Spam؟

هنا نخرج من مرحلة Authentication إلى مرحلة Deliverability.

SPF وDKIM وDMARC تثبت هوية الإرسال وتساعد Receivers على تقييم الرسالة، لكنها لا تعطي ضمانًا بأن كل رسالة ستدخل Inbox.

إذا كانت الثلاثة PASS، راجع عوامل أخرى.

1. Reputation للـDomain والـIP

Domain جديدة أو IP لم ترسل بريدًا من قبل لا تملك History طويلة لدى مزودي البريد.

كذلك IP سيئة السمعة قد تؤثر على التسليم.

إذا كنت تستخدم Shared Email Provider، فالمزود يدير جزءًا كبيرًا من بنية الإرسال.

أما إذا كنت تشغل Mail Server بنفسك على VPS، فأنت تتحمل أيضًا مسؤولية IP Reputation وReverse DNS وإعدادات SMTP وتسليم البريد.

2. حجم الإرسال تغير فجأة

Domain كانت ترسل عشرين رسالة يوميًا ثم بدأت فجأة بإرسال عشرات الآلاف قد تبدو مختلفة جدًا لأنظمة مكافحة Spam.

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

3. المستخدمون يبلغون عن الرسائل كـSpam

يمكن أن تكون Authentication مثالية، لكن إذا كان المستلمون يضغطون:

Report spam

مرارًا، فهذه إشارة سلبية قوية.

لا ترسل Marketing لمن لم يطلبها، واجعل طريقة إلغاء الاشتراك واضحة في البريد التسويقي.

4. ترسل إلى عناوين سيئة أو قديمة

قائمة Email مليئة بعناوين غير صالحة تزيد Bounces وتقلل جودة الإرسال.

راقب العناوين التي تفشل بصورة دائمة ولا تستمر في إعادة الإرسال إليها بلا نهاية.

5. محتوى الرسالة نفسها

لا توجد قائمة سحرية من «الكلمات الممنوعة» تستطيع حذفها وينتهي Spam.

لكن رسالة تبدو احتيالية أو تحتوي روابط غريبة أو HTML مكسورة أو عددًا مبالغًا فيه من الروابط والصور قد تحصل على تقييم أسوأ.

رسائل Transactional الأفضل أن تكون مباشرة:

رقم الطلب
المنتجات
القيمة
حالة الدفع
عنوان الشحن
رابط موثوق للمتجر

بدل تحويل رسالة تأكيد طلب إلى Newsletter كاملة.

6. From وReply-To غير منطقيتين

إذا كان From يقول:

[email protected]

لكن Reply-To يشير إلى Domain غريبة تمامًا بلا سبب، أو الروابط داخل الرسالة كلها تذهب إلى Domains مختلفة، فقد تصبح الرسالة أقل وضوحًا للمستلم وأنظمة الحماية.

اجعل هوية الرسالة منطقية ومتناسقة.

7. رابط المتجر نفسه به مشكلة

Email قد تكون موثقة جيدًا، لكن إذا كانت تحتوي على Links إلى Domain مصابة أو مخترقة أو ذات سمعة سيئة، فهذه مشكلة منفصلة.

حماية الموقع نفسه جزء من منظومة Email أيضًا.

لو كنت ترسل من Mail Server على VPS بنفسك

SPF وDKIM وDMARC ليست كل إعدادات Mail Server.

تحتاج أيضًا إلى الانتباه إلى أشياء مثل:

• Hostname صحيحة.
• PTR / Reverse DNS.
• Forward DNS متناسقة.
• TLS.
• IP غير مدرجة في Blocklists مؤثرة.
• عدم تشغيل Open Relay.
• إدارة Queue وBounces.
• Reputation للـIP.

ولهذا بالنسبة إلى متجر صغير أو متوسط، استخدام مزود Transactional Email متخصص يكون غالبًا أسهل من بناء Mail Server عامة من الصفر.

طريقة التشخيص الأسرع

ترتيب إعداد Domain جديدة للبريد

إذا كنت تبدأ من الصفر، استخدم هذا الترتيب:

1. حدد جميع الأنظمة التي سترسل Email.
2. وثق Domain داخل كل مزود.
3. أنشئ SPF واحدة صحيحة تشمل المصادر المطلوبة.
4. أضف DKIM Records التي يقدمها كل مزود.
5. اختبر رسائل فعلية وتأكد من SPF وDKIM.
6. أضف DMARC بسياسة مراقبة مناسبة.
7. راقب مصادر الإرسال والتقارير.
8. أصلح أي نظام لا يحقق Alignment.
9. بعد التأكد من البيئة، شدد DMARC تدريجيًا إذا كان ذلك مناسبًا لك.

بعد كل تغيير، اسأل الرسالة نفسها

لا تعتمد على أن لوحة DNS تظهر Record باللون الأخضر.

أرسل Email حقيقية وافتح Headers.

في النهاية يجب أن تعرف الإجابة عن هذه الأسئلة:

من أرسل الرسالة؟

هل SPF سمحت له؟

هل الرسالة تحمل DKIM صالحة؟

بأي Domain تم توقيعها؟

هل هذه Domain متوافقة مع From؟

هل DMARC نجحت؟

إذا نجحت كلها، لماذا صنفها Receiver كـSpam؟

عندما تفصل هذه الأسئلة عن بعضها، تتحول مشكلة «الإيميلات تروح Spam» من مشكلة غامضة إلى خطوات يمكن تشخيصها واحدة واحدة.