أسباب عدم وصول بريد نموذج التواصل وطريقة الإصلاح

1. الملخّص التنفيذيّ

عندما «ينجح الإرسال» من نموذج التواصل لكن الرسالة لا تصل، يكون السبب في العادة ليس كود إرسال البريد، بل تصميم المرسل. الخلاصة في ثلاث نقاط.

1. ثبّت From: على نطاق الموقع، وضع عنوان مستخدم النموذج في Reply-To:. الهدف مواءمة المرسل الظاهر مع النطاق الذي يُصادَق فعليّاً.
2. اضبط SPF و DKIM معاً. التحويل يكسر SPF بسهولة، والاعتماد على SPF وحده يُسقط رسائل مشروعة.
3. ابدأ DMARC بمراقبة p=none، ثمّ ارفع تدريجيّاً إلى quarantine / reject. الانتقال فوراً إلى reject يوقف بريدك المشروع أيضاً.

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

الجمهور المستهدف والبيئة المفترضة

هذا المقال موجَّه لمن يواجه مشكلة عدم وصول رسائل الإشعار من نموذج التواصل في موقع الشركة.

حديث سجلّات DNS (SPF / DKIM / DMARC) وتصميم الـ headers مشترك سواء كان خادم الويب Windows أو Linux، وسواء كان الإرسال عبر MTA خاصّ أو خدمة خارجيّة. حتّى إن اختلفت لغة التنفيذ، ما يُعاد تفسيره نقطتان فقط: «أين تُركَّب الـ headers» و«أين يُحدَّد envelope sender».

مصطلحات هذا المقال

نلخّص أوّلاً مصطلحات تظهر في النصّ دون شرح لاحق.

بنية هذا المقال

1. الملخّص التنفيذيّ (هذا الفصل)
2. أدوار SPF و DKIM و DMARC وحقل From ── فهم الآليّة
3. سيناريوهات الفشل الشائعة في نموذج التواصل
4. خطوات التشخيص والأوامر ── الـ headers و DNS و SMTP والإرسال الفعليّ
5. أنماط تصميم From الموصى بها
6. دليل الإعداد حسب التشكيلة (SMTP خارجيّ / استضافة مشتركة / PHP)
7. قائمة تحقّق استكشاف الأخطاء

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. أدوار SPF و DKIM و DMARC وحقل From

في تسليم البريد يجب الفصل بين الـ envelope و الـ headers. ما يتحقّق منه SPF أساساً هو MAIL FROM أثناء جلسة SMTP، وهو المرسل من ناحية التسليم. عند التسليم النهائيّ ينبغي أن يبقى مسار عكسيّ واحد فقط بوصفه Return-Path، ولا ينبغي لنظام SMTP المرسِل أن يصنع من البداية رسالة تحمل header اسمه Return-Path. في المقابل يمثّل From: على جانب headers الجسم «ممّن تبدو الرسالة»، و Reply-To: وجهة الردّ، و Sender: الجهة التي أرسلت فعليّاً.

تعرّف RFC 5322 حقل From: بأنّه مؤلّف الرسالة، و Sender: بأنّه جهة الإرسال الفعليّة. إن كان المؤلّف وجهة الإرسال هما نفسهما فلا ينبغي استخدام Sender:، وإن أردنا جعل وجهة الردّ مختلفة عن المؤلّف فالمنهج الصحيح استخدام Reply-To:. وتصرّح RFC 5322 أيضاً بأنّه ينبغي عدم وضع عنوان لا يخصّ المؤلّف في From:. إشعار نموذج التواصل عادة ليس رسالة يرسلها المستخدم نفسه عبر MUA، بل إشعار يصنعه نظام الموقع، فوضع عنوان المستخدم في From: ينحرف بسهولة عن دلالة المواصفة أيضاً.

يلصق DKIM توقيعاً على بعض headers والجسم، ويتحقّق المستقبِل بمفتاح عامّ في DNS. يُمثَّل نطاق التوقيع بـ d= ضمن DKIM-Signature، ويُجلَب المفتاح العامّ عبر selector كما في selector._domainkey.example.com. يُستخدَم DKIM بوصفه مصادقة «أكثر صموداً نسبيّاً أمام التحويل»، لكن إن عُدِّل الجسم أو الـ headers الموقَّعة في الطريق فشلت bh= (تجزئة الجسم) والتحقّق من التوقيع.

لا يكتفي DMARC بنجاح SPF أو DKIM، بل ينظر فيما إذا كان النطاق المُصادَق منهما متّسقاً مع نطاق From:. هذه هي النقطة المحوريّة. إن نجح SPF بقيمة MAIL FROM=bounces.vendor.net وكان From: contact@example.com، فإنّ alignment الخاصّ بـ SPF يسقط. وإن نجح DKIM بـ d=example.com يمكن أن يجتاز DMARC، لكن في غياب DKIM يفشل DMARC. يعرّف DMARC أوضاع alignment صارمة/مرنة عبر adkim / aspf، وسياسات p=none|quarantine|reject، ووجهات تقارير rua / ruf.

