Azure Communication Services 이메일의 보낸 사람 인증 지원을 위한 모범 사례
이 문서에서는 DNS 레코드에 대한 이메일 전송 모범 사례 및 공격자가 도메인에서 보낸 것처럼 보이는 메시지를 보내는 것을 방지하는 보낸 사람 인증 방법을 사용하는 방법을 제공합니다.
이메일 인증 및 DNS 설정
이메일을 보내려면 이메일 보낸 사람이 실제로 도메인을 소유하고 있는지 확인하고, 도메인 평판, 바이러스 검사, 스팸 필터링, 피싱 시도, 맬웨어 등을 포함하는 여러 단계가 필요합니다. 적절한 이메일 인증을 구성하는 것은 이메일에 대한 신뢰를 구축하고 도메인 평판을 보호하기 위한 기본 원칙입니다. 이메일이 인증 검사를 통과하면 수신 도메인은 해당 인증 검사와 관련된 ID에 대해 이미 설정된 평판을 유지하면서 해당 이메일에 정책을 적용할 수 있으며 수신자는 해당 ID가 유효하다는 것을 확신할 수 있습니다.
MX(메일 교환) 레코드
MX(메일 교환) 레코드는 이메일을 올바른 서버로 라우팅하는 데 사용됩니다. 도메인을 대신하여 이메일 메시지를 수락할 책임이 있는 메일 서버를 지정합니다. DNS는 이메일 도메인의 MX 레코드에 대한 최신 정보로 업데이트해야 합니다. 그렇지 않으면 일부 배달 오류가 발생합니다.
SPF(발신자 정책 프레임워크)
SPF RFC 7208은 도메인 소유자가 표준 DNS TXT 레코드를 통해 대신 이메일을 보낼 수 있도록 승인된 시스템 목록을 게시하고 유지 관리할 수 있는 메커니즘입니다. 이 레코드는 도메인을 대신하여 이메일을 보낼 권한이 있는 메일 서버를 지정하는 데 사용됩니다. 이메일 스푸핑을 방지하고 이메일 배달 가능성을 높이는 데 도움이 됩니다.
DKIM(도메인 키 식별 메일)
DKIM RFC 6376을 사용하면 조직에서 수신자가 유효성 검사할 수 있는 방식으로 메시지 전송에 대한 책임을 주장할 수 있습니다. 이 레코드는 이메일이 전송되는 도메인을 인증하는 데도 사용되며 이메일 스푸핑을 방지하고 이메일 배달 가능성을 높이는 데 도움이 됩니다.
DMARC(도메인 기반 메시지 인증, 보고 및 준수)
DMARC RFC 7489는 메일 발신 조직이 메일 수신 조직이 메일 처리를 개선하는 데 사용할 수 있는 메시지 유효성 검사, 처리 및 보고에 대한 도메인 수준 정책 및 기본 설정을 표현할 수 있는 확장 가능한 메커니즘입니다. 또한 이메일 수신자가 SPF 및 DKIM 검사에 실패한 메시지를 처리해야 하는 방법을 지정하는 데도 사용됩니다. 이렇게 하면 이메일 배달 가능성이 향상되고 이메일 스푸핑을 방지하는 데 도움이 됩니다.
ARC(인증된 수신 체인)
ARC 프로토콜 RFC 8617은 메시지에 대한 인증된 관리 체인을 제공하므로 메시지를 처리하는 각 엔터티가 이전에 처리한 엔터티와 각 홉에서 메시지의 인증 평가를 식별할 수 있습니다. ARC는 아직 인터넷 표준이 아니지만 채택이 증가하고 있습니다.
이메일 인증 작동 방식
이메일 인증은 보낸 사람(예: notification@contoso.com)의 이메일 메시지가 합법적이고 해당 이메일 도메인(예: contoso.com)의 예상 원본에서 온 것인지 확인합니다. 이메일 메시지에는 여러 발신자 또는 보낸 사람 주소가 포함될 수 있습니다. 이러한 주소는 다양한 목적으로 사용할 수 있습니다. 예를 들어 다음 주소를 살펴보겠습니다.
메일 보낸 사람 주소는 보낸 사람을 식별하고 배달 못 함 알림과 같이 메시지 배달에 문제가 발생할 경우 반송 알림을 보낼 위치를 지정합니다. 이는 이메일 메시지의 봉투 부분에 나타나며 이메일 애플리케이션에서는 표시되지 않습니다. 이를 5321.MailFrom 주소 또는 역방향 경로 주소라고도 합니다.
보낸 사람 주소는 메일 애플리케이션에서 보낸 사람 주소로 표시되는 주소입니다. 이 주소는 전자 메일의 작성자를 식별합니다. 즉, 메시지 작성을 담당하는 사람 또는 시스템의 사서함입니다. 5322.From 주소라고도 합니다.
SPF(발신자 정책 프레임워크)는 도메인의 메일에서 보낸 아웃바운드 이메일의 유효성을 검사하는 데 도움이 됩니다.
DKIM(도메인키 식별 메일)은 대상 이메일 시스템이 도메인에서 메일에서 아웃바운드로 보낸 메시지를 신뢰하도록 합니다.
DMARC(도메인 기반 메시지 인증, 보고 및 준수)는 SPF(발신자 정책 프레임워크) 및 DKIM(도메인키 식별 메일)과 함께 작동하여 메일 보낸 사람을 인증하고 대상 이메일 시스템이 도메인에서 보낸 메시지를 신뢰하도록 합니다.
DMARC 구현
SPF 및 DKIM과 함께 DMARC를 구현하면 스푸핑 및 피싱 이메일에 대한 풍부한 보호 기능을 제공합니다. SPF는 DNS TXT 레코드를 사용하여 지정된 도메인에 대해 인증된 전송 IP 주소 목록을 제공합니다. 일반적으로 SPF 검사는 5321.MailFrom 주소에 대해서만 수행됩니다. 즉, SPF 자체를 사용할 때 5322.From 주소가 인증되지 않습니다. 이를 통해 사용자는 SPF 검사를 통과하지만 스푸핑된 5322.From 보낸 사람 주소가 있는 메시지를 받을 수 있습니다.
SPF의 DNS 레코드와 마찬가지로 DMARC의 레코드는 스푸핑 및 피싱을 방지하는 데 도움이 되는 DNS 텍스트 (TXT) 레코드입니다. DMARC TXT 레코드를 DNS에 게시합니다. DMARC TXT 레코드는 발신 도메인의 소유자로 의심되는 이메일 작성자의 IP 주소의 유효성을 검사하여 이메일 메시지의 원본의 유효성을 검사합니다. DMARC TXT 레코드는 인증된 아웃바운드 전자 메일 서버를 식별합니다. 그런 다음 대상 전자 메일 시스템은 수신한 메시지가 인증된 아웃바운드 전자 메일 서버에서 보낸 것인지 확인할 수 있습니다. 이렇게 하면 도메인과 DMARC에서 보낸 모든 이메일의 5321.MailFrom과 5322.From 주소가 일치하지 않게 되어 해당 이메일에 대해 실패합니다. 이를 방지하려면 도메인에 DKIM을 설정해야 합니다.
DMARC 정책 레코드를 사용하면 도메인에서 이메일이 인증을 사용한다고 알릴 수 있습니다. 도메인 사용에 대한 피드백을 수집하기 위해 이메일 주소를 제공합니다. 인증 확인을 통과하지 못한 메시지 처리를 위해 요청된 정책을 지정합니다. 다음이 권장됩니다.
- DMARC 레코드를 게시하는 정책 문 도메인은 가능한 경우 "p=reject", 그렇지 않은 경우 "p=quarantine"입니다.
- "p=none", "sp=none" 및 pct<100에 대한 정책 문은 가능한 한 빨리 제거하는 것을 목표로 과도기 상태로만 표시되어야 합니다.
- 게시된 모든 DMARC 정책 레코드에는 최소한 DMARC 집계 보고서를 수신하기 위한 사서함을 가리키는 "rua" 태그가 포함되어야 하며 개인 정보 보호 문제로 인해 보고서를 수신할 때 회신을 보내지 않아야 합니다.
다음 단계
다음 문서는 사용자에게 유용할 수 있습니다.
- 이메일 클라이언트 라이브러리 숙지
- 사용자 지정 확인 도메인으로 이메일을 보내는 방법은 무엇인가요? 사용자 지정 도메인 추가
- Azure 관리되는 도메인으로 이메일을 보내는 방법은 무엇인가요? Azure 관리되는 도메인 추가