הקמת אפליקציה והרשאות לשליחת דואר באמצעות Microsoft 365 ו-Microsoft Graph

הקמת הרשאות לשליחת דואר דרך Microsoft 365 באמצעות Microsoft Graph

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

הרשאות נדרשות לביצוע התהליך:

  • Global Administrator

  • Application Administrator

  • Cloud Application Administrator (ברוב המקרים)


שלב 1 – כניסה לפורטל Azure

היכנס לכתובת:

https://portal.azure.com

התחבר באמצעות חשבון בעל הרשאות מנהל.

מה הפעולה מבצעת?
גישה לממשק הניהול של Microsoft Entra ID (לשעבר Azure Active Directory), שבו מנוהלות אפליקציות והרשאות.


שלב 2 – פתיחת App Registrations

בשורת החיפוש העליונה הקלד:

App registrations

ובחר בתוצאה.

מה הפעולה מבצעת?
מעבר למסך שבו יוצרים ומנהלים אפליקציות הרשומות בארגון.


שלב 3 – יצירת אפליקציה חדשה

לחץ על:

+ New registration

מלא את הפרטים הבאים:

Name

Yogev Insurance Mailer

(ניתן לבחור כל שם אחר המתאר את מטרת האפליקציה.)

Supported account types

בחר:

Accounts in this organizational directory only (Single tenant)

Redirect URI

יש להשאיר ריק.

בסיום לחץ:

Register

מה הפעולה מבצעת?
יוצרת זהות ייחודית (Application Identity) שבאמצעותה המערכת תזדהה מול Microsoft במקום להשתמש בשם משתמש וסיסמה.


שלב 4 – שמירת מזהי האפליקציה

במסך Overview יופיעו שני ערכים חשובים:

Application (Client) ID

מזהה ייחודי של האפליקציה.

Directory (Tenant) ID

מזהה הארגון ב-Microsoft 365.

יש להעתיק ולשמור את שני הערכים.

מה הפעולה מבצעת?
ערכים אלו ישמשו את המערכת בעת קבלת Access Token לצורך שליחת הודעות.


שלב 5 – יצירת Client Secret

בתפריט הצד בחר:

Certificates & secrets

לחץ:

+ New client secret

הגדר:

Description

לדוגמה:

mailer-secret

Expires

בחר את משך הזמן הארוך ביותר שהארגון מאפשר.

לחץ:

Add

לאחר יצירת ה-Secret תופיע עמודת:

Value

יש להעתיק את הערך מיד.

Microsoft מציגה את הערך פעם אחת בלבד. לאחר סגירת המסך לא ניתן יהיה לצפות בו שוב.

מה הפעולה מבצעת?
Client Secret הוא מפתח האימות של האפליקציה ומשמש יחד עם ה-Client ID לקבלת Access Token.


שלב 6 – הוספת הרשאות Microsoft Graph

בתפריט הצד בחר:

API permissions

לחץ:

+ Add a permission

בחר:

Microsoft Graph

לאחר מכן:

Application permissions

חשוב לבחור Application Permissions ולא Delegated Permissions.

בתיבת החיפוש הקלד:

Mail.Send

סמן את ההרשאה.

לחץ:

Add permissions

מה הפעולה מבצעת?
מעניקה לאפליקציה הרשאה לשלוח הודעות דואר באמצעות Microsoft Graph ללא צורך במשתמש מחובר.


שלב 7 – מתן Admin Consent

לחץ על:

Grant admin consent for [שם הארגון]

ואשר באמצעות:

Yes

ודא שליד ההרשאה מופיע:

Mail.Send
Granted for <Organization>

עם סימון ירוק.

מה הפעולה מבצעת?
מאשרת שהארגון מעניק לאפליקציה את ההרשאה שהוגדרה. ללא אישור זה ההרשאה לא תהיה פעילה.


שלב 8 – הגבלת ההרשאות לתיבת הדואר (מומלץ)

כברירת מחדל, הרשאת Mail.Send (Application) עשויה לאפשר לאפליקציה לשלוח הודעות בשם כל תיבת דואר בארגון.

מטעמי אבטחת מידע מומלץ להגביל את האפליקציה כך שתוכל לשלוח הודעות רק מתיבת הדואר הייעודית של המערכת.

דוגמאות:

ההגבלה מתבצעת על ידי מנהל Exchange Online באמצעות:

  • Application RBAC (מומלץ בארגונים חדשים)

  • Application Access Policies (בארגונים קיימים, בהתאם לסביבת העבודה)

חשיבות השלב
במקרה של שימוש לא מורשה באפליקציה, ההשפעה תהיה מוגבלת לתיבת הדואר שהוגדרה בלבד.


שלב 9 – העברת הפרטים למפתח

לאחר השלמת כל השלבים יש להעביר למפתח בערוץ מאובטח בלבד:

  • Application (Client) ID

  • Directory (Tenant) ID

  • Client Secret Value

  • כתובת תיבת הדואר שממנה יתבצעו השליחות

לדוגמה:

mailer@company.com

אין לשלוח:

  • סיסמת משתמש

  • קודי אימות

  • פרטי התחברות לחשבון Microsoft


לאחר מסירת הפרטים

לאחר קבלת הנתונים, המפתח יבצע את יתרת ההגדרה במערכת (לדוגמה Supabase או שרת היישום), כולל:

  • קבלת Access Token מ-Microsoft.

  • התחברות ל-Microsoft Graph.

  • שליחת הודעות דואר.

  • תמיכה בקבצים מצורפים.

  • שליחת הודעות HTML.

  • שליחה אוטומטית ללא שימוש בסיסמת משתמש.


סיכום

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

נוהל הקמת הרשאות לשליחת דואר באמצעות Microsoft 365 (Microsoft Graph)

גרסה: 1.0
מטרה: הקמת אפליקציה והרשאות המאפשרות למערכת פנימית (כגון אתר אינטרנט, API או Supabase) לשלוח הודעות דואר אלקטרוני דרך Microsoft 365 באופן מאובטח, ללא שימוש בשם משתמש וסיסמה.


1. מבוא

Microsoft ממליצה כיום להשתמש ב־Microsoft Graph API ובמנגנון OAuth 2.0 לצורך שליחת הודעות דואר ממערכות אוטומטיות.

בגישה זו, המערכת אינה מתחברת באמצעות משתמש וסיסמה, אלא מזדהה באמצעות אפליקציה רשומה ב־Microsoft Entra ID (לשעבר Azure Active Directory). לאחר ההזדהות מתקבל Access Token זמני, שבעזרתו ניתן לשלוח הודעות דואר בצורה מאובטחת.

יתרונות השיטה

  • ללא שמירת סיסמת משתמש במערכת.

  • תואם להמלצות האבטחה של Microsoft.

  • תמיכה בקבצים מצורפים.

  • תמיכה בהודעות HTML.

  • שליחה אוטומטית ללא התערבות משתמש.

  • אפשרות להגבלת ההרשאות לתיבת דואר ייעודית.


2. כיצד התהליך עובד

מערכת │ ▼ Client ID + Client Secret │ ▼ Microsoft Entra ID │ Access Token │ ▼ Microsoft Graph │ ▼ Microsoft 365 Exchange Online │ ▼ שליחת הודעת דואר


3. דרישות מקדימות

יש לבצע את ההגדרה באמצעות אחד מהתפקידים הבאים:

  • Global Administrator

  • Application Administrator

  • Cloud Application Administrator

מומלץ לבצע את ההגדרה באמצעות חשבון מנהל ייעודי.


4. יצירת App Registration

שלב 1 – כניסה לפורטל Azure

היכנס ל:

https://portal.azure.com

והתחבר עם חשבון מנהל.

מטרת השלב: גישה לפורטל הניהול של Microsoft Entra ID.


שלב 2 – פתיחת App Registrations

בשורת החיפוש העליונה חפש:

App registrations

ולחץ על התוצאה.

מטרת השלב: מעבר למסך ניהול האפליקציות של הארגון.


שלב 3 – יצירת אפליקציה חדשה

לחץ:

+ New registration

מלא את השדות:

שדה

ערך

Name

Yogev Insurance Mailer

Supported account types

Accounts in this organizational directory only (Single tenant)

Redirect URI

להשאיר ריק

לחץ:

Register

הסבר

  • Name – שם תיאורי בלבד.

  • Single Tenant – מגביל את האפליקציה לארגון שלכם.

  • Redirect URI – אינו נדרש מאחר שמדובר באפליקציה שרצה ברקע ואינה מבצעת התחברות משתמש.


5. שמירת מזהי האפליקציה

במסך Overview שמור את הערכים הבאים:

Application (Client) ID