تترجم إرشادات Gmail الحديثة هذه الفلسفة التصميميّة مباشرة إلى متطلّبات تشغيل. تصرّح Google بأنّه «لا تنتحل header الـ From:»، وأنّه «في البريد المباشر يجب أن يتطابق نطاق header الـ From: مع نطاق SPF أو نطاق DKIM». إشعارات نموذج التواصل ليست رسائل تسويقيّة، لكنّ منطق فلاتر الاستقبال الأساسيّ هو نفسه، فإذا تجاهلنا هذا المنطق ينخفض معدّل الوصول.

sequenceDiagram
    participant User as مستخدم النموذج
    participant App as تطبيق الويب
    participant SMTP as MTA الإرسال / خدمة SMTP
    participant DNS as DNS
    participant MX as MX جهة الاستقبال

    User->>App: إرسال النموذج
    App->>App: تحديد From / Reply-To / Sender
    App->>SMTP: طلب إرسال SMTP
    SMTP->>SMTP: إلحاق توقيع DKIM
    SMTP->>MX: MAIL FROM / RCPT TO / DATA
    MX->>DNS: استعلام SPF (MAIL FROM)
    MX->>DNS: استعلام مفتاح DKIM العام (selector._domainkey)
    MX->>DNS: استعلام DMARC (_dmarc + نطاق From)
    MX->>MX: حكم الـ alignment
    MX-->>App: استلام / بريد مزعج / رفض / ارتداد

النقطة المهمّة في هذا المسار هي أنّ معيار حكم DMARC يدور حتّى النهاية حول نطاق From:. لأنّنا نلامس From: على جانب التطبيق، و MAIL FROM على جانب SMTP، و SPF/DKIM/DMARC على جانب DNS، كلّاً على حدة، لا يحلّ إصلاح واحد منها فقط مشكلة عدم الوصول.

3. سيناريوهات الفشل الشائعة في نموذج التواصل

الأكثر شيوعاً هو وضع عنوان مستخدم النموذج في From:. مثلاً، عند الإرسال من SMTP الموقع وجعل From: taro@gmail.com، فإنّ ما يجتاز SPF أو DKIM عادة هو نطاق الموقع، لا نطاق Gmail. والنتيجة انحراف يجعل From: على Gmail والنطاق المُصادَق هو example.com، فيفشل alignment في DMARC. تطلب Google نفسها تجنّب انتحال From: وتطابق From: مع نطاق SPF/DKIM.

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

نقص الإعدادات الأوّليّة عند استخدام خدمات SMTP خارجيّة نمط شائع كذلك. في SendGrid قد لا يمكن الإرسال دون ضبط Domain Authentication، وعند تشغيل Automated Security تُولَّد سجلّات مصادقة بصيغة CNAME، ويمكن عند الحاجة ضبط Custom Return Path أو Custom DKIM Selector. في SES يُستخدَم افتراضيّاً MAIL FROM على amazonses.com، فيتحقّق SPF ضمنيّاً، لكن إن أردنا alignment لـ SPF مع نطاق الموقع فيجب ضبط custom MAIL FROM. في Mailgun أيضاً، إن لم تُضبَط SPF/DKIM لنطاق الإرسال و MX اللازمة، لن يتكوّن توقيع إرسال صحيح.

MTA المحلّيّ ضمن الاستضافة المشتركة لغم يسهل إغفاله. حتّى لو كان موقعك مُصادَقاً، إن كان IP الفعليّ الخارج IP مشتركاً سيّئ السمعة، أو لا يوجد PTR، أو لم يُضَف DKIM من جانب الاستضافة، ينخفض معدّل الوصول. تُلزِم Google بـ PTR لـ IP الإرسال، وترشد إلى أنّ سوء سمعة الـ IP المشترك قد يكون سبباً لأخطاء من سلسلة 5.7.1.

طريقة استخدام mail() في PHP أو مكتبات الإرسال عرضة للفشل أيضاً. يشرح دليل PHP أنّ mail() يحتاج إلى header اسمه From، وأنّه يمكن عبر معاملات إضافيّة تحديد envelope sender بـ sendmail -f. أي بدل تركيب header اسمه Return-Path: بنفسك، مرِّر envelope sender إلى الـ MTA. سوء فهم هذه النقطة يؤدّي إلى انحراف بين المرسل المستخدَم في فحص SPF والمرسل الذي يفترضه التطبيق.

أخيراً، حالة العبث بـ Sender أو From في موضع ينبغي فيه استخدام Reply-To. إن كان الهدف توجيه الردّ إلى المستخدم فقط فإنّ Reply-To يكفي. أمّا Sender فيُستخدَم حين تريد توضيح أنّ «المؤلّف يختلف عن جهة الإرسال الفعليّة»، وليس header يُستخدَم بانتظام في نموذج التواصل. الفصل بين هل غاية التصميم «إعادة الردّ إلى المستخدم» أم «إظهار الجهة المسؤولة عن الإشعار» يقلّل الحوادث.

4. خطوات التشخيص والأوامر

