حماية البريد الإلكتروني في Microsoft 365 — دليل إعداد SPF وDKIM وDMARC واستكشاف الأخطاء

لماذا أصبحت مصادقة البريد الإلكتروني ضرورة حتمية في 2026؟

لنكن صريحين: حماية البريد الإلكتروني لم تعد مجرد توصية أمنية يمكنك تأجيلها — بل أصبحت شرطًا إلزاميًا لضمان وصول رسائلك من الأساس. فمنذ مطلع 2024، فرضت Google وYahoo متطلبات صارمة لمصادقة البريد على المرسلين بكميات كبيرة (أكثر من 5,000 رسالة يوميًا)، تشمل إعداد SPF وDKIM وDMARC. ثم في مايو 2025، لحقت بهم Microsoft بإعلانها عن تطبيق سياسات مماثلة على رسائل البريد الواردة إلى Outlook.com وHotmail وLive.com.

ولم يتوقف الأمر عند هذا الحد. مع إصدار Security Baseline الإصدار 2512 في يناير 2026، عزّزت Microsoft حماية تطبيقات Microsoft 365 للمؤسسات بشكل ملحوظ — حظر الروابط غير الآمنة، وإيقاف البروتوكولات القديمة، ومنع وحدات الماكرو غير الموقّعة.

الخلاصة؟ أي مؤسسة تستخدم Microsoft 365 ولا تملك إعدادات مصادقة بريد إلكتروني صحيحة تُخاطر بفقدان رسائلها في مجلدات البريد العشوائي — أو رفضها بالكامل.

في هذا الدليل، سنمشي معًا خطوة بخطوة على إعداد بروتوكولات SPF وDKIM وDMARC في بيئة Microsoft 365. ولن نكتفي بالإعداد فقط — بل سنتطرّق لاستكشاف الأخطاء الشائعة وإصلاحها، وكذلك تكوين طبقات الحماية الإضافية في Microsoft Defender for Office 365.

فهم بروتوكولات مصادقة البريد الإلكتروني الثلاثة

قبل أن ندخل في التفاصيل التقنية، من المهم فهم كيف تعمل هذه البروتوكولات الثلاثة معًا. فكّر فيها كطبقات دفاعية متكاملة — كل واحدة تسدّ ثغرة معيّنة لحماية نطاقك من الانتحال والتصيّد الاحتيالي:

• SPF (Sender Policy Framework): يحدّد خوادم البريد المصرّح لها بالإرسال نيابةً عن نطاقك عبر سجل TXT في DNS.
• DKIM (DomainKeys Identified Mail): يُرفق توقيعًا رقميًا مشفّرًا بكل رسالة صادرة للتحقق من أنها لم تُعدَّل أثناء النقل.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): يربط نتائج SPF وDKIM معًا ويحدّد الإجراء المتّخذ عند فشل المصادقة (مراقبة، عزل، أو رفض).

نقطة مهمة: كل بروتوكول وحده لا يكفي. صراحةً، من خلال التعامل مع بيئات مؤسسية متعددة، القوة الحقيقية تظهر فقط عند تفعيلها جميعًا معًا لتشكيل إطار مصادقة شامل ومتين.

إعداد SPF في Microsoft 365 — خطوة بخطوة

ما الذي يفعله سجل SPF؟

ببساطة، سجل SPF يُخبر خوادم البريد المستقبِلة: "هذه هي الخوادم الوحيدة المسموح لها بإرسال بريد من نطاقي — أي شيء آخر لا يمثّلني". فأي رسالة تأتي من خادم غير مُدرَج ستُعامَل وفقًا لسياسة SPF المحددة.

خطوات إنشاء سجل SPF

1. سجّل الدخول إلى لوحة تحكم مزوّد DNS الخاص بنطاقك (سواء كان GoDaddy أو Cloudflare أو Namecheap أو غيرهم).
2. أنشئ سجل TXT جديدًا بالقيم التالية:

Host: @
Type: TXT
Value: v=spf1 include:spf.protection.outlook.com -all
TTL: 3600

3. إذا كنت تستخدم خدمات إرسال أخرى بجانب Microsoft 365 (مثل Mailchimp أو Salesforce)، أضف سجلاتها في نفس سجل SPF — وليس في سجل منفصل:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com -all

