תמונה: נוצרה באמצעות AI עבור מערכת ITPortal
כאשר משתמש ב-Microsoft 365 יכול לקבל דואר אבל כל הודעה יוצאת חוזרת עם השגיאה 550 5.1.8, אחת הסיבות הנפוצות היא חסימה אוטומטית של השולח. לפני שלוחצים על Unblock צריך לבדוק אם החשבון נפרץ, להחליף סיסמה, לבטל חיבורים חשודים ורק אז להסיר את ההגבלה.
Microsoft עשויה להוסיף תיבת דואר לרשימת Restricted entities כאשר היא מזהה חריגה ממגבלות שליחה או סימנים שמתאימים לדואר זבל. מבחינת המשתמש התופעה מבלבלת: Outlook נראה מחובר, הודעות נכנסות כרגיל, אבל כל ניסיון לשלוח מסתיים בדוח אי-מסירה.
איך מזהים שהחסימה מגיעה מ-Microsoft 365
הסימן הבולט הוא NDR עם הקוד 550 5.1.8 Access denied, bad outbound sender, ולעיתים מופיע הסבר שהכתובת נחשדת בשליחת ספאם. לפי התיעוד הרשמי של Microsoft, משתמש מוגבל נשאר מסוגל לקבל דואר אך אינו יכול לשלוח.
חשוב להבדיל בין מצב זה לבין תיבה מלאה, תקלה ב-Outlook, רשומת DNS שגויה או חסימה אצל יעד מסוים. אם השגיאה מופיעה מול כמה נמענים והקוד הוא 5.1.8, כדאי להתחיל ב-Restricted entities.
שלב ראשון: לאבטח את החשבון
חסימת שליחה היא לעיתים תוצאה של חשבון שנפרץ או של יישום שקיבל הרשאה ושולח הודעות בלי ידיעת המשתמש. שחרור מיידי ללא טיפול במקור עלול לגרום לחסימה חוזרת ולהמשך דליפת מידע.
- אפסו את סיסמת המשתמש לסיסמה חדשה וייחודית.
- ודאו שאימות רב-שלבי פעיל וששיטות האימות שייכות למשתמש.
- בטלו סשנים פעילים ובדקו מכשירים וכניסות חריגות ב-Microsoft Entra.
- בדקו כללי Inbox ו-Forwarding שלא נוצרו על ידי המשתמש.
- עברו על הרשאות אפליקציות ו-OAuth והסירו חיבורים לא מוכרים.
- בדקו את Sent Items ואת Message Trace כדי להבין מה נשלח ומתי.
בארגון שמנהל כמה תיבות, זה המקום לחבר בין טיפול נקודתי לבין ניטור קבוע. צוותי IT ושירותים מנוהלים כמו M-Challenge צריכים לוודא שהתראות על משתמש מוגבל מגיעות ליותר מאדם אחד ושיש נוהל תגובה ברור.
שלב שני: לפתוח את Restricted entities
היכנסו ל-Microsoft Defender בכתובת security.microsoft.com ועברו אל Email & collaboration > Review > Restricted entities. אפשר גם לפתוח ישירות את security.microsoft.com/restrictedentities.
אתרו את המשתמש, סמנו אותו ובחרו Unblock. Microsoft מציגה המלצות אבטחה לפני האישור. אל תדלגו עליהן: ודאו שהסיסמה שונתה, שהחשבון נמצא בשליטה ושמקור השליחה החריגה טופל. לאחר מכן המשיכו, אשרו את הסרת ההגבלה ושלחו הודעת בדיקה לנמען פנימי וחיצוני.
לפי Microsoft, ברוב המקרים ההגבלה מוסרת בתוך שעה, אך תקלה זמנית יכולה להאריך את התהליך עד 24 שעות. אין טעם ללחוץ שוב ושוב או ליצור כללים עוקפים בזמן שהשחרור מתעדכן.
אפשר גם דרך Exchange Online PowerShell
מנהלי מערכת שמעדיפים PowerShell יכולים להציג שולחים חסומים באמצעות Get-BlockedSenderAddress. לפני הסרה יש לזהות במדויק את ה-UPN או כתובת ה-SMTP ולוודא שהחשבון כבר אובטח. שימוש בפקודה אינו מחליף את בדיקת האירוע, אלא רק מספק דרך נוחה לעבוד בסביבה גדולה.
למה החסימה חוזרת
- הסיסמה הוחלפה אך סשנים או הרשאות אפליקציה זדוניות נשארו פעילים.
- תוכנת דיוור או סורק שולחים דרך תיבת משתמש במקום דרך מחבר מתאים.
- המכשיר המקומי נגוע או ש-Outlook כולל תוסף חשוד.
- כלל העברה חיצוני ממשיך להפיץ הודעות.
- הארגון חורג ממגבלות השליחה של השירות באופן קבוע.
אם הבעיה חוזרת, עצרו את השליחה ובדקו את הנתונים במקום להעלות מגבלות באופן עיוור. במקרים רבים החסימה היא ההתראה הראשונה לכך שמישהו משתמש בחשבון בניגוד למדיניות.
איך למנוע את האירוע הבא
ודאו שמדיניות ההתראה User restricted from sending email פעילה ושנמעני ההתראה מעודכנים. הפעילו אימות רב-שלבי, השתמשו בגישה מותנית בהתאם לרישוי ובדקו כניסות ממדינות או מכשירים לא צפויים. מומלץ גם להפריד בין תיבות משתמש לבין מערכות ששולחות כמות גדולה של דואר.
למי שמטפל באירועי התחזות דרך סביבת Microsoft, כדאי לקרוא גם את המדריך שלנו על מתחזים לתמיכת IT ב-Teams. בשני המקרים המטרה היא לא רק להחזיר את השירות, אלא להבין איך התוקף נכנס ולמנוע ממנו לחזור.
שאלות נפוצות
האם המשתמש עדיין יכול לקבל דואר בזמן החסימה?
כן. חסימת Restricted entities מתמקדת בשליחה החוצה, ולכן קבלת הדואר בדרך כלל ממשיכה.
כמה זמן לוקח לשחרר את החסימה?
Microsoft מציינת שברוב המקרים ההסרה מתבצעת בתוך שעה, אך במצבים זמניים התהליך עשוי להימשך עד 24 שעות.
האם מספיק לשנות סיסמה?
לא תמיד. צריך לבדוק גם סשנים פעילים, שיטות MFA, כללי דואר והרשאות אפליקציות. אחרת הגורם שיצר את השליחה החריגה עלול להישאר פעיל.