أوّل ما ينبغي فعله هو النظر إلى headers البريد الخامّة قبل النظر إلى الكود. في Gmail عبر «إظهار مصدر الرسالة»، وفي Outlook عبر «تفاصيل الرسالة» أو «ترويسات الإنترنت»، يمكن التحقّق من Authentication-Results و Return-Path و From و Reply-To و DKIM-Signature و Received. النظر هنا يفصل بدقّة عالية بين هل المشكلة «لم يُرسَل» أم «انكسر اتّساق المصادقة».

أوّل ما يُنظَر إليه في الـ headers

النقاط الخمس التالية ذات الأولويّة القصوى:

1. ما نطاق From:
2. ما نطاق Return-Path:
3. هل يظهر spf=pass / dkim=pass / dmarc=pass في Authentication-Results:
4. عند dkim=pass، ما نطاق header.i= أو d=
5. عند dmarc=fail، هل السبب فشل المصادقة أم alignment failure

في دليل Google لاستكشاف أخطاء DMARC مذكور صراحة أنّه حتّى لو اجتازت الرسالة المصادقات الأخرى، إن لم تكن الـ headers متّسقة (aligned) فسيفشل DMARC.

أوامر التحقّق من DNS

dig أداة تقليديّة موجَّهة لاستكشاف أخطاء DNS، ويصفها دليل BIND بأنّها أداة استعلام DNS مرنة وذات إخراج واضح. nslookup أداة فحص أخفّ، يمكن استخدامها حتّى في الوضع غير التفاعليّ. للتحقّق من مصادقة نموذج التواصل نستعلم على الأقلّ عن SPF و DKIM و DMARC الثلاثة.

# SPF
dig +short TXT example.com

# DKIM
dig +short TXT form2026._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

# Windows なら
nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=txt form2026._domainkey.example.com

مثال الإخراج المتوقّع كالتالي:

"v=spf1 include:sendgrid.net include:mailgun.org ip4:203.0.113.10 -all"
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
"v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; adkim=r; aspf=r; fo=1"

ما يجب النظر إليه هنا هو هل سجلّ SPF موحَّد في سجلّ واحد، وهل يمكن جلب المفتاح العامّ لـ DKIM، وهل يحتوي DMARC على p=. تحدّد RFC 7208 أنّ SPF يجب أن يحدّ آليّات إثارة استعلامات DNS بمجموع 10، وتجاوز الحدّ سبب لـ permerror.

التحقّق من اتّصال SMTP و TLS

openssl s_client عميل SSL/TLS عامّ من OpenSSL، مفيد للتحقّق من STARTTLS وسلسلة الشهادات لخادم SMTP. عبر -starttls smtp يبدأ STARTTLS في SMTP، وعبر -showcerts يعرض قائمة الشهادات التي يعيدها الخادم.

printf 'QUIT\r\n' | openssl s_client \
  -connect smtp.example.com:587 \
  -starttls smtp \
  -servername smtp.example.com \
  -showcerts \
  -brief

مثال على الإخراج:

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
250 CHUNKING

بهذا يمكن على الأقلّ رؤية هل يمكن الاتّصال بخادم SMTP، وهل STARTTLS مفعَّل، وهل توجد علل ظاهرة في التحقّق من الشهادة. تطلب Google TLS من المرسلين بحجم معيّن فأكثر، وعدم استخدام TLS قد يكون سبباً لـ 5.7.29.

اختبار إعادة إنتاج الإرسال الفعليّ

swaks أداة عمليّة مخصّصة لاختبار SMTP، تعيد إنتاج اختبارات الإرسال شاملة TLS والمصادقة وامتدادات SMTP بمرونة. في تحقيق عدم وصول نموذج التواصل، من المفيد إرسال رسالة واحدة فقط «بنفس SMTP / نفس From / نفس Reply-To / نفس الوجهة» دون المرور بالتطبيق.

swaks \
  --server smtp.example.com \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user contact@example.com \
  --auth-password '********' \
  --from bounce@example.com \
  --to yourtest@gmail.com \
  --h-From "サイト通知 <contact@example.com>" \
  --h-Reply-To "山田太郎 <visitor@gmail.com>" \
  --header "Subject: swaks test" \
  --body "This is a test"

النموذج الاعتياديّ عند نجاح الإرسال:

=== Trying smtp.example.com:587...
=== Connected to smtp.example.com.
<-  250-STARTTLS
<-  250-AUTH LOGIN PLAIN
->  STARTTLS
<-  220 Ready to start TLS
...
<-  250 2.0.0 Ok: queued as ABC123DEF

إن فشل عبر التطبيق ونجح عبر swaks، فالاحتمال الأقوى أنّ السبب يميل إلى تركيب الـ headers في المكتبة أو ضبط envelope sender. وعلى العكس، إن سقط swaks بالطريقة نفسها، يمكن حصر السبب في DNS أو SMTP أو سياسات جهة الاستقبال.

التشخيص الخارجيّ عبر mail-tester

