حماية البريد الإلكتروني: الدليل الاحترافي لـ SPF وDKIM وDMARC

في عام 1982، عندما كُتبت مواصفة بروتوكول SMTP لأول مرة، لم يكن في ذهن مصمّميها أي شيء اسمه انتحال الهوية. كانت الشبكة صغيرة، والأطراف تثق ببعضها، فجاء البروتوكول بلا أي آلية للتحقق من أنّ المُرسِل هو فعلاً من يدّعي أنه هو. هذه الثغرة البنيوية لم تُغلق حتى اليوم على مستوى البروتوكول نفسه: أي جهاز في العالم يستطيع أن يفتح اتصال SMTP ويكتب في حقل From عنوان [email protected] دون أن يملك أي علاقة بنطاقك.

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

طبقات المصادقة الثلاث—SPF وDKIM وDMARC—هي الردّ الهندسي على هذه الثغرة. وفوقها بُنيت طبقات أحدث تعالج ما تبقّى من ثغرات: النقل المشفّر (MTA-STS)، إعادة التوجيه (ARC)، والهوية البصرية (BIMI). هذا الدليل يشرح آلية عمل كل طبقة، والثغرة التي تسدّها، وكيف تجتمع لتحويل نطاقك من هدف سهل إلى قلعة يصعب انتحالها—مع سجلات DNS جاهزة وخطة تطبيق مرحلية.

لماذا لا يكفي SMTP وحده: مشكلة العنوانين

قبل الدخول في البروتوكولات، لا بدّ من فهم نقطة تقنية دقيقة تُبنى عليها كل آلية المصادقة: رسالة البريد تحمل عنوانَي مُرسِل، لا عنوانًا واحدًا.

1. عنوان الغلاف (Envelope Sender / MAIL FROM / Return-Path): يُستخدم على مستوى بروتوكول النقل، وهو الذي تُرسَل إليه إشعارات الفشل (bounces). المستخدم لا يراه عادةً.

2. عنوان الترويسة المرئي (Header From): هو ما يظهر فعليًا في صندوق الوارد كاسم المُرسِل.

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

احتفظ بهذه الفكرة في ذهنك: SPF يفحص عنوان الغلاف، وDKIM يفحص التوقيع، وDMARC هو الوحيد الذي يربط النتيجة بالعنوان المرئي الذي يراه المستخدم.

الطبقة الأولى: SPF — من يحقّ له الإرسال باسمك

ما هو SPF

Sender Policy Framework (SPF) هو قائمة معلنة بمصادر الإرسال المصرَّح لها باستخدام اسم نطاقك. تنشر كسجل TXT واحد في DNS، فيعرف الخادم المستقبِل أي عناوين IP وأي خدمات يُسمح لها بإرسال بريد نيابةً عنك. المبدأ بسيط: إذا وصل بريد يدّعي أنه من نطاقك لكن من عنوان IP غير مدرج في القائمة، فقد فشل فحص SPF.

آلية العمل

عند استقبال رسالة، يقرأ الخادم المستقبِل نطاق عنوان الغلاف، ثم يستعلم عن سجل SPF لهذا النطاق ويقارن عنوان IP المُرسِل بالقائمة. مثال على سجل SPF نموذجي:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all"

قراءة السجل عنصرًا بعنصر:

نقطة حاسمة في المُعامِل الأخير:

إقرأ أيضًا

المساعد الذكي من إليفانتي

نظام أسماء النطاقات (DNS): كيف يعمل دفتر هاتف الإنترنت، وكيف تدير سجلاتك باحترافية

في كل مرة تكتب فيها عنوان موقع في المتصفح وتضغط Enter، تحدث خلف الكواليس سلسلةٌ من الاستعلامات عبر بنيةٍ تحتيةٍ…

يونيو 29, 2026

النطاقات (Domains): الدليل الشامل لفهم بنية الإنترنت من الجذر إلى التسجيل والإدارة

كل ما تحتاج معرفته عن النطاقات: ما هي، وكيف نشأت الحاجة إليها، وآلية عملها داخل نظام أسماء النطاقات، ومنظومة تسجيلها…

