اقفل باب Email Spoofing على دومين شركتك

الخلاصة: مش هتقدر تمنع كل واحد على الإنترنت من إنه يحاول ينتحل اسم شركتك، بس تقدر تخلي انتحال الدومين الحقيقي بتاعك أصعب بكتير. لما SPF وDKIM وDMARC يبقوا متظبطين ومعاهم Enforcement حقيقية، ومراجعة لكل Sender، ومراقبة مستمرة، أغلب محاولات الـ spoofing المباشرة تقدر تقع قبل ما توصل للـ inbox.

الأول، لازم نفهم Email spoofing معناها إيه فعلاً

الـ Email من أساسها Technology بتثق زيادة شوية.

Attacker يقدر يعمل Message شكلها جاية من finance@yourcompany.com أو الـ CEO أو الـ support team أو أي Address على الدومين بتاعك، من غير ما يكون دخل على Email account عندك أصلاً.

وده مش معناه تلقائياً إن الـ mailbox اتهكرت.

ممكن يكون الشخص بس زوّر الـ From address اللي بتظهر للمستلم.

الفرق ده مهم، لأن علاج Account compromised مختلف عن علاج Domain spoofing.

نوع الهجوم	إيه اللي حصل	أهم دفاع
Domain spoofing	الـ attacker زوّر دومينك في الـ From address	SPF وDKIM وDMARC
Display-name spoofing	استخدم اسم موظف عندك من Email تانية	Impersonation filtering وتوعية المستخدمين
Lookalike domain	سجل Domain شبه دومينك	Domain monitoring وAnti-phishing controls
Mailbox compromise	دخل على Account حقيقية	MFA وAccount security وSession controls

SPF وDKIM وDMARC مهمين جداً، بس أساساً بيحلوا أول مشكلة. مش Magic solution لكل أنواع الانتحال.

1. SPF بتقول للعالم مين مسموح له يبعت باسم دومينك

SPF أو Sender Policy Framework هي DNS record بتحدد الـ systems المسموح لها تبعت Email باسم الدومين.

لو شركتك بتستخدم Google Workspace أو Microsoft 365 أو CRM أو Email marketing platform أو الموقع أو Ticketing system أو App تانية، الـ senders دي لازم تبقى محسوبة ومتظبطة صح.

SPF policy ناضجة غالباً بتنتهي بـ Hard fail:

v=spf1 include:your-authorised-sender.example -all

الجزء المهم هو -all. معناه إن المصادر اللي مش موجودة في الـ policy مش مسموح لها تبعت باسم الدومين.

بس SPF لوحدها مش كفاية.

SPF بتراجع الـ technical envelope sender المستخدم أثناء توصيل الـ email. الـ address اللي المستخدم شايفها في From ممكن تكون مختلفة. وده واحد من أهم الأسباب اللي DMARC اتعملت علشانها.

ما تفضلش تزود Services في SPF وخلاص

كل Third-party tool تطلب منك تضيف SPF include جديدة لازم تتراجع.

CRM قديمة، Newsletter platform بطلت تستخدمها، Server اتقفلت، أو SaaS tool اتجربت مرة ممكن تفضل Authorised بعد سنين لو محدش شالها.

SPF المفروض تعكس Infrastructure الشركة دلوقتي، مش تاريخ كل Tool استخدمتها من يوم ما الشركة بدأت.

2. DKIM بتثبت إن Infrastructure مصرح لها وقّعت الـ Message

DKIM أو DomainKeys Identified Mail بتحط Cryptographic signature على الـ outgoing messages.

الـ sending system بتمضي الـ message بـ Private key، وإنت بتنشر الـ public key المقابلة في DNS. الـ receiving server تقدر بعدها تتأكد إن الـ signature سليمة.

وده بيدي المستلم طريقة إضافية يعرف بيها إن الـ message فعلاً عدت من Infrastructure مسموح لها توقّع باسم الدومين.

استخدم DKIM keys قوية، وثّق الـ selectors، شيل القديمة اللي مبقتش مستخدمة، واعمل Rotation وقت ما يكون مناسب.

والأهم، اتأكد إن أهم الـ senders فعلاً بتعمل Signing بدومينك، بدل ما كل Vendor تعتمد بالكامل على الدومين بتاعها.

3. DMARC هي المكان اللي حماية الـ spoofing بتبقى جد

DMARC بتربط الـ visible From address بـ SPF وDKIM.

علشان DMARC تعدي، لازم على الأقل Authentication method واحدة تعدي ويبقى فيه Alignment مناسب مع الدومين اللي المستلم شايفه.

وبعد كده DMARC بتقول للـ receiving mail systems تعمل إيه في الرسائل اللي فشلت.