mail-tester خدمة تُرسَل إليها رسالة على عنوان اختباريّ عشوائيّ، فتحلّل الرسالة وخادم الإرسال و IP الإرسال وتعيد تقريراً تفصيليّاً. مناسبة كتشخيص أوّليّ لحالات «لا تصل لسبب غامض» في MTA محلّيّ أو خادم مشترك.

الاستخدام بسيط:

1. الحصول على عنوان الاختبار الذي يصدره mail-tester
2. إرسال رسالة واحدة بنفس مسار نموذج التواصل
3. الاطّلاع على النتيجة، وعلى ملاحظات SPF / DKIM / DMARC / البحث العكسيّ / قوائم الحظر / تركيب الجسم

يجب عدم الحكم على التسليم في الإنتاج بناءً على نتيجة mail-tester وحدها، لكنّها على الأقلّ تكشف بسرعة «غياب SPF أصلاً» أو «تعذّر جلب المفتاح العامّ لـ DKIM» أو «تركيب الجسم والمرسل غير طبيعيّ».

عيّنة لتحليل الـ headers

مثال للفشل:

Return-Path: <bounce-123@vendor.example.net>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-123@vendor.example.net designates 198.51.100.10 as permitted sender) smtp.mailfrom=vendor.example.net;
       dkim=none;
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=gmail.com
From: 山田太郎 <visitor@gmail.com>
Reply-To: 山田太郎 <visitor@gmail.com>
Subject: استفسار

في هذه الرسالة، حتّى لو اجتاز SPF نفسه، فإنّ From: على gmail.com فيفشل DMARC. عطل نموذجيّ ناتج عن وضع عنوان المستخدم في From: في نموذج التواصل.

مثال للنجاح:

Return-Path: <bounce@example.com>
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass header.i=@example.com header.s=form2026;
       dmarc=pass header.from=example.com
From: Example Site <contact@example.com>
Reply-To: 山田太郎 <visitor@gmail.com>
Subject: إشعار استفسار

بهذا الشكل تُؤمَّن سهولة الردّ على المستخدم عبر Reply-To:، ويتوحّد المرسل الظاهر والمرسل المُصادَق على example.com معاً، فيستقرّ معدّل الوصول كثيراً.

5. أنماط تصميم From الموصى بها

المبدأ الذي لا يتزعزع في نموذج التواصل هو توحيد «النطاق المستخدَم في المصادقة» مع «نطاق From الذي يُعرَض للمستلم». وعلى ذلك تُفلَت وجهة الردّ فقط إلى Reply-To:. يستقرّ التصميم بتقسيمه إلى ثلاث طبقات: استخدام Sender: فقط عند الحاجة، وضبط Return-Path عبر الـ envelope.

أساس هذا الجدول دلالات From / Sender / Reply-To في RFC 5322، ومعاملة Return-Path في RFC 5321، ومواصفة DMARC التي تحكم على الاتّساق بناءً على From:. الافتراضيّ لإشعارات النموذج يكفي معه «النمط الموصى به» في السطر الأوّل. حتّى في المواقف التي تشعر فيها برغبة وضع عنوان المستخدم في From:، يتحقّق الهدف بوضع وجهة الردّ في Reply-To:.

ما ينبغي تذكّره خصوصاً هو أنّ Return-Path ليس «header يُحرَّر»، بل «نتيجة envelope sender المستخدَم في التسليم». في PHP mail() نتعامل معه عبر -f، وفي خدمات SMTP عبر إعدادات Custom MAIL FROM / Return Path / bounce domain، وهذا هو التطبيق الصحيح.

6. دليل الإعداد حسب التشكيلة

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

حين يستخدم الموقع SMTP خارجيّاً

أهمّ نقطة في SMTP الخارجيّ هي إنهاء مصادقة نطاقك أوّلاً. ترشد Google أيضاً إلى أنّه عند استخدام مزوّد خدمة بريد يجب التحقّق من أنّ تلك الخدمة تصادق SPF و DKIM لنطاقك.

التشكيلة الموصى بها

• From: هو contact@example.com أو contact@form.example.com
• Reply-To: عنوان مستخدم النموذج
• Return-Path / MAIL FROM هو نطاق فرعيّ للارتداد تديره أنت، مثل bounce.example.com
• DKIM يوقَّع بـ example.com أو بنطاق فرعيّ مخصّص للإرسال
• DMARC يوضع على نطاق From: الظاهر

إعدادات SendGrid النمطيّة

في SendGrid، Domain Authentication شرط مسبق، وعند تفعيل Automated Security تُولَّد 3 سجلّات CNAME. عند إيقافه يُولَّد MX واحد و TXT اثنان، ويمكن أيضاً ضبط Custom Return Path و Custom DKIM Selector.

; 例: SendGrid（実際の値は管理画面で生成されたものを使う）
em123.example.com.           CNAME   u123456.wl.sendgrid.net.
s1._domainkey.example.com.   CNAME   s1.domainkey.u123456.wl.sendgrid.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u123456.wl.sendgrid.net.

_dmarc.example.com.          TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

