مُدقق توصيل البريد الإلكتروني
مرشد
مُدقق توصيل البريد الإلكتروني
يُمكنك مراجعة إعدادات التحقق من بريد إلكتروني لمجال خلال ثوانٍ. أدخل أي مجال، وستقوم الأداة بإجراء استعلامات DNS حية على مُحلل Cloudflare لفحص سجلات SPF، DMARC، MX، وBIMI، ثم تُعرض المشكلات الحقيقية في التكوين مع تقييم واضح يُحدد النجاح أو الفشل، مع درجة توصيل مُجمعة.
كيفية استخدام
- أدخل المجال الذي ترغب في التحقق منه (مثلاً
example.com) في الحقل المخصص. - انقر أكمل. تُجرى الأداة أربع استعلامات DNS عبر HTTPS بشكل متوازي.
- راجع درجة التوصيل في الأعلى، ثم قراءة التفاصيل لكل سجل (SPF، DMARC، MX، وBIMI).
- أعد إصلاح أي مشكلات مُحددة — مثل وجود أكثر من سجل SPF، عدد كبير من الاستعلامات DNS،
p=noneDMARC، أو عنوان تقارير مفقود، أو عدم وجود خادم MX — ثم أعد تشغيل التحقق.
خصائص
- فحص سجل SPF – يتحقق من
v=spf1السَّيْر، ويُعدّ الميكانيزمات المُستخدمة في الاستعلام DNS وفقًا للحد الأقصى المحدد في RFC 7208 وهو 10، ويُحدد+all,?all، والميكانيزم المُستَهَلِل، ويُحذر عند وجود أكثر من سجل SPF مُعلن.ptrفحص سجل DMARC - – يحلل كل علامة، ويُحقق من قوة السياسة ( )، ويُعرض
none,quarantine,rejectعناوين التقارير، ويُحذر عند أنruaوrufأقل من 100.pctسجلات MX - – تُعرض كل خادم بريد مع أولوية، مُرتّب تصاعديًا لكي ترى الوجهة الأساسية بسرعة. فحص المكافأة BIMI
- – يقرأ ، ويتحقق من
default._bimi.<domain>عنوان رمز SVG، ويُلاحظ ما إذا كان شهادة العلامة المُعتمدة (l=) مُحددة.a=درجة التوصيل - – درجة مُوزعة بشكل مُوزع على SPF، DMARC، وMX، بحيث تعرف بسرعة ما إذا كان المجال جاهزًا للنشر أم لا يحتاج إلى تحسين. – تُجرى الاستعلامات من خلال المتصفح مباشرة على نقطة نهاية DNS عبر HTTPS من Cloudflare. لا يُلامس أي مجال مُختبر بجهازنا.
- مُريح من حيث الخصوصية ما الفرق بين SPF، DKIM، وDMARC؟
1.1.1.1SPF هو سجل DNS يُحدد أي خوادم البريد المسموح لها بإرسال بريد مُرسل باسم المجال. يُستخدم DKIM لتوقيع كل رسالة مُستقبلة بمفتاح تشفير بحيث يمكن للمستقبل التحقق من أنها لم تُعدل أثناء النقل. يُربط DMARC بين الاثنين: يُخبر المستقبل ما يجب فعله عند فشل التوافق مع SPF أو DKIM، ويُحدد مكان إرسال التقارير المجمعة. يجب أن تكون الثلاثة مُتوفرة لضمان توصيل قوي.
التعليمات
-
لماذا يُحدد سجل SPF حدًا لـ 10 استعلام DNS؟
يُحدّر RFC 7208 عدد الاستعلامات الممكنة في تحقق SPF إلى 10 لمنع تضخُّم الطلب وضمان تنبؤية معالجة البريد. كل ميكانيزم مثل include، a، mx، ptr، exists، وredirect يستهلك استعلامًا واحدًا. تجاوز الحد يؤدي إلى خطأ دائم (PermError)، والذي يُعامل عادةً كفشل مُباشر في SPF — يُرسل بريدك إلى مجلد البريد العشوائي أو يُرفض بشكل كامل.
-
ما معنى سياسة DMARC p=none؟
p=none هي سياسة مراقبة فقط. سيقوم المُستقبلون بفحص التوافق ويرسلون تقارير مجمعة (من خلال عنوان rua=)، لكنهم لن يُعزلوا أو يرفضوا البريد الذي يفشل. تُستخدم أثناء جمع البيانات وإصلاح المصادر المُوثوقة، لكن المجال المُثبت على p=none لا يُوفر أي حماية ضد التزوير. الهدف هو الانتقال إلى p=quarantine ثم إلى p=reject.
-
هل أحتاج إلى سجل MX حتى لو كنت أرسل البريد فقط ولا أستقبله؟
من الناحية التقنية لا — لأن سجلات MX تصف كيفية معالجة البريد المُستقبل. لكن كثير من المُستقبلين يُعتبرون غياب سجل MX علامة ضعيفة على مُرسل بريد، ولا يمكن إرسال إشعارات الـ bounce إلى مجال لا يحتوي على سجل MX. يُنشر معظم المُشغلين سجلًا فارغًا (Null MX) (RFC 7505: سجل MX واحد بـ '0 .') إذا لم يقبلوا البريد المُستقبل، لضمان وضوح الهدف.
-
أجرِ تحققًا لتوصيل البريد
مُدقق توصيل البريد 1
تثبيت ملحقاتنا
أضف أدوات IO إلى متصفحك المفضل للوصول الفوري والبحث بشكل أسرع
恵 وصلت لوحة النتائج!
لوحة النتائج هي طريقة ممتعة لتتبع ألعابك، يتم تخزين جميع البيانات في متصفحك. المزيد من الميزات قريبا!
