在 Microsoft 365 中 (SRS) 的寄件者重寫配置
注意事項
在 2023 年 8 月，將會對 SMTP 或信箱轉寄的郵件推出變更。 往後，SRS 將用來重寫這些訊息，而不是轉寄信箱。 這會將轉送方法合併到 Exchange Online 中的所有使用 SRS。 雖然 SRS 是設計來避免轉寄的訊息中斷，但某些特殊案例可能會看到問題。 這項變更的其中一個案例是，透過內部部署伺服器轉送至因特網的訊息將不會使用 SRS 重寫。 若要避免此行為變更，請參閱此處涵蓋的新設定： 寄件者重寫配置即將進行的變更。
轉送集區功能已在 Microsoft 365 中引進，這會影響 SRS 重寫行為。 符合此轉送集區的資格的訊息會略過由 SRS 重寫，並從不屬於Microsoft 365 SPF 記錄的 IP 傳送。 這主要會影響 SPF 在進入 Exchange Online 時無法通過 SPF 檢查的訊息，讓 SRS 無法修正這些失敗。 如需詳細資訊，請參閱這裡的轉送集區文件： 輸出傳遞集區。
已將 SRS) 功能 (傳送者重寫配置新增至 Microsoft 365，以解決自動轉送與 SPF 不相容的問題。 SRS 功能會針對從 Microsoft 365 外部傳送的所有適用訊息，重寫 P1 寄件者位址 (也稱為信封發件者位址) 。
注意事項
電子郵件客戶端顯示的 From 標頭，也稱為顯示來源位址或 P2 發件者位址，保持不變。
SRS 功能可改善傳遞的適用訊息，這些訊息會在傳送者原則架構 (SPF) 從原始發件者送達時進行檢查，但在轉寄後無法在最終外部目的地進行 SPF 檢查。
在下列案例中，SRS 會重寫 P1 From 位址：
- Microsoft 365 中使用下列任一方法自動轉送 (或重新導向) 至外部收件者的訊息：
- SMTP 轉送
- 重新導向) 信箱規則 (或收件匣規則
- 郵件流程 (傳輸) 規則重新導向
- 具有外部成員的群組或 DLL
- 郵件聯繫人轉寄
- 郵件用戶轉寄
- 從客戶的內部部署環境自動轉送 (或重新導向) 並透過 Exchange Online 轉送的訊息。
請務必注意，SRS 重寫是用來防止詐騙未經驗證的網域。 您應該只從您擁有的網域傳送訊息，而且您已透過 [已接受的網域] 清單驗證您的擁有權。 如需 Microsoft 365 中已接受網域的詳細資訊，請參閱 在 Exchange Online 中管理公認的網域。
注意事項
SRS 重寫無法修正針對轉寄的訊息傳遞 DMARC 的問題。 雖然SPF檢查現在會因為重寫的 P1 From 位址而通過，但 DMARC 也需要對齊檢查訊息才能通過。 針對轉寄的訊息，DKIM 一律會失敗，因為已簽署的 DKIM 網域不符合 From 標頭網域。 如果原始寄件者將其 DMARC 原則設定為拒絕轉寄的郵件，則郵件傳輸代理程式會拒絕轉寄的郵件 (接受 DMARC 原則的 MTA) 。 ARC 標準的開發目的是為了解決 DKIM 的轉送問題，並已在我們的服務中實作以解決這些問題。
此失敗案例和其他傳遞失敗會導致非傳遞報告 (NDR) 在未使用 SRS 重寫時傳回至 Exchange Online，而不是傳送給原始發件者。 因此，SRS 實作的一部分是在無法傳遞訊息時，將傳回的 NDR 重新路由傳回給原始寄件者。
下列各節會呈現不同的自動轉送案例，以及 SRS 如何處理這些案例的資訊。
針對裝載於 Microsoft 365 的信箱自動轉寄電子郵件
對於傳送至託管信箱並使用 SMTP 轉送、信箱規則重新導向或傳輸規則重新導向等機制自動轉寄的郵件，會在郵件離開 Exchange Online 之前重寫 P1 From 位址。 位址會使用下列模式重寫：
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
在下列範例中，郵件會從 Bob (bob@fabrikam.com) 傳送至 Exchange Online () john.work@contoso.com 中的 John 信箱。 John 已從此信箱自動轉寄至其住家電子郵件地址 (john.home@example.com) 。 請注意 SRS 如何重寫 P1 From 位址。
| 原始訊息 | 自動轉送的訊息 | |
|---|---|---|
| 收件者 | john.work@contoso.com |
john.home@example.com |
| P1 來源 | bob@fabrikam.com |
john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com |
| 從標頭 | bob@fabrikam.com |
bob@fabrikam.com |
當 SRS 重寫 P1 From 位址時，它會增加電子郵件地址的使用者名稱部分長度。 不過，電子郵件位址的限制為64個字元。 因此，如果重寫電子郵件地址的長度超過 64 個字元，則會採用下列格式：
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
其中 <Default Accepted Domain> 是為租用戶設定的預設接受網域名稱。
從客戶的內部部署伺服器轉送
當來自未驗證網域的訊息從客戶的內部部署伺服器或透過 Exchange Online 的應用程式轉送時， P1 From 位址會在離開 Exchange Online 之前重寫。 位址會使用下列模式重寫：
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
在下列範例中，郵件會從 Bob (bob@fabrikam.com) 傳送至 John 的信箱 (john.onprem@contoso.com) ，此信箱位於執行 Exchange Server 的公司伺服器上。 John 已從此信箱自動轉寄至其住家電子郵件地址 (john.home@example.com) 。 請注意 SRS 在此案例中如何重寫 P1 From 位址。 建議客戶將預設接受的網域設定為自己的其中一個網域。
| 類型 | 原始訊息 | Exchange Online 所接收的轉送訊息 | 從 Exchange Online 傳送的轉送訊息 |
|---|---|---|---|
| 收件者 | john.onprem@contoso.com |
john.home@example.com |
john.home@example.com |
| P1 來源 | bob@fabrikam.com |
bob@fabrikam.com |
bounces+SRS=44ldt=IX@contoso.com |
| 從標頭 | bob@fabrikam.com |
bob@fabrikam.com |
bob@fabrikam.com |
在某些情況下，SRS 重寫的轉送訊息可能不會傳遞，而且可能會產生 NDR。
若要接收這些 DDR，租用戶系統管理員必須建立名為 「bounces」 的信箱，該信箱裝載於 Exchange Online 或內部部署。 此信箱的網域必須設定為租用戶的預設接受網域。
傳送至客戶內部部署伺服器的轉寄訊息
根據設計，SRS 會將內部部署伺服器視為在信任界限內，而且不會重寫系結至內部部署的轉送訊息。 不過，對於使用內部部署伺服器將訊息路由傳送至因特網的複雜路由設定，未重寫 SRS 的轉送訊息可能會因為 SPF 失敗而遭到拒絕。 若要解決此問題，系統管理員可以為流經內部部署輸出連接器的流量啟用 SRS。 SenderRewritingEnabled 設定可用來執行此動作，並可使用 New-OutboundConnector 或 Set-OutboundConnector Cmdlet 進行設定。
此設定不適用於處理訊息給外部收件者的合作夥伴連接器，而且這些訊息必須在需要時套用 SRS。 對於夥伴連接器，SenderRewritingEnabled 設定會顯示為 true，而且任何嘗試設定其值時都會傳回錯誤。
郵件流程 (傳輸) 重新導向的郵件
假設規則可以基於任何原因重新導向郵件，而不只是因為特定收件者，轉寄信箱沒有任何概念。 考慮到這一點，SRS 重寫位址會採用下列形式：
bouncesEtr+SRS=<Hash>=<Timestamp>=<OrigSenderDomain>=<OrigSenderUser>@<Default Accepted Domain>
若要接收 NDR，您的租用戶必須能夠接收傳送給名為 「bouncesETR」 之使用者的訊息，我們才能將訊息重新導向至原始寄件者。 例如，如果租用戶中沒有這類信箱，Directory-Based Edge封鎖可能會干擾傳回NDR。
轉送集區和略過 SRS
轉送集區功能已在 Microsoft 365 中引進，這會影響 SRS 重寫行為。 符合此轉送集區的資格的訊息會略過由 SRS 重寫，並從不屬於Microsoft 365 SPF 記錄的 IP 傳送。 這主要會影響第一次傳送至 Exchange Online 時 SPF 檢查失敗的訊息，因為 SRS 不應該透過重寫來修正這些失敗。 如需詳細資訊，請參閱這裡的轉送集區文件： 輸出傳遞集區