[server] 하이브리드 배포에서 Office 365에 대한 모든 외부 메일이 SPF에 실패하고 EOP에 의해 정크로 표시됨
한마디로 : 합법적 인 이메일은 정크 메일 폴더에 EOP (Exchange Online Protection)가 이메일 메시지를 정크 (SCL5) 및 SPF 실패로 스탬핑하므로 정크 폴더에 도착합니다. 이는 모든 외부 도메인 (예 : gmail.com/hp.com/microsoft.com)에서 클라이언트 도메인 (contoso.com)으로 발생합니다.
배경 정보 :
사서함을 Office 365 (Exchange Online)로 마이그레이션하기 시작했습니다. 하이브리드 배포 / 공존 공존 구성입니다. 여기서 :
- 온-프레미스 = Exchange 2003 (레거시) 및 2010 (하이브리드 배포 용으로 설치됨)
- 오프-프레미스 = Office 365 (Exchange Online)
- EOP는 SPF 검사를 위해 구성되었습니다.
- 온-프레미스에서 Exchange Online으로 모든 사서함 마이그레이션을 완료하지 않았으므로 MX 레코드가 온-프레미스를 가리키고 있습니다.
외부 사용자가 조직의 Office 365 사서함으로 전자 메일을 보낼 때 (메일 흐름 : 외부-> 메일 게이트웨이-> 온-프레미스 메일 서버-> EOP-> Office 365) EOP가 SPF 조회 및 하드 / 소프트를 수행하는 경우 메일을 수신 한 메일 게이트웨이의 외부 IP 주소가있는 메시지 실패
온-프레미스 사서함에는이 문제가 표시되지 않으며 Office 365로 마이그레이션 된 사서함 만 표시됩니다.
예 1 : Microsoft에서 O365로
Authentication-Results: spf=fail (sender IP is 23.1.4.9)
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9;
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5
예 2 : HP에서 O365로
Authentication-Results: spf=none (sender IP is 23.1.4.9)
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none
(message not signed) header.d=none; Received-SPF: None
(protection.outlook.com: hp.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 5
예 3 : Gmail에서 O365로
Authentication-Results: spf=softfail (sender IP is 23.1.4.9)
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com;
dkim=fail (signature did not verify) header.d=gmail.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
gmail.com discourages use of 23.1.4.9 as permitted sender)
X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report가 포함 된 메시지 헤더는 http://pastebin.com/sgjQETzM을 참조하십시오 .
참고 : 23.1.4.9는 온-프레미스 하이브리드 Exchange 2010 서버 커넥터의 Exchange Online에 대한 공용 IP 주소입니다.
하이브리드 배포의 공존 단계에서 외부 전자 메일이 EOP에 의해 정크 메일로 표시되지 않도록하려면 어떻게해야합니까?
[2015-12-12 업데이트]
이 문제는 설정과 관련이 없으므로 Office 365 지원 (에스컬레이션 / 백엔드 팀)에 의해 해결되었습니다.
우리는 다음을 제안했습니다.
- EOP 허용 목록에서 퍼블릭 IP를 화이트리스트에 추가합니다 (시도되었습니다.)
- 도메인에 대한 SPF 레코드 추가 : “v = spf1 ip4 : XXX.XXX.XXX.XXX ip4 : YYY.YYY.YYY.YYY include : spf.protection.outlook.com -all”(이 제안이 유효하다고 생각하지 마십시오. EOP는 gmail.com의 SPF 레코드에 지정되어 있지 않으므로 SMTP IP 주소에 대해 gmail.com을 확인하지 않아야합니다. SPF가 작동하는 방식으로 보이지 않습니다.)
- TLS가 활성화되어 있는지 확인하십시오 (아래 참조).
핵심은 세 번째 요점입니다. “TLS를 사용하지 않으면 로컬 Exchange에서 들어오는 전자 메일은 내부 / 신뢰 전자 메일로 표시되지 않으며 EOP는 모든 레코드를 확인합니다.”
지원팀은 메일 헤더에서 아래 줄로 TLS 문제를 확인했습니다.
- X-MS-Exchange-Organization-AuthA : 익명
이것은 EOP가 이메일을 수신했을 때 TLS가 활성화되지 않았 음을 나타냅니다. EOP는 수신 이메일을 신뢰 이메일로 처리하지 않았습니다. 올바른 것은 다음과 같아야합니다.
- X-MS Exchange 조직 -AuthA : 내부
그러나 이것은 설정에 의한 것이 아닙니다. 지원 담당자는 Exchange 2010 하이브리드 서버에서 자세한 SMTP 로그를 확인하여 설정이 올바른지 확인했습니다.
거의 동시에 그들의 백엔드 팀은 문제의 원인을 정확히 알려주지 않고 문제를 해결했습니다 (불행히도).
수정 한 후 메시지 헤더가 아래와 같이 크게 변경되었음을 알 수 있습니다.
Exchange 2003에서 Office 365 로의 내부 원본 메일의 경우 :
-
X-MS-Exchange-Organization-AuthA : 내부 ( “익명”)
-
SCL = -1 (SCL = 5)
- SPF 수신 : SoftFail (동일 함)
그리고 Office 365로 보내는 외부 메일 (예 : gmail.com)의 경우 :
-
X-MS-Exchange-Organization-AuthAs : 익명 (동일 함)
-
SCL = 1 (SCL = 5)
-
SPF 수신 : SoftFail (동일 함)
SPF 검사가 여전히 Office 365에 대한 gmail.com (외부)에 대해 소프트 오류가 발생하더라도 지원 담당자는 문제가 없으며 모든 메일은 정크 폴더 대신받은 편지함으로 이동합니다.
참고로 문제를 해결하는 동안 백엔드 팀은 구성 상 사소한 구성 문제를 발견했습니다. IP 허용 목록에 정의 된 인바운드 커넥터 (예 : Exchange 2010 하이브리드 서버의 공용 IP)의 IP가 다른 Office 365 지원에서 제안되었습니다. 문제 해결 단계). 이를 수행 할 필요가 없으며 실제로 라우팅 문제가 발생할 수 있음을 알려줍니다. 그들은 초기 단계에서 이메일이 스팸으로 표시되지 않았으므로 여기에도 가능한 문제가 있다고 언급했습니다. 그런 다음 IP 허용 목록에서 IP를 제거했습니다. 그러나 IP 허용 목록을 설정하기 전에 스팸 문제가 발생했습니다. 허용 목록이 원인이라고 생각하지 않았습니다.
결론적으로 지원 담당자는 “EOP 메커니즘이어야한다”고 말했다. 따라서 모든 것은 메커니즘으로 인해 발생합니다.
관심있는 사람은 지원 담당자 중 한 명과 함께하는 문제 해결 스레드를 여기에서 볼 수 있습니다. https://community.office365.com/en-us/f/156/t/403396
답변
메일 흐름이 하이브리드 서버에서 O365로 직접 전달되고 있습니까?
하이브리드 마법사를 실행하면 로컬 및 O365에서 커넥터를 만들어야합니다.이 커넥터는 포리스트 간의 메일 흐름을 내부 메일로 밟습니다. 즉, EOP / 스팸 검사를 무시하고 해당 SPF 메시지가 표시되지 않아야합니다.
에지 장치가 헤더를 수정하는 경우 서버와 O365간에 메시지 헤더를 수정하지 않아야합니다. 하이브리드 마법사에서 작성된 커넥터를 대체 할 수있는 기존 커넥터가 없는지 확인하십시오. 생성 된 기존 커넥터를 항상 삭제하고 마법사를 다시 실행하여 다시 만들 수 있습니다.
Exchange에서 전송 규칙을 확인하고 O365로 이동하기 전에 메시지를 수정하지 않는지 확인하십시오. 규칙이 해제되어 있으면 다시 테스트하여 문제가 아닌지 확인하십시오.
페더레이션이 올바르게 구성되었는지 마지막으로 확인하십시오. 그렇지 않은 경우 메일이 올바르게 처리되지 않을 수 있습니다. 하이브리드 마법사를 다시 실행하면 도움이됩니다.
답변
여기 전문가는 아니지만 Exchange와 함께 플레이 한 지 오랜 시간이 지났지 만 최선을 다해 답변하려고 노력할 것입니다.
디자인을 잠시 논의 해 보자. 먼저 모든 트래픽을 EOP로 라우팅 한 다음 사내 구축 형 Exchange 서버로 라우팅하지 않겠습니까? 좋은 기능을 잃어 버리면 단일 위치에서 스팸을보다 쉽게 제어 할 수 있습니다 (로컬 Exchange에 스팸 방지 필터도 있다고 가정).
이제 스팸 문제로 넘어가겠습니다.
- 메일 흐름 및 커넥터 : 들어오는 모든 전자 메일이 발신자 메일 서버 IP 주소 대신 동일한 23.1.4.9 IP 주소에서 생성 된 것으로 보이면 SPF 검사가 실패 할 수 있으므로 커넥터가 올바르게 설정되지 않은 것 같습니다. 이는 발신자 IP와 해당 발신자 IP의 도메인 이름을 확인하는 것이 목적이기 때문입니다. 커넥터 설정 방법을 검토하는 데 확실히 시간을 할애 할 것입니다. https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150) ) .aspx
- EOP 스팸 필터 및 연결 필터 : 커넥터의 IP 설정이 올바르게 완료된 경우 (예 : EOP 에서 스팸 / 연결 필터를 보는 시간) IP 23.1.4.9에서 들어오는 이메일 확인을 우회하는 필터를 작성합니다. 그러나 모든 수신 전자 메일이 스팸 필터 검사 목록을 무시하게하므로 이전 지점에서 언급 한 문제가 발생하여 커넥터를 확인하고 우선적으로 수신 전자 메일을 EOP로 라우팅합니다.