كيف تتحقق من عناوين البريد الإلكتروني بالجملة: ماذا تثبت فحوص الصياغة وMX وSMTP فعلًا

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

طبقات التحقق الخمس

الطبقة	ما تفحصه	ما تثبته	ما لا تستطيع إثباته
1. الصياغة	الصيغة مقابل قواعد RFC 5321/5322	أن السلسلة قد تكون عنوان بريد	أن النطاق أو الصندوق موجود
2. النطاق / DNS	سجلّ MX (أو A بديلًا) للنطاق	أن النطاق يقبل البريد	أن هذا الصندوق موجود
3. إشارات المخاطر	نطاقات مؤقتة، حسابات أدوار، أخطاء إملائية	احتمال انخفاض القيمة أو الشكاوى	أي شيء عن شخص بعينه
4. فحص SMTP	مصافحة RCPT TO دون إرسال	تلميح بأن الخادم يقبل المستلِم	حالة موثوقة (catch-all والقائمة الرمادية والحجب)
5. التأكيد	المالك ينقر رابطًا أرسلته إليه	أن الصندوق موجود وأن المالك موافق	لا شيء مما لا يستطيع: هذا هو المعيار الذهبي

الطبقة 1: التحقق من الصياغة

تحدّد قواعد الصياغة RFC 5321 وRFC 5322. عمليًا تفحص: @ واحدة بالضبط، وجزءًا محليًا حتى 64 حرفًا، ونطاقًا بتسميات صالحة (حتى 63 حرفًا لكل منها) ونطاقًا علويًا حقيقيًا، بلا مسافات ولا أحرف غير مسموحة، وحدًّا أقصى للمسار 256 حرفًا (أي عنوانًا بنحو 254 حرفًا). احذر أن تكون أشدّ من المعيار: العناوين التي تحوي + (name+tag@example.com) والنطاقات المدوَّلة صالحة. مجموعة قواعد بسيطة وآمنة:

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$        # intentionally permissive: one @, a dot in the domain, a TLD of 2+ chars
# then: length(local) <= 64, length(domain) <= 255, no label > 63 chars, TLD not all digits

النمط المتساهل مقصود: التعبير النمطي الصارم يرفض عملاء حقيقيين، وفحص DNS في الطبقة التالية يقوم بالتصفية الحقيقية. يسرد دليل صياغة عنوان البريد لدينا ما هو مسموح بالضبط.

الطبقة 2: فحوص DNS وMX

يخبرك استعلام DNS هل يستطيع النطاق استقبال البريد. القاعدة: إن كان للنطاق سجلّ MX ذهب البريد إليه؛ وإن لم يكن له فيعود SMTP إلى سجلّ A/AAAA للنطاق («MX الضمني»)؛ أما «null MX» (هدف واحد هو .، RFC 7505) فيعلن صراحةً أن النطاق لا يقبل بريدًا. يلتقط هذا الأخطاء الإملائية مثل gmial.com التي لا خوادم بريد لها والنطاقات المنتهية. فحص برمجي بسيط:

// Node.js
const dns = require('dns').promises;
async function canReceiveMail(domain) {
  try {
    const mx = await dns.resolveMx(domain);
    if (mx.length === 1 && mx[0].exchange === '') return false;   // null MX
    return mx.length > 0;
  } catch (e) {
    if (e.code === 'ENODATA' || e.code === 'ENOTFOUND') {
      try { return (await dns.resolve4(domain)).length > 0; } catch { return false; }  // implicit MX
    }
    throw e;                                                       // SERVFAIL/timeouts = unknown, not invalid
  }
}

لاحظ السطر الأخير: فشل DNS يعني «مجهول» لا «غير صالح»؛ ومعاملة انتهاء المهلة كعنوان غير صالح من أشيع طرق حذف مشتركين جيدين.

✉️مدقق البريد الإلكترونيالصيغة وMX والبريد المؤقت والأخطاء الإملائية، فردي أو جماعيافتح الأداة →

الطبقة 3: كشف المؤقت والأدوار والأخطاء الإملائية

• العناوين المؤقتة (خدمات صناديق مؤقتة) تعمل لفترة قصيرة ونادرًا ما تُقرأ؛ استبعادها يحسّن جودة القائمة. يعتمد كشفها على قائمة نطاقات تتقادم، فعامله كإشارة لا كحكم.
• حسابات الأدوار (info@ وsales@ وadmin@) صناديق مشتركة بمعدّلات شكاوى أعلى وتفاعل أقل.
• الأخطاء الإملائية في النطاقات الشائعة يمكن تصحيحها أو اقتراح تصحيحها، لكن لا تصحّح تلقائيًا دون تأكيد: بعض النطاقات المشابهة حقيقية.

