email-authentication

AWS SES 이메일 인증

Amazon Simple Email Service(SES)는 Simple Mail Transfer Protocol(SMTP)로 이메일을 보내요. 그런데 SMTP 자체에는 아무런 인증 기능이 없어서, 스패머가 남의 이메일인 것처럼 위장하거나 출처를 숨긴 메시지를 보내기 쉬워요. 이메일 헤더를 조작하고 발신 IP 주소를 속여서, 받는 사람이 받은 이메일이 진짜라고 믿게 만들 수 있죠.

대부분의 ISP는 이메일이 정당한지 판단하기 위해 이메일이 인증되었는지를 확인해요. 인증은 발신자가 "자신이 보내는 계정의 소유자"임을 증명하도록 요구하는 절차예요. 어떤 경우에는 ISP가 인증되지 않은 이메일의 전달을 거부하기도 하죠. 전달률(deliverability)을 최적화하려면 이메일을 인증하는 게 좋아요. 지금부터 SES에서 쓰는 주요 인증 방식인 SPF, DKIM, DMARC에 대해 알아볼게요.

출처: 문서

본문

SPF로 이메일 인증하기

SPF(Sender Policy Framework)는 이메일 스푸핑을 막기 위해 설계된 이메일 검증 표준이에요. 도메인 소유자는 SPF를 이용해 "내 도메인으로 이메일을 보낼 수 있는 서버"를 이메일 제공업체에 알려줘요. SPF는 RFC 7208에 정의되어 있어요.

SES로 보내는 메시지는 기본 MAIL FROM 도메인으로 amazonses.com의 하위 도메인을 자동으로 사용해요. 기본 MAIL FROM 도메인이 이메일을 보낸 애플리케이션(즉 SES)과 일치하므로 SPF 인증이 자동으로 성공해요. 그래서 SES에서는 SPF가 기본적으로 설정되어 있는 셈이에요.

만약 SES 기본 MAIL FROM 도메인을 쓰지 않고, 자신이 소유한 도메인의 하위 도메인을 쓰고 싶다면 이를 커스텀(custom) MAIL FROM 도메인이라고 해요. 이 경우 커스텀 MAIL FROM 도메인에 대한 SPF 레코드를 직접 게시해야 해요. 또한 SES는 커스텀 MAIL FROM 도메인이 이메일 제공업체가 보내는 바운스/컴플레인 알림을 받을 수 있도록 MX 레코드 설정도 요구해요. SPF 설정 절차와 MX·SPF(TXT) 레코드 게시 방법은 "Using a custom MAIL FROM domain"에서 확인할 수 있어요.

DKIM으로 이메일 인증하기

DKIM(DomainKeys Identified Mail)은 "특정 도메인에서 왔다고 주장하는 이메일이 실제로 그 도메인 소유자에 의해 승인된 것"임을 보장하기 위한 이메일 보안 표준이에요. 공개 키 암호화를 사용해서 이메일에 개인 키로 서명하고, 받는 쪽 서버는 도메인의 DNS에 게시된 공개 키로 전송 중에 이메일 내용이 변경되지 않았는지 검증해요.

DKIM 서명은 선택 사항이에요. DKIM을 지원하는 이메일 제공업체에서 전달률을 높이기 위해 DKIM 서명을 쓸 수 있어요. Amazon SES는 DKIM 서명을 위한 네 가지 옵션을 제공해요:

  • Easy DKIM: SES가 공개/개인 키 쌍을 생성하고, 해당 아이덴티티에서 보내는 모든 메시지에 DKIM 서명을 자동으로 추가해요.
  • Deterministic Easy DKIM(DEED): Easy DKIM을 쓰는 부모 아이덴티티의 DKIM 서명 속성을 자동으로 상속하는 복제 아이덴티티를 만들어, 여러 AWS 리전에서 일관된 DKIM 서명을 유지할 수 있어요.
  • BYODKIM(Bring Your Own DKIM): 직접 제공한 공개/개인 키 쌍으로 SES가 해당 아이덴티티에서 보내는 모든 메시지에 DKIM 서명을 추가해요.
  • 수동 DKIM 서명: SendRawEmail API로 보내는 이메일에 직접 DKIM 서명을 추가해요.

