تقني
إعداد DNS هو الأساس الخفي لقابلية تسليم البريد الإلكتروني البارد. ففي حين يركّز معظم ممارسي البريد الإلكتروني البارد على سطور الموضوع والنصوص وجداول الإرسال، فإن البنية التحتية التقنية الكامنة تحتها هي التي تحدّد ما إذا كانت رسائلك ستصل إلى صندوق الوارد أصلًا. سجلات DNS المُعدّة بشكل خاطئ مسؤولة عن حالات فشل التسليم أكثر من أي عامل منفرد آخر، ومع ذلك تظل مفهومة بشكل سيّئ لدى غالبية مرسِلي البريد الإلكتروني البارد.
يقدّم هذا الدليل التقني تعمّقًا شاملًا في إعداد DNS للبريد الإلكتروني البارد. سنفحص كل نوع من أنواع السجلات بالتفصيل، ونستكشف بروتوكولات المصادقة التي تحمي سمعة إرسالك، ونعالج مشكلات الانتشار الشائعة، ونعرض طرق التحقق التي تضمن أن بنيتك التحتية جاهزة للإنتاج. سواء كنت تُعدّ أول نطاق للبريد الإلكتروني البارد أو تدير مئات النطاقات على نطاق واسع، فسيمنحك هذا الدليل المعرفة التقنية لتحقيق وصول ثابت إلى صندوق الوارد.
فهم أنواع سجلات DNS الخاصة بالبريد الإلكتروني
يعمل نظام أسماء النطاقات (DNS) بمثابة دفتر عناوين الإنترنت، إذ يترجم أسماء النطاقات المقروءة للبشر إلى عناوين IP المقروءة للآلات. وبالنسبة للبريد الإلكتروني، يؤدي DNS غرضًا إضافيًا بالغ الأهمية: فهو يخبر خوادم البريد المستقبِلة بالخوادم المصرّح لها بإرسال البريد نيابةً عن نطاقك وكيفية مصادقة تلك الرسائل. إن فهم أنواع السجلات الأربعة الأساسية الضرورية للبريد الإلكتروني البارد هو الخطوة الأولى نحو الإعداد الصحيح.
سجلات MX (متبادِل البريد)
تحدّد سجلات MX خوادم البريد المسؤولة عن استقبال البريد الخاص بنطاقك. وعلى الرغم من استخدامها بشكل أساسي للبريد الوارد، فإن سجلات MX ضرورية لمصداقية البريد الإلكتروني البارد. تتحقق مرشّحات البريد المزعج بشكل روتيني مما إذا كان نطاق الإرسال يمتلك سجلات MX صالحة، لأن النطاقات التي تفتقر إليها لا تستطيع استقبال الردود وغالبًا ما ترتبط بعمليات البريد المزعج.
يتكوّن سجل MX من مكوّنين: قيمة الأولوية واسم مضيف خادم البريد. تشير أرقام الأولوية الأقل إلى تفضيل أعلى، مما يتيح لك إعداد خوادم بريد أساسية واحتياطية.
# MX Record Example example.com. IN MX 10 mail.example.com. example.com. IN MX 20 mail-backup.example.com. # Google Workspace MX Records example.com. IN MX 1 ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
سجلات SPF (إطار سياسة المرسِل)
تحدّد سجلات SPF عناوين IP وخوادم البريد المصرّح لها بإرسال البريد نيابةً عن نطاقك. عندما يتلقى خادم مستقبِل رسالة تدّعي أنها من نطاقك، فإنه يتحقق من سجل SPF الخاص بك للتأكد من شرعية خادم الإرسال. وهذا يمنع مرسِلي البريد المزعج من انتحال نطاقك في عنوان "From" الخاص بهم.
تُنشر سجلات SPF كسجلات TXT في DNS الخاص بك. وهي تستخدم صيغة محدّدة تتضمن آليات (مثل "ip4" و"include" و"a") ومؤهِّلات تحدّد كيفية التعامل مع المرسِلين المطابقين وغير المطابقين.
# Basic SPF Record Structure v=spf1 [mechanisms] [qualifier]all # SPF Record for Google Workspace v=spf1 include:_spf.google.com ~all # SPF Record with Multiple Sending Sources v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.1.1 ~all # SPF Qualifiers: # +all = Pass (allow all - not recommended) # -all = Hard Fail (reject unauthorized senders) # ~all = Soft Fail (accept but mark as suspicious) # ?all = Neutral (no policy)
سجلات DKIM (البريد المُعرَّف بمفاتيح النطاق)
يضيف DKIM توقيعًا تشفيريًا إلى رسائلك الصادرة، مما يثبت أن الرسالة أُرسلت فعليًا من نطاقك ولم تُعدَّل أثناء النقل. يوقّع خادم الإرسال الرسالة بمفتاح خاص، وتتحقق الخوادم المستقبِلة من التوقيع باستخدام مفتاح عام منشور في DNS الخاص بك.
تُنشر سجلات DKIM كسجلات TXT عند نطاق فرعي محدّد يتضمن محدِّدًا (معرِّفًا اعتباطيًا لزوج المفاتيح). يتيح لك نظام المحدِّد هذا تدوير المفاتيح دون تعطيل تسليم البريد، واستخدام مفاتيح مختلفة لخدمات إرسال مختلفة.
# DKIM Record Location [selector]._domainkey.example.com # Google Workspace DKIM Record Example google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." # DKIM Record Components: # v=DKIM1 - DKIM version # k=rsa - Key type (RSA is standard) # p=... - Public key (base64 encoded) # t=s - Optional: strict mode (subdomain signing) # t=y - Optional: testing mode
سجلات DMARC (مصادقة الرسائل المستندة إلى النطاق)
يبني DMARC على SPF وDKIM بإضافة طبقة سياسة تخبر الخوادم المستقبِلة بما يجب فعله عندما تفشل الرسائل في المصادقة. كما يوفّر آلية إبلاغ ترسل إليك بيانات عن الرسائل التي تدّعي أنها من نطاقك، سواء كانت شرعية أم احتيالية.
يُعدّ DMARC أساسيًا لأنه يقدّم مفهوم "المحاذاة"، بحيث يتطلب أن يطابق النطاق في ترويسة "From" المرئية النطاق المُصادَق عليه عبر SPF أو DKIM. وهذا يسدّ ثغرة كانت تتيح لمرسِلي البريد المزعج اجتياز SPF/DKIM مع الاستمرار في انتحال عنوان المرسِل المعروض.
# DMARC Record Location _dmarc.example.com # Basic DMARC Record (Monitoring Mode) v=DMARC1; p=none; rua=mailto:dmarc@example.com # Recommended DMARC Record for Cold Email v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com # Strict DMARC Record (Full Protection) v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com # DMARC Policy Options: # p=none - Monitor only (no action on failures) # p=quarantine - Send to spam folder # p=reject - Reject the email entirely # Additional Tags: # sp= - Subdomain policy # pct= - Percentage of messages to apply policy # adkim= - DKIM alignment mode (s=strict, r=relaxed) # aspf= - SPF alignment mode (s=strict, r=relaxed) # rua= - Aggregate report destination # ruf= - Forensic report destination
كيف تعمل سلسلة المصادقة
فهم كيفية عمل SPF وDKIM وDMARC معًا أمر بالغ الأهمية لتشخيص مشكلات قابلية التسليم. عندما ترسل رسالة بريد إلكتروني بارد، يجري الخادم المستقبِل سلسلة من الفحوص بترتيب محدّد، وتصبّ نتائج كل فحص في قرار المصادقة الإجمالي.
الخطوة 1: فحص SPF
يستخرج الخادم المستقبِل النطاق من عنوان MAIL FROM (مرسِل المغلّف) ويستعلم عن سجل SPF الخاص بذلك النطاق. ثم يتحقق مما إذا كان عنوان IP المتصل مصرَّحًا له بموجب سجل SPF. والنتيجة هي إحدى الحالات التالية: pass أو fail أو softfail أو neutral أو none أو temperror أو permerror.
الخطوة 2: فحص DKIM
يفحص الخادم المستقبِل ترويسة DKIM-Signature في الرسالة، ويستخرج المحدِّد ونطاق التوقيع، ويسترجع المفتاح العام المقابل من DNS، ويتحقق من التوقيع التشفيري. إذا طابق التوقيع محتوى الرسالة وترويساتها، فإن DKIM ينجح.
الخطوة 3: تقييم DMARC
يقيّم DMARC نتائج كل من SPF وDKIM، لكنه يضيف شرط المحاذاة. يجب أن يطابق النطاق في ترويسة "From" المرئية إما النطاق المُصادَق عليه عبر SPF أو النطاق الموقِّع عبر DKIM (اعتمادًا على إعدادات وضع المحاذاة). إذا نجح أحدهما على الأقل مع محاذاة صحيحة، فإن DMARC ينجح. ثم تحدّد سياسة DMARC ما يحدث للرسائل التي تفشل في هذا التقييم.
"حالات فشل المصادقة قاتلة صامتة في البريد الإلكتروني البارد. تختفي رسائلك في مجلدات البريد المزعج دون إشعار بالارتداد، ودون رسالة خطأ، ودون أي دليل على وجود خلل ما. وبحلول الوقت الذي تلاحظ فيه تراجع معدلات الردود، قد تكون أسابيع من التواصل قد ضاعت هباءً."
انتشار DNS: استكشاف الأخطاء وإصلاحها وأفضل الممارسات
انتشار DNS هو العملية التي تنتشر بها التغييرات على سجلات DNS عبر شبكة الإنترنت من المحلِّلات التكرارية. عندما تحدّث سجل DNS، فإنه لا يظهر في كل مكان على الفور. سترى خوادم مختلفة حول العالم السجلات القديمة والجديدة في أوقات مختلفة، مما قد يتسبب في حالات فشل مصادقة مؤقتة أثناء فترة الانتقال.
فهم TTL (مدة البقاء)
TTL هي القيمة (بالثواني) التي تخبر محلِّلات DNS بالمدة التي يجب أن تخزّن فيها السجل مؤقتًا قبل التحقق من التحديثات. تعني قيمة TTL البالغة 3600 أن المحلِّلات ستخزّن السجل مؤقتًا لمدة ساعة واحدة. تعني قيم TTL الأقل انتشارًا أسرع للتغييرات لكنها تؤدي إلى استعلامات DNS أكثر. أما قيم TTL الأعلى فتقلّل حركة مرور DNS لكنها تبطئ الانتشار.
بالنسبة لسجلات مصادقة البريد الإلكتروني، نوصي بقيم TTL التالية:
- سجلات MX: 3600 ثانية (ساعة واحدة) - مستقرة نسبيًا، نادرًا ما تتغير
- سجلات SPF: 300-600 ثانية (5-10 دقائق) - قد تحتاج إلى تحديث عند إضافة خدمات
- سجلات DKIM: 3600 ثانية (ساعة واحدة) - مستقرة بمجرد إعدادها
- سجلات DMARC: 3600 ثانية (ساعة واحدة) - تُضبط عادةً مرة واحدة وتُترك
مشكلات الانتشار الشائعة وحلولها
المشكلة 1: عدم ظهور التغييرات بعد الوقت المتوقع أولًا، تحقق من حفظ التغييرات بشكل صحيح لدى مزوّد DNS الخاص بك. ثم افحص باستخدام أدوات بحث DNS متعددة من مواقع جغرافية مختلفة. إذا كانت خوادم الأسماء المرجعية تُظهر السجلات الصحيحة لكن المحلِّلات الأخرى لا تُظهرها، فهذا تأخير انتشار طبيعي.
المشكلة 2: نتائج غير متسقة بين المحلِّلات أثناء الانتشار، ستمتلك المحلِّلات المختلفة إصدارات مخزّنة مؤقتًا مختلفة. وهذا سلوك متوقّع. تجنّب إرسال حملات مهمة مباشرة بعد تغييرات DNS. انتظر لمدة لا تقل عن ضعف قيمة TTL السابقة لضمان انتشار واسع.
المشكلة 3: حدود معدل واجهة برمجة تطبيقات مزوّد DNS عند إعداد عدة نطاقات برمجيًا، قد تصطدم بحدود معدل واجهة برمجة التطبيقات. باعِد بين طلباتك ونفّذ تراجعًا أسّيًا. يتعامل InboxOne مع هذا تلقائيًا عبر وضع الطلبات في طابور ذكي.
# Check DNS propagation from command line # Query MX records dig MX example.com +short nslookup -type=mx example.com # Query SPF record (TXT) dig TXT example.com +short nslookup -type=txt example.com # Query DKIM record dig TXT selector._domainkey.example.com +short # Query DMARC record dig TXT _dmarc.example.com +short # Query specific nameserver (bypass local cache) dig @8.8.8.8 TXT example.com +short # Check TTL remaining dig example.com +noall +answer
طرق التحقق: ضمان الإعداد الصحيح
قبل إرسال أي رسائل بريد إلكتروني بارد من نطاق مُعدّ حديثًا، يجب أن تتحقق من أن جميع سجلات المصادقة مُعدّة ومنتشرة بشكل صحيح. إن تخطّي هذه الخطوة من أكثر الأسباب شيوعًا لكوارث قابلية التسليم. فسجل واحد مُعدّ بشكل خاطئ يمكن أن يقوّض معدل وصول حملتك بأكملها إلى صندوق الوارد.
أدوات التحقق عبر الإنترنت
يمكن للعديد من الأدوات المجانية عبر الإنترنت أن تتحقق من إعداد DNS الخاص بك:
- MXToolbox: فاحص شامل لسلامة البريد الإلكتروني يختبر MX وSPF وDKIM وDMARC وحالة القوائم السوداء
- Google Admin Toolbox: أداة فحص MX وdig مصمّمة خصيصًا للتحقق من Google Workspace
- DMARC Analyzer: تحليل مفصّل لسجل DMARC ومعالجة التقارير المجمّعة
- Mail-Tester: أرسل رسالة اختبار واحصل على درجة قابلية تسليم مفصّلة مع توصيات محدّدة
تحليل ترويسة البريد الإلكتروني
أكثر طرق التحقق موثوقية هي إرسال رسالة اختبار وتحليل نتائج المصادقة في ترويسات الرسالة. يعرض Gmail، على سبيل المثال، نتائج المصادقة مباشرة في الرسالة عند النقر على "إظهار الأصل". ابحث عن هذه الترويسات:
# Email Authentication Headers to Check Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector header.b=abc123; spf=pass (google.com: domain of sender@example.com designates 192.168.1.1 as permitted sender) smtp.mailfrom=sender@example.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com # What to look for: # dkim=pass - DKIM signature verified successfully # spf=pass - Sending IP is authorized by SPF record # dmarc=pass - DMARC evaluation passed (SPF/DKIM aligned) # Common failure indicators: # dkim=fail (signature verification failed) # spf=softfail (IP not in SPF, but soft fail policy) # dmarc=fail (alignment failure or policy violation)
المراقبة الآلية
يصلح التحقق اليدوي للإعداد الأولي، لكن المراقبة المستمرة ضرورية للحفاظ على قابلية التسليم. يمكن أن تُحذف سجلات DNS عن طريق الخطأ، أو تنتهي صلاحيتها، أو تصبح غير صالحة بسبب تغييرات لدى المزوّد. تلتقط المراقبة الآلية هذه المشكلات قبل أن تؤثّر في حملاتك.
تشمل المقاييس الرئيسية التي يجب مراقبتها صلاحية سجل SPF وعدد عمليات البحث (بحد أقصى 10 عمليات بحث)، ووجود مفتاح DKIM وصلاحيته التشفيرية، واتساق سياسة DMARC وتسليم التقارير، وتوافر سجل MX وأوقات استجابته.
أخطاء إعداد DNS الشائعة الواجب تجنّبها
حتى مديرو الأنظمة ذوو الخبرة يرتكبون أخطاء في إعداد DNS. غالبًا ما تمرّ هذه الأخطاء دون ملاحظة لأسابيع أو أشهر لأن البريد الإلكتروني "يعمل نوعًا ما" - إذ تُسلَّم الرسائل لكن بمعدلات منخفضة. إليك أكثر الأخطاء شيوعًا وكيفية تجنّبها.
الخطأ 1: سجلات SPF متعددة
وجود أكثر من سجل SPF على نطاق واحد يتسبب في فشل فوري للمصادقة. تنصّ مواصفات SPF على أن النطاق يجب ألا يمتلك عدة سجلات SPF. إذا كنت بحاجة إلى تفويض مصادر إرسال إضافية، فأضِفها إلى سجل SPF الحالي باستخدام آلية "include".
الخطأ 2: تجاوز حدود عمليات بحث SPF
يمكن أن تتضمن سجلات SPF إشارات إلى سجلات أخرى (عبر "include" و"redirect" و"a" و"mx" وغيرها)، لكن العدد الإجمالي لعمليات بحث DNS أثناء تقييم SPF يجب ألا يتجاوز 10. تُحتسب كل آلية "include" كعملية بحث واحدة، وتُحتسب عمليات التضمين المتداخلة ضمن الإجمالي. تجاوز هذا الحد يتسبب في إرجاع SPF لخطأ دائم.
الخطأ 3: حجم مفتاح DKIM صغير جدًا
تُعدّ مفاتيح DKIM الأصغر من 1024 بت غير آمنة وقد تتسبب في فشل المصادقة مع بعض المستقبِلين. استخدم مفاتيح بحجم 2048 بت لتحقيق أمان وتوافق مثاليين. تواجه بعض مزوّدي DNS الأقدم مشكلات مع مفاتيح 2048 بت بسبب حدود طول سجل TXT؛ في تلك الحالات، يجب تقسيم المفتاح عبر عدة سلاسل نصية.
الخطأ 4: سياسة DMARC صارمة جدًا في البداية
البدء بسياسة DMARC من نوع "reject" قبل التحقق من تدفقات بريدك وصفة لكارثة. ابدأ بـ "none" لجمع التقارير وتحديد أي مصادر إرسال شرعية ربما نسيتها. انتقل إلى "quarantine" للاختبار، ثم إلى "reject" بمجرد أن تصبح واثقًا من أن جميع الرسائل الشرعية مُصادَق عليها بشكل صحيح.
الخطأ 5: نسيان سياسات النطاقات الفرعية
لا تنطبق سياسات SPF وDMARC على نطاقك الجذري تلقائيًا على النطاقات الفرعية. إذا كنت ترسل من نطاقات فرعية (مثل mail.example.com)، فإن كل نطاق فرعي يحتاج إلى سجل SPF خاص به. أما بالنسبة لـ DMARC، فيمكنك استخدام وسم "sp" لتعيين سياسة نطاق فرعي، أو إنشاء سجلات DMARC منفصلة لكل نطاق فرعي.
كيف يزيل InboxOne تعقيد إعداد DNS
في حين أن فهم إعداد DNS أمر قيّم، فإن الواقع هو أن الإدارة اليدوية لـ DNS لا تتوسّع. لا تستطيع الوكالات التي تدير عشرات أو مئات نطاقات البريد الإلكتروني البارد أن تتحمّل إعداد ومراقبة سجلات المصادقة يدويًا لكل منها. وهنا تصبح إدارة DNS الآلية من InboxOne ضرورية.
إعداد DNS التلقائي الكامل
عندما تشتري نطاقًا عبر InboxOne أو تربط نطاقًا موجودًا، يقوم نظامنا تلقائيًا بإعداد جميع سجلات DNS المطلوبة. تُنشأ سجلات SPF وDKIM وDMARC وMX بإعدادات مثالية خلال دقائق. ولا توجد أي تعديلات يدوية مطلوبة ولا تخمين بشأن توقيت الانتشار.
يدعم InboxOne كلًّا من Cloudflare وClouDNS لإدارة DNS. تضمن تكاملات واجهة برمجة التطبيقات لدينا مع هؤلاء المزوّدين إنشاء السجلات بشكل صحيح، وتحسين قيم TTL، والتعامل تلقائيًا مع أي خصوصيات تخصّ كل مزوّد.
المراقبة المستمرة والإصلاح التلقائي
يراقب InboxOne Protect سلامة DNS لنطاقك على مدار الساعة طوال أيام الأسبوع. إذا حُذف سجل عن طريق الخطأ، أو عُدّل بشكل غير صحيح، أو فشل في التحقق، فإن نظامنا يكتشف المشكلة خلال دقائق ويصلحها تلقائيًا. ستتلقى إشعارات بأي مشكلات، لكن في معظم الحالات، تُحلّ المشكلة قبل أن ترى التنبيه أصلًا.
إدارة النطاقات بالجملة
بالنسبة للوكالات العاملة على نطاق واسع، يوفّر InboxOne عمليات بالجملة تُعدّ DNS لعشرات النطاقات في آنٍ واحد. يتعامل نظام وضعنا في الطابور الذكي مع حدود معدل واجهة برمجة التطبيقات، ويتتبّع حالة الانتشار عبر جميع النطاقات، ويبلغ عندما يصبح كل نطاق جاهزًا للاستخدام. وهذا يحوّل ما قد يكون ساعات من العمل اليدوي إلى دقائق قليلة من الإشراف.
"كان إعداد DNS الجزء الأكثر إرهاقًا في إطلاق نطاقات بريد إلكتروني بارد جديدة. مع InboxOne، لا أفكّر فيه حرفيًا أبدًا. تصبح النطاقات جاهزة للإحماء خلال دقائق من الشراء، مع مصادقة مثالية في كل مرة."
- مالك وكالة بريد إلكتروني بارد
ملخص أفضل ممارسات إعداد DNS
سواء كنت تُعدّ DNS يدويًا أو باستخدام أدوات آلية، فإن اتّباع أفضل الممارسات التالية سيضمن قابلية تسليم مثالية لحملات بريدك الإلكتروني البارد.
- اضبط دائمًا أنواع السجلات الأربعة جميعها: تعمل MX وSPF وDKIM وDMARC معًا. تخطّي أي منها يخلق ثغرات.
- استخدم قيم TTL مناسبة: قيم TTL أقل للسجلات التي تتغير كثيرًا، وأعلى للسجلات المستقرة.
- تحقق قبل الإرسال: أكّد دائمًا أن المصادقة تعمل عبر تحليل ترويسات البريد من رسائل اختبار.
- ابدأ بسياسات DMARC مرنة: استخدم p=none في البداية، ثم انتقل إلى سياسات أكثر صرامة كلما اكتسبت الثقة.
- راقب باستمرار: يمكن أن ينكسر إعداد DNS بصمت. المراقبة المنتظمة تلتقط المشكلات قبل أن تؤثّر في الحملات.
- أبقِ عمليات بحث SPF أقل من 10: دقّق سجل SPF الخاص بك بانتظام لضمان عدم تجاوز حد عمليات البحث.
- استخدم مفاتيح DKIM بحجم 2048 بت: توفّر المفاتيح الأكبر أمانًا أفضل دون مشكلات توافق.
- وثّق إعدادك: احتفظ بسجلات لما هي الخدمات المصرّح لها لكل نطاق.
الخاتمة
إعداد DNS هو الأساس التقني الذي يحدّد ما إذا كانت رسائلك الإلكترونية الباردة ستصل إلى صندوق الوارد أم ستختفي في البريد المزعج. إن فهم كيفية عمل سجلات MX وSPF وDKIM وDMARC معًا يمنحك المعرفة لتشخيص مشكلات قابلية التسليم وضمان إعداد بنيتك التحتية بشكل صحيح.
غير أن الإدارة اليدوية لـ DNS تصبح غير عملية بشكل متزايد كلما توسّعت. فالوقت المُنفق في إعداد السجلات، واستكشاف مشكلات الانتشار، والمراقبة بحثًا عن المشكلات، هو وقت لا يُنفق على تشغيل حملاتك فعليًا. لهذا السبب توجد منصات مثل InboxOne: للتعامل مع التعقيد التقني حتى تتمكن من التركيز على ما يهم أكثر - كتابة تواصل رائع وتنمية عملك.
سواء اخترت إدارة DNS يدويًا أو الاستفادة من الأتمتة، فإن المبادئ الواردة في هذا الدليل ستساعدك على الحفاظ على بنية المصادقة التحتية التي تتطلبها قابلية تسليم البريد الإلكتروني الحديثة. تستحق رسائلك الإلكترونية الباردة أن تصل إلى صندوق الوارد. والإعداد الصحيح لـ DNS يضمن وصولها.
FAQالأسئلة الشائعة
كم من الوقت يستغرق انتشار DNS عادةً؟
يستغرق انتشار DNS عادةً ما بين 15 دقيقة و48 ساعة، اعتمادًا على إعدادات TTL (مدة البقاء) ومزوّد DNS. مع مزوّدين مثل Cloudflare، غالبًا ما تنتشر التغييرات خلال 5-15 دقيقة. يضمن الإعداد التلقائي في InboxOne إعدادات TTL مثالية لانتشار أسرع.
هل يمكنني امتلاك عدة سجلات SPF على نطاق واحد؟
لا، ينبغي أن يكون لديك سجل SPF واحد فقط لكل نطاق. وجود عدة سجلات SPF يتسبب في فشل المصادقة لأن الخوادم المستقبِلة لن تعرف أيًّا منها ينبغي استخدامه. إذا كنت بحاجة إلى تفويض عدة مصادر إرسال، فادمجها في سجل SPF واحد باستخدام آلية 'include'.
ماذا يحدث إذا فشل DMARC لكن نجح SPF أو DKIM؟
يتطلب DMARC المحاذاة، أي أن النطاق في ترويسة 'From' يجب أن يطابق إما النطاق المُصادَق عليه عبر SPF أو النطاق الموقِّع عبر DKIM. إذا فشلت المحاذاة حتى عندما ينجح SPF أو DKIM بشكل فردي، فسيفشل DMARC. لهذا السبب فإن الإعداد الصحيح للبروتوكولات الثلاثة جميعها أمر أساسي.
هل أحتاج إلى سجلات MX لإرسال رسائل البريد الإلكتروني البارد؟
على الرغم من أن سجلات MX مخصّصة في المقام الأول لاستقبال الرسائل، فإن إعدادها مهم لمصداقية البريد الإلكتروني البارد. تتحقق العديد من مرشّحات البريد المزعج من وجود سجلات MX كدليل على شرعية النطاق. قد يُوسَم النطاق الذي لا يحتوي على سجلات MX بأنه مشبوه لأنه لا يستطيع استقبال الردود.
كيف يتعامل InboxOne مع إعداد DNS لعدة نطاقات؟
يقوم InboxOne تلقائيًا بإعداد سجلات SPF وDKIM وDMARC وMX لجميع النطاقات المشتراة أو المتصلة عبر المنصة. باستخدام تكامل واجهة برمجة التطبيقات مع Cloudflare أو ClouDNS، تُنشأ السجلات خلال دقائق دون أي تدخل يدوي. كما يراقب نظامنا سلامة DNS على مدار الساعة طوال أيام الأسبوع ويصلح المشكلات تلقائيًا.
ما الفرق بين الفشل الليّن (~all) والفشل القاسي (-all) في SPF؟
الفشل الليّن (~all) يخبر الخوادم المستقبِلة بقبول الرسائل التي تفشل في SPF لكن مع وسمها كمشبوهة، بينما الفشل القاسي (-all) يوجّه الخوادم إلى رفض الرسائل مباشرة. بالنسبة للبريد الإلكتروني البارد، يُنصح بالبدء بالفشل الليّن أثناء الإحماء، ثم الانتقال إلى الفشل القاسي بمجرد ترسّخ سمعة الإرسال لديك.
كيف يمكنني التحقق من أن سجلات DNS الخاصة بي مُعدّة بشكل صحيح؟
يمكنك التحقق من سجلات DNS باستخدام أدوات مثل MXToolbox أو Google Admin Toolbox أو أدوات سطر الأوامر مثل dig وnslookup. يوفّر InboxOne تحققًا مدمجًا من DNS يفحص تلقائيًا جميع سجلات المصادقة وينبّهك إلى أي مشكلات قبل أن تؤثّر في قابلية التسليم.
Cold email infrastructure platform. Buy domains, provision Google Workspace mailboxes, auto-configure DNS, and export to 5 outreach platforms — all from one dashboard.
© 2026 InboxOne. All rights reserved.