보낸 메일이 스팸함으로 가는 이유
발신 메일이 수신자의 스팸함으로 들어가거나, 반대로 누군가 회사 도메인을 사칭해 피싱 메일을 보내는 문제는 대부분 발신자 인증이 제대로 설정되지 않아 생긴다. SPF, DKIM, DMARC는 “이 메일이 정말 이 도메인에서 보낸 것이 맞는지”를 수신 서버가 확인할 수 있게 해주는 세 가지 인증 방식이다. 세 가지를 순서대로 갖추면 스팸 오분류를 줄이고 도메인 사칭 피해도 예방할 수 있다.
SPF, 어느 서버가 발신을 허용받았는지 알린다
SPF(Sender Policy Framework)는 특정 도메인을 대신해 메일을 보낼 수 있는 서버 목록을 DNS에 TXT 레코드로 공개하는 방식이다. 호스트 항목은 @ 또는 빈칸으로, 값은 v=spf1 include:_spf.google.com ~all처럼 발신을 허용할 서버를 include 구문으로 나열하는 형태다. 수신 서버는 메일이 도착하면 실제 발신 서버가 이 목록에 있는지 확인하고, 없으면 스팸으로 분류하거나 거부한다.
DKIM, 메일에 서명을 붙인다
DKIM(DomainKeys Identified Mail)은 발신 서버가 메일 내용에 암호화 서명을 붙이고, 수신 서버는 DNS에 공개된 공개키로 이 서명을 검증하는 방식이다. 보통 selector._domainkey 형태의 호스트명에 TXT(또는 서비스에 따라 CNAME) 레코드로 등록한다. 서명이 검증되면 메일이 전송 중에 위변조되지 않았다는 것과 실제로 해당 도메인에서 보낸 메일이라는 것이 함께 증명된다.
DMARC, SPF·DKIM 결과에 따라 처리 방침을 정한다
DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM 검증에 실패한 메일을 수신 서버가 어떻게 처리할지 정하는 정책이다. _dmarc 호스트에 TXT 레코드로 v=DMARC1; p=none; rua=mailto:admin@도메인; 형태로 등록한다. p 값에는 세 단계가 있다.
| 정책 | 동작 | 적용 시점 |
|---|---|---|
| none | 조치 없이 리포트만 수집 | 도입 초기, 모니터링 단계 |
| quarantine | 인증 실패 메일을 스팸함으로 보냄 | SPF·DKIM 안정화 이후 |
| reject | 인증 실패 메일 수신 자체를 거부 | 운영이 완전히 안정된 이후 |
설정 순서와 유의사항
- SPF 레코드를 먼저 등록하고, 실제 발신에 사용하는 모든 서버(자체 메일 서버, 마케팅 발송 서비스 등)를 빠짐없이 포함한다.
- DKIM을 설정해 메일 서명이 정상적으로 검증되는지 확인한다.
- SPF·DKIM 반영에는 보통 24~48시간이 걸리므로, 이 기간이 지난 뒤 DMARC를
p=none으로 먼저 등록해 리포트를 수집한다. - 리포트를 통해 정상 발신처가 모두 인증을 통과하는 것을 확인한 뒤, 단계적으로
quarantine→reject로 정책을 강화한다.
세 가지 레코드 중 하나라도 빠지면 인증 체계가 완전하지 않다. 특히 뉴스레터나 CRM 같은 외부 발송 서비스를 함께 쓰는 경우, 그 서비스의 발신 서버가 SPF·DKIM 설정에서 누락되지 않았는지 반드시 확인해야 한다.
정리
SPF는 발신 서버를 검증하고, DKIM은 메일 위변조를 막고, DMARC는 인증에 실패한 메일을 어떻게 처리할지 정한다. 세 가지를 한 번에 강한 정책으로 적용하기보다는, DMARC를 none으로 시작해 리포트로 정상 발신 현황을 확인한 뒤 단계적으로 정책을 강화하는 것이 실제 메일 발송에 지장을 주지 않으면서 스팸·피싱을 줄이는 방법이다.