ما يسهل الوقوع فيه مع SendGrid هو حالة «اكتفاء بمصادقة SMTP فقط، دون ضبط Domain Authentication». في هذه الحالة يمكن الإرسال نفسه، لكن من جانب الاستقبال تضعف العلاقة بين From: والنطاق المُصادَق. الأساس هو إنجاز Domain Authentication، ثمّ ضبط Custom Return Path عند الحاجة فوقه.

إعدادات SES النمطيّة

يستخدم SES افتراضيّاً MAIL FROM على نطاق فرعيّ من amazonses.com، فيتحقّق SPF نفسه ضمنيّاً. لكن إن أردنا alignment لـ SPF مع نطاق الموقع نستخدم custom MAIL FROM. في هذه الحالة يطلب SES من نطاق custom MAIL FROM TXT لـ SPF و MX، ويجب أن يكون MX واحداً بالضبط. وفي Easy DKIM نضيف 3 CNAME إلى DNS.

; 例: SES Easy DKIM
abcde12345._domainkey.example.com.   CNAME   abcde12345.dkim.amazonses.com.
fghij67890._domainkey.example.com.   CNAME   fghij67890.dkim.amazonses.com.
klmno54321._domainkey.example.com.   CNAME   klmno54321.dkim.amazonses.com.

; 例: SES custom MAIL FROM
bounce.example.com.                  MX      10 feedback-smtp.ap-northeast-1.amazonses.com.
bounce.example.com.                  TXT     "v=spf1 include:amazonses.com -all"

_dmarc.example.com.                  TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

النقطة المهمّة في تصميم SES هي أن يكون نطاق MAIL FROM ليس نطاق From: المرسِل نفسه، بل نطاقاً فرعيّاً مخصّصاً للارتداد. ترشد AWS أيضاً إلى أن يكون MAIL FROM نطاقاً فرعيّاً ليس هو نطاق الإرسال الفعليّ نفسه.

إعدادات Mailgun النمطيّة

في Mailgun، عند التحقّق من نطاق الإرسال نحتاج إلى TXT لـ SPF و TXT لـ DKIM، إضافة إلى MX اثنين. إن وُجد SPF مسبقاً، فبدلاً من إضافة سجلّ SPF جديد نُدخِل include:mailgun.org ضمن السجلّ الموجود. قد تظهر مفاتيح DKIM متعدّدة، لكن إن كان المفتاح المستخدَم حاليّاً منشوراً بصورة صحيحة في DNS فالإرسال ممكن.

; 例: Mailgun をサブドメインで使う
mg.example.com.                      TXT     "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.example.com.        TXT     "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
mg.example.com.                      MX      10 mxa.mailgun.org.
mg.example.com.                      MX      10 mxb.mailgun.org.
email.mg.example.com.                CNAME   mailgun.org.

_dmarc.example.com.                  TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

Mailgun متناسب مع التشغيل عبر نطاق فرعيّ، فبتخصيص نطاق إرسال مثل mg.example.com تسهل إدارة إشعارات النموذج وإشعارات المعاملات.

حين يُرسل الموقع عبر MTA محلّيّ في استضافة مشتركة

أوّل ما يجب النظر إليه في الاستضافة المشتركة هو جودة بنية الإرسال على جانب الاستضافة، لا تطبيقك. إن كان PTR لـ IP الإرسال، ودعم DKIM، وسمعة الـ IP المشترك، ووضوح سجلّات الإرسال ضعيفة، فهذه التشكيلة في حدّ ذاتها غير مؤاتية. تولي Google أهمّيّة لـ PTR لـ IP الإرسال، وترشد إلى أنّ سوء سمعة الـ IP المشترك قد يكون سبباً للحجب.

من الناحية العمليّة، الترتيب الآمن هو الآتي:

1. التحقّق من أنّ شركة الاستضافة تتيح ضبط SPF/DKIM/PTR عبر لوحة الإدارة أو الدعم
2. تثبيت From: دائماً على نطاقك
3. تضمين IP الإرسال للاستضافة أو نطاق الإرسال المسموح به في SPF
4. تفعيل DKIM عبر ميزة الاستضافة. إن لم تكن متوفّرة، التبديل إلى SMTP خارجيّ
5. إن أمكن، فصل عنوان ارتداد لـ MAIL FROM إلى مثل bounce.example.com

في خادم الاستضافة المشتركة، ابدأ بالسؤال لدى الجهة المتعاقد معها

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

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

كنموذج لإنشاء DKIM بنفسك في استضافة مشتركة، تتيح أنظمة من نوع OpenDKIM توليد المفتاح الخاصّ وسجلّ TXT لـ DNS عبر opendkim-genkey. بنية وضع المفتاح العامّ لـ DKIM في selector._domainkey.example.com المرفقة بالـ selector تتطابق مع RFC 6376.

mkdir -p /etc/opendkim/keys/example.com
opendkim-genkey -D /etc/opendkim/keys/example.com -d example.com -s form2026
chown opendkim:opendkim /etc/opendkim/keys/example.com/form2026.private
chmod 600 /etc/opendkim/keys/example.com/form2026.private

صورة ما بعد التوليد كالتالي:

form2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

