Microsoft 365의 SRS(보낸 사람 다시 쓰기 체계)
참고
2023년 8월에 변경 내용이 SMTP 또는 사서함 전달 메시지로 롤아웃됩니다. 앞으로 전달 사서함 대신 이러한 메시지를 다시 작성하는 데 SRS가 사용됩니다. 이렇게 하면 Exchange Online에서 모든 SRS를 사용하도록 전달 메서드가 통합됩니다. SRS는 전달된 메시지의 중단을 방지하도록 설계되어 있지만 몇 가지 특별한 경우에 문제가 발생할 수 있습니다. 이 변경의 한 가지 경우는 온-프레미스 서버를 통해 인터넷에 릴레이되는 메시지가 SRS로 다시 작성되지 않는다는 것입니다. 이 동작 변경을 방지하려면 보낸 사람 다시 쓰기 체계 예정된 변경 내용에서 다루는 새 설정을 참조하세요.
릴레이 풀 기능은 SRS 재작성 동작에 영향을 미치는 Microsoft 365에서 도입되었습니다. 이 릴레이 풀에 적합한 메시지는 SRS에서 다시 작성되지 않으며 Microsoft 365 SPF 레코드에 포함되지 않은 IP에서 전송됩니다. 이는 주로 SRS가 이러한 오류를 수정하지 않도록 Exchange Online을 입력할 때 SPF 검사를 실패하는 메시지에 영향을 줍니다. 자세한 내용은 아웃바운드 배달 풀의 릴레이 풀 설명서를 참조하세요.
자동 전달이 SPF와 호환되지 않는 문제를 해결하기 위해 SRS(보낸 사람 다시 쓰기 체계) 기능이 Microsoft 365에 추가되었습니다. SRS 기능은 Microsoft 365에서 외부로 전송되는 모든 적용 가능한 메시지에 대해 P1 보낸 사람 주소(봉투 보낸 사람 주소라고도 함)를 다시 작성합니다.
참고
보낸 사람 헤더(보낸 사람 표시 주소 또는 P2 보낸 사람 주소라고도 함)는 전자 메일 클라이언트에 의해 표시되는 변경되지 않은 상태로 유지됩니다.
SRS 기능은 원본 보낸 사람으로부터 도착할 때 SPF(보낸 사람 정책 프레임워크) 검사를 통과하지만 전달된 후 최종 외부 대상에서 SPF 검사에 실패하는 적용 가능한 메시지의 배달을 개선합니다.
SRS는 다음 시나리오 에서 P1 From 주소를 다시 작성합니다.
- 다음 방법 중 일부를 사용하여 외부 수신자에게 자동 전달(또는 리디렉션)되는 Microsoft 365의 메시지:
- SMTP 전달
- 사서함 규칙(또는 받은 편지함 규칙) 리디렉션
- 메일 흐름(전송) 규칙 리디렉션
- 외부 멤버가 있는 그룹 또는 DL
- 메일 연락처 전달
- 메일 사용자 전달
- 고객의 온-프레미스 환경에서 자동 전달(또는 리디렉션)되며 Exchange Online을 통해 릴레이되는 메시지입니다.
SRS 재작성은 확인되지 않은 도메인의 스푸핑을 방지하는 데 사용됩니다. 소유한 도메인과 허용 도메인 목록을 통해 소유권을 확인한 도메인에서만 메시지를 보내야 합니다. Microsoft 365의 허용 도메인에 대한 자세한 내용은 Exchange Online에서 허용된 도메인 관리를 참조하세요.
참고
SRS 다시 쓰기는 전달된 메시지에 대한 DMARC 전달 문제를 해결하지 않습니다. 이제 다시 작성된 P1 보낸 편지 주소로 인해 SPF 검사가 통과되지만 DMARC에는 메시지를 전달하기 위한 맞춤 검사도 필요합니다. 전달된 메시지의 경우 서명된 DKIM 도메인이 From 헤더 도메인과 일치하지 않으므로 DKIM은 항상 실패합니다. 원래 보낸 사람이 전달된 메시지를 거부하도록 DMARC 정책을 설정하는 경우 전달된 메시지는 DMARC 정책을 적용하는 MTA(메시지 전송 에이전트)에 의해 거부됩니다. ARC 표준은 DKIM의 전달 문제를 해결하기 위해 개발되었으며 이러한 문제를 해결하기 위해 서비스에서 구현되었습니다.
이 오류 시나리오는 다른 배달 오류와 함께 SRS 재작성을 사용하지 않을 때 원래 보낸 사람 대신 NDR(배달 못함 보고서)이 Exchange Online으로 반환됩니다. 따라서 SRS 구현의 일부는 메시지를 배달할 수 없는 경우 반환된 NDR을 원래 보낸 사람에게 다시 라우팅하는 것입니다.
다음 섹션에서는 다양한 자동 전달 시나리오와 SRS가 이를 처리하는 방법에 대한 정보를 제공합니다.
Microsoft 365에서 호스트되는 사서함에 대한 자동 전달 전자 메일
호스트된 사서함으로 전송되고 SMTP 전달, 사서함 규칙 리디렉션 또는 전송 규칙 리디렉션과 같은 메커니즘을 사용하여 자동 전달되는 메시지의 경우 메시지가 Exchange Online에서 나가기 전에 P1 보낸 사람 주소를 다시 작성합니다. 주소는 다음 패턴을 사용하여 다시 작성됩니다.
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
다음 예제에서는 Bob()에서 Exchange Onlinejohn.work@contoso.com(bob@fabrikam.com)의 John 사서함으로 메시지를 보냅니다. John은 이 사서함에서 집 이메일 주소(john.home@example.com)로 자동 설정되었습니다. SRS에서 P1 From 주소를 다시 작성하는 방법을 확인합니다.
| 원본 메시지 | 자동 전달된 메시지 | |
|---|---|---|
| 받는 사람 | john.work@contoso.com |
john.home@example.com |
| P1 From | bob@fabrikam.com |
john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com |
| 헤더에서 | bob@fabrikam.com |
bob@fabrikam.com |
SRS에서 P1 보낸 사람 주소를 다시 작성하면 전자 메일 주소의 사용자 이름 부분 길이가 증가합니다. 그러나 전자 메일 주소의 제한은 64자입니다. 따라서 다시 작성된 전자 메일 주소의 길이가 64자를 초과하면 다음 형식이 사용됩니다.
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
여기서 <Default Accepted Domain> 은 테넌트에서 설정된 기본 허용 도메인의 이름입니다.
고객의 온-프레미스 서버에서 릴레이
확인되지 않은 도메인에서 시작된 메시지가 고객의 온-프레미스 서버 또는 Exchange Online을 통해 애플리케이션에서 릴레이되면 Exchange Online에서 나가기 전에 P1 보낸 편지 주소가 다시 작성됩니다. 주소는 다음 패턴을 사용하여 다시 작성됩니다.
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
다음 예제에서는 메시지가 Bob(bob@fabrikam.com)에서 Exchange Server를 실행하는 회사의 서버에 있는 John의 사서함(john.onprem@contoso.com)으로 전송됩니다. 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 From | bob@fabrikam.com |
bob@fabrikam.com |
bounces+SRS=44ldt=IX@contoso.com |
| 헤더에서 | bob@fabrikam.com |
bob@fabrikam.com |
bob@fabrikam.com |
경우에 따라 SRS에서 다시 작성하는 릴레이된 메시지가 배달되지 않을 수 있으며 NDR이 생성될 수 있습니다.
이러한 NDR을 받으려면 테넌트 관리자가 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 건너뛰기
릴레이 풀 기능은 SRS 재작성 동작에 영향을 미치는 Microsoft 365에서 도입되었습니다. 이 릴레이 풀에 적합한 메시지는 SRS에서 다시 작성되지 않으며 Microsoft 365 SPF 레코드에 포함되지 않은 IP에서 전송됩니다. 이는 주로 SRS가 다시 쓰기로 이러한 오류를 수정해서는 안 되므로 Exchange Online으로 처음 전송할 때 SPF 검사가 실패하는 메시지에 영향을 줍니다. 자세한 내용은 아웃바운드 배달 풀의 릴레이 풀 설명서를 참조하세요.