DKIM 서명 키 길이 — 많은 DNS 제공업체가 DKIM 2048비트 RSA 암호화를 완전히 지원하면서, Amazon SES도 더 안전한 인증을 위해 DKIM 2048을 지원하고 기본 키 길이로 사용해요. Easy DKIM은 1024 또는 2048비트 키 길이를 선택할 수 있고, 새 아이덴티티를 만들면 기본적으로 DKIM 2048로 생성돼요. 2048비트 키는 BYODKIM에서도 쓸 수 있는데, 이때 서명 키 길이는 최소 1024비트에서 최대 2048비트여야 해요.

DKIM 고려 사항 — DKIM은 "From" 주소에 사용하는 도메인에 대해서만 설정하면 돼요("Return-Path"나 "Reply-to" 주소의 도메인은 불필요). 여러 AWS 리전에서 이메일을 보낸다면 각 리전에서 DKIM 설정을 완료해야 해요. 그리고 DKIM 속성은 부모 도메인에서 상속되기 때문에, 도메인을 DKIM으로 검증하면 그 하위 도메인과 해당 도메인 주소를 쓰는 이메일 아이덴티티의 모든 이메일에도 DKIM 인증이 적용돼요. 개별 이메일 주소 아이덴티티의 DKIM 설정은 부모 도메인/하위 도메인의 설정을 자동으로 덮어쓸 수 있어요. 다만 발신자 평판을 떨어뜨리고 스팸 폴더로 분류되거나 도메인이 스푸핑될 위험이 커지므로 DKIM 서명을 비활성화하는 것은 일반적으로 권장되지 않아요.

DMARC 인증 프로토콜 준수하기

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM을 사용해 이메일 스푸핑과 피싱을 탐지하는 이메일 인증 프로토콜이에요. DMARC를 준수하려면 메시지가 SPF 또는 DKIM 중 하나로 인증되어야 해요. 둘 다 사용한다면 이메일 전송에 가장 높은 수준의 보호를 보장할 수 있어요.

각 인증 방식의 역할을 정리하면 이렇게 돼요:

  • SPF – 커스텀 MAIL FROM 도메인 대신 메일을 보낼 수 있는 메일 서버를 DNS TXT 레코드로 식별해요. 받는 메일 시스템은 이 SPF TXT 레코드를 참고해 메시지가 승인된 서버에서 왔는지 확인해요.
  • DKIM – 발신 메시지의 이메일 헤더에 디지털 서명을 추가해요. 받는 시스템은 이 서명으로 이메일이 도메인이 소유한 키로 서명되었는지 검증해요. 포워딩되면 메시지의 봉투(envelope)가 바뀌어 SPF 인증이 무효가 되지만, 디지털 서명은 헤더에 남아 있기 때문에 DKIM은 메시지가 포워딩되어도 작동해요(내용이 변경되지 않은 경우).
  • DMARC – SPF와 DKIM 중 적어도 하나와 도메인 정렬(alignment)이 되도록 보장해요. SPF는 MAIL FROM 주소의 도메인만 확인하고, DKIM은 DKIM 서명의 도메인만 확인할 뿐, 둘 다 받는 사람이 보는 "From" 주소는 확인하지 못해요. DMARC는 From 주소의 도메인이 SPF 또는 DKIM의 도메인과 정렬되도록 요구해서 이 문제를 해결해요.

DMARC 정리 — 받는 사람이 보는 From 주소가 SPF 또는 DKIM 중 하나로 인증되어야 DMARC를 통과해요. 두 검사가 모두 실패하면 DMARC도 실패해요. 따라서 SPF와 DKIM이 모두 있어야 DMARC가 발신 이메일 인증에 가장 좋은 기회를 확보할 수 있어요.

도메인에 DMARC 정책 설정하기 — DMARC를 설정하려면 도메인의 DNS 설정에 DMARC 설정을 담은 TXT 레코드를 추가해야 해요. Route 53을 쓴다면 "Working with Records"를 참고하면 돼요. 레코드 이름은 _dmarc.{{example.com}}(여기서 {{example.com}}은 내 도메인)이고, 값에는 도메인에 적용할 DMARC 정책이 들어가요. 예시는 다음과 같아요:

Name Type Value
_dmarc.example.com TXT "v=DMARC1;p=quarantine;rua=mailto:[email protected]"

이 예시 정책은 인증에 실패한 메시지를 스팸 폴더로 보내라는 뜻이에요(p=quarantine). 다른 옵션으로는 아무것도 하지 않는 p=none, 메시지를 완전히 거부하는 p=reject가 있어요. 그리고 rua=mailto:[email protected]은 DMARC에 실패한 모든 이메일에 대한 집계 보고서를 보내라는 의미예요(rua는 Reporting URI for Aggregate reports의 약자).

DMARC 구현 모범 사례 — DMARC 정책 강제(enforcement)는 점진적으로 단계를 나눠 도입하는 게 좋아요. 하위 도메인부터 시작해서 마지막에 최상위 도메인에 적용하면서 다음 순서를 따르는 걸 권장해요:

  1. 모니터링 모드로 시작(p=none): 인증에 실패한 메시지에 대한 통계를 요청하는 모니터링용 레코드를 만들어, 자신의 정상 트래픽이 얼마나 인증을 통과하는지 파악해요.
  2. 격리 정책 적용(p=quarantine): 정상 트래픽이 대부분 정렬된다고 판단되면, DMARC에 실패한 메시지를 스팸 폴더로 보내는 정책을 적용해요.
  3. 거부 정책 적용(p=reject): 마지막 단계로, DMARC에 실패한 메시지를 아예 수락하지 않는 정책을 적용해요. 거부는 SMTP 바운스로 이어지기 때문에 어느 메시지가 실패했는지 정확히 알 수 있어요.

SPF 기반 DMARC 준수 — 메시지가 다음 두 조건을 모두 만족해야 해요: (1) 커스텀 MAIL FROM 도메인의 DNS에 게시한 유효한 SPF(TXT) 레코드 기반의 SPF 검사를 통과해야 하고, (2) 이메일 헤더의 From 주소 도메인이 MAIL FROM 주소에 지정된 도메인(또는 그 하위 도메인)과 정렬되어야 해요. SES에서 SPF 정렬을 이루려면 도메인의 DMARC 정책이 엄격한 SPF 정책(aspf=s)을 지정하면 안 돼요(완화 정책 relaxed가 기본). 내 도메인의 SPF 정렬 상태는 다음 명령으로 확인할 수 있어요:

dig TXT _dmarc.{{example.com}}

출력의 Non-authoritative answer에서 v=DMARC1로 시작하는 레코드를 찾아보세요. aspf=r가 포함되어 있거나 aspf 문자열이 아예 없다면 SPF 완화 정렬을 쓰는 것이고, aspf=s가 있다면 엄격 정렬을 쓰는 거예요. 후자라면 시스템 관리자가 DMARC TXT 레코드에서 이 태그를 제거해야 해요.

DKIM 기반 DMARC 준수 — 메시지가 다음 두 조건을 모두 만족해야 해요: (1) 유효한 DKIM 서명이 있고 DKIM 검사를 통과해야 하고, (2) DKIM 서명에 지정된 도메인이 From 주소의 도메인과 정렬되어야 해요. SES는 기본적으로 엄격한 DKIM 정책을 사용해요. 준수를 위해 Easy DKIM을 설정하면 SES가 자동으로 이메일에 서명해요. DKIM 정렬 상태도 위와 같은 명령으로 확인할 수 있어요:

dig TXT _dmarc.{{example.com}}

이번에는 adkim=r이거나 adkim 문자열이 없으면 완화 정렬, adkim=s면 엄격 정렬이에요. 웹 기반 도구(dmarcian의 DMARC Inspector나 MxToolBox의 DMARC Check Tool)로도 확인할 수 있어요.

참고: SPF·DKIM·DMARC 세 가지를 함께 사용하면 도메인을 완전히 보호하면서 받는 사람의 받은편지함(inbox)으로의 전달률을 높일 수 있어요.

더 알아보기 (Learn more)