4. استخدم -all (hard fail) بدلاً من ~all (soft fail) لحماية أقوى — فهذا يأمر الخوادم المستقبِلة برفض الرسائل من مصادر غير مصرّح بها بشكل قاطع.

القواعد الأساسية لسجل SPF

• سجل واحد فقط: لا يمكن أن يكون لديك أكثر من سجل SPF TXT واحد لكل نطاق. وجود أكثر من سجل يُسبّب خطأ PermError (وهذا الخطأ أكثر شيوعًا مما تتوقع).
• حد 10 عمليات بحث DNS: كل include: وredirect= وa: وmx: تُعَدّ عملية بحث. تجاوز هذا الحد يُسبّب فشل SPF مباشرة.
• أقل من 255 حرفًا لكل سلسلة: إذا تجاوز السجل هذا الحد، قسّمه إلى سلاسل متعددة.

استكشاف أخطاء SPF الشائعة

المشكلة	السبب المحتمل	الحل
SPF PermError	تجاوز حد 10 عمليات بحث DNS أو وجود سجلين SPF	ادمج جميع السجلات في سجل واحد واستخدم أداة SPF Flattening لتقليل عمليات البحث
الرسائل تذهب للبريد العشوائي رغم إعداد SPF	استخدام ~all بدلاً من -all أو عدم تفعيل DKIM/DMARC	غيّر إلى -all وفعّل DKIM وDMARC
فشل SPF لرسائل تُعاد توجيهها	إعادة التوجيه تغيّر عنوان IP المرسِل	هذا سلوك طبيعي — DKIM يحل هذه المشكلة لأنه لا يتأثر بإعادة التوجيه
رسائل جهة خارجية تفشل	خادم الطرف الثالث غير مُدرَج في سجل SPF	أضف include: الخاص بالخدمة إلى سجل SPF

التحقق من سجل SPF باستخدام PowerShell

# التحقق من سجل SPF لنطاقك
Resolve-DnsName -Name "yourdomain.com" -Type TXT | Where-Object { $_.Strings -match "spf" }

# التحقق من عدد عمليات البحث DNS
# استخدم أداة خارجية مثل MXToolbox SPF Lookup

إعداد DKIM في Microsoft 365 — التوقيع الرقمي لرسائلك

كيف يعمل DKIM؟

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

خطوات تفعيل DKIM في Microsoft 365

1. افتح بوابة Microsoft Defender على العنوان: https://security.microsoft.com
2. انتقل إلى: Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
3. اختر نطاقك المخصّص (وليس النطاق الافتراضي *.onmicrosoft.com).
4. انقر على Enable لتفعيل توقيع DKIM.
5. ستظهر لك سجلات CNAME التي يجب إضافتها إلى DNS:

selector1._domainkey.yourdomain.com
  CNAME → selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

selector2._domainkey.yourdomain.com
  CNAME → selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

6. أضف سجلات CNAME هذه في لوحة تحكم DNS الخاصة بك.
7. انتظر انتشار DNS (يتراوح بين 15 دقيقة و48 ساعة — حسب مزوّد DNS لديك).
8. عُد إلى بوابة Defender وفعّل DKIM مرة أخرى.

استكشاف أخطاء DKIM الشائعة

المشكلة	السبب المحتمل	الحل
فشل تفعيل DKIM في بوابة Defender	سجلات CNAME لم تنتشر بعد في DNS	انتظر 24-48 ساعة وتأكد من صحة السجلات باستخدام nslookup
خطأ CNAME record does not exist	السجلات غير صحيحة أو فيها أخطاء إملائية	تحقق من أن اسم المضيف والقيمة مطابقان تمامًا لما تعرضه بوابة Defender
توقيع DKIM غير موجود في الرسائل الصادرة	DKIM معطّل أو الرسائل تُرسَل عبر خدمة خارجية	تأكد من التفعيل في Defender وأعدّ DKIM بشكل منفصل لكل خدمة إرسال
فشل DKIM بعد تعديل الرسالة	خدمة وسيطة عدّلت محتوى الرسالة (مثل قوائم بريدية)	هذا متوقع — DMARC يعالج هذا من خلال سياسة التراجع إلى SPF