يونيو 30, 2026

• -all — رفض صارم: أي مصدر غير مدرج يفشل. هذا هو الوضع الآمن والمُوصى به.
• ~all — فشل ليّن (softfail): يُقبل البريد لكن يُوسم كمشبوه. مناسب أثناء الاختبار فقط.
• ?all — محايد: لا يقوم بأي إجراء. عمليًا بلا فائدة أمنية.

حدود SPF التي يجب أن تعرفها

SPF قوي لكنه ليس كافيًا وحده، لسببين جوهريين:

1. ينكسر عند إعادة التوجيه (Forwarding): إذا أعاد خادم وسيط توجيه رسالتك، يتغيّر عنوان IP المُرسِل، فيفشل SPF رغم شرعية الرسالة.

2. لا يحمي العنوان المرئي: SPF يفحص عنوان الغلاف فقط، لا حقل From الذي يراه المستخدم. يستطيع مهاجم اجتياز SPF من نطاقه الخاص بينما يعرض اسم نطاقك في الترويسة.

كما أن للمواصفة حدًّا صارمًا: عشر عمليات استعلام DNS كحد أقصى (كل include وa وmx تُحتسب). تجاوز هذا الحد يُنتج خطأ permerror يُبطل السجل كليًّا—وهو خطأ شائع جدًّا لدى من يجمعون عدة مزوّدين خارجيين. الحل هو ما يُعرف بـ تسطيح SPF (SPF Flattening) أو تقليل عدد المزوّدين.

الطبقة الثانية: DKIM — التوقيع الرقمي الذي يثبت سلامة الرسالة

ما هو DKIM

DomainKeys Identified Mail (DKIM) يضيف توقيعًا رقميًا مشفّرًا إلى كل رسالة صادرة. يُوقَّع التوقيع بمفتاح خاص لا يغادر خوادمك أبدًا، ويُتحقَّق منه بمفتاح عام تنشره في DNS. إذا تطابق التوقيعان، فهذا يثبت أمرين معًا: أن الرسالة صادرة فعلاً من نطاقك، وأنها لم تُعدَّل في الطريق. التشبيه الأدق: توقيع الشيك المصرفي—من يملك المفتاح الخاص وحده يستطيع إنتاج توقيع يجتاز التحقق.

آلية العمل

1. عند الإرسال، يحسب خادمك بصمة (hash) لمجموعة من ترويسات الرسالة (From, Subject, Date…) ولجسم الرسالة، ثم يوقّعها بالمفتاح الخاص.

2. يُدرَج التوقيع في ترويسة جديدة اسمها DKIM-Signature.

3. الخادم المستقبِل يقرأ من التوقيع اسم النطاق (d=) والمُحدِّد (s=)، فيستعلم عن المفتاح العام من DNS ويعيد حساب البصمة. إن تطابقت، ينجح DKIM.

مثال على سجل مفتاح DKIM العام (المفتاح مختصر هنا؛ في الواقع طويل جدًّا):

mail._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7... (المفتاح العام الكامل)"

بنية ترويسة DKIM-Signature التي تُرفق بكل رسالة:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
    h=from:subject:date:to; bh=(بصمة الجسم); b=(التوقيع)

توصيات عملية لـ DKIM

• استخدم مفتاح RSA بطول 2048 بت كحدّ أدنى موصى به (1024 بت أصبح ضعيفًا)؛
• دوِّر المفاتيح دوريًّا (كل 6 أشهر تقريبًا) عبر إنشاء مُحدِّد جديد؛
• خصّص مُحدِّدًا منفصلًا لكل مزوّد خارجي (خادمك، منصة التسويق، نظام الفوترة…) حتى تتمكن من تتبّع كل مصدر وإلغائه بمعزل عن الباقي؛
• على خوادم لينكس المستقلة، يُنشَأ زوج المفاتيح غالبًا عبر OpenDKIM:

opendkim-genkey -b 2048 -s mail -d example.com

محدودية DKIM: مثل SPF، لا يربط DKIM التوقيع بالعنوان المرئي From. يستطيع مهاجم أن يوقّع رسالة توقيعًا سليمًا من نطاقه الخاص، بينما يعرض نطاقك في الترويسة. هنا يأتي دور DMARC ليغلق الحلقة.