המזהה הייחודי של האפליקציה.

Directory (Tenant) ID

המזהה של הארגון ב־Microsoft 365.

חשוב: יש לשמור את שני הערכים לצורך מסירתם למפתח.


6. יצירת Client Secret

בתפריט הימני בחר:

Certificates & secrets

לחץ:

+ New client secret

הגדר:

Description

לדוגמה:

mailer-secret

Expiration

בחר את התקופה הארוכה ביותר שמדיניות הארגון מאפשרת.

לחץ:

Add

לאחר היצירה יופיע:

Value

⚠ יש להעתיק ולשמור את הערך מיד. Microsoft לא תציג אותו שוב.

מהו Client Secret?

זהו מפתח האימות של האפליקציה, המשמש יחד עם ה־Client ID לצורך קבלת Access Token.


7. הוספת הרשאות Microsoft Graph

בתפריט הימני בחר:

API permissions

לחץ:

+ Add a permission

בחר:

Microsoft Graph

לאחר מכן:

Application permissions

אין לבחור Delegated Permissions.

חפש:

Mail.Send

סמן את ההרשאה.

לחץ:

Add permissions

מה ההרשאה מאפשרת?

שליחת הודעות דואר באמצעות Microsoft Graph גם כאשר אין משתמש מחובר.


8. מתן Admin Consent

לחץ:

Grant admin consent for [שם הארגון]

ואשר.

בסיום ודא שמופיע:

Mail.Send – Granted for [Organization]

עם סימון ירוק.

מדוע זה נדרש?

ללא אישור מנהל המערכת, ההרשאה לא תהיה פעילה גם אם נוספה.


9. הגבלת ההרשאות לתיבת דואר אחת (מומלץ)

כברירת מחדל, הרשאת Mail.Send (Application) מאפשרת לאפליקציה לשלוח הודעות בשם כל תיבת דואר בארגון.

מטעמי אבטחת מידע מומלץ להגביל את ההרשאה לתיבת דואר ייעודית בלבד, לדוגמה:

ההגבלה מתבצעת על ידי מנהל Exchange Online באמצעות:

  • Application RBAC (מומלץ)

  • Application Access Policies (בסביבות קיימות)

למה זה חשוב?

הגבלת ההרשאה מפחיתה משמעותית את הסיכון במקרה של שימוש לא מורשה באפליקציה.


10. הפרטים שיש להעביר למפתח

יש להעביר בערוץ מאובטח בלבד:

  • Application (Client) ID

  • Directory (Tenant) ID

  • Client Secret Value

  • כתובת תיבת הדואר שתשמש לשליחה

לדוגמה:

mailer@company.com


11. אין להעביר למפתח

  • סיסמת חשבון Microsoft

  • קוד אימות דו־שלבי (MFA)

  • Recovery Codes

  • פרטי התחברות אישיים

המערכת אינה זקוקה להם.


12. בדיקת תקינות (Checklist)

לפני מסירת הנתונים, ודא שכל הסעיפים הבאים הושלמו:

בדיקה

סטטוס

נוצר App Registration

נשמר Client ID

נשמר Tenant ID

נוצר Client Secret

נשמר Client Secret

נוספה הרשאת Mail.Send

בוצע Grant Admin Consent

הוגבלה הגישה לתיבת הדואר (מומלץ)

הועברו כל הפרטים למפתח בערוץ מאובטח


13. תקלות נפוצות

הודעת שגיאה

סיבה אפשרית

פתרון

AccessDenied

Admin Consent לא בוצע או חסרה הרשאה

בדוק שההרשאה נוספה ואושרה

Unauthorized

Client ID / Tenant ID שגויים

אמת את הערכים במסך Overview

Invalid Client Secret

ה־Secret שגוי או פג תוקף

צור Client Secret חדש

Mailbox not found

כתובת השולח אינה קיימת או אינה מורשית

ודא שהתיבה קיימת ושהאפליקציה מורשית להשתמש בה

Insufficient privileges

הרשאות Exchange או Graph אינן מספיקות

בדוק את הרשאות Mail.Send ואת הגדרות Exchange


14. לאחר השלמת ההגדרה

לאחר קבלת הנתונים, המפתח יבצע את ההגדרה במערכת (לדוגמה Supabase או שרת היישום), הכוללת:

  • קבלת Access Token באמצעות OAuth 2.0.

  • התחברות ל־Microsoft Graph.

  • שליחת הודעות דואר.

  • תמיכה בקבצים מצורפים.

  • שליחת הודעות HTML.

  • שליחה אוטומטית ללא שימוש בסיסמת משתמש.