p=none: راقب بس من غير Enforcement.
p=quarantine: اطلب إن الرسائل الفاشلة تتعامل بشكل مشبوه.
p=reject: اطلب إن الرسائل الفاشلة تترفض.

لو دومينك قاعد للأبد على p=none، إنت عندك Monitoring، بس الحماية نفسها لسه مش قوية.

الهدف في Deployment ناضجة غالباً يبقى Enforcement بعد ما تتأكد إن كل Sender حقيقية عندك متعرفة ومتظبطة صح.

4. DMARC strict قوية، بس لازم الـ Alignment تشتغل

إنك تنشر p=reject مش كفاية لو الـ legitimate services عندك متظبطة غلط.

تخيل الـ CRM بتاعتك بتبعت:

From: sales@yourcompany.com

بس لا SPF identity ولا DKIM signature عاملين Alignment صح مع دومينك.

DMARC بتاعتك ممكن تعتبر الرسالة غير موثقة بشكل صحيح، والـ receiving server ترفضها.

علشان كده الانتقال من Monitoring لـ Enforcement لازم ييجي بعد Sender audit.

اعمل Map لكل System بتبعت Email باسم دومينك:

Employee mailboxes.
CRM systems.
Email marketing platforms.
Help desks.
Accounting وInvoicing systems.
Website contact forms.
E-commerce notifications.
Appointment platforms.
Cloud applications.
Internal software.

كل واحدة فيهم محتاجة Authentication strategy.

5. الموقع والـ Apps جزء من Email perimeter بتاعتك

شركات كتير بتأمن Employee email كويس جداً وتنسى الـ applications اللي بتبعت Automated messages.

الموقع يبعت Password reset. الـ CRM تبعت Proposal. الـ E-commerce platform تبعت Order confirmation. Custom system تبعت Alerts. Support platform تبعت Tickets.

لو الـ systems دي بتستخدم دومينك، يبقى هي جزء من Email infrastructure.

وده مهم جداً لما الشركات تستثمر في تطوير Software مخصصة. Email authentication لازم تدخل كـ Infrastructure requirement من وقت الـ implementation، مش حاجة نفتكرها بعد ما الـ emails تبدأ تدخل Spam.

ونفس الفكرة في تطوير المواقع. Contact forms والـ transactional notifications المفروض تتبعت من Infrastructure متوثقة صح، مش أي Mail function موجودة على الـ server وخلاص.

6. استخدم DMARC Reports بدل ما تخمّن

واحدة من أقوى مميزات DMARC هي الـ reporting.

Aggregate reports تقدر توريك أنهي Servers بتبعت Messages بتقول إنها من دومينك، وهل الرسائل دي بتعدي SPF وDKIM وDMARC ولا لأ.

وده بيكشف نوعين مختلفين جداً من المشاكل:

Legitimate service إنت نسيت تعمل لها Authentication صح.
Infrastructure بتحاول تنتحل دومين شركتك.

الـ raw reports مش ألطف حاجة في القراءة، علشان كده Companies كتير بتستخدم DMARC reporting platform تحولها لـ dashboards وalerts.

المهم مش اسم الـ tool. المهم إن فيه حد فعلاً بيراجع البيانات.

7. احمي الـ Subdomains كمان

إنك تقفل yourcompany.com كويس وتسيب الـ subdomains من غير Policy مناسبة ممكن يفتح مساحة ملهاش لازمة.

لو Attacker قدرت تنتحل billing.yourcompany.com أو support.yourcompany.com، ناس كتير هتشوف اسم البراند جوه الدومين وتفترض إن الرسالة حقيقية.

DMARC تقدر تشمل Subdomain policy باستخدام sp=.

لو الـ subdomains مش المفروض تبعت Email، ما تسيبهاش Permissive من غير سبب.

وفي Infrastructure أكبر، ممكن كمان تفصل Senders بشكل متعمد. Marketing mail على Subdomain، Transactional mail على واحدة تانية، وCorporate employee mail على الدومين الأساسي.

ده يخلي الـ authentication والـ reputation والـ troubleshooting وإدارة الـ vendors أسهل.

8. اقفل الـ Domains اللي مش المفروض تبعت Email أصلاً

Companies كتير بتملك Defensive domains أو Domains قديمة أو Campaign domains أو Product domains لمجرد حماية الاسم.

لو Domain مش المفروض تبعت Email، قول ده بوضوح.

SPF بالشكل ده:

v=spf1 -all

بتقول إن مفيش Server مسموح لها تبعت Email للدومين ده.

ومعاها DMARC reject policy تقدر تضيف Layer تانية للرسائل اللي بتحاول تستخدم الدومين في الـ visible From.

ما تسيبش Domain مش مستخدمة في الإرسال من غير Mail policy لمجرد إن محدش عندك بيستخدمها.