# /etc/opendkim/KeyTable
form2026._domainkey.example.com example.com:form2026:/etc/opendkim/keys/example.com/form2026.private

# /etc/opendkim/SigningTable
*@example.com form2026._domainkey.example.com

لكن إن كنت لا تستطيع التحكّم بنفسك في PTR أو outbound relay في الاستضافة المشتركة، فالأقصر الانتقال إلى SMTP خارجيّ. حتّى للإرسال بكمّيّة قليلة كإشعارات نموذج التواصل، فإنّ MTA محلّيّاً ضعيف المصادقة في وضع غير مؤاتٍ أمام Gmail وبريد الشركات.

حين يستخدم الموقع PHP mail() أو مكتبة SMTP

PHP mail() مريح، لكن من زاوية المصادقة ومعدّل الوصول يعتمد على هويّة الـ MTA الذي خلفها. يشرح دليل PHP أنّ البريد يحتاج إلى header اسمه From، وأنّه عند الإرسال عبر sendmail_path يمكن تحديد envelope sender بمعاملات إضافيّة. بمعنى مقلوب، استخدام mail() لا يضبط SPF/DKIM/DMARC تلقائيّاً.

أوّلاً، نصمّم بالحدّ الأدنى كالتالي:

• From: هو contact@example.com
• Reply-To: هو مستخدم النموذج
• envelope sender هو bounce@example.com
• إدراج عنوان المستخدم بوضوح في الجسم أيضاً
• إن أمكن، استخدام SMTP مُصادَق بدلاً من mail()

مثال على أبسط تشكيلة لـ mail()

إدخال مدخلات المستخدم في الـ headers كما هي خطر. إن خُلِط CR/LF في $name أو $email يستطيع المهاجم حقن headers إضافيّة مثل Bcc:، فيصبح النموذج مرحِّلاً للبريد العشوائيّ. يرشد دليل PHP أيضاً إلى التحقّق/التطبيع الإلزاميّ للمدخلات الخارجيّة المستخدَمة في الـ headers. في المثال أدناه يُنقَّى أيّ شيء يُحقَن في الـ headers سلفاً، شاملاً وسيط envelope sender (additional_params).

<?php

// أعد فقط قيمة يجوز وضعها في header. ارفض إن احتوت CR/LF/NUL.
function sanitize_header_value(string $value): string {
    if (preg_match('/[\r\n\0]/', $value)) {
        throw new InvalidArgumentException('Invalid characters in header value');
    }
    return trim($value);
}

// تحقّق من عنوان البريد وفق RFC.
function sanitize_email(string $email): string {
    $clean = sanitize_header_value($email);
    if (!filter_var($clean, FILTER_VALIDATE_EMAIL)) {
        throw new InvalidArgumentException('Invalid email address');
    }
    return $clean;
}

$to = 'ops@example.com';
$subject = sanitize_header_value('إشعار استفسار');

// $name / $email / $message مدخلات النموذج. $message للنص فيجوز CR/LF،
// أما $name / $email المستخدمان في الـ header فارفض CR/LF حتماً.
$safeName  = sanitize_header_value($name);
$safeEmail = sanitize_email($email);

$body = <<<TEXT
Name: {$safeName}
Email: {$safeEmail}

{$message}
TEXT;

$headers = [
    'From' => 'Example Site <contact@example.com>',
    'Reply-To' => sprintf('%s <%s>', $safeName, $safeEmail),
    'Content-Type' => 'text/plain; charset=UTF-8',
];

// additional_params يصل إلى الصدفة أيضاً، فاستخدم قيمة ثابتة ولا تخلط مدخلات ديناميكية.
mail($to, $subject, $body, $headers, '-fbounce@example.com');

نقطة هذا المثال اثنتان. الأولى أنّنا لا نكتب Return-Path: كـ header، بل نمرّر envelope sender بوسيط -f الخامس. والثانية أنّ مدخلات المستخدم التي تُحقَن في headers مثل Reply-To: تمرّ عبر دالّة تنقية ترفض CR/LF. إن رُكِّبت الـ headers بلا تنقية، يستطيع المهاجم دفق سلسلة مثل \r\nBcc: victim@example.com لحقن header إضافيّ، ولذلك يعدّ دليل PHP التحقّق عند استخدام مدخلات خارجيّة في الـ headers أمراً لازماً. يصل additional_params في النهاية إلى الصدفة أيضاً، فمرِّره بقيمة ثابتة دون خلط مدخلات المستخدم.

مثال باستخدام مكتبة SMTP

<?php
$mail->isSMTP();
$mail->Host = 'smtp.example.com';
$mail->Port = 587;
$mail->SMTPAuth = true;
$mail->SMTPSecure = 'tls';
$mail->Username = getenv('SMTP_USER');
$mail->Password = getenv('SMTP_PASS');

$mail->setFrom('contact@example.com', 'Example Site');
$mail->addAddress('ops@example.com');
$mail->addReplyTo($email, $name);

// بعض المكتبات تتيح ضبط Sender / return-path على حدة
$mail->Sender = 'bounce@example.com';

$mail->Subject = 'إشعار استفسار';
$mail->Body = $body;

