SMTP 인증 및 SPF, DKIM 그리고 DMARC 두 가지 로그인 방법은 서로 바꿔서 사용할 수 없습니다. SMTP AUTH는 클라이언트를 SMTP 서버에 인증합니다. SPF 도메인의 봉투 정책에 따라 전송 호스트를 평가하고, DKIM 메시지 서명을 확인하며, DMARC 표시되는 보낸 사람을 기준으로 정렬된 도메인 인증을 평가합니다. 성공적인 계정 로그인은 다운스트림 DMARC 실패와 공존할 수 있으며 인바운드 인터넷 메일은 제출 계정을 인증할 필요가 없습니다.
클라이언트-서버 관계 찾기
RFC 4954 AUTH 확장과 SASL 메커니즘의 사용을 정의합니다. 서버의 인증 정책은 인증된 클라이언트가 수행할 수 있는 작업을 결정합니다. 인증된 계정 이름을 안다고 해서 가능한 모든 봉투나 보이는 보낸 사람 주소가 자동으로 승인되는 것은 아닙니다. 제출 서비스는 일반적으로 추가 발신자, 중계 및 조직 제한을 적용합니다.
RFC 6409 메시지 제출과 릴레이를 구별합니다. 자격 증명이나 DNS 변경하기 전에 애플리케이션이 어떤 서비스를 사용하고 있는지 확인하세요. 공급자의 인증된 제출 서비스에 연결하는 장치는 인터넷 메일을 도메인의 MX 로 전달하는 원격 메일 서버와 다른 관계를 갖습니다. 외부 발신자에게 사서함 비밀번호를 제공하여 일반적인 인바운드 인증 실패를 해결하려고 시도하지 마십시오.
도메인 증거 다운스트림을 따르세요.
SPF RFC 7208 에 따라 연결 호스트와 관련 봉투 ID를 확인합니다. DKIM 확인은 다음을 사용합니다. 선택자 공개 키 자료를 찾고 RFC 6376 에 따라 해당 콘텐츠를 확인하기 위해 서명으로 도메인에 서명합니다. DMARC 사용하려면 전달 도메인과 표시되는 보낸 사람 도메인 간의 적절한 관계가 필요합니다. RFC 9989.
애플리케이션은 공급업체 계정에 성공적으로 인증한 다음 정렬되지 않은 반송 도메인 및 정렬되지 않은 DKIM 서명 도메인을 사용하여 보낼 수 있습니다. 다운스트림 SPF 와 DKIM 모두 통과하지만 DMARC 실패할 수 있습니다. 반대로, 적절하게 구성된 도메인은 해당 수신자 측 홉에서 SMTP AUTH 없이 서버 간에 배달되는 메일에서 DMARC 전달할 수 있습니다. 계정 자격 증명과 도메인 인증은 해당 경계에서 조사되어야 합니다.
비밀을 노출시키지 않고 증거를 활용하세요
로그인 실패의 경우 자격 증명과 토큰을 제외하고 서비스 끝점, 보안 전송 상태, 알려진 방법 및 전체 오류를 기록합니다. 로그인 후 보낸 사람 거부의 경우 허용된 보낸 사람 정책과 거부된 명령을 캡처합니다. 다운스트림 오류의 경우 신뢰할 수 있는 수신자 결과, 봉투 정보, DKIM d 및 s 값, 표시되는 보낸 사람 도메인을 얻습니다. 인증 페이로드를 티켓이나 기사 예시에 복사하지 마세요.
두 가지 가상 결과 비교
사례 A: 클라이언트는 제출 서비스를 인증하고 전송이 허용되지만 최종 수신자는 vendor.example 에 대한 SPF 패스와 d=vendor.example 의 DKIM 패스를 보고하고 From은 brand.example 사용합니다. 적용 가능한 DMARC 정책이 있고 해결되지 않은 평가 오류가 없다고 가정하면 도메인이 정렬되지 않고 메시지가 DMARC 실패합니다. 다른 비밀번호는 해당 도메인 관계를 변경할 수 없습니다.
사례 B: 서버는 해당 홉에 대한 SMTP AUTH 없이 일반 인바운드 메일을 수신자 MX 에게 전달합니다. 신뢰할 수 있는 수신자가 유효한 것을 보고합니다. DKIM 서명 d=brand.example 은 From= brand.example 과 일치합니다. 적용 가능한 정책이 있고 해결되지 않은 평가 오류가 없으면 정렬된 서명이 DMARC 패스를 제공할 수 있습니다. 이는 요청된 비즈니스 작업을 수행하기 위한 안전한 콘텐츠, 받은 편지함 배치 또는 권한을 설정하지 않습니다. 두 경우 모두 발명된 비교입니다. 자격 증명, 공급자 로그인 또는 암호화 테스트가 사용되지 않았습니다.
담당 구성을 복구하십시오.
AUTH가 실패하면 공급자가 현재 지원하는 인증 방법과 전송 요구 사항을 따르세요. 단순히 오래된 기사에 언급되어 있다는 이유만으로 오래된 메커니즘을 활성화하지 마십시오. 인증된 계정에 주소 사용 권한이 부족한 경우 일반 관리 프로세스를 통해 승인된 발신자 구성을 복구하세요. 하류인 경우 조정 실패하는 경우 다른 비밀번호를 사용하는 것이 도움이 될 것이라고 가정하는 대신 합법적인 발신자가 지원하는 봉투 또는 DKIM 도메인을 구성하세요.
수리 후 무해한 메시지를 사용하여 제출 및 최종 수신자 평가를 모두 테스트합니다. 클라이언트 인증, 보낸 사람 허용, 메시지 허용, 도메인 메커니즘 평가, 최종 처리 관찰 등 고유한 결과를 유지합니다. 단일 성공 레이블에는 너무 많은 내용이 숨겨져 있습니다. 연습에서는 이러한 결과를 분리하는 방법을 가르칩니다. 실행된 프로토콜 처리, DKIM 확인 또는 테넌트 구성을 요구하지 않습니다.
별도의 합격 결과 보관
- 클라이언트 인증: 엔드포인트, 지원되는 메커니즘 및 결과를 기록하며 비밀은 기록하지 않습니다.
- 보낸 사람 허용됨: 계정이 이 봉투와 보이는 보낸 사람에 대해 승인되었는지 확인하세요.
- 메시지 승인: 콘텐츠 전송 및 수신 서버 이후 응답을 유지합니다.
- 검증된 도메인: 신뢰할 수 있는 SPF / DKIM 결과와 DMARC 정렬을 독립적으로 기록합니다.
- 배송 관찰: 전송 승인을 받은 편지함 보장으로 변환하지 않고 수신자 측 결과를 유지합니다.