웹사이트를 운영하다 보면 누구나 한 번쯤 겪는 문제가 있다. 문의 폼 자동 답장이 고객에게 안 간다. 주문 확인 메일이 며칠 뒤에 스팸함에서 발견된다. 정성껏 만든 뉴스레터의 오픈율이 유독 낮다. 대부분의 경우 원인은 메일 본문이 아니라 도메인이 발송자로서 충분히 인증되지 않았기 때문이다.
지메일, 네이버, 다음 같은 메일 서버는 매일 수십억 통의 메일을 분류하며, 발송자가 진짜 그 도메인의 주인이 맞는지를 DNS 레코드로 검증한다. 이 검증에 통과하지 못하면 아무리 정상적인 내용이어도 스팸함으로 분류되거나 아예 차단된다. 다행히 해결책은 표준화돼 있다. SPF, DKIM, DMARC 세 가지다.
SPF — "이 도메인으로 메일을 보낼 수 있는 서버 목록"
SPF(Sender Policy Framework)는 도메인의 발송 허용 서버 목록을 DNS에 선언하는 레코드다. 받는 쪽 서버는 메일이 도착하면 헤더의 발송 서버 IP가 그 목록에 있는지 확인한다. 목록에 없으면 위조 가능성이 있다고 판단한다.
예를 들어 회사에서 구글 워크스페이스로 메일을 보내고, 홈페이지 문의 폼에서는 Mailgun을 쓴다면 TXT 레코드에 다음과 같이 넣는다.
v=spf1 include:_spf.google.com include:mailgun.org ~all
마지막의 ~all은 "목록에 없는 서버는 소프트 실패"라는 뜻이다. 초기에는 ~all로 시작해 모니터링한 뒤, 안정되면 -all(하드 실패)로 바꾸는 것이 안전하다.
DKIM — "이 메일이 중간에 변조되지 않았다는 서명"
DKIM(DomainKeys Identified Mail)은 발송 서버가 메일에 전자서명을 붙여 보내고, 받는 서버가 도메인의 공개키로 이 서명을 검증하는 방식이다. SPF가 "누가 보냈는가"를 확인한다면 DKIM은 "내용이 손상되지 않았는가"까지 확인한다.
설정은 메일 서비스 업체(구글 워크스페이스, 네이버 웍스, SendGrid, Mailgun 등)에서 제공하는 공개키 문자열을 TXT 레코드로 넣기만 하면 된다. 보통 selector._domainkey.도메인 형태로 등록한다. 서비스마다 셀렉터 이름이 다르기 때문에, 여러 메일 경로를 쓴다면 각각 따로 등록해야 한다.
DMARC — "SPF와 DKIM이 실패하면 어떻게 할지 결정하는 규칙"
DMARC(Domain-based Message Authentication, Reporting and Conformance)는 앞의 두 검사가 실패했을 때 받는 서버가 어떻게 행동할지를 도메인 주인이 직접 지시하는 정책이다.
- p=none — 아무 조치도 하지 않는다. 모니터링 단계에서 먼저 사용한다.
- p=quarantine — 스팸함으로 보낸다.
- p=reject — 받지 않고 거부한다.
또한 rua=mailto: 주소를 지정해 두면 매일 받는 서버들이 "당신 도메인으로 메일이 얼마나 왔고 얼마나 통과했는지" 집계 리포트를 보내준다. 이 리포트를 통해 도메인이 스푸핑에 얼마나 노출돼 있는지 파악할 수 있다.
2024년부터 구글과 야후가 하루 5,000통 이상 발송자에게 DMARC를 사실상 의무화했기 때문에, 뉴스레터를 운영하는 곳이라면 더 이상 선택이 아닌 필수다.
실전 체크리스트 — 설정부터 검증까지
- 홈페이지에서 메일이 나가는 모든 경로를 정리한다. 문의 폼, 주문 확인, 뉴스레터, 비밀번호 재설정, 결제 영수증 등.
- 각 경로의 메일 발송 서비스에서 SPF include 값과 DKIM 공개키를 받아둔다.
- 도메인 DNS에 SPF, DKIM, DMARC(p=none) TXT 레코드를 등록한다.
- Gmail, Outlook, 네이버로 각각 테스트 메일을 보내 본다. 수신한 메일 원문 보기에서 SPF=pass, DKIM=pass, DMARC=pass가 모두 찍히는지 확인한다.
- 1~2주 동안 DMARC 리포트를 확인하며 누락된 발송 경로가 없는지 살핀다.
- 문제가 없으면 p=quarantine, 안정되면 p=reject로 강화한다.
실무에서 자주 만나는 함정
SPF 레코드를 두 개 만드는 실수. 한 도메인에는 SPF TXT 레코드가 딱 하나만 있어야 한다. 서비스가 늘어날 때마다 새로 추가하지 말고 기존 레코드의 include 항목을 늘려야 한다.
메일 발송 서비스를 바꾸고도 DNS를 그대로 두는 경우. 사용하지 않는 include는 바로 지워야 한다. 쓰지 않는 서비스의 IP가 남아 있으면 오히려 스팸 평판이 떨어진다.
발송자 주소와 회신자 주소를 다르게 설정하는 경우. From의 도메인과 Return-Path 도메인이 일치해야 DMARC가 정렬(alignment) 검사를 통과한다. 외부 뉴스레터 툴을 쓸 때 자주 어긋나는 부분이다.
메일 발송은 "보내는 순간"이 아니라 "도착한 순간"에 끝나는 일이다. 받은함에 들어가지 못한 메일은 존재하지 않은 것과 같다.
CYAN 에이전시에서 홈페이지를 맡아 운영할 때 가장 먼저 점검하는 항목 중 하나가 바로 이 도메인 인증 설정이다. 사이트 자체는 멋지게 만들었는데 문의 답장이 고객에게 안 가서 계약을 놓치는 사례가 생각보다 많다. 도메인 인증은 한 번 제대로 잡아두면 오래 가는 기반 작업이니, 새 웹사이트를 오픈할 때 혹은 리뉴얼 시점에 반드시 함께 챙기기를 권한다.