9. Google Workspace أو Microsoft 365 مش هيصلحوا كل حاجة أوتوماتيك

نقل Email الشركة لـ Provider كبيرة خطوة مفيدة جداً للأمان والإدارة، بس تغيير الـ provider مش هيمنع شخص من إنه يحاول يكتب دومينك في From field مزورة.

إنت لسه محتاج DNS authentication.

Google Workspace وMicrosoft 365 وغيرهم يقدروا يعملوا DKIM signing ويوفروا Anti-phishing controls قوية، بس SPF وDKIM وDMARC لازم يفضلوا بيعكسوا طريقة الشركة الفعلية في الإرسال.

لو DNS policy ضعيفة، مجرد إنك بتدفع في Mailbox أقوى مش هيعمل DMARC قوية بدالك.

10. DMARC مش بتحميك من Lookalike domains

هنا بيحصل لخبطة عند Companies كتير.

لو الدومين الحقيقي هو:

yourcompany.com

Attacker تسجل:

yourcornpany.com

مع تغيير بسيط في الحروف.

DMARC بتاعتك ملهاش أي سلطة على الدومين الجديدة.

الـ attacker مالكاها. وممكن كمان تعمل SPF وDKIM وDMARC ممتازين للدومين المزيفة.

ده اسمه Lookalike أو Cousin-domain attack.

الحماية هنا ممكن تشمل Monitoring للدومينات الشبيهة باسم البراند، تسجيل أهم الـ variants بنفسك، Inbound impersonation detection، مراقبة Certificate activity، وتدريب الفريق يبص على الـ sender domain الفعلية بدل الـ display name بس.

11. DMARC كمان مش هتمنع Display-name spoofing

الـ attacker مش لازم تستخدم دومينك أصلاً.

ممكن تبعت من:

randomaccount@gmail.com

وتكتب الـ display name:

Ahmed Hassan, CEO

على Mobile email app، الاسم ممكن يبقى ظاهر أكتر بكتير من الـ address الحقيقية.

DMARC مش تقدر تمنع حد يستخدم اسم شخص.

هنا محتاج Inbound anti-impersonation controls وتوعية للموظفين وFinancial approval process واضحة وسياسات Mail security مناسبة.

12. احمي الـ Accounts الحقيقية كمان

Spoofing مزعجة. بس Compromised mailbox أسوأ.

لو Attacker دخلت فعلاً على Account المدير أو الـ finance، الـ email ممكن تعدي SPF وDKIM وDMARC عادي، لأنها فعلاً اتبعت من Infrastructure مصرح لها.

علشان كده Email authentication لازم تبقى جنب Identity security قوية.

فعّل Multi-factor authentication.
استخدم Phishing-resistant authentication لما يكون عملي.
راجع Suspicious sign-ins.
اقفل Old accounts بسرعة.
قلل Administrator privileges.
راجع Forwarding rules والـ mailbox delegates.
أمّن Password-reset processes.
درّب الـ finance والـ management ضد Payment-change fraud.

SPF وDKIM وDMARC بتحموا هوية الدومين. Account security بتحمي الناس الحقيقية اللي بتستخدمه.

13. ما تخليش Third-party vendors تبقى أضعف نقطة

كل SaaS platform مسموح لها تبعت باسم شركتك بتوسع Email supply chain.

قبل ما تسمح لـ vendor تستخدم Primary domain، شوف هل بتدعم Aligned DKIM، الـ return-path domains بتتدار إزاي، الـ authentication موثقة إزاي، وإيه اللي يحصل لما تبطل تستخدم الخدمة.

ولما يكون منطقي، افصل External senders على Dedicated subdomains بدل ما كل System تاخد نفس الهوية اللي المديرين والموظفين بيستخدموها.

وده بيبقى أهم كل ما الشركة توصل Marketing platforms وCRMs وSupport systems وCustom applications وAutomation ببعض. Digital ecosystem مترابطة محتاجة Governance واضحة لمين مسموح له يبعت Email، بنفس أهمية الـ APIs والـ integrations نفسها.

14. افهم p=reject معناها إيه فعلاً

النقطة دي مهمة جداً.

DMARC p=reject مش بتمنع الـ scammer إنها تدوس Send.

هي بتنشر Instruction للـ receiving mail systems إن الرسائل اللي تفشل DMARC المفروض تترفض.

الـ major receiving systems بيعتمدوا بقوة على Email authentication، بس في الآخر الـ receiving server هي اللي بتقرر هتعمل إيه بالـ message.

يعني حتى Domain متظبطة صح ما تقدرش تضمن إن Forged email مش هتتعمل في أي مكان على الإنترنت.