الطبقة الثالثة: DMARC — السياسة التي تحوّل الفحص إلى حماية

ما هو DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) هو طبقة السياسة والتقارير التي تجلس فوق SPF وDKIM. يفعل ثلاثة أشياء لا يفعلها أيٌّ منهما وحده:

1. يفرض المحاذاة (Alignment): يتأكد أن النطاق الذي اجتاز SPF أو DKIM هو نفسه النطاق المرئي في حقل From. هذا بالضبط ما يسدّ ثغرة “العنوانين” التي شرحناها.

2. يحدّد السياسة: يخبر الخادم المستقبِل ماذا يفعل بالرسالة الفاشلة.

3. يُرسل التقارير: يُعيد إليك تقارير عمّن يرسل باسم نطاقك ومن ينتحله.

قاعدة النجاح والمحاذاة

تنجح رسالة في DMARC إذا نجح واحد على الأقل من SPF أو DKIM وكان محاذيًا للعنوان المرئي. لا يشترط نجاح الاثنين. هذه المرونة مهمة عمليًّا: إعادة التوجيه غالبًا تكسر SPF لكنها تُبقي توقيع DKIM سليمًا، فيبقى DMARC ناجحًا عبر DKIM وحده.

المحاذاة نوعان:

• مُتساهلة (relaxed): تكفي مطابقة النطاق الأساسي (يُقبل النطاق الفرعي mail.example.com مع example.com).
• صارمة (strict): يجب تطابق النطاق حرفيًّا.

قراءة سجل DMARC

يُنشر السجل عند _dmarc.example.com:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100; sp=reject; fo=1"

السياسات الثلاث — من المراقبة إلى الرفض

• p=none — لا إجراء؛ الرسالة تُسلَّم كالمعتاد. هدفه الوحيد المراقبة وجمع التقارير. إنه نقطة البداية، لا نقطة النهاية.
• p=quarantine — الرسالة الفاشلة تُحوَّل إلى مجلد الرسائل غير المرغوبة (Spam).
• p=reject — الرسالة الفاشلة تُرفض قبل التسليم. هذا وحده يمنح حماية حقيقية من الانتحال.

الخطأ الأكثر شيوعًا: التوقّف عند p=none والاعتقاد أن “لدينا DMARC”. سجل p=none يراقب ولا يحمي؛ المهاجم لا يزال قادرًا على انتحال نطاقك بحرية. الهدف النهائي دائمًا هو p=reject بعد فترة مراقبة كافية.

كيف تجتمع الطبقات الثلاث معًا

الأدق أن نفهمها كأدوار متكاملة، لا بدائل:

إهمال أي واحدة يترك ثغرة: قد تجتاز SPF وتُنتحل مع ذلك في العنوان المرئي؛ وقد يجتاز DKIM وتُنتحل الهوية أيضًا. DMARC وحده هو الذي يفحص المحاذاة، لكنه بلا SPF وDKIM هشّ، لأنه يبني حكمه على نتائجهما.

للتحقق من إعدادات أي نطاق يدويًّا، هذه الأوامر أساسية:

# فحص سجل SPF
dig +short TXT example.com

# فحص مفتاح DKIM (استبدل mail بالمُحدِّد الفعلي)
dig +short TXT mail._domainkey.example.com

# فحص سجل DMARC
dig +short TXT _dmarc.example.com

الطبقات المتقدمة: ما بعد الثلاثية الأساسية

الثلاثية تعالج الهوية. لكن يبقى ثلاث ثغرات: إعادة التوجيه تكسر المصادقة، ونقل الرسالة قد يجري بلا تشفير، والمستخدم لا يملك إشارة بصرية للثقة. هذه الطبقات تعالجها بالترتيب.

ARC — إنقاذ المصادقة عبر الوسطاء

