고객에게 견적서를 보내고 사흘이 지나도 답이 없어 전화를 걸면, 십중팔구 같은 말을 듣는다. "메일을 안 받은 것 같은데요?" 다시 메일함을 뒤져보라고 부탁하면 한참 후에 스팸함에서 우리 메일이 발견된다. 사장님은 광고도 안 보냈고, 첨부파일에 이상한 링크를 넣지도 않았다. 잘못한 사람은 없는데, 매출은 새고 있다.
2024년부터 구글과 야후가 보내는 메일에 도메인 인증을 강제하기 시작하면서 SPF, DKIM, DMARC 세 가지 약자가 작은 회사 사장님의 일이 되었다. 안 한다고 메일이 막히지는 않지만, 인증이 없으면 받는 쪽 메일 서버가 "이 발신자는 누구인지 모르겠다"고 판단해 조용히 스팸함으로 보낸다. 이 글에서는 도메인 인증을 처음 설정하는 작은 회사가 챙겨야 할 다섯 가지 원칙을 정리한다.
1. 우리 도메인으로 누가 메일을 보내는지부터 모두 적는다
SPF의 핵심은 "우리 회사 이름으로 메일을 보낼 수 있는 서버 목록"을 도메인에 박아두는 일이다. 그런데 작은 회사 사장님 대다수가 자기도 모르는 채로 여러 곳에서 회사 메일을 보내고 있다.
- 구글 워크스페이스 또는 네이버웍스 같은 업무용 메일
- 가입 폼·문의 폼이 자동으로 보내는 알림 메일 (사이트 호스팅이 발송)
- 스티비·메일침프 같은 뉴스레터 발송 서비스
- 아임웹·카페24 같은 솔루션이 보내는 주문 안내 메일
- 이메일 마케팅을 대신 해주는 외주 업체
이 다섯 군데가 같은 도메인으로 발송하고 있다면, SPF 레코드에 다섯 군데를 모두 기록해야 한다. 한 군데만 빠져도 그 채널의 메일은 인증에 실패한다. 설정 작업을 시작하기 전에 발송 채널 목록을 종이에 먼저 쓰는 것이 첫 번째 원칙이다.
2. SPF 레코드는 한 줄, include 10개 이내로 관리한다
SPF는 도메인의 TXT 레코드 한 줄로 표현된다. 가장 흔한 형태는 이렇다.
v=spf1 include:_spf.google.com include:_spf.mlsend.com ~all
여기서 자주 사고가 나는 지점이 두 가지다. 첫째, SPF 레코드는 한 도메인에 한 줄만 존재할 수 있다. 사장님이 새 메일 서비스를 붙일 때마다 "v=spf1 ..." 줄을 새로 추가하면, 두 번째 줄이 첫 번째 줄을 무효로 만들어 도메인 전체의 메일이 인증에 실패한다.
include 10회 제한
둘째, SPF는 인증 과정에서 외부 도메인을 조회하는 횟수가 10번을 넘으면 안 된다. include 한 줄이 내부적으로 또 다른 include를 부르는 경우가 많아서, 사장님이 보기에는 5줄밖에 안 써 놨는데 실제로는 13회 조회가 일어나기도 한다. "왜 갑자기 메일이 스팸으로 간다"는 신호 중 절반은 이 한계 초과 때문이다. 새 서비스를 추가할 때마다 SPF 체크 사이트로 횟수를 확인하는 습관이 필요하다.
3. DKIM은 발송 서비스마다 따로 켜고, 키 길이는 2048bit를 쓴다
SPF가 "이 IP가 우리 회사 메일을 보낼 수 있다"를 증명한다면, DKIM은 "이 메일의 내용이 중간에 변조되지 않았다"를 증명한다. 발송 서비스마다 고유한 키를 만들고, 그 키를 도메인에 등록해야 동작한다.
- 구글 워크스페이스: 관리 콘솔 → 앱 → Gmail → 이메일 인증에서 키 생성
- 네이버웍스: 관리자 → 도메인 → DKIM 설정
- 스티비·메일침프: 발송 도메인 등록 단계에서 자동 생성
여기서 놓치기 쉬운 부분이 키 길이다. 일부 서비스는 기본값이 아직 1024bit인데, 2026년 기준 받는 쪽 서버 상당수가 1024bit를 약한 키로 분류해 신뢰도를 깎는다. 새로 키를 만들 때는 가능한 한 2048bit를 선택하고, 일부 DNS 제공자가 한 줄에 255자 제한이 있다는 점도 함께 확인해야 한다.
4. DMARC는 p=none으로 시작해 데이터를 모으고 천천히 조인다
SPF와 DKIM이 통과했는지를 종합해 판단하는 정책이 DMARC다. 처음 도입할 때 가장 위험한 결정이 "바로 p=reject로 가자"는 것이다. 인증이 깨지는 채널이 하나라도 남아 있으면, 받는 쪽 서버가 그 메일을 즉시 거부하기 때문에 사장님이 보내는 거래처 메일이 통째로 사라진다.
3단계로 천천히 올린다
- 1~4주차: p=none으로 설정하고 rua= 주소로 매일 리포트만 수집한다. 어느 채널에서 인증이 실패하는지 데이터로 본다.
- 5~8주차: 실패하던 채널을 모두 수정한 뒤 p=quarantine으로 올린다. 의심 메일은 받는 쪽 스팸함으로 간다.
- 9주차 이후: 한 달 동안 실패 리포트가 안정적이면 p=reject로 올린다. 사칭 메일은 받는 쪽에서 거부된다.
이 단계를 건너뛰면 도메인 평판이 한 번에 무너진다. 평판은 쌓기 어렵고 깎이는 데는 하루면 충분하다.
5. From 주소와 발송 도메인은 반드시 같은 도메인으로 맞춘다
마지막 함정은 From 주소다. 사장님이 회사 도메인이 cyan-agency.com인데, 스티비에서 발송할 때 From을 [email protected]으로 설정해 두면 어떤 인증을 해도 무용지물이다. 받는 쪽은 도메인을 보고 cyan-agency.com의 SPF·DKIM·DMARC를 조회하지 않는다.
네 가지를 모두 같은 도메인으로 정렬해야 한다. From 주소의 도메인, SPF의 도메인, DKIM의 d= 값, DMARC를 발행한 도메인이 일치해야 "정렬(alignment)이 맞다"고 판정된다. 작은 회사 사장님이 "인증은 다 설정했는데 왜 안 되지?"라고 묻는 경우의 절반은 이 정렬 문제다.
실무 체크리스트
- From의 @ 뒤 도메인을 통일했는가
- 회사 사람들에게도 무료 메일이 아니라 도메인 메일을 쓰게 정리했는가
- 외주 디자이너·마케터가 우리 도메인으로 발송할 권한이 정확히 등록돼 있는가
- DMARC 리포트를 한 달에 한 번이라도 사람이 열어보는가
마치며
도메인 인증은 한 번 설정하고 잊어버리는 작업이 아니다. 회사가 새 서비스를 도입할 때마다, 외주 업체가 바뀔 때마다, 사이트를 옮길 때마다 같이 점검해야 한다. 하지만 사장님이 매번 DNS 콘솔을 열어 TXT 레코드와 씨름할 일은 아니다. 첫 설정만 제대로 잡아 두면 평판은 알아서 쌓이고, 견적 메일은 받은편지함의 가장 위에 도착한다.
CYAN 에이전시는 작은 회사 사이트를 만들 때 도메인·메일·발송 채널까지 함께 정리해 둔다. 사이트만 잘 만들어도 거기서 시작된 문의가 다시 사장님에게 닿지 못하면 의미가 없기 때문이다. 메일이 자꾸 스팸함으로 간다는 신호가 보인다면, 사이트 리뉴얼과 함께 도메인 인증부터 점검해 보시길 권한다.