$mail->send();

ميزة مكتبة SMTP أنّها تسهّل التحكّم في مرسل الـ header ومرسل الـ envelope كلّاً على حدة. في استخدام نموذج التواصل هي الأنسب لتصميم يثبّت From: على نطاق الموقع ويضع وجهة الردّ وحدها في Reply-To:.

أمثلة عيانيّة لـ SPF و DKIM و DMARC

مثال أساسيّ لـ SPF

example.com. TXT "v=spf1 ip4:203.0.113.10 include:sendgrid.net -all"

في SPF يجب تضمين جميع مصادر الإرسال الفعليّة. عند استخدام مرسل طرف ثالث تطلب Google أيضاً التحقّق من أنّ ذلك المرسل مُصادَق عبر SPF و DKIM. كذلك لـ SPF حدّ لعدد استعلامات DNS، فالحذر من تكديس include.

مثال أساسيّ لـ DKIM

form2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

يُستخدَم الـ selector لتدوير المفاتيح، ويمكن أن تتعايش مفاتيح عامّة متعدّدة على النطاق نفسه. في التشغيل يكون اسم يميّز الغرض أو السنة والشهر أوضح لاحقاً من default.

أمثلة إدخال DMARC

أوّلاً وضع المراقبة.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; adkim=r; aspf=r; fo=1"

ثمّ حين تريد عزل جزء.

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@example.com; adkim=r; aspf=r"

أخيراً التشغيل الصارم.

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-agg@example.com; adkim=s; aspf=s"

p=none مراقبة فقط، و quarantine توصية بالعزل، و reject توصية بالرفض أثناء SMTP. يبدّل adkim و aspf بين strict و relaxed. أسلم من الانتقال فوراً إلى reject أن ترصد الحجم ومصادر الإرسال المشروعة بـ none ثمّ ترفع تدريجيّاً.

علاوة على ذلك، عند إرسال rua / ruf إلى خدمة تجميع خارج الشركة، تشترط RFC 7489 سجلّ DNS إضافيّاً على جانب الطرف الثالث. مثلاً إن أُرسلت تقارير example.com إلى thirdparty.example.net، يجب على جهة الاستقبال نشر example.com._report._dmarc.thirdparty.example.net TXT "v=DMARC1".

7. قائمة تحقّق استكشاف الأخطاء

أخيراً نلخّص ترتيب تحقّق يُستخدَم كما هو في الميدان. عدم وصول بريد نموذج التواصل يُحسَم أسرع بالقضاء على البنود من الأعلى إلى الأسفل.

ما يجب التحقّق منه أوّلاً

• هل From: على نطاقك
• هل وضعت عنوان المستخدم في Reply-To:
• هل يوجد في Authentication-Results إمّا spf=pass أو dkim=pass، وإضافة إلى ذلك dmarc=pass
• إن كان dmarc=fail، أهو فشل مصادقة أم alignment failure
• هل SPF موحَّد في سجلّ واحد
• هل عدد استعلامات SPF مفرط
• هل يمكن جلب المفتاح العامّ لـ DKIM
• هل يحتوي DMARC على p=
• هل PTR والبحث العكسيّ لـ IP الإرسال سليم
• هل لا تستخدم IP مشتركاً، أو هل لم تتدهور سمعته

أين تنظر في الارتداد والسجلّات

إن وصل بريد ارتداد، فالمهمّ داخل DSN بصيغة message/delivery-status الحقول Final-Recipient و Status و Action و Diagnostic-Code. تعرّف RFC 3464 معلومات فشل التسليم المقروءة آليّاً هذه. مثلاً إن وُجد سطر مثل Diagnostic-Code: smtp; 550 relay not permitted فالرفض من جانب SMTP لا من طبقة التطبيق.

على جانب الخادم ننظر على الأقلّ إلى سجلّات تسليم الـ MTA. في Postfix تظهر نجاح التسليم وفشله، وبقاء الطابور، ورفض الترحيل، وفشل حلّ DNS، وتحذيرات milter لـ DKIM. الأمر مماثل في Exim. أوامر التحقّق النموذجيّة كالتالي.

# 例: Postfix
journalctl -u postfix -n 200 --no-pager
postqueue -p

# 例: Exim
exim -bp

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

كيفيّة النظر في Gmail و Outlook

في Gmail عبر «إظهار مصدر الرسالة»، وفي Outlook من Microsoft عبر «تفاصيل الرسالة» أو «ترويسات الإنترنت»، يمكن التحقّق من الـ headers الخامّة. في تحقيق عدم وصول نموذج التواصل يكون حفظ نص الـ headers كاملاً والمقارنة أجدى من لقطة الشاشة.

تمييز أخطاء جانب الاستقبال

أخطاء سلسلة Gmail يسهل قراءة سببها من الرمز.

حتّى في الأسئلة الشائعة لدى Google مذكورة هذه الأخطاء واتّجاه المعالجة. الأكثر شيوعاً في نموذج التواصل هو عدم اتّساق الـ alignment برمز 4.7.32.