Authenticated Received Chain (ARC) يحلّ مشكلة “DMARC الذي يكسر إعادة التوجيه”. عندما تمرّ الرسالة عبر وسيط شرعي (قائمة بريدية، خدمة إعادة توجيه)، قد يُعدّل الوسيط الرسالة فتفشل فحوص المصادقة الأصلية. يقوم ARC بـ ختم نتائج المصادقة الأصلية قبل التعديل، فيستطيع الخادم النهائي—إن كان يثق بالوسيط كـ “خاتم ARC موثوق”—أن يعتمد النتيجة الأصلية بدل رفض الرسالة ظلمًا. ARC يعالج مشكلة تشغيلية حقيقية، لكن اعتماده لا يزال محدودًا نسبيًّا.

MTA-STS وTLS-RPT — تأمين النقل نفسه

الطبقات السابقة كلها عن الهوية. لكن ماذا عن الاتصال بين الخوادم؟ منذ 1982 كان بإمكان الخوادم التخاطب بنص صريح غير مشفّر، ما يفتح الباب لهجمات تخفيض التشفير (Downgrade) والوسيط (Man-in-the-Middle).

MTA-STS (Mail Transfer Agent Strict Transport Security) يمثّل لـ SMTP ما يمثّله HSTS لـ HTTPS: سياسة تقول للخوادم المُرسِلة إليك “يجب أن تخاطبني عبر TLS بشهادة صالحة؛ وإن تعذّر التشفير، فلا تُرسل بنص صريح—بل افشل”. يتطلّب ثلاثة مكوّنات:

1. سجل DNS عند mta-sts.example.com _:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260701T000000Z"

2. ملف سياسة يُستضاف عبر HTTPS على

https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

3. شهادة TLS صالحة على خوادم البريد.

الوضع mode يتدرّج: testing (يراقب دون رفض)، ثم enforce (يرفض الاتصالات غير المشفّرة). حذارِ: تفعيل enforce مع تهيئة خاطئة يرفض بريدًا شرعيًّا—لذا ابدأ دائمًا بـ testing.

TLS-RPT (TLS Reporting) هو شريك MTA-STS في المراقبة. يمنحك تقارير يومية عن نجاح أو فشل اتصالات TLS الواردة، فترى المشاكل قبل أن تُسقط بريدًا حقيقيًا. ولذلك لا تُفعِّل MTA-STS بدون TLS-RPT، وإلا ستكون “محميًّا لكن لا تعلم ماذا يحصل”:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

بديل أو مُكمِّل: DANE. إن كان نطاقك مفعّلًا عليه DNSSEC، يمكنك استخدام DANE (عبر سجلات TLSA) لتحقيق هدف مشابه لتأمين النقل، بالاعتماد على DNSSEC للتحقق من الشهادة بدل سلطة إصدار خارجية. المعايير الوطنية في بعض الدول تفرض الثلاثة (DANE + MTA-STS + TLS-RPT) معًا كممارسة فضلى.

BIMI — الهوية البصرية وشعار العلامة في صندوق الوارد

Brand Indicators for Message Identification (BIMI) هو الطبقة المرئية: يعرض شعار علامتك التجارية الموثّق بجانب رسائلك في صناديق الوارد الداعمة. يحوّل المصادقة من “مشروع أمني” إلى “أصل تسويقي”.

لكن شروطه صارمة عمدًا:

• DMARC عند الإنفاذ (p=quarantine أو p=reject)—بلا ذلك لا يظهر الشعار إطلاقًا.
• الشعار بصيغة SVG Tiny Portable/Secure.
• علامة تجارية مسجّلة رسميًّا.
• شهادة علامة موثّقة (Verified Mark Certificate – VMC) من سلطة معتمدة—وهي شرط لدى مزوّدين كبار مثل Gmail، وتُجدَّد سنويًّا.

default._bimi.example.com.  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

متطلبات مزوّدي البريد الكبار: لم يعد الأمر اختياريًّا

ما كان “ممارسة فضلى موصى بها” أصبح شرطًا إلزاميًّا للوصول إلى صندوق الوارد. منذ فبراير 2024، فرض Google وYahoo متطلبات على المُرسِلين بكثافة (Bulk Senders)—المعرَّفين بمن يرسل 5,000 رسالة أو أكثر يوميًّا إلى عناوين المستخدمين—ثم لحقت Microsoft بمتطلبات مماثلة في مايو 2025.

