מדריך הטמעת DMARC ב-Microsoft 365: מ-none ל-reject בלי לשבש את הדואר

By Mirko Peters · 2026-10-21

למדו כיצד להטמיע DMARC ב-Microsoft 365 בצורה בטוחה, משלב הניטור ועד למדיניות דחייה מחמירה, מבלי לפגוע באספקת הדואר הלגיטימי של הארגון.

Automatically translated with AI from the original post. Read the English original

הפעלת פרוטוקולי אימות דואר אלקטרוני בדייר Microsoft 365 יכולה להרגיש כמו נטרול פצצה, אם מבצעים את הצעדים בסדר לא נכון. מדריך השלבים הזה להטמעת DMARC ב-Microsoft 365 מלווה מנהלי IT במעבר בטוח משלב הניטור הראשוני ועד למדיניות דחייה מחמירה, בלי להפיל בטעות לתוך הריק חשבוניות עסקיות לגיטימיות, קמפיינים שיווקיים או התראות אוטומטיות.

עיקרי הדברים

• יש להטמיע אימות דואר אלקטרוני תמיד בסדר הנכון: קודם SPF, אחר כך DKIM, ולבסוף DMARC.
• התחילו את מדיניות ה-DMARC עם p=none כדי לנטר את התעבורה ולמפות את כל שירותי השליחה הלגיטימיים והלא מורשים.
• הימנעו מחריגה ממגבלת 10 הבדיקות ב-SPF על ידי ביקורת זהירה של שירותי צד שלישי כמו פלטפורמות שיווק ומערכות תמיכה.
• עברו בהדרגה דרך שלבי הסגר ואחוזי יישום לפני שמגיעים למדיניות דחייה מחמירה.
• הגדירו את דוחות הצבירה כך שיופנו לתיבת דואר משותפת ולא לתיבת הדואר של אדם מסוים, כדי להבטיח נראות רציפה.

כלל הזהב של סדר ההטמעה

אם תזכרו עיקרון אחד במהלך פרויקט החיזוק האבטחתי, שיהיה זה סדר ההטמעה. ארגונים נתקלים בבעיות לעיתים קרובות משום שהם מיישמים את התקנים בסדר הפוך. מכיוון שמערכת הדואר נשענת על פרוטוקולים מדור קודם כמו SMTP, שנבנו על בסיס אמון ולא על אימות, הצבת מדיניות אכיפה מחמירה לפני מיפוי התשתית תגרום לכשל בדואר הלגיטימי.

הרצף הנכון בונה רשת ביטחון בכל שלב. עליכם לקבוע את רשימת האורחים, להחיל את אטמי האבטחה שלכם, ורק לאחר מכן להכניס את השופט שמחבר את הכול. דילוג קדימה משאיר אתכם בלי ידיעה ברורה על זרמי הדואר שלכם, וניחושים הם הדרך המהירה ביותר לגרום לכך שהדואר של החברה ייחסם על ידי נמענים חיצוניים.

שלב ראשון: הקמת SPF והסכנות במגבלות החיפוש

הצעד הראשון שלכם הוא לפרסם רשומת Sender Policy Framework (SPF) בשורש הדומיין. דמיינו זאת כרשימת האורחים בכניסה למועדון exclusive. היא מציינת במפורש אילו שרתים רשאים לשלוח הודעות הנושאות את שם הדומיין שלכם.

בעת כתיבת רשומת SPF ראשונית ל-Microsoft 365, סיימו אותה עם soft fail (~all) ולא עם hard fail (-all). כך אתם אומרים לשרתים המקבלים להתייחס לדואר לא מורשה בחשדנות במקום לדחות אותו מיד. תקופת הביניים הזו נותנת לכם מקום לאתר שירותים שאולי פספסתם.

הימנעות מהמלכודת של עשר הבדיקות

מוקש משמעותי בניהול SPF הוא מגבלת 10 החיפושים המחמירה. בכל פעם ששרת מקבל מעבד את רשומת ה-SPF שלכם ונתקל במנגנון שדורש שאילתת DNS נפרדת, כמו פלטפורמת אוטומציה שיווקית של צד שלישי, מערכת תמיכת לקוחות או ספק שכר, הוא צורך חיפוש אחד מהתקציב שלכם.

אם הארגון שלכם מוסיף יותר מדי שירותים חיצוניים, סך החיפושים שלכם יחרוג מעשרה, וכתוצאה מכך כל הערכת ה-SPF תיכשל. סריקות של מיליוני דומיינים מראות שאחוז לא מבוטל מהחברות שוברות בשוגג את האבטחה של הדואר שלהן בדרך זו. בצעו ביקורת קבועה של השירותים כדי לשמור על טביעת SPF קלה.

שלב שני: הפעלת DKIM ב-Microsoft 365

אחרי שרשימת הנמענים שלכם פורסמה, צריך דרך להבטיח שהודעות לא יעברו שינוי במהלך השליחה. DomainKeys Identified Mail (DKIM) פועל כמו חותם שעווה דיגיטלי שנחתם על כל הודעה יוצאת. הוא כולל חתימה קריפטוגרפית שמכסה את שורת הנושא, גוף ההודעה וכתובת השולח הגלויה (From).

ב-Microsoft 365, הודעות שנשלחות מהדומיין הברירת מחדל שלכם מסוג onmicrosoft.com נחתמות אוטומטית. עם זאת, דומיין העסק המותאם אישית שלכם נשאר ללא חתימה עד שתגדירו DKIM במפורש במרכז הניהול. כדי לעשות זאת כראוי, יש ליצור שני מצביעי selector (selector1 ו-selector2) ב-DNS הציבורי שלכם. הגדרת שני המצביעים מאפשרת ל-Microsoft לסובב מפתחות חתימה בהמשך בצורה חלקה, ללא השבתה.

