تخبرك سجلات SPF وDKIM وDMARC في جوهرها ما إذا كان خادم بريدك الإلكتروني يمتلك تصريحاً شرعياً للتحدث باسم نطاقك، وما إذا كانت الرسائل التي تخرج منه محمية من التلاعب أثناء النقل. نحن في Hostna ندرك أن إعداد هذه السجلات بشكل صحيح هو الفارق الجوهري بين وصول رسالتك إلى صندوق الوارد أو ضياعها في مجلد البريد المهمل. تعمل هذه البروتوكولات الثلاثة كنظام متكامل للتحقق من الهوية، حيث يكمل كل منها الآخر لسد الثغرات التي قد يستغلها منتحلو الشخصية.
عندما ترسل بريداً إلكترونياً من خادمك، يقوم الخادم المستلم بفحص سجلات DNS الخاصة بنطاقك. إذا وجد أن سجل SPF لا يتضمن عنوان IP الخاص بالخادم المرسل، أو أن توقيع DKIM غير متطابق، فإن سياسة DMARC هي التي تقرر مصير هذه الرسالة. هذا النظام ليس مجرد إجراء تقني، بل هو حجر الزاوية في بناء سمعة خادم البريد الخاص بك لدى مزودي الخدمة العالميين.
| السجل | ماذا يخبر الخادم المستلم؟ | التأثير التقني عند الفشل |
|---|---|---|
SPF |
قائمة بعناوين IP المسموح لها بالإرسال. |
فشل SoftFail أو HardFail حسب الإعداد. |
DKIM |
أن محتوى الرسالة لم يتغير منذ خروجها. | فشل التحقق من التوقيع الرقمي Signature Invalid. |
DMARC |
كيفية التعامل مع الرسائل التي تفشل في الاختبارين أعلاه. | تنفيذ إجراء reject أو quarantine. |
سجل SPF: قائمة المسموح لهم بالدخول
سجل SPF (Sender Policy Framework) هو سجل TXT في نظام DNS يحدد الخوادم المسموح لها بإرسال رسائل بريد إلكتروني نيابة عن نطاقك. عندما تصل رسالة إلى وجهتها، ينظر الخادم المستلم إلى عنوان IP الذي جاءت منه الرسالة ويقارنه بالعناوين الموجودة في سجل SPF. إذا لم يكن العنوان موجوداً، يتم اعتبار الرسالة مشبوهة.
من الأمور التقنية الحرجة التي يجب مراقبتها هي DNS Lookup Limit. يضع بروتوكول SPF حداً أقصى يبلغ 10 عمليات بحث DNS لكل سجل. إذا قمت بإضافة العديد من آليات include:، فقد يتجاوز السجل هذا الحد، مما يؤدي إلى خطأ من نوع PermError، وهو ما يعني تجاهل السجل بالكامل. يمكنك التحقق من سجل SPF الخاص بك باستخدام الأمر التالي في واجهة السطر البرمجي:
dig TXT example.com +shortيجب أن يظهر السجل بصيغة تبدأ بـ v=spf1 وتنتهي بـ ~all (فشل مرن) أو -all (فشل صارم). في خوادمنا في ألمانيا التي تعمل بلوحة تحكم Plesk، يتم ضبط هذه السجلات تلقائياً لتشمل عنوان IP الخاص بالخادم، ولكن عند استخدام خدمات خارجية للإرسال، يجب دمجها بحذر لتجنب تجاوز حد العشر عمليات بحث.
سجل DKIM: الختم الرقمي المشفر
بينما يركز SPF على “من” يرسل، يركز DKIM (DomainKeys Identified Mail) على “سلامة” ما يتم إرساله. يقوم الخادم المرسل بإنشاء توقيع رقمي فريد لكل رسالة باستخدام مفتاح خاص Private Key. يتم وضع هذا التوقيع في ترويسة البريد الإلكتروني (Header). في المقابل، تقوم أنت بنشر المفتاح العام Public Key في سجلات DNS الخاصة بنطاقك.
عندما يستلم الطرف الآخر الرسالة، يستخدم المفتاح العام لفك تشفير التوقيع. إذا تطابقت النتيجة مع محتوى الرسالة، فهذا يؤكد أن الرسالة لم يتم تعديلها أثناء عبورها للإنترنت. تعتمد قوة هذا التشفير على طول المفتاح، حيث نستخدم في Hostna مفاتيح بطول 2048 بت لتوفير مستوى عالٍ من الأمان. للتحقق من وجود سجل DKIM لنطاقك، يمكنك استخدام أمر dig مع تحديد الـ selector (الذي غالباً ما يكون default في Plesk):
dig TXT default._domainkey.example.com +shortيعد نظام أسماء النطاقات هو الوعاء الذي يحمل هذه المفاتيح، وأي تأخير في تحديث TTL (Time To Live) قد يؤدي إلى استمرار فشل التحقق لفترة بعد تغيير الإعدادات.
سجل DMARC: صانع القرار النهائي
سجل DMARC (Domain-based Message Authentication, Reporting, and Conformance) هو الطبقة الإدارية التي تجمع بين SPF وDKIM. هو الذي يخبر الخوادم المستلمة: “إذا فشلت الرسالة في اختبار SPF أو DKIM، فافعل بها كذا”. بدون DMARC، قد يقرر الخادم المستلم من تلقاء نفسه ما إذا كان سيقبل الرسالة أم لا، وهو ما يؤدي إلى نتائج غير متوقعة.
يتكون سجل DMARC من وسوم (Tags) برمجية، أهمها وسم السياسة p=. هناك ثلاث قيم ممكنة لهذا الوسم:
p=none: المراقبة فقط، لا يتم اتخاذ إجراء ضد الرسائل الفاشلة.p=quarantine: وضع الرسائل الفاشلة في مجلد البريد غير المرغوب فيه.p=reject: رفض الرسالة تماماً وعدم استلامها.
الانتقال إلى سياسة p=reject يتطلب الحذر الشديد. نوصي دائماً بالبدء بسياسة p=none مع تفعيل تقارير RUA عبر الوسم rua=mailto:admin@example.com. هذه التقارير تصلك كملفات XML دورية توضح لك عناوين IP التي تحاول الإرسال باسم نطاقك، مما يساعدك في اكتشاف أي خوادم شرعية نسيت إضافتها إلى سجل SPF. يمكنك الاطلاع على التفاصيل التقنية الكاملة لهذا البروتوكول في وثيقة RFC 7489 الرسمية.
تحديات الإرسال من الخليج إلى العالم
بالنسبة لأصحاب الأعمال في السعودية والإمارات وبقية دول الخليج، فإن استخدام الاستضافة في ألمانيا يوفر استقراراً تقنياً كبيراً، ولكن يجب الانتباه إلى أن زمن الاستجابة (Latency) بين الخليج وألمانيا (الذي يقدر بحوالي 100-130 ملي ثانية) لا يؤثر على تسليم البريد، بل ما يؤثر هو سمعة عنوان IP. لذا، فإن ضبط سجل rDNS (Reverse DNS) ليتطابق مع اسم مضيف خادم البريد (Hostname) هو خطوة مكملة لسجلات SPF وDKIM.
إذا كنت تدير خادم افتراضي خاص، تأكد من أن سجل PTR الخاص بك يشير إلى نطاقك. بدون هذا التطابق، قد ترفض خوادم الاستقبال الكبرى رسائلك حتى لو كانت سجلات DMARC صحيحة. كما يجب مراعاة قوانين حماية البيانات المحلية مثل PDPL عند التعامل مع بيانات البريد الإلكتروني، حيث أن توفر اتفاقية معالجة البيانات (DPA) يساعدك في الامتثال لهذه المتطلبات عند تخزين البيانات في خوادمنا الألمانية.
خطوات التحقق والمعالجة
إذا واجهت مشكلة في وصول البريد، ابدأ دائماً بفحص الترويسات (Headers) للرسالة المستلمة. ابحث عن حقل Authentication-Results. سيخبرك هذا الحقل بوضوح بنتيجة فحص كل سجل:
spf=passتعني أن عنوان الخادم معتمد.dkim=passتعني أن التوقيع صحيح.dmarc=passتعني أن السياسة تم تطبيقها بنجاح.
عند استخدام سيرفر ويندوز لإرسال رسائل عبر برمجيات خاصة، تأكد من أن تطبيقك يدعم التوقيع الرقمي DKIM برمجياً أو أنك تستخدم SMTP Relay يقوم بهذه المهمة نيابة عنك. توفر لوحة التحكم واجهة سهلة لتوليد هذه المفاتيح بنقرة واحدة، مما يقلل من احتمالية الخطأ اليدوي في كتابة السجلات الطويلة داخل إعدادات النطاق الخاص بك.
في حال استمرار المشاكل، يرجى التواصل مع فريق الدعم الفني لدينا باللغة الإنجليزية، مع تزويدنا بالرسالة الخطأ كاملة (Bounce message) ونتائج أمر dig للسجلات التي قمت بضبطها، لنتمكن من مراجعة الإعدادات على مستوى خادم الأسماء والتأكد من مطابقتها للمعايير العالمية.
كُتبت هذه المقالة بمساعدة الذكاء الاصطناعي ضمن خط البحث الخاص بـ Hostna ونُشرت دون مراجعة فردية. أخبرنا إن وجدت خطأ فيها.