الملخّص العملي للمتطلبات:

1. مصادقة كاملة: SPF وDKIM معًا، وسجل DMARC بحدٍّ أدنى p=none، مع محاذاة سليمة.

2. إلغاء اشتراك بنقرة واحدة (One-Click Unsubscribe): وفق المعيار RFC 8058، مع احترام طلب الإلغاء خلال يومين. (الرسائل المعاملاتية كإعادة تعيين كلمة المرور مُستثناة.)

3. معدّل شكاوى منخفض: يجب إبقاء معدّل الإبلاغ عن السبام دون 0.1%، وتجنّب بلوغ 0.3% الذي يُعدّ “منطقة خطر” تؤدي إلى الحظر.

الأهم أن الإنفاذ لم يعد رمزيًّا. في البداية كانت الرسائل غير الممتثلة تُؤجَّل بأخطاء مؤقتة، لكن مع أواخر 2025 انتقل كبار المزوّدين إلى الرفض الدائم عبر خطأ SMTP الشهير 550—أي أن الرسالة لا تصل حتى إلى مجلد السبام، بل تُرفض عند البوابة. من لم يمتثل، لا يصل بريده. النقطة ببساطة: المصادقة صارت الحد الأدنى لدخول صندوق الوارد، لا ميزة إضافية.

ملاحظة على التطوّر المستمر: تعمل مجموعة عمل IETF على تحديث مواصفة DMARC (المعروف بـ DMARCbis) لترقيتها إلى معيار مقترح رسمي، مع تحديثات ذات صلة على DKIM لمعالجة هجمات “إعادة التشغيل (Replay)”. هذه المعايير تتطوّر باستمرار؛ ننصح دائمًا بمراجعة وثائق IETF والصفحات الرسمية لكل مزوّد للاطّلاع على أحدث التفاصيل قبل أي نشر إنتاجي.

كيف تردع هذه الطبقات الاحتيال فعليًّا

لنترجم النظرية إلى سيناريوهات هجوم حقيقية ونرى أين تنكسر كل حيلة:

السيناريو 1 — انتحال مباشر لنطاقك. يفتح المهاجم اتصال SMTP ويضع From: [email protected] من خادمه الخاص. مع p=reject، تفشل المحاذاة (لا SPF ولا DKIM يعودان لنطاقك)، فتُرفض الرسالة قبل أن تصل أحدًا. الحماية: DMARC عند الإنفاذ.

السيناريو 2 — تلاعب بالمحتوى في الطريق. يعترض المهاجم رسالة شرعية ويبدّل رقم الحساب المصرفي في نصها. يكسر هذا التعديل بصمة DKIM، فتفشل الرسالة عند المستقبِل. الحماية: DKIM.

السيناريو 3 — تخفيض التشفير للتنصّت. يجلس المهاجم بين خادمين ويجبرهما على التخاطب بنص صريح ليقرأ المحتوى. مع MTA-STS في وضع enforce، يرفض الخادم المُرسِل التخاطب بلا TLS، فتفشل حيلة التخفيض. الحماية: MTA-STS + TLS-RPT.

السيناريو 4 — تصيّد عبر نطاق فرعي مهمل. ينتحل المهاجم news.yourcompany.com ظنًّا أن سياستك تغطي النطاق الرئيسي فقط. مُعامِل sp=reject في سجل DMARC يغلق هذا الباب لكل النطاقات الفرعية دفعةً واحدة. الحماية: مُعامِل sp في DMARC.

السيناريو 5 — خداع بصري. حتى مع كل ما سبق، قد يتردّد المستخدم أمام رسالة شرعية لأنه اعتاد الحذر. ظهور شعار علامتك الموثّق بجانب الرسالة (BIMI) يمنحه إشارة ثقة فورية يصعب على المحتال تزويرها لأنها تتطلب اجتياز كامل طبقات الحماية. الحماية: BIMI.

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

خطة النشر المرحلية الآمنة

