한마디로 : 합법적 인 이메일은 정크 메일 폴더에 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