세 개의 레코드, 하나의 판단
- 1 · SPF
어떤 서버가 이 도메인으로 보낼 수 있는가
DNS 레코드에 도메인의 발송 권한이 있는 호스트를 나열하고, 수신 측은 SMTP 전송에 사용된 envelope 발신자와 대조합니다. 사람이 실제로 보는 From: 주소에 대해서는 아무것도 보장하지 않으며, 메일이 전달(forward)되면 깨집니다.[1]
- 2 · DKIM
메일이 스스로 들고 다니는 서명
발송 시스템이 선택한 헤더와 본문을 개인키로 서명하고, 수신 측은 DNS의 공개키로 검증합니다. 증명이 연결한 호스트가 아니라 메일 안에 들어 있으므로 SPF가 깨지는 일반적인 전달 상황에서도 유지됩니다.[2]
- 3 · DMARC
결과를 보이는 발신자와 연결
DMARC는 통과한 SPF 또는 DKIM 결과가 From: 헤더의 도메인과 정렬(alignment)되도록 요구하고, 아무것도 정렬되지 않을 때 수신 측이 취할 조치를 공표하며, 집계 보고서를 요청합니다. 이 정렬이 앞의 둘을 독자에게 의미 있게 만드는 부분입니다.[3]
- 4 · 사업자 기준
수신 사업자는 더 높은 기준을 둡니다
대형 사업자는 프로토콜 기본선 위에 자체 발신자 요구사항을 공개합니다. Google은 모든 발신자에 인증을 요구하고, 대량 발신자에게는 SPF·DKIM과 DMARC 정렬, 마케팅 메일의 원클릭 수신거부, 공개된 기준 아래로 유지되는 스팸 신고율을 요구합니다.[4]
세 가지는 각각 다른 것을 증명합니다
세 레코드를 한 묶음으로 설명하는 경우가 많은데, 그러면 왜 셋 다 필요한지가 가려집니다. SPF는 호스트를 인가하고 envelope 발신자를 검사합니다. DKIM은 도메인 키를 가진 주체가 서명했고 서명된 부분이 변조되지 않았음을 증명합니다. 둘 다 독자에게 보이는 주소에 대해서는 말하지 않습니다.[1][2][3]
그 증명을 보이는 신원과 연결하는 것이 DMARC이고, 셋 중 유일하게 보고를 돌려줍니다. 집계 보고서를 읽지 않고 DMARC만 공표하면 가치의 대부분을 버리는 셈입니다. 그 보고서가 곧 '누가 우리 도메인으로 보내고 있는가'의 목록입니다.[1][2][3]
메일을 끊지 않는 순서로 적용하세요
먼저 SPF와 DKIM을 공표하고, 우리 이름으로 보내는 모든 시스템에서 통과하는지 확인합니다. 그다음 보고 주소를 넣은 모니터링 모드로 DMARC를 공표하고, 청구 주기가 한 번 돌 만큼 충분히 유지합니다. 분기 청구서나 연간 갱신 안내처럼 2주 관찰로는 놓치는 발신원이 바로 이런 것들입니다.[3][4]
정책은 그 뒤에 조입니다. 거부(reject)보다 격리(quarantine)가 먼저입니다. 곧바로 거부로 가는 것은, 아무도 기억하지 못하던 시스템이 급여 안내를 보내고 있었다는 사실을 그 안내가 멈춘 순간에 알게 되는 전형적인 방법입니다.[3][4]
- 발송하는 모든 시스템에 대해 SPF·DKIM 공표
- 보고 주소를 넣어 DMARC를 모니터링 모드로 공표
- 정상 발신자가 실패하지 않을 때까지 보고서 확인
- 격리로 조인 뒤 거부로 전환
원인은 대개 잊고 있던 발신 시스템입니다
대부분의 전달 문제는 레코드가 잘못된 것이 아닙니다. 우리 도메인으로 보내면서 목록에 들어가지 않은 시스템이 원인입니다. 헬프데스크, CRM, 청구 플랫폼, 마케팅 도구, 모니터링 알림, 웹사이트 문의 폼, 일정 초대, 그리고 지금 이 자리의 누구보다 오래된 서버의 레거시 애플리케이션입니다.[3]
그래서 문법보다 목록이 중요합니다. 문법은 맞지만 빠진 것이 있는 레코드가 최악의 결과를 만듭니다. 대부분의 메일은 가고 일부만 조용히 실패하며, 고객이 '아무것도 못 받았다'고 말하기 전까지 실패가 보이지 않습니다.[3]
대량 발송 기준은 프로토콜보다 엄격합니다
DMARC 통과는 목표가 아니라 기본선입니다. 사업자 요구사항은 RFC에 없는 운영 조건을 더합니다. 마케팅 메일의 작동하는 원클릭 수신거부, 낮은 신고율, 발송 호스트의 정상 정·역방향 DNS, 전송 구간 TLS 같은 것들입니다.[4]
이 조건들은 설정이 아니라 행동에 관한 것이라 한 번 맞춰두고 잊을 수 없습니다. 1년 전에는 깨끗했던 목록에 오랜 공백 뒤 발송하면 신고율이 오르고, 같은 도메인을 쓰는 거래 메일의 전달률까지 함께 잃습니다. 마케팅 발송과 거래 발송을 서로 다른 서브도메인으로 분리하는 이유가 이것입니다.[4]