الطبقة 4: التحقق عبر SMTP ومشكلاته

يتصل التحقق عبر SMTP بخادم البريد ويصدر RCPT TO:<address> ليرى هل يقبله الخادم، ثم يقطع الاتصال دون إرسال رسالة. يبدو مثاليًا لكنه هشّ:

جواب الخادم	المعنى المعتاد	الموثوقية
250 مقبول	قد يكون الصندوق موجودًا، أو الخادم catch-all	منخفضة: نطاقات catch-all تقبل كل شيء
550 5.1.1 المستخدم غير معروف	الصندوق غير موجود	عالية حين يأتي من خادم البريد الحقيقي
450/451 مؤقت	قائمة رمادية أو تحديد معدّل	مجهول: أعد المحاولة لاحقًا
اتصال مرفوض/محجوب	الفحص محجوب من عنوانك	مجهول

• خوادم catch-all تقبل كل مستلِم، فـ «مقبول» لا يثبت شيئًا.
• المزوّدون الكبار يحجبون الفحص أو يعيدون أجوبة متطابقة لكل العناوين لمنع الحصاد.
• خطر السمعة: تكرار الفحوص من عنوان IP واحد يشبه هجوم حصاد الدليل وقد يدرج عنوانك في قوائم الحظر.
• الخصوصية والقانونية: فحص عناوين أشخاص لم يعطوك عناوينهم قد يتعارض مع قواعد حماية البيانات.

لهذه الأسباب لا تجري أدوات المتصفح فحص SMTP، وعليك أن تعامل «صالح» من أي فاحص SMTP كاحتمال لا كحقيقة.

الطبقة 5: التأكيد هو الإثبات الحقيقي الوحيد

إن كان يجب أن ينتمي الصندوق فعلًا إلى الشخص فأرسل بريد تأكيد برابط فريد (double opt-in). تثبت النقرة الوجود والملكية والموافقة في خطوة واحدة، وتحميك من فخاخ السبام ومن أخطاء الكتابة التي يرتكبها المستخدمون الحقيقيون.

سير عمل عملي للقوائم الكبيرة

1. طبّع: قصّ المسافات، وحوّل النطاق إلى أحرف صغيرة، وأزل المكرَّر (احذر من نقاط Gmail والعناوين ذات علامة +؛ لا تدمج إلا إن كنت متأكدًا).
2. فحص الصياغة: أسقط المدخلات المشوّهة واحتفظ بتقرير الأسباب.
3. فحص DNS: أزل النطاقات التي لا MX ولا A لها؛ واحتفظ بإخفاقات DNS كـ «مجهول» وأعد المحاولة.
4. وسم المخاطر: افصل العناوين المؤقتة وعناوين الأدوار وقرّر لكل حملة.
5. أرسل على مراحل: ابدأ بأكثر شرائحك تفاعلًا، وراقب الارتدادات، ثم وسّع.
6. أوقف الارتدادات الدائمة نهائيًا بعد أول إرسال.

🧹منظّف قوائم البريدإزالة المكرر والخاطئ وتصحيح النطاقات وتقسيم القائمة حسب المزوّدافتح الأداة →

حالات خاصة تُربك أدوات التحقق

الحالة	مثال	المعالجة الصحيحة
علامات +	ana+shop@example.com	صالح. احتفظ به كما كُتب؛ وسلّم إلى العنوان كاملًا
النقاط في Gmail	a.na@gmail.com مقابل ana@gmail.com	يعاملهما Gmail كصندوق واحد، لكن غيره لا يفعل: طبّع فقط حين تعرف المزوّد
جزء محلي بين علامتي اقتباس	"ana smith"@example.com	قانوني لكنه نادر؛ اقبل أو ارفض بسياسة لا بالمصادفة
نطاقات مدوَّلة	user@bücher.example	حوّل النطاق إلى Punycode (xn--bcher-kva.example) لفحص DNS
جزء محلي بيونيكود (SMTPUTF8، RFC 6531)	用户@example.cn	صالح فقط إن دعمه النظام المستقبِل؛ علّمه «محفوفًا بالمخاطر» لا «غير صالح»
حالة الأحرف	Ana@Example.COM	النطاق غير حسّاس للحالة؛ احتفظ بالجزء المحلي كما هو، وقارن دون حساسية لتحديد التكرار فقط إن كان مزوّدك كذلك
نقطة أو مسافات في النهاية	ana@example.com.	قصّ المسافات؛ وأزل النقطة الأخيرة في النطاق بعد الإبلاغ عنها