النشر الدفعي لكل شيء دفعةً واحدة هو الطريق الأسرع لرفض بريدك الشرعي. اتّبع هذا التسلسل، ولا تقفز فوق أي مرحلة:

1. أرسِ الأساس (SPF + DKIM). اضبط SPF بـ -all بعد التأكد من إدراج كل مصادر إرسالك الشرعية، وفعّل توقيع DKIM بمفتاح 2048 بت. تحقّق بأوامر dig.

2. ابدأ DMARC بالمراقبة. انشر p=none مع rua. راقب التقارير التجميعية أسبوعين إلى أربعة أسابيع لاكتشاف أي مصدر شرعي يفشل (منصات تسويق، أنظمة فوترة، خدمات طرف ثالث نسيتها).

3. تدرّج نحو الإنفاذ. انتقل إلى p=quarantine (يمكن استخدام pct لتطبيقها تدريجيًّا على نسبة من البريد)، وراقب، ثم انتقل إلى p=reject. لا تنسَ sp=reject لتغطية النطاقات الفرعية.

4. أمّن النقل. انشر MTA-STS في وضع testing مع TLS-RPT، راقب التقارير أسبوعين إلى أربعة أسابيع لإصلاح أي خلل في الشهادات أو سجلات MX، ثم انتقل إلى enforce.

5. أضِف الهوية البصرية (اختياري). بعد بلوغ DMARC مرحلة الإنفاذ، جهّز شعار SVG وشهادة VMC وانشر سجل BIMI.

6. راقب باستمرار. المصادقة ليست إعدادًا يُضبط مرة ويُنسى. المصادر الجديدة والخدمات المضافة وانحراف التهيئة مخاطر مستمرة—راجع تقارير DMARC أسبوعيًّا ودقّق المكدّس ربع سنويًّا.

الخلاصة والخطوة التالية

بروتوكول SMTP وُلد بلا هوية، ومصادقة البريد هي الطبقة التي تُصلح هذا العيب البنيوي المستمر منذ أربعة عقود. الثلاثية الأساسية—SPF وDKIM وDMARC—تُثبت من أنت وتمنع انتحالك، والطبقات المتقدمة—ARC وMTA-STS وTLS-RPT وBIMI—تسدّ ما تبقّى من ثغرات في إعادة التوجيه والنقل والثقة البصرية.

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

خطوتك التالية العملية: افحص نطاقك الآن بأوامر dig الثلاثة أعلاه. إن وجدت DMARC غائبًا أو عالقًا عند p=none، فأنت لا تزال قابلاً للانتحال اليوم. ابدأ بنشر p=none مع rua، وراقب التقارير، وامضِ نحو الإنفاذ.

ملاحظة: تتطوّر معايير مصادقة البريد ومتطلبات المزوّدين باستمرار، وبعض الأرقام والمواعيد الواردة هنا مرتبطة بلحظة النشر. للاطّلاع على أحدث التفاصيل، راجع المصادر الرسمية (IETF، وصفحات Postmaster لدى Google وYahoo وMicrosoft) والصفحات الحيّة لشركة إليفانتي.

مقالات ذات صلة

المساعد الذكي من إليفانتي

نظام أسماء النطاقات (DNS): كيف يعمل دفتر هاتف الإنترنت، وكيف تدير سجلاتك باحترافية

في كل مرة تكتب فيها عنوان موقع في المتصفح وتضغط Enter، تحدث خلف الكواليس سلسلةٌ من الاستعلامات عبر بنيةٍ تحتيةٍ موزّعةٍ حول العالم، تنتهي في…

60.3% match يونيو 29, 2026

النطاقات (Domains): الدليل الشامل لفهم بنية الإنترنت من الجذر إلى التسجيل والإدارة

كل ما تحتاج معرفته عن النطاقات: ما هي، وكيف نشأت الحاجة إليها، وآلية عملها داخل نظام أسماء النطاقات، ومنظومة تسجيلها وإدارتها وتأمينها، مع نظرة على…

58.7% match يونيو 30, 2026

المقال التالي

المساعد الذكي من إليفانتي

تحكم DNS محترف

أسرار النطاقات

بريدك المهني الآن

تعرف على التصيد