التحقق من DKIM باستخدام PowerShell

# التحقق من سجلات DKIM CNAME
Resolve-DnsName -Name "selector1._domainkey.yourdomain.com" -Type CNAME
Resolve-DnsName -Name "selector2._domainkey.yourdomain.com" -Type CNAME

# التحقق من المفتاح العام DKIM
Resolve-DnsName -Name "selector1._domainkey.yourdomain.com" -Type TXT

إعداد DMARC في Microsoft 365 — السياسة والتقارير

كيف يعمل DMARC؟

DMARC هو الذي يجمع الصورة كلها. يأخذ نتائج SPF وDKIM ويقرّر على أساسها مصير الرسائل الفاشلة: هل نقبلها؟ نعزلها؟ أم نرفضها؟ بالإضافة إلى ذلك، يوفّر آلية إبلاغ ترسل تقارير مفصّلة عن كل محاولة إرسال من نطاقك — سواء كانت شرعية أو محاولات انتحال.

خطوات إنشاء سجل DMARC

1. تأكد أولًا من إعداد SPF وDKIM بشكل صحيح — هذا شرط أساسي لا يمكن تجاوزه.
2. أنشئ سجل TXT في DNS بالقيم التالية:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; pct=100
TTL: 3600

استراتيجية التدرّج في تطبيق DMARC

هنا نقطة يخطئ فيها الكثيرون. لا تقفز مباشرة إلى سياسة p=reject — فقد تحظر رسائل شرعية وتُسبّب مشاكل أنت في غنى عنها. من واقع التجربة، الطريقة الصحيحة هي التدرّج:

1. المرحلة 1 — المراقبة (2-4 أسابيع):

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

في هذه المرحلة لن يتأثر شيء فعليًا. اجمع التقارير وحلّلها لمعرفة جميع مصادر الإرسال الشرعية من نطاقك (وغالبًا ستكتشف مصادر لم تكن تعلم بوجودها).

2. المرحلة 2 — العزل التدريجي (2-4 أسابيع):

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1

ابدأ بعزل 25% فقط من الرسائل الفاشلة، ثم ارفع النسبة تدريجيًا إلى 50% ثم 100%. هذه الطريقة تمنحك الوقت لملاحظة أي مشكلة قبل أن تتفاقم.

3. المرحلة 3 — الرفض الكامل:

v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1

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

فهم علامات سجل DMARC

العلامة	الوصف	القيم المتاحة
v	إصدار البروتوكول	DMARC1 (إلزامي)
p	سياسة النطاق الرئيسي	none، quarantine، reject
sp	سياسة النطاقات الفرعية	none، quarantine، reject
rua	عنوان التقارير المجمّعة (Aggregate)	عنوان بريد إلكتروني
ruf	عنوان تقارير الفشل التفصيلية (Forensic)	عنوان بريد إلكتروني
fo	خيارات إبلاغ الفشل	0 (كلاهما يفشل)، 1 (أي فشل)
pct	نسبة الرسائل المطبّق عليها السياسة	1-100
adkim	وضع محاذاة DKIM	r (مرن)، s (صارم)
aspf	وضع محاذاة SPF	r (مرن)، s (صارم)

استكشاف أخطاء DMARC الشائعة

المشكلة	السبب المحتمل	الحل
رسائل شرعية تُرفَض أو تُعزَل	مصدر إرسال شرعي غير مُدرَج في SPF أو لا يوقّع بـ DKIM	حلّل تقارير DMARC (RUA) لتحديد المصدر وأضفه إلى SPF أو فعّل DKIM له
عدم استلام تقارير DMARC	عنوان rua غير صحيح أو السجل فيه خطأ بنيوي	تحقق من صياغة السجل وأن البريد يقبل الرسائل الواردة
النطاقات الفرعية غير محمية	عدم تحديد سياسة sp	أضف sp=reject لسياسة النطاقات الفرعية أو أنشئ سجل DMARC منفصل لكل نطاق فرعي
تقارير DMARC بتنسيق XML غير مقروءة	التقارير المجمّعة تأتي بتنسيق XML مضغوط	استخدم أدوات مثل dmarcian أو Valimail أو DMARC Analyzer لعرض التقارير بشكل مرئي

