이메일 인증은 DNS에 레코드를 추가하는 데서 끝나지 않습니다. 실제 발송 경로를 빠짐없이 파악하고 SPF와 DKIM을 통과시킨 뒤, DMARC 보고서를 바탕으로 정책을 단계적으로 강화해야 합니다.
세 인증 기술의 역할부터 구분하기
SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버와 서비스를 DNS에 등록하는 방식입니다. 수신 서버는 실제 발송 서버의 IP 또는 호스트가 SPF 정책에 포함되는지 확인합니다.
DKIM은 발송 시스템이 메일에 전자서명을 붙이고, 수신 서버가 DNS에 공개된 공개키로 서명을 검증하는 방식입니다. 발송 도중 본문이나 주요 헤더가 변경되면 검증에 실패할 수 있습니다.
DMARC는 SPF 또는 DKIM 결과와 사람이 보는 From 주소의 도메인이 일치하는지 확인하고, 실패한 메일을 어떻게 처리할지 정하는 정책입니다. 따라서 세 기술은 대체재가 아니라 함께 설계해야 하는 인증 체계입니다.
- SPF: 발송 서버와 외부 이메일 서비스의 허용 목록 관리
- DKIM: 메시지 서명과 공개키 검증
- DMARC: From 도메인 정렬, 실패 정책, 집계 보고서 수신
- 실제 발송 도구가 여러 개라면 도메인별·서비스별 발송 경로를 먼저 분리해 기록
DNS 레코드 설정 전에 발송 경로를 목록화하기
설정 오류의 상당수는 DNS 문법보다 누락된 발송 서비스에서 발생합니다. CRM, 마케팅 자동화 도구, 영업 담당자의 메일 클라이언트, 고객지원 시스템, 거래명세서 발송 서비스처럼 같은 도메인을 사용하는 모든 경로를 확인해야 합니다.
각 서비스에 대해 사용하는 From 도메인, Return-Path 또는 Envelope-From 도메인, DKIM 서명 도메인, SPF에 필요한 include 값, 테스트 수신 주소를 표로 관리하세요. 서비스가 제공한 값을 임의로 추측하거나 다른 업체의 값을 재사용하지 않는 것이 안전합니다.
- 발송 서비스명과 담당자
- 사용하는 From 주소 및 하위 도메인
- SPF에 필요한 include 또는 IP 정보
- DKIM selector와 공개키 제공 여부
- DMARC 보고서 수신 주소와 개인정보 처리 기준
- 서비스 해지 시 DNS에서 제거할 항목과 영향 범위
SPF와 DKIM을 순서대로 구성하는 방법
SPF는 도메인당 하나의 TXT 레코드로 관리해야 합니다. 기존 SPF가 있다면 새 레코드를 추가하는 대신 기존 값에 필요한 발송원을 합쳐야 하며, 서비스 제공업체가 안내한 include를 정확히 입력해야 합니다. 중복 SPF 레코드나 불필요한 발송원은 인증 실패와 관리 복잡성을 키울 수 있습니다.
DKIM은 서비스가 안내한 selector 이름으로 공개키 TXT 레코드를 등록합니다. selector는 서비스마다 다를 수 있으므로 동일한 selector를 덮어쓰지 않도록 확인하세요. 여러 발송 서비스를 운영한다면 서비스별 selector를 분리하고, 키 교체 절차와 담당자를 문서화합니다.
레코드 저장 후에는 발송 서비스의 인증 상태만 보지 말고 실제 수신 메일의 원문 헤더에서 SPF와 DKIM 결과를 확인해야 합니다. 테스트 메일은 내부 계정뿐 아니라 주요 수신 환경과 외부 테스트 주소에서 각각 확인하세요.
- 기존 SPF TXT 레코드가 있는지 먼저 조회
- 새 발송원을 추가할 때 기존 SPF를 덮어쓰지 않기
- SPF에 사용하지 않는 IP와 include 정리
- DKIM selector와 공개키의 철자·따옴표·줄바꿈 확인
- 테스트 메일의 Authentication-Results 헤더에서 spf=pass, dkim=pass 여부 확인
- DKIM 서명 도메인과 From 도메인이 정렬되는지 확인
DMARC는 모니터링에서 강제 정책으로 단계 전환하기
처음부터 강한 정책을 적용하면 정상 발송까지 격리되거나 거부될 수 있습니다. 모든 발송 경로가 SPF 또는 DKIM을 통과하고 From 도메인과 정렬되는지 확인한 뒤, DMARC를 모니터링 중심으로 시작하는 편이 안전합니다.
DMARC 레코드는 일반적으로 _dmarc 하위 도메인에 TXT로 등록합니다. 정책에는 실패 처리 방식, 집계 보고서 주소, 필요 시 포렌식 보고서 관련 설정과 정렬 모드를 포함할 수 있습니다. 보고서 수신 주소는 실제로 분석할 수 있는 메일함이나 전용 분석 도구로 지정해야 합니다.
보고서에서 알 수 없는 발송원, SPF 또는 DKIM 실패, 정렬 실패가 반복되지 않는지 확인한 뒤 정책을 강화합니다. 정책 변경은 한 번에 모든 도메인에 적용하지 말고 대표 발송 도메인이나 하위 도메인에서 영향 범위를 확인하세요.
- 1단계: DMARC 모니터링 정책으로 합법적 발송원 수집
- 2단계: 실패 원인을 서비스별로 분류하고 SPF·DKIM 정렬 수정
- 3단계: 정상 발송 비중과 예외 경로를 확인한 뒤 격리 정책 검토
- 4단계: 미승인 발송이 실제 수신되지 않도록 거부 정책 검토
- 정책 강화 전 고객지원·거래 메일·자동화 캠페인 발송 여부 재확인
- 보고서에 개인정보가 포함될 수 있으므로 수신·보관 권한 제한
설정 완료 후 주간 운영 점검표
이메일 인증은 일회성 프로젝트가 아니라 발송 도구와 조직 구조가 바뀔 때마다 갱신하는 운영 항목입니다. 신규 서비스 도입, 도메인 이전, 대량 발송 시스템 변경, DKIM 키 교체가 있을 때는 변경 전후로 테스트해야 합니다.
인증 통과만으로 도달률이 보장되는 것은 아닙니다. 반송, 스팸 신고, 수신거부, 발신자 평판과 함께 확인하고, 인증 실패가 특정 캠페인이나 특정 발송 시스템에 집중되는지 구분해야 합니다.
- 주간: DMARC 집계 보고서에서 신규 발송원과 실패율 추세 확인
- 주간: SPF에 등록된 불필요한 서비스와 IP 검토
- 월간: DKIM 키와 selector의 소유자·교체 일정 확인
- 변경 시: DNS 변경 전후 테스트 메일의 원문 헤더 보관
- 장애 시: 최근 추가된 발송 서비스와 DNS 변경 이력부터 대조
- 종료 시: 사용하지 않는 발송 서비스의 SPF·DKIM·접근권한 정리
자주 묻는 질문
SPF와 DKIM 중 하나만 설정해도 되나요?
가능한 수신 환경이 있을 수 있지만 권장되지 않습니다. SPF는 발송 서버 기준이고 DKIM은 메시지 서명 기준이므로 서로 다른 실패 원인을 보완합니다. DMARC 통과를 위해서는 SPF 또는 DKIM 중 하나가 From 도메인과 정렬된 상태로 성공해야 하지만, 운영 안정성을 위해 두 인증을 모두 구성하는 편이 안전합니다.
DMARC 정책을 바로 reject로 설정해도 되나요?
모든 합법적 발송 경로를 확인한 경우에만 검토해야 합니다. 먼저 모니터링 정책으로 보고서를 수집하고, 누락된 CRM·자동화 도구·거래 메일이 없는지 확인한 뒤 단계적으로 강화하세요. 그렇지 않으면 정상적인 고객 커뮤니케이션이 거부될 수 있습니다.
SPF 레코드를 여러 개 등록하면 안 되나요?
도메인에 SPF 정책이 여러 개 있으면 수신 서버가 정책을 해석하지 못할 수 있습니다. 기존 TXT 레코드를 조회한 뒤 하나의 SPF 정책에 필요한 발송원을 통합하고, 더 이상 사용하지 않는 include와 IP는 제거해야 합니다.
DKIM은 언제 키를 교체해야 하나요?
정해진 주기만으로 판단하기보다 서비스의 보안 정책, 키 노출 의심, 발송 시스템 변경, 담당자 권한 변경을 기준으로 교체합니다. 새 selector를 먼저 등록해 검증한 뒤 발송 시스템을 전환하고, 기존 selector는 기존 메일 검증에 필요한 기간을 고려해 바로 삭제하지 않는 방식으로 운영합니다.