整理 Microsoft 365 NDR、Message Trace、SPF／DKIM／DMARC、共用信箱、群組授權、條件式存取與 Teams 常見管理問題。
信件路由與退信代碼：機器已經告訴你答案，你要看得懂
Exchange Online 退信時，真正有用的線索是那串 NDR（Non-Delivery Report）狀態碼，它遵循 RFC 3463 的 class.subject.detail 結構，中文錯誤訊息只是翻譯，代碼才是根因。這是一套值得背下來的語言。
先讀碼，再動手
- 550 5.1.1 與 5.1.10：都是「找不到收件者」。真正原因通常有兩層——一是地址打錯或對方信箱已停用；二更陰險，收件者其實還在，但寄件人 Outlook 的自動完成（autocomplete）快取存的是一筆早已失效的舊內部位址（X.500／LegacyExchangeDN）。這時候叫他重打地址沒用，要請他在收件欄把那筆灰色建議按 Delete 刪掉，重新輸入才會走到正確的 GAL 位址。
- 550 5.7.509：對方網域啟用了 DMARC 且政策是 reject，代表你這邊送出的信在收件端沒通過驗證。這不是對方的問題，是你家的 SPF 或 DKIM 沒對齊，要回頭檢查自己的 DNS。
- 550 5.7.1 與 5.7.606-649：被對方或防護政策明確拒收，常見於 IP 信譽不佳或觸發傳輸規則，需要看對方回傳的診斷字串定位。
判斷準則很簡單：5.1.x 往收件端與位址找，5.7.x 往驗證與政策找。分錯類，後面全白費。
SPF、DKIM、DMARC 三支柱，關鍵字是「對齊」
很多人以為 SPF 有設、DKIM 有簽就算過關，其實 DMARC 的核心不是「有沒有通過」，而是 RFC 7489 定義的識別對齊（identifier alignment）：SPF 驗證的是信封寄件人 RFC5321.MailFrom 網域，DKIM 驗證的是簽章裡的 d= 網域，而 DMARC 要求這兩者至少有一個，要跟使用者看到的 From 標頭網域對齊，才算真正通過。預設是寬鬆（relaxed）模式，比對到組織網域層級即可；嚴格（strict）則要完全一致。這解釋了一個常見鬼打牆：明明 SPF 顯示 pass，DMARC 卻 fail——因為第三方代發服務用了它自己的信封網域，SPF 過了但沒跟你的 From 對齊。
SPF 這條 DNS 記錄還有兩個致命細節。第一，全公司同一個網域只能有一筆 SPF TXT 記錄，內容形如 v=spf1 include:spf.protection.outlook.com -all。很多人為了加第三方發信服務又另開一筆新的，結果兩筆 SPF 並存，依 RFC 7208 直接判 PermError，全公司的信可能一起掉進垃圾桶。第二，SPF 有 10 次 DNS 查詢的硬上限（RFC 7208 §4.6.4）：include、a、mx、ptr、exists 這些機制每個都吃一次查詢，串接太多外部服務很容易超過 10 次，一超過就是 PermError、驗證整組失效；而 ip4、ip6、all 不查 DNS、不計次。所以健檢 SPF 時，我們不只看內容對不對，還會實際跑一次 lookup 數，逼近上限的就要用巨集或扁平化收斂。
要查一封信到底卡在哪：用對工具
定位單一封信的旅程，靠的是郵件流裡的訊息追蹤（Message Trace）。這裡有個時效的重點：微軟已於 2025 年下半年起淘汰舊的 Get-MessageTrace／Get-MessageTraceDetail，全面轉向 Get-MessageTraceV2。新指令可回溯 90 天（舊的只有 10 天），但有兩個工程限制要記住——單次查詢最多只能拉 10 天區間，要覆蓋完整 90 天得分段多次查；而且有租戶層級節流，每 5 分鐘上限約 100 次查詢請求。使用前也要確認 Exchange Online PowerShell 模組更新到 V3 3.7.0 以上，否則指令根本不存在。另外提醒一句常見的過度設計：大多數中小企業根本不需要自建連接器（connector），Exchange Online 開箱即能收發，亂建連接器反而把正常信流導歪，是進場檢查健檢時最常拆掉的東西。
授權與共用信箱：先搞懂 50GB 那條線，再談要不要花錢
授權出包，十之八九不是缺 license，而是設定打架。當你用群組式授權（group-based licensing）時，如果兩個產品各自帶了互斥的服務計畫，PowerShell 會回報 MutuallyExclusiveViolation；而使用者沒設定使用位置（Usage location）時，指派會失敗並回報 ProhibitedInUsageLocationViolation。這兩種微軟都不會自動幫你解，得由管理員決定保留哪個產品、補齊哪個欄位。實務上把授權集中用安全性群組管理，比一個一個手動點省事太多，但代價就是這類衝突要看得懂錯誤碼。
資料保留的邊界更要背熟，因為它直接關係到「人走了資料還救不救得回來」：
- 信箱資料：拿掉授權後，Exchange Online 的信箱資料預設保留 30 天，這期間重新指派授權就能完整救回；若要更長期保存，要在刪除前設定為非作用中信箱（inactive mailbox）並掛上保留，否則過期就真的清掉。
- OneDrive：帳號刪除後預設保留 30 天，可在 SharePoint 系統管理中心把保留期調到最長 3650 天。
- 離職交接的標準動作，是先轉共用信箱或設定非作用中信箱、再回收授權，順序反了就容易踩進 30 天倒數。
共用信箱最常被問的永遠是「要不要錢」。判準是這條清楚的線：容量在 50GB 以內、又不啟用封存（Archive）或訴訟保留（Litigation Hold），就完全不用授權。一旦你要 100GB 空間、要 In-Place Archive、要 Litigation Hold，就得補 Exchange Online Plan 2，或走較省的 Plan 1 加封存附加元件這條路。這條線背後的邏輯是：50GB 是免費信箱的天花板，任何合規類的工作負載都會把它推過門檻。
另一個天天被客訴的問題是「用共用信箱寄出去的信，寄件備份找不到」。根因是 Outlook 實際上是用個人帳號代寄，副本進了個人的寄件備份，共用信箱裡自然是空的。正解是兩行 PowerShell，新舊版 Outlook 都吃：
- Set-Mailbox 信箱 -MessageCopyForSentAsEnabled $True（處理「傳送身分」寄出）
- 再加 -MessageCopyForSendOnBehalfEnabled $True（處理「代理傳送」寄出）
還有一條原則：共用信箱對應的那個帳號要永遠封鎖登入，它天生就不該拿來當一般帳號用，開著登入等於多一個沒人在顧的門。
MFA 與條件式存取：別在鎖門的時候把自己也鎖在外面
導入多因素驗證，最怕的不是設定太複雜，而是把管理員自己鎖死。動工前有一條不能省的鐵則：先建立兩個以上的緊急存取（break-glass）帳號。這幾個帳號要用 onmicrosoft.com 網域、純雲端、不與地端同步、給予永久的全域管理員角色，並且明確排除在任何「封鎖登入」的條件式存取政策之外。進階做法會給它們防釣魚的驗證方式（如 FIDO2 安全金鑰或憑證），且刻意跟日常管理帳號不同，把憑證拆開存放在多位管理者知道的安全處，並且每季實際登入測試一次，確認現行政策沒有把這道逃生門也擋掉。整個條件式存取的鏈路裡，這是唯一不容出錯的一環——因為它是你被鎖住時唯一能開門的手。
還有一個天天有人踩的觀念誤區：安全性預設值（Security Defaults）跟條件式存取無法並存。只要租戶裡存在任何一條 CA 政策，哪怕是停用或僅報告模式，你都沒辦法再開安全性預設值。這代表一旦踏進條件式存取的世界，就是全面接手身分安全，不能再回頭靠那個一鍵開關。
使用者被擋下時，排查其實很直接：到登入記錄（Sign-in logs）點開那筆失敗，「條件式存取」分頁會直接告訴你是哪一條政策、命中什麼條件、錯誤碼是什麼。看到 AADSTS53003 就是被 CA 擋下，順著它指的政策去看授與（grant）與條件即可，不必瞎猜。
故障率、復原成功率與工時不適合用別人的平均值推估。現場應留下資產、告警、備份、還原演練、事件處理與停機紀錄，再用自家數據決定汰換、容量與維運優先順序。
Teams：九成問題靠清快取，協作權限要分清兩種模型
至於外部協作，一定要把兩種模型分清楚，它們常被混為一談：
- 外部存取（External access）：跟其他組織的人一對一通話、聊天，多半預設開啟，但對方碰不到你團隊裡的檔案，本質是組織對組織的聯邦（federation）。
- 來賓存取（Guest access）：把外部人員實際請進某個團隊一起做事、看得到頻道與檔案。這個要在 Teams 系統管理中心開啟，而且不是開一個開關就好——它牽動 Entra ID、Microsoft 365 群組、SharePoint 三層授權，少放行任何一層，來賓就是加不進來。
判斷準則：只是要跟外面的人講話，用外部存取；要讓外面的人進來協作，才動來賓存取。搞混的下場，通常是把不該開的權限開太大，或是怎麼邀都邀不進來卻查不出卡在哪一層。
這些雷的共通點：牽一髮動全身
你會發現，上面每一類設定單獨看都不算難，難在它們彼此牽連、環環相扣。一筆 SPF 沒收斂、一條 CA 政策沒排除緊急帳號、一個離職流程順序顛倒，就可能讓全公司收不到信、登不進系統，或把資料留在 30 天的倒數裡。維運 M365 真正的價值，不在會點哪個按鈕，而在看得懂機器留下的代碼、知道每條線背後的邊界，並且在動手前就想好逃生門在哪。
廷皓科技在高雄楠梓，長期服務高雄、台南、屏東一帶的中小企業，從 M365 導入、信件路由與 DNS 驗證健檢、授權與共用信箱盤點，到條件式存取與緊急帳號規劃都能承接。想找一個既懂微軟雲端底層機制、又叫得動、出得了現場的在地後盾，歡迎跟廷皓聊聊，讓這些會半夜出包的雷，變成有人替你顧著的日常。