15. סיכום

לאחר השלמת כל השלבים, האפליקציה תהיה מורשית לשלוח הודעות דואר דרך Microsoft Graph בצורה מאובטחת ובהתאם להמלצות Microsoft. מומלץ להשתמש בתיבת דואר ייעודית, להגביל את ההרשאות אליה בלבד, ולשמור את פרטי ה־Client Secret במקום מאובטח.

הוראות להקמת הרשאת שליחת מייל דרך Microsoft 365  (CLOUDE)
=====================================================
עבור מי שיש לו הרשאות) Global Administrator / Application Administrator)
מטרה: לאפשר למערכת פנימית לשלוח מיילים (כולל קבצים מצורפים) דרך תיבת
הדואר של העסק ב -Microsoft 365, .בלי לחשוף שום סיסמה בקוד האתר
:שלבים
——-
כנס ל . 1 : https://portal.azure.com
בחיפוש העליון הקלד . 2 : "App registrations" .ובחר אותו
לחץ . 3 "+ New registration".
– Name: Yogev Insurance Mailer
– Supported account types: "Accounts in this organizational directory only
(Single tenant)"
– Redirect URI: השאר ריק
לחץ – "Register"
בעמוד שנפתח . 4 (Overview), :העתק ושמור
– "Application (client) ID"
– "Directory (tenant) ID"
בתפריט הצד . 5 : "Certificates & secrets" → לחץ "+ New client secret"
– Description: למשל) כל שם "mailer-secret")
– Expires: הבחירה הארוכה ביותר האפשרית
לחץ – "Add"
מיד תופיע עמודת – "Value" — ( העתק ושמור אותה **עכשיו** (היא לא תוצג שוב לעולם
בתפריט הצד . 6 : "API permissions" → "+ Add a permission"
בחר – "Microsoft Graph"
בחר – "Application permissions" ( לא Delegated!)
בתיבת החיפוש הקלד – "Mail.Send" וסמן אותו
לחץ – "Add permissions"
לחץ על הכפתור . 7 "Grant admin consent for [ ואשר "[שם הארגון "Yes".
ודא שליד ההרשאה – Mail.Send מופיע צ'קמארק ירוק וכתוב "Granted for…"
:שלח בחזרה לעומר (בערוץ מאובטח, לא מייל/וואטסאפ רגיל אם אפשר) . 8
– Application (client) ID
– Directory (tenant) ID
– Client Secret Value
למשל) כתובת תיבת הדואר ששולחת – xxx@xxx.com)
זהו — לאחר קבלת הפרטים האלה, המשתמש ימשיך את ההקמה בעצמו ב -Supabase.

נוהל עבודה (SOP)

הקמת אפליקציה והרשאות לשליחת דואר באמצעות Microsoft 365 ו-Microsoft Graph

גרסה: 1.0
עודכן בתאריך: 07/07/2026
מטרה: הקמת הרשאות מאובטחות לשליחת הודעות דואר אלקטרוני באמצעות Microsoft Graph ללא שימוש בסיסמת משתמש.


1. רקע

מערכות רבות (כגון אתרי אינטרנט, מערכות CRM, מערכות ERP, Supabase, Azure Functions או שירותי Backend אחרים) נדרשות לשלוח הודעות דואר אלקטרוני באופן אוטומטי.

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

הפתרון המומלץ כיום הוא שימוש ב־Microsoft Graph API ובאפליקציה רשומה ב־Microsoft Entra ID (לשעבר Azure Active Directory). בדרך זו המערכת מזדהה כאפליקציה, מקבלת אסימון גישה (Access Token) זמני ושולחת הודעות ללא חשיפת סיסמת משתמש.


2. מטרת הנוהל

בסיום התהליך תתקבל אפליקציה בעלת הרשאה לשלוח הודעות דואר באמצעות Microsoft Graph, כך שניתן יהיה:

  • לשלוח הודעות HTML.

  • לצרף קבצים.

  • לשלוח הודעות אוטומטיות.

  • להשתמש בכתובת דואר ארגונית.

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


3. דרישות מקדימות

יש לבצע את התהליך באמצעות חשבון בעל אחת מההרשאות הבאות:

  • Global Administrator

  • Application Administrator

  • Cloud Application Administrator

במידה שמבקשים להגביל את ההרשאות לתיבת דואר מסוימת בלבד, ייתכן שתידרש גם הרשאת Exchange Administrator.

הערת אבטחה: מומלץ לבצע את התהליך מחשבון מנהל ייעודי ולא מחשבון אישי המשמש לעבודה שוטפת.


4. תהליך ההקמה

שלב 1 – כניסה לפורטל Azure

היכנס אל:

https://portal.azure.com

והתחבר באמצעות חשבון מנהל.

מטרת השלב

פורטל Azure הוא ממשק הניהול המרכזי של Microsoft Entra ID, שבו יוצרים ומנהלים אפליקציות, זהויות והרשאות.


שלב 2 – פתיחת App Registrations

בחיפוש העליון הקלד:

App registrations

ובחר בתוצאה.

הסבר

App Registration הוא אובייקט המייצג אפליקציה בתוך הארגון. לכל אפליקציה מוקצים מזהים והרשאות משלה, בדומה לזהות של משתמש.

חשיבות

באמצעות App Registration ניתן להעניק למערכת הרשאות ייעודיות, לנהל אותן ולבטלן במידת הצורך, ללא תלות בחשבון משתמש.


שלב 3 – יצירת אפליקציה חדשה

לחץ:

+ New registration

מלא את הפרטים:

שדה

ערך

Name

Yogev Insurance Mailer (או שם אחר לפי בחירתכם)

Supported account types

Accounts in this organizational directory only (Single tenant)

Redirect URI

להשאיר ריק

לאחר מכן לחץ:

Register

הסבר

  • Name – שם תיאורי בלבד לצורכי ניהול.

  • Single Tenant – מגביל את השימוש לארגון שלכם בלבד.

  • Redirect URI – אינו נדרש מאחר שהאפליקציה אינה מבצעת התחברות של משתמשים.

המלצה: השתמשו בשם המעיד על מטרת האפליקציה (למשל "ERP Mail Service" או "Website Mail Sender").


שלב 4 – שמירת מזהי האפליקציה

לאחר יצירת האפליקציה יוצג מסך Overview.

יש לשמור את הערכים הבאים:

Application (Client) ID

מזהה ייחודי של האפליקציה.

משמש בכל בקשת הזדהות.


Directory (Tenant) ID

מזהה ייחודי של הארגון ב-Microsoft 365.

מאפשר ל-Microsoft לזהות באיזה Tenant האפליקציה רשומה.

הערה: שני הערכים אינם סודיים, אך הם חיוניים לתהליך ההזדהות.


שלב 5 – יצירת Client Secret

עבור אל:

Certificates & secrets

בחר:

+ New client secret

הגדר:

  • Description – לדוגמה: mailer-secret

  • Expiration – בחר את התקופה הארוכה ביותר המותרת על פי מדיניות הארגון.

לחץ:

Add

חשוב

מיד לאחר היצירה תוצג עמודת Value.

יש להעתיק אותה באופן מיידי.

לאחר סגירת המסך Microsoft לא תציג אותה שוב.

מהו Client Secret?

זהו מפתח סודי המשמש את האפליקציה לצורך הזדהות מול Microsoft.

הערת אבטחה: יש לשמור את ה-Client Secret בכספת סודות (Secrets Manager, Azure Key Vault וכדומה), ולא בקוד המקור או בקבצי תצורה חשופים.


שלב 6 – הענקת הרשאות Microsoft Graph

עבור אל:

API Permissions

בחר:

+ Add a permission

לאחר מכן:

  1. Microsoft Graph

  2. Application permissions

  3. חפש: Mail.Send

  4. סמן את ההרשאה

  5. לחץ: Add permissions

מדוע לבחור Application Permissions?

קיימים שני סוגי הרשאות:

  • Delegated Permissions – מיועדות לאפליקציות הפועלות בשם משתמש מחובר.

  • Application Permissions – מיועדות לשירותים אוטומטיים הפועלים ללא משתמש.

במערכת Backend או Supabase יש להשתמש ב-Application Permissions בלבד.


שלב 7 – מתן Admin Consent

לאחר הוספת ההרשאות לחץ:

Grant admin consent for

ואשר.

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

Granted for

הסבר

Admin Consent הוא אישור של מנהל המערכת לכך שהאפליקציה רשאית להשתמש בהרשאות שביקשה.

ללא אישור זה, Microsoft תחסום את הגישה ל-Graph API גם אם ההרשאה נוספה.


5. הגבלת ההרשאות לתיבת דואר מסוימת (מומלץ)

מדוע שלב זה חשוב?

הרשאת Mail.Send (Application) מעניקה לאפליקציה אפשרות עקרונית לשלוח הודעות בשם כל תיבת דואר בארגון.

ברוב הארגונים מדובר בהרשאה רחבה מדי.

לכן מומלץ להגביל את האפליקציה לתיבת דואר ייעודית אחת בלבד.

לדוגמה:

כיצד מבצעים זאת?

באמצעות Exchange Online Administrator.

בארגונים חדשים מומלץ להשתמש ב-Application RBAC.

בארגונים קיימים ייתכן שעדיין נעשה שימוש ב-Application Access Policies.

המלצת אבטחת מידע: מומלץ ליצור תיבת דואר ייעודית לשליחת הודעות אוטומטיות, ולא להשתמש בתיבת הדואר האישית של עובד.


6. הפרטים שיש להעביר למפתח

לאחר סיום ההקמה יש להעביר בערוץ מאובטח בלבד:

  • Application (Client) ID

  • Directory (Tenant) ID

  • Client Secret Value

  • כתובת תיבת הדואר המורשית לשליחה

לדוגמה:

mailer@company.com

אין להעביר: סיסמת משתמש, קוד אימות דו-שלבי או פרטי התחברות לחשבון Microsoft.


7. כיצד פועל מנגנון השליחה?

בכל פעם שהמערכת תשלח הודעה:

  1. היא תבקש אסימון גישה (Access Token) מ-Microsoft באמצעות:

    • Client ID

    • Tenant ID

    • Client Secret

  2. Microsoft יאמת את האפליקציה וינפיק אסימון זמני.

  3. המערכת תשתמש באסימון כדי לקרוא ל-Microsoft Graph API.

  4. Microsoft Graph ישלח את ההודעה באמצעות תיבת הדואר שהוגדרה.

יתרונות

  • אין שימוש בסיסמת משתמש.

  • האסימון זמני ומתחדש אוטומטית.

  • ניתן לבטל הרשאות בכל עת.

  • כל הפעולות מתועדות ביומני הארגון (Audit Logs).


8. שיקולי אבטחת מידע

✔ אין לשמור Client Secret בקוד המקור.
✔ יש להשתמש בכספת סודות (כגון Azure Key Vault או מנהל סודות אחר).
✔ מומלץ להגדיר תיבת דואר ייעודית לשליחת הודעות.
✔ מומלץ להגביל את ההרשאות באמצעות Application RBAC.
✔ יש למחוק Client Secrets שאינם בשימוש.
✔ מומלץ לתעד מועד תפוגה של ה-Client Secret ולהחליפו לפני שפג תוקפו.
✔ יש לעקוב אחר יומני הביקורת של Microsoft 365 כדי לזהות שימוש חריג.


9. פתרון תקלות נפוצות

שגיאה

סיבה אפשרית

פתרון

AccessDenied

חסרה הרשאת Mail.Send או שלא בוצע Admin Consent

ודא שההרשאה נוספה ואושרה

Invalid Client Secret

ה-Secret שגוי או פג תוקף

צור Client Secret חדש

Unauthorized

Client ID או Tenant ID שגויים

בדוק את הערכים במסך Overview

Mailbox not found

כתובת השולח אינה קיימת או שאין הרשאה אליה

ודא שהתיבה קיימת ושהאפליקציה מורשית להשתמש בה

Insufficient privileges

חסרה הרשאת Application או הגבלת RBAC

בדוק את הרשאות Graph ואת הגדרות Exchange


10. סיכום

יישום התהליך מאפשר למערכת לשלוח הודעות דואר באופן מאובטח, בהתאם להמלצות Microsoft, ללא שימוש בסיסמת משתמש.

השילוב של Microsoft Entra ID, Microsoft Graph והרשאות Application מספק פתרון מודרני, מאובטח וניתן לניהול, המתאים למערכות ארגוניות ולשירותים אוטומטיים.

לצורך אבטחה מיטבית, מומלץ להגביל את האפליקציה לתיבת דואר ייעודית, לשמור את ה-Client Secret בכספת סודות ולהקפיד על סבב החלפה תקופתי של סודות והרשאות.