كيف تختبر أداة تحقق قبل أن تثق بها

سواء بنيتها بنفسك أو استخدمت خدمة، اختبرها بمجموعة صغيرة تعرف أجوبتها. ضمّ 20 عنوانًا يجب أن تنجح (بعلامات + ونطاقات علوية طويلة ونطاقات فرعية ونطاقات يونيكود)، و20 يجب أن تفشل (بلا @، ونقطتان متتاليتان، ومسافات، وجزء محلي من 65 حرفًا)، و10 نطاقات موجودة لكن بلا بريد (null MX أو لا MX/A)، و10 صناديق حقيقية تملكها لدى مزوّدين مختلفين. احسب الرفض الخاطئ منفصلًا عن القبول الخاطئ: الأول يكلّفك عملاء، والثاني يكلّفك ارتدادات. أداة تحقق ترفض أي عنوان من العناوين التي يجب أن تنجح أشدّ من أن تُشغَّل عند التسجيل، مهما كانت أرقامها الأخرى جيدة.

كيف تقرأ تقرير التحقق

الحالة	المعنى	الإجراء
صالح	الصياغة والنطاق ناجحان	أرسل؛ وهذا لا يضمن وجود الصندوق
محفوف بالمخاطر	مؤقت أو دور أو اقتراح تصحيح	قسّم؛ أكّد أو استبعد بحسب الهدف
غير صالح	مشوّه أو النطاق لا يستقبل بريدًا	أزله
مجهول	فشل DNS أو شبكة	أعد المحاولة لاحقًا؛ لا تحذف

بعد أول إرسال تصحّح بيانات الارتداد الصورة: كل ما ارتدّ ارتدادًا دائمًا ينتقل إلى قائمة الإيقاف، ويخبرك المعدّل هل كان التنظيف كافيًا. أبقِ الارتدادات دون نحو 2% والشكاوى دون 0.1%، وهي الأرقام التي تجعلك متطلبات Gmail وYahoo تهتم بها.

الخصوصية والموافقة أثناء التحقق

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

أخطاء شائعة

• استخدام تعبير نمطي من الإنترنت يرفض + أو النطاقات العلوية الجديدة.
• معاملة «صيغة صالحة» على أنها «قابل للتسليم».
• شراء قوائم «متحقَّق منها»: التحقق لا يصنع موافقة.
• التحقق مرة واحدة ثم عدم تكراره؛ فالعناوين تتقادم مع الوقت.
• رفض تسجيل بسبب عنوان غير مألوف لكنه قانوني، وخسارة عملاء حقيقيين.

أسئلة شائعة

هل يمكنني التحقق من وجود عنوان بريد دون إرسال رسالة؟

ليس بموثوقية. قد يلمّح فحص SMTP إلى ذلك، لكن خوادم catch-all والقائمة الرمادية والحجب تجعل النتائج غير يقينية. الطريقة اليقينية الوحيدة رسالة تأكيد.

ما هو عنوان البريد catch-all؟

نطاق catch-all يقبل البريد لأي جزء محلي، فتبدو فحوص SMTP دائمًا صالحة. لا يمكنك معرفة هل صندوق معيّن موجود حتى ترسل.

هل أحجب عناوين البريد المؤقتة؟

يعتمد على الهدف. للنشرات وإنشاء الحسابات قيمتها منخفضة عادة فيستبعدها كثير من المرسِلين. أما لتنزيل مرة واحدة فقد تسمح بها.

هل فحص سجلّ MX كافٍ؟

يثبت أن النطاق يستقبل البريد، فيلتقط الأخطاء الإملائية والنطاقات الميتة، لكنه لا يثبت وجود الصندوق.

كم مرة أنظّف قائمتي؟

تحقّق عند الجمع، ثم نظّف بالجملة قبل الحملات الكبيرة ومرات قليلة سنويًا على الأقل، وأزل الارتدادات الدائمة بعد كل إرسال.

المراجع ومزيد من القراءة

1. RFC 5321 — Simple Mail Transfer Protocol
2. RFC 5322 — Internet Message Format
3. RFC 7505 — A "Null MX" No Service Resource Record
4. Google — Email sender guidelines