تكوين طبقات الحماية الإضافية في Microsoft Defender for Office 365

انتهينا من إعداد SPF وDKIM وDMARC — ممتاز. لكن القصة لم تنتهِ هنا. Microsoft Defender for Office 365 يوفّر طبقات حماية إضافية تعمل فوق المصادقة الأساسية، واستخدامها يُحدث فرقًا كبيرًا في مستوى الأمان.

سياسات الحماية المُسبقة (Preset Security Policies)

يقدّم Defender ثلاثة مستويات حماية جاهزة، وكل مستوى مناسب لحالة معيّنة:

• Built-in Protection: مفعّلة افتراضيًا لجميع المستخدمين وتوفر حماية أساسية عبر Safe Links وSafe Attachments.
• Standard Protection: مناسبة لمعظم المستخدمين العاديين مع إعدادات متوازنة بين الأمان والإنتاجية.
• Strict Protection: خصّصها للأشخاص الأكثر عرضة للاستهداف — المديرين التنفيذيين، فرق المالية، وأي شخص يتعامل مع معلومات حسّاسة.

لتفعيل السياسات المُسبقة: security.microsoft.com → Policies & rules → Threat policies → Preset Security Policies

Safe Attachments — فحص المرفقات في بيئة معزولة

تأخذ هذه الميزة أي مرفق وتفحصه في بيئة افتراضية معزولة (Sandbox) قبل تسليمه للمستقبِل. الفحص يستغرق عادةً حوالي 15 دقيقة — تأخير بسيط، لكنه ثمن معقول مقابل حماية فعلية من المرفقات الخبيثة.

للتكوين، انتقل إلى:

Microsoft Defender Portal → Email & collaboration → Policies & rules
  → Threat policies → Safe Attachments → Create policy

الإعدادات الموصى بها:

• Action: Block — لحظر الرسائل التي تحتوي مرفقات ضارة بشكل مباشر.
• Redirect: فعّل إعادة التوجيه إلى صندوق بريد أمني حتى يتمكن فريقك من تحليل المرفقات المشبوهة.
• Safe Attachments for SharePoint, OneDrive, and Teams: لا تنسَ تفعيلها — كثير من المسؤولين يغفلون عن حماية الملفات المشتركة.

Safe Links — فحص الروابط في الوقت الفعلي

تفحص Safe Links كل رابط في الرسائل الواردة وتُعيد كتابته لتوجيهه عبر خوادم Microsoft للتحقق منه عند النقر. والجيد في الأمر أنها تعمل أيضًا في تطبيقات Office وMicrosoft Teams — وليس فقط في البريد الإلكتروني.

الإعدادات الموصى بها:

• فعّل URL rewriting للرسائل الواردة.
• فعّل Real-time URL scanning للملفات القابلة للتنزيل.
• فعّل الحماية في Microsoft Teams وتطبيقات Office 365.
• لا تستثنِ أي نطاقات إلا للضرورة القصوى — وحتى حينها، قيّم المخاطر أولًا.

سياسات مكافحة التصيّد (Anti-Phishing Policies)

لتكوين حماية متقدمة ضد انتحال الهوية، اتبع الخطوات التالية:

1. انتقل إلى: security.microsoft.com → Anti-phishing
2. أنشئ سياسة جديدة أو عدّل السياسة الافتراضية.
3. فعّل Impersonation Protection للمستخدمين المهمين (CEO، CFO، مديري تقنية المعلومات — أي شخص يُستهدف عادةً).
4. فعّل Mailbox Intelligence — هذه الميزة تتعلّم أنماط البريد المعتادة لكل مستخدم وتكشف أي نشاط غير طبيعي.
5. فعّل Spoof Intelligence لكشف محاولات انتحال النطاقات.

أدوات التحقق والاختبار

أتممت الإعداد — ممتاز. لكن كيف تتأكد أن كل شيء يعمل بالشكل الصحيح؟ هنا تأتي أهمية أدوات التحقق.

أدوات سطر الأوامر (PowerShell وnslookup)

# التحقق من جميع سجلات مصادقة البريد دفعة واحدة
$domain = "yourdomain.com"

