이메일 인증은 DNS 레코드를 추가하는 작업에서 끝나지 않습니다. 발송 주체를 정리하고 정렬 상태와 인증 결과를 확인한 뒤 DMARC 정책을 단계적으로 강화해야 합니다.
세 인증 기술의 역할부터 구분하기
SPF는 해당 도메인을 대신해 메일을 보낼 수 있는 서버를 DNS에 선언합니다. 수신 서버는 발송 IP가 SPF에 포함됐는지 확인하지만, 전달 과정에서 발송 IP가 바뀌면 인증이 실패할 수 있습니다.
DKIM은 발송 시스템이 메일에 전자서명을 붙이고 수신 서버가 공개키로 검증하는 방식입니다. 본문과 주요 헤더가 변경되지 않았는지 확인할 수 있으며, 발송 시스템별 selector를 사용해 키를 구분합니다.
DMARC는 SPF 또는 DKIM 인증 결과가 수신자에게 보이는 From 도메인과 정렬되는지 확인하고, 실패한 메일을 어떻게 처리할지 정책으로 선언합니다. 따라서 DMARC는 SPF와 DKIM을 대체하는 설정이 아니라 두 인증 결과를 통제하는 운영 계층입니다.
- SPF: 승인된 발송 서버와 서비스 목록 관리
- DKIM: 발송 시스템별 서명과 공개키 관리
- DMARC: From 도메인 정렬, 실패 정책, 집계 보고서 관리
설정 전에 발송 주체를 목록화하기
DNS를 수정하기 전에 회사 도메인을 사용하는 모든 발송 경로를 적습니다. 대표적인 업무 메일, 마케팅 자동화 도구, CRM, 고객지원 시스템, 거래성 알림, 설문·이벤트 도구를 따로 구분해야 누락을 줄일 수 있습니다.
각 발송 주체에 대해 사용하는 From 주소, 실제 발송 도메인, SPF 제공 여부, DKIM selector, 반송 주소, 담당자를 기록합니다. 외부 도구가 독립된 발송 서브도메인을 지원한다면 마케팅 메일과 임직원 메일을 분리하는 편이 원인 추적에 유리합니다.
사용하지 않는 서비스와 과거에 등록한 DNS 값을 먼저 정리합니다. 특히 SPF 레코드를 여러 개 만들거나, 더 이상 쓰지 않는 서비스의 include를 계속 남겨두면 인증과 운영 모두 복잡해집니다.
- 발송 서비스별 From 도메인과 반송 도메인 확인
- 외부 도구의 공식 SPF·DKIM 안내값 확보
- 같은 도메인에 SPF TXT 레코드가 여러 개 있는지 확인
- 서비스 해지 시 DNS 레코드와 접근 권한도 함께 정리
- 발송 도메인 변경이 수신자에게 미치는 영향 기록
SPF와 DKIM을 먼저 구성하는 순서
SPF는 도메인당 하나의 SPF 정책으로 통합합니다. 각 서비스가 제공한 include 또는 IP 값을 검토한 뒤 기존 정책에 합치고, 실제 사용하지 않는 항목은 제외합니다. 여러 SPF 레코드를 별도로 추가하면 수신 서버가 정책을 무효로 판단할 수 있습니다.
DKIM은 각 발송 서비스에서 키를 생성한 뒤 selector와 공개키를 DNS에 등록하는 방식이 일반적입니다. 개인키는 발송 서비스에 남고 공개키만 DNS에 게시되므로, 개인키를 문서나 메신저로 공유하지 않도록 합니다.
설정 후에는 테스트 메일을 내부 계정과 외부 계정으로 각각 보내고 원문 헤더를 확인합니다. SPF와 DKIM이 통과했는지뿐 아니라 DKIM 서명의 d= 도메인과 수신자에게 표시된 From 도메인이 일치하거나 조직적으로 정렬되는지도 확인해야 합니다.
- 기존 SPF TXT를 확인한 뒤 하나의 정책으로 통합
- DKIM selector는 서비스별로 구분하고 변경 이력을 기록
- DNS 전파 지연을 고려해 즉시 실패로 단정하지 않기
- 메일 원문에서 spf, dkim, dmarc 결과와 도메인 값 확인
- 개인키는 발송 플랫폼 외부로 복사하지 않기
DMARC를 단계적으로 적용하는 방법
SPF와 DKIM의 실제 통과 여부를 확인한 뒤 DMARC 레코드를 추가합니다. 처음에는 p=none으로 관찰하면서 rua 보고서 수신 주소를 설정하고, 합법적인 발송 경로와 실패 원인을 분류합니다. 보고서에는 수신자와 발송 IP 등 운영 정보가 포함될 수 있으므로 전용 수신함과 접근 권한을 정하는 것이 좋습니다.
정상 발송 경로가 확인되면 정책을 quarantine으로 강화하고, 영향을 받는 캠페인이나 거래성 메일이 없는지 다시 점검합니다. 충분한 검토 후 reject로 전환할 수 있지만, 신규 발송 서비스나 인수·합병으로 추가된 도메인이 있다면 먼저 목록에 반영해야 합니다.
정책 강도만 올리는 것보다 rua 보고서에서 From 도메인, 발송 IP, SPF·DKIM 정렬 결과를 정기적으로 분류하는 과정이 중요합니다. 보고서를 읽지 못하는 조직이라면 정책 강화 전에 담당자와 검토 주기를 정해두어야 합니다.
- 초기 정책은 관찰 목적의 p=none으로 시작
- rua 보고서를 전용 주소로 받고 개인정보 접근 범위 제한
- 정상 발송·미승인 발송·설정 누락을 구분
- quarantine 적용 전 마케팅·거래성 메일을 각각 테스트
- reject 전환 기준과 롤백 담당자 지정
배포 후 검증과 운영 체크리스트
인증 설정은 DNS에 값을 넣는 순간보다 배포 후 검증이 중요합니다. 새 캠페인, 예약 발송, 자동화 후속 메일, 고객지원 회신처럼 서로 다른 경로에서 샘플을 보내고 수신 서버의 헤더와 DMARC 보고서를 함께 비교합니다.
전달이나 재전송이 포함된 메일은 SPF가 실패할 수 있으므로 DKIM 서명이 유지되는지 확인합니다. 메일 포워딩 서비스, 리스트 서버, 보안 게이트웨이에서 제목·본문·헤더를 변경하면 DKIM도 영향을 받을 수 있어 예외를 추측하기보다 실제 경로를 재현해야 합니다.
정기 점검에서는 새 발송 서비스가 추가됐는지, 인증서가 아니라 DKIM 키와 DNS 값이 변경됐는지, DMARC 보고서에 예상하지 못한 발송 IP가 나타나는지 확인합니다. 인증 실패율을 단일 성과지표로 해석하지 말고 정상 발송량과 변경 이력을 함께 보세요.
- 발송 경로별 테스트 메일을 원문으로 보관
- From, Return-Path, DKIM d= 값의 관계 확인
- 포워딩·재전송·보안 게이트웨이 경로 별도 점검
- 새 외부 도구 도입 시 SPF·DKIM·DMARC 영향 검토
- 월별 또는 변경 발생 시 DNS와 보고서 점검
- 문제 발생 시 DMARC 정책 완화보다 원인과 누락 경로부터 확인
자주 묻는 질문
SPF만 설정해도 이메일 인증이 완료되나요?
아닙니다. SPF는 승인된 발송 서버를 확인하는 한 가지 방식입니다. 전달 과정에서 SPF가 실패할 수 있으므로 DKIM을 함께 구성하고, DMARC로 From 도메인과의 정렬 및 실패 정책을 관리하는 것이 필요합니다.
DMARC를 처음부터 reject로 설정해도 되나요?
모든 발송 경로를 파악하고 SPF·DKIM 정렬을 검증했다면 가능하지만, 누락된 외부 도구나 거래성 메일이 있으면 정상 메일도 거부될 수 있습니다. 일반적으로 p=none으로 보고서를 관찰한 뒤 단계적으로 강화합니다.
SPF 레코드를 서비스마다 하나씩 추가하면 되나요?
도메인에는 SPF 정책을 하나로 통합해야 합니다. 서비스별 안내값을 기존 TXT 레코드에 합치고, 더 이상 사용하지 않는 include나 IP는 제거해야 합니다.
DKIM selector는 무엇이며 왜 기록해야 하나요?
selector는 DKIM 공개키를 DNS에서 찾기 위한 식별자입니다. 발송 서비스나 키 교체 시 서로 다른 selector를 사용할 수 있으므로, 서비스명·등록일·교체일을 함께 기록하면 장애 원인을 추적하기 쉽습니다.