اللي تقدر تعمله إنك تخلي استخدام الدومين الحقيقي بتاعك من Infrastructure غير موثقة أصعب بكتير في الـ delivery.

15. ما تلخبطش Standards تانية مع Anti-spoofing

ممكن تقابل Technologies زي ARC وMTA-STS وTLS reporting وBIMI.

كلهم ممكن يبقوا مفيدين، بس بيحلوا مشاكل مختلفة.

ARC بتساعد تحافظ على Authentication information لما Intermediary موثوقة تعدل أو تعمل Forward للرسالة.
MTA-STS بتساعد تفرض Encrypted SMTP transport بين Mail systems بتدعمها.
TLS reporting بتساعد تكشف مشاكل تشفير الـ delivery.
BIMI ممكن تساعد في Verified brand presentation عند Mailbox providers بتدعمها.

ولا واحدة فيهم بديل عن SPF وDKIM وDMARC كأساس حماية الـ spoofing.

Email spoofing lockdown checklist

اعمل SPF واحدة صحيحة فيها الـ authorised senders بس.
اتحرك ناحية SPF hard fail بعد ما تتأكد إن الـ sender inventory صح.
فعّل DKIM لكل Sending platform مهمة.
استخدم Aligned DKIM بدومينك لما يكون ممكن.
انشر DMARC واجمع Aggregate reports.
ما تفضلش على p=none للأبد.
انقل لـ Enforcement بعد ما تراجع كل الـ legitimate senders.
احمي الـ unused والـ non-sending subdomains.
راجع SaaS services قديمة لسه عندها Sending authority.
راقب Lookalike domains بشكل منفصل.
فعّل Inbound impersonation protection للموظفين.
استخدم MFA قوية على الـ real mailboxes.
أمّن Email اللي طالعة من الموقع والـ CRM والـ support والـ transactional systems.
راجع DMARC reports باستمرار بدل ما تعتبر الـ setup مشروع مرة واحدة.

لو SPF وDKIM وDMARC بيعدوا بالفعل والـ policy عندك Reject، إنت عملت أهم جزء في حماية الدومين الحقيقي. الـ layer اللي بعدها تبقى Visibility، Governance للـ third-party senders، حماية الـ subdomains، Lookalike-domain defence، Inbound impersonation controls، وتأمين الـ accounts الحقيقية اللي أي Attacker هتفضل إنها تسرقها بدل ما تنتحلها.

FAQ: إزاي توقف Email spoofing

هل Email spoofing ممكن تتمنع 100%؟

تقدر تخلي Spoofing المباشرة للدومين الحقيقي أصعب بكتير باستخدام SPF وDKIM وDMARC مع Enforcement. بس مش هتقدر تمنع كل Display-name attack أو Lookalike domain أو Receiving server ضعيفة أو مجرد محاولة لإنشاء رسالة مزورة.

هل DMARC p=reject كفاية تمنع الـ spoofing؟

هي من أقوى Controls ضد Direct domain spoofing، بس لازم الـ legitimate senders عندك تعمل Authentication وAlignment صح. وكمان مش بتحمي من Similar domains أو Accounts حقيقية اتهكرت.

ليه ناس لسه تقدر تنتحل شركتي بعد ما عملت SPF؟

SPF لوحدها بتراجع الـ technical sending source ومش بتحمي الـ visible From identity بشكل كامل. علشان كده محتاج DKIM وDMARC معاها علشان تعمل Domain authentication وAlignment أقوى.

هل Google Workspace تمنع حد ينتحل دوميني؟

Google Workspace تقدر توفر Mail infrastructure قوية وDKIM signing وAnti-phishing controls، بس إنت لسه محتاج تظبط DNS authentication صح. نقل الـ email لـ provider جديدة لوحده مش هيوقف محاولة تزوير الدومين.

إزاي أحمي الشركة من Domains مزيفة شبه دوميني؟

DMARC ما تقدرش تتحكم في Domain حد تاني مالكها. راقب الـ lookalike registrations، سجل أهم الـ variants بنفسك لما يكون منطقي، استخدم Inbound impersonation detection، ودرّب الفريق يراجع الـ sender domain الحقيقية.

لو شركتك عندها كذا Website وCRM وEmail platform وSupport system وCustom application بيبعتوا Email، وإنت مش متأكد 100% مين فيهم مسموح له يستخدم الدومين، احجز استشارة مجانية مع Mighty Leap. نقدر نعمل Map للـ digital infrastructure، نحدد Authentication gaps، ونحوّل مجموعة Senders ملخبطة لـ System متحكم فيها.

رامي موسى

كاتب ومشرف

نبني علامات لا تُنسى عبر تطوير الويب والسيو والإعلانات المدفوعة و CRM.