Write-Host "=== SPF Record ===" -ForegroundColor Green
Resolve-DnsName -Name $domain -Type TXT | Where-Object { $_.Strings -match "spf" } | Select-Object -ExpandProperty Strings

Write-Host "`n=== DKIM Records ===" -ForegroundColor Green
Resolve-DnsName -Name "selector1._domainkey.$domain" -Type CNAME -ErrorAction SilentlyContinue | Format-List
Resolve-DnsName -Name "selector2._domainkey.$domain" -Type CNAME -ErrorAction SilentlyContinue | Format-List

Write-Host "`n=== DMARC Record ===" -ForegroundColor Green
Resolve-DnsName -Name "_dmarc.$domain" -Type TXT | Select-Object -ExpandProperty Strings

استخدام Exchange Online PowerShell للتحقق من إعدادات DKIM

# الاتصال بـ Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName [email protected]

# عرض حالة DKIM لجميع النطاقات
Get-DkimSigningConfig | Format-Table Domain, Enabled, Status

# عرض تفاصيل DKIM لنطاق محدد
Get-DkimSigningConfig -Identity "yourdomain.com" | Format-List

أدوات الويب المجانية

لا تحتاج الاعتماد على سطر الأوامر فقط — هناك أدوات ويب ممتازة ومجانية يمكنك استخدامها:

• MXToolbox: للتحقق من SPF وDKIM وDMARC وسمعة النطاق — أداة شاملة وسهلة الاستخدام.
• Mail-Tester.com: أرسل رسالة اختبار واحصل على تقييم شامل لمصادقة بريدك (صراحةً، من أفضل الأدوات السريعة لهذا الغرض).
• Google Admin Toolbox: Check MX للتحقق من إعدادات DNS.
• dmarcian: لتحليل تقارير DMARC بشكل مرئي ومفهوم بدلاً من قراءة ملفات XML يدويًا.
• Valimail: لمراقبة امتثال DMARC بشكل مستمر.

اختبار عملي — إرسال رسالة تجريبية

الخطوة الأخيرة والأهم: بعد إعداد البروتوكولات الثلاثة، أرسل رسالة اختبار إلى عنوان Gmail وافحص رؤوس الرسالة بنفسك:

1. افتح الرسالة في Gmail واختر "Show original".
2. ابحث عن هذه النتائج:

SPF:    PASS
DKIM:   PASS
DMARC:  PASS

إذا ظهرت كلمة PASS بجانب البروتوكولات الثلاثة، يمكنك الاطمئنان — إعداداتك صحيحة ومكتملة.

متطلبات Microsoft للمرسلين بكميات كبيرة في 2025-2026

هذا الجزء يستحق الانتباه. أعلنت Microsoft في 2025 عن متطلبات جديدة تخص أي جهة ترسل أكثر من 5,000 رسالة يوميًا إلى عناوين Outlook.com وHotmail وLive.com:

• إلزامية SPF: يجب أن يجتاز سجل SPF التحقق للنطاق المرسِل.
• إلزامية DKIM: يجب توقيع الرسائل رقميًا بـ DKIM.
• إلزامية DMARC: يجب نشر سجل DMARC بسياسة p=none كحد أدنى مع محاذاة SPF أو DKIM.
• عنوان مرسِل صالح: يجب أن يتطابق عنوان From مع النطاق المصادَق.
• آلية إلغاء اشتراك: يجب توفير رابط إلغاء اشتراك بنقرة واحدة (RFC 8058) للرسائل التسويقية.
• معدل شكاوى منخفض: الحفاظ على معدل شكاوى البريد العشوائي أقل من 0.3%.

ما يجعل الأمر أكثر إلحاحًا أن هذه المتطلبات تتماشى مع ما فرضته Google وYahoo منذ 2024. يعني ذلك أن الامتثال لمعايير مصادقة البريد الإلكتروني أصبح ضروريًا لوصول رسائلك إلى صناديق الوارد عند جميع مزوّدي البريد الرئيسيين — بدون استثناء.

قائمة مراجعة شاملة لمصادقة البريد في Microsoft 365

قبل أن تعتبر أنك انتهيت، مرّ على هذه القائمة وتأكد من كل نقطة:

1. ☐ سجل SPF TXT منشور في DNS يحتوي على include:spf.protection.outlook.com
2. ☐ لا يوجد أكثر من سجل SPF واحد لكل نطاق
3. ☐ عدد عمليات بحث DNS في SPF أقل من 10
4. ☐ سجلات DKIM CNAME مُضافة ومفعّلة في بوابة Defender
5. ☐ DKIM مفعّل لجميع النطاقات المخصصة المستخدمة للإرسال
6. ☐ سجل DMARC TXT منشور على _dmarc.yourdomain.com
7. ☐ سياسة DMARC في مرحلة مناسبة (none → quarantine → reject)
8. ☐ عناوين تقارير DMARC (rua/ruf) تعمل وتستقبل التقارير
9. ☐ Safe Attachments مفعّلة مع سياسة Block
10. ☐ Safe Links مفعّلة مع فحص الروابط في الوقت الفعلي
11. ☐ سياسة Anti-Phishing تتضمن حماية انتحال الهوية للمستخدمين المهمين
12. ☐ اختبار إرسال رسالة ناجح مع نتائج PASS لـ SPF وDKIM وDMARC

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

هل يمكنني إعداد DMARC دون تفعيل DKIM؟

من الناحية التقنية، نعم يمكنك ذلك. لكن هل أنصح به؟ إطلاقًا. يعتمد DMARC على محاذاة SPF أو DKIM (أو كليهما). بدون DKIM، تفقد طبقة حماية أساسية، والأهم أن رسائلك المُعاد توجيهها تصبح عرضة لفشل المصادقة — لأن SPF وحده لا يتعامل جيدًا مع إعادة التوجيه. فعّل كلا البروتوكولين دائمًا قبل إعداد DMARC.

كم من الوقت يستغرق تفعيل SPF وDKIM وDMARC بالكامل؟

إعداد السجلات نفسها في DNS يمكن إنجازه خلال ساعة أو أقل. لكن انتشار DNS مسألة أخرى — يتراوح بين 15 دقيقة و48 ساعة حسب المزوّد. أما الجزء الذي يأخذ وقتًا فعلاً فهو التطبيق الكامل لسياسة DMARC p=reject، ويُفضَّل أن يمتد على 4-8 أسابيع للمرور بمراحل المراقبة والعزل التدريجي والتأكد من عدم تأثر الرسائل الشرعية.

ما الفرق بين hard fail ‏(-all) وsoft fail ‏(~all) في SPF؟

الخيار -all (hard fail) يأمر الخوادم المستقبِلة بوضوح: ارفض أي رسالة تأتي من خادم غير مُدرَج في سجل SPF. أما ~all (soft fail) فيُعلّم الرسائل كمشبوهة لكن لا يرفضها. في 2026، ومع تشديد متطلبات المصادقة من كل الجهات، يُنصح باستخدام -all — لكن تأكد أولاً من إدراج جميع مصادر الإرسال الشرعية.

هل Microsoft 365 يُرسل تقارير DMARC المجمّعة (RUA)؟

نعم. أصبحت Microsoft ترسل تقارير DMARC المجمّعة كنطاق مستقبِل. هذا يعني أنه إذا أرسلت بريدًا إلى مستخدمي Microsoft 365، فقد تستلم تقارير RUA من Microsoft تُظهر نتائج مصادقة رسائلك. ولتحليل هذه التقارير بسهولة بدلًا من التعامل مع ملفات XML، استخدم أدوات مثل dmarcian أو Valimail.

ماذا أفعل إذا كانت رسائل جهة خارجية (مثل نظام CRM أو خدمة تسويق) تفشل في مصادقة SPF؟

الحل مباشر: أضف سجل include: الخاص بتلك الخدمة إلى سجل SPF الخاص بك. على سبيل المثال، لخدمة Mailchimp أضف include:servers.mcsv.net. لكن — وهذه نقطة مهمة — لا تنسَ حد الـ 10 عمليات بحث DNS. إذا كنت تقترب من الحد، استخدم أداة SPF Flattening لتحويل عمليات البحث إلى عناوين IP مباشرة. بالإضافة إلى ذلك، حاول تفعيل DKIM لتلك الخدمة بشكل مستقل إن كان هذا الخيار متاحًا — فهذا يمنحك طبقة حماية إضافية ويخفّف الضغط عن SPF.