Google וספקים גדולים נוספים ממליצים לתת ל-SPF ול-DKIM לפעול בצורה תקינה למשך 48 שעות לפחות לפני שנוגעים ב-DMARC. תקופת ההתייצבות הזו מבטיחה שהבדיקות הבסיסיות שלכם יציבות לפני שהשופט מגיע.

שלב שלישי: פריסת DMARC במצב ניטור

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) פועל כשופט. הוא אינו מבצע בדיקה משלו על תוכן ההודעה; במקום זאת, הוא בוחן את תוצאות בדיקות ה-SPF וה-DKIM שלכם ובודק אם הן מיושרות עם שם הדומיין הגלוי בשורת From.

כאשר מפרסמים לראשונה את רשומת ה-TXT של DMARC בכתובת _dmarc.yourdomain.com, פרמטר המדיניות (policy) צריך להיות מוגדר במצב ניטור בלבד: p=none. כשקוראים את הרשומה משמאל לימין, היא אומרת לשרתים המקבלים: "זוהי רשומת DMARC. בשלב זה אין לנקוט בצעדי אכיפה אם הבדיקות נכשלות, ויש לשלוח דוחות מצטברים לכתובת הדוא"ל הזו."

לעולם אל תדלגו על שלב הניטור הזה. דוחות צבירה יומיים (RUA) שנשלחים כקבצי XML יחשפו כל שירות, לגיטימי או זדוני, ששולח דואר בשם הדומיין שלכם. נתבו את הדוחות האלה לתיבת דואר משותפת ומנוטרת ולא לתיבת הדואר של עובד בודד, כדי שלא ילכו לאיבוד בזמן חופשות.

שלב רביעי: מעבר מהסגר לדחייה

אחרי שהסקירות השבועיות שלכם מראות שכל זרמי הדואר הלגיטימיים עוברים יישור באופן תקין, הגיע הזמן להדק את הברגים. פרמטר המדיניות של DMARC עובר בין שלוש עמדות תפעוליות נפרדות:

• None (p=none): מגדל השמירה. צפייה בלבד, המשמשת לביקורת ולאיסוף נתוני דוחות מצטברים.
• Quarantine (p=quarantine): תווית האזהרה. מורה לשרתים המקבלים לסמן הודעות חשודות או כושלות, בדרך כלל על ידי ניתובן ישירות לתיקיית הזבל או הספאם של הנמען.
• Reject (p=reject): הדלת הנעולה. מורה למקבלים להשמיט לגמרי הודעות שלא אומתו או מזויפות, לפני שהן מגיעות לתיבת הדואר.

כדי לבצע את המעבר בצורה חלקה ככל האפשר, השתמשו בכפתורי האחוזים של DMARC (pct=). ניתן לאכוף הסגר או דחייה על שבריר קטן מהדואר הכושל, כגון 10%, אחר כך 25% ואז 50%, לפני שמתחייבים באופן מלא. ההגדלה ההדרגתית הזו מונעת שיבוש עסקי פתאומי אם כלי ניוזלטרים פורץ לא צפוי ייכשל.

סיכום

הגנה על תשתית הדואר האלקטרוני של הארגון מפני Business Email Compromise (BEC) והתחזות לדומיין דורשת סבלנות ואסטרטגיית פריסה מתודית. באמצעות הקמת SPF, הפעלת DKIM והגברה זהירה של מדיניות DMARC משלב הצפייה ועד לדחייה מחמירה, אתם שומרים על שם החברה ומבטיחים שההודעות האותנטיות שלכם תמיד יגיעו ליעדן.

כדי להעמיק במנגנוני פרוטוקולי אימות הדואר האלקטרוני, האזינו לפרק המלא לתובנות מומחים, לאסטרטגיות ארכיטקטורה מעשיות ולהדרכה מעשית לדייר Microsoft 365 שלכם.

שאלות נפוצות

כמה זמן כדאי להשאיר את מדיניות DMARC על none ב-Microsoft 365?

Google ומומחי אבטחת דואר אלקטרוני ממליצים להשאיר את מדיניות DMARC על p=none למשך שבוע לפחות. פרק זמן זה מבטיח שתאספו דוחות צבירה מקיפים הכוללים זרמי דואר עסקי שבועיים ומחזוריים.

מדוע צריך להפעיל DKIM לפני שמפעילים DMARC?

DKIM חותם על ההודעה בצורה קריפטוגרפית ונשאר איתה, וכך שורד תרחישי העברת דואר שלעיתים קרובות שוברים את SPF. הגדרה תקינה של גם SPF וגם DKIM מבטיחה שיישור DMARC יעבור באופן אמין.

האם Microsoft 365 שולחת דוחות DMARC פורנזיים?

לא. בעוד ש-Microsoft 365 ישלח דוחות מצטברים (RUA) לכתובת הדיווח שהגדרתם, הוא לא ייצור ולא ישלח דוחות פורנזיים (RUF), גם אם הם מבוקשים ברשומת ה-DMARC שלכם.

מה קורה אם אפרסם שתי רשומות DMARC עבור הדומיין המותאם אישית שלי?

פרסום של מספר רשומות DMARC גורם לשרתי הדואר המקבלים להתבלבל ולא להחיל שום מדיניות, וכך מבטל לחלוטין את מאמצי האבטחה שלכם. ודאו תמיד שלדומיין יש בדיוק רשומת DMARC TXT אחת.