المعيار الأخير للحكم

إن تحقّقت الشروط الثلاثة التالية معاً، يمكن القول إنّ تصميم إشعار نموذج التواصل متين.

1. From: تحت example.com
2. Reply-To: عنوان مستخدم النموذج
3. يظهر dmarc=pass في Authentication-Results

إن اكتملت هذه الثلاث، فالتصميم سليم أياً كان المسار: SendGrid أو SES أو Mailgun أو استضافة مشتركة أو مكتبة SMTP. وعلى العكس، إن نقص واحد منها فـ الأقصر أن تبدأ بالشكّ في تصميم From:.

روابط مرجعيّة

مواصفات ومصادر أوّليّة لكلّ خدمة. القيمة الفعليّة التي تُدخَل في DNS يجب أن تأخذ دائماً أولويّة القيمة التي يعرضها الخدمة المستخدمة.

المواصفات (RFC)

• RFC 5321 - Simple Mail Transfer Protocol ─ معاملة الـ envelope و MAIL FROM و Return-Path
• RFC 5322 - Internet Message Format ─ دلالات From: و Sender: و Reply-To:
• RFC 7208 - Sender Policy Framework (SPF) ─ مواصفة SPF بما فيها حدّ عدد استعلامات DNS
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures ─ الـ selector و d= وأهداف التوقيع
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ─ الـ alignment و p= ووجهات التقارير الخارجيّة
• RFC 3464 - An Extensible Message Format for Delivery Status Notifications ─ كيفيّة قراءة الارتداد (DSN)

إرشادات جهة الاستقبال

• Email sender guidelines - Gmail Help ─ متطلّبات SPF / DKIM / DMARC و PTR وتطابق From:
• Gmail SMTP errors and codes - Google Workspace Admin Help ─ معنى 5.7.x / 4.7.x والمعالجة

خدمات الإرسال والتنفيذ

• How to Set Up Domain Authentication - SendGrid ─ أسلوب CNAME و Custom Return Path
• Configuring a custom MAIL FROM domain - Amazon SES ─ متطلّبات MX و SPF
• Easy DKIM in Amazon SES ─ الـ CNAME الثلاثة
• Domains - Mailgun Documentation ─ السجلّات اللازمة للتحقّق من نطاق الإرسال
• PHP: mail - Manual ─ معاملة الـ headers و additional_params (-f)
• swaks - Swiss Army Knife for SMTP ─ اختبار الإرسال الفعليّ

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما أكثر سبب شائع لعدم وصول رسائل نموذج التواصل؟

ليس اتّصال SMTP نفسه، بل عدم تطابق المرسل الظاهر (`From:`) مع المرسل الذي يُصادَق فعليّاً (`MAIL FROM` في SPF و `d=` في DKIM). الأكثر شيوعاً تصميم يضع عنوان Gmail لمستخدم النموذج في `From:` كما هو. عند الإرسال من SMTP الموقع مع `From: taro@gmail.com` يُصادَق نطاق الموقع بينما `From:` على Gmail، فيفشل alignment في DMARC.

كيف ينبغي ضبط From في رسائل إشعار نموذج التواصل؟

الأساس تثبيت `From:` على نطاق الموقع، ووضع عنوان مستخدم النموذج في `Reply-To:`. بهذا تبقى سهولة الردّ، ويتوحّد المرسل الظاهر والمرسل المُصادَق على النطاق نفسه، فيستقرّ معدّل الوصول. يُستخدَم `Sender:` فقط حين يختلف المؤلّف عن جهة الإرسال الفعليّة، أمّا `Return-Path` فلا يُكتَب يدوياً في الـ header، بل يُضبَط من جانب الـ MTA أو خدمة البريد بوصفه envelope sender.

ما أوّل خطوة في التحقيق في عدم وصول البريد؟

النظر إلى الـ headers الخامّة للرسالة الواردة قبل النظر إلى الكود. في Gmail عبر «إظهار مصدر الرسالة»، راجع `Authentication-Results` و `Return-Path` و `From` و `DKIM-Signature`. الأولويّة لنطاق `From:` ونطاق `Return-Path:` وهل `spf` / `dkim` / `dmarc` تساوي `pass`. عند `dmarc=fail` ميّز بين فشل المصادقة و alignment failure. على جانب DNS استعلم عن سجلّات SPF و DKIM و DMARC الثلاثة بـ `dig` أو `nslookup`.

هل يجوز ضبط DMARC على reject من البداية؟

أسلم من الانتقال فوراً إلى reject أن تبدأ بوضع المراقبة `p=none` لرصد الحجم ومصادر الإرسال المشروعة، ثمّ ترفع تدريجيّاً إلى quarantine ثمّ reject. `p=none` مراقبة فقط، و quarantine توصية بالعزل، و reject توصية بالرفض أثناء SMTP. كذلك يكسر التحويل SPF بسهولة، وقد ينكسر DKIM أيضاً إن عُدِّل الجسم أو الـ headers في الوسيط، لذلك من المهمّ عدم الاعتماد على SPF وحده وتفعيل DKIM دائماً.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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