DKIM·SPF·DMARC는 DNS에 값을 추가하는 것만으로 끝나지 않습니다. 실제 발송 경로를 파악하고 인증 결과와 도메인 정렬을 검증한 뒤, DMARC 정책을 단계적으로 강화해야 합니다.
설정 전에 발송 경로부터 목록화하기
인증 레코드를 추가하기 전에 회사 도메인으로 이메일을 보내는 모든 시스템을 확인하세요. 사내 메일, CRM, 뉴스레터 도구, 고객지원 솔루션, 거래 알림 시스템, 웹사이트 폼 등은 서로 다른 발송 서버를 사용할 수 있습니다.
발송 시스템을 빠뜨린 상태에서 SPF나 DMARC를 강하게 적용하면 정상적인 메일도 수신 서버에서 격리되거나 거부될 수 있습니다. 시스템별로 사용하는 발신 주소, 발송 도메인 또는 하위 도메인, 외부 메일 서비스, 담당자를 표로 정리하면 이후 오류 추적이 쉬워집니다.
- 발송 시스템명과 담당 부서 기록
- From 주소와 Return-Path 또는 envelope-from 확인
- 실제 발송에 사용하는 IP, 메일 서비스, 릴레이 경로 확인
- 운영·테스트·거래 알림용 도메인을 구분
- 사용하지 않는 발송 서비스와 오래된 DNS 레코드 식별
SPF는 발송 서버의 범위를 정확히 정의하기
SPF는 특정 도메인의 메일을 대신 보낼 수 있는 서버나 서비스 범위를 DNS의 TXT 레코드로 선언하는 방식입니다. 같은 호스트명에 SPF 레코드를 여러 개 만들지 말고, 하나의 레코드 안에서 필요한 ip4, ip6, include 항목을 통합해야 합니다.
외부 발송 서비스가 제공한 include 값을 무조건 추가하기보다 실제 사용 여부를 확인하세요. 사용하지 않는 서비스가 남아 있으면 관리 범위가 불필요하게 넓어지고, 변경 시 어떤 항목이 영향을 받는지 판단하기 어려워집니다. SPF 조회 한도와 리디렉션 구조도 DNS 관리 담당자와 함께 점검해야 합니다.
- 발신 도메인의 TXT 레코드가 하나인지 확인
- 현재 사용하는 외부 발송 서비스의 공식 SPF 안내값만 반영
- 서비스를 중단하면 관련 include 또는 IP 항목 제거
- SPF가 주로 envelope-from 도메인에 적용된다는 점 확인
- 수정 후 SPF 검사 도구와 실제 수신 테스트로 결과 확인
DKIM 서명과 공개키를 발송 서비스에 연결하기
DKIM은 발송 시스템이 메일에 전자서명을 추가하고, 수신 서버가 DNS의 공개키로 서명을 검증하는 방식입니다. 발송 서비스에서 생성한 selector와 공개키를 확인한 뒤, 일반적으로 selector._domainkey 하위 호스트명에 TXT 레코드를 등록합니다.
DKIM은 서비스별 selector를 분리하면 교체와 장애 대응이 편해집니다. 공개키를 잘못 복사하거나 줄바꿈·따옴표·공백을 임의로 수정하면 검증이 실패할 수 있으므로, DNS 제공업체의 입력 형식과 발송 서비스의 안내를 함께 확인하세요. 비공개 개인키는 DNS에 올리거나 외부에 공유하면 안 됩니다.
- 발송 서비스별 selector와 서명 도메인 기록
- 공개키는 발송 서비스가 제공한 값을 그대로 등록
- 개인키가 노출되지 않았는지 접근 권한 점검
- 서비스 변경 시 새 selector를 먼저 검증한 후 기존 selector 폐기
- 수신한 테스트 메일의 Authentication-Results에서 dkim=pass 확인
DMARC는 정렬 상태를 확인한 뒤 단계적으로 적용하기
DMARC는 From 헤더의 도메인과 SPF 또는 DKIM 인증 도메인이 일치하는지 확인하고, 실패한 메일을 어떻게 처리할지 정책으로 선언합니다. SPF 또는 DKIM이 통과했더라도 From 도메인과 인증 도메인이 정렬되지 않으면 DMARC 관점에서는 실패할 수 있습니다.
처음부터 p=reject를 적용하기보다 집계 보고서를 받을 주소를 준비하고 p=none으로 관찰하는 방식이 안전합니다. 보고서에서 정상 발송 시스템과 미승인 발송원을 구분한 뒤 필요한 인증과 정렬을 보완하고, 조직의 리스크 허용 수준에 따라 quarantine 또는 reject로 전환하세요.
- _dmarc 발신 도메인에 TXT 레코드 생성
- rua 보고서 수신 주소와 보고서 분석 담당자 지정
- 정책 대상 범위를 확인하기 위해 필요하면 하위 도메인 정책도 별도 검토
- adkim, aspf의 정렬 모드와 조직의 발송 구조가 맞는지 확인
- p=none에서 관찰한 뒤 quarantine, reject 전환 기준을 문서화
설정 후 인증 결과를 실제 메일로 검증하기
DNS 조회 결과만으로는 충분하지 않습니다. 각 발송 시스템에서 테스트 메일을 보내고 수신 서버의 원문 헤더를 확인해야 합니다. Authentication-Results에서 spf, dkim, dmarc 결과를 확인하고, From·Return-Path·DKIM d= 도메인의 관계를 함께 기록하세요.
검증은 한 개의 메일만으로 끝내지 말고 주요 발송 경로와 다양한 수신 환경에서 반복하세요. 전달 실패가 발생하면 DNS 전파 지연, 잘못된 selector, 제3자 서비스의 미등록 발송 경로, 전달 과정에서 본문이 변경된 문제 등을 순서대로 분리해 확인합니다.
- 대표 발송 시스템마다 테스트 메일 발송
- 메일 원문에서 SPF·DKIM·DMARC 결과와 도메인 확인
- Forwarding 또는 메일 게이트웨이 경유 시 결과 재확인
- DMARC 집계 보고서의 발송 IP와 내부 발송 목록 대조
- 실패 사례는 발생 시각, 메시지 ID, 발송 시스템, 수신 도메인과 함께 기록
운영 책임과 변경 관리 루틴 만들기
이메일 인증은 한 번 설정하고 끝나는 항목이 아닙니다. CRM 도입, 발송 업체 교체, 하위 도메인 추가, 메일 게이트웨이 변경이 발생할 때마다 인증 영향도를 검토해야 합니다. DNS 변경 권한과 발송 플랫폼 관리 권한을 분리하되, 최종 책임자는 한 명으로 지정하는 편이 좋습니다.
월별 또는 변경 발생 시점에 DMARC 보고서와 SPF·DKIM 실패 사례를 검토하세요. 정책을 강화할 때는 정상 메일 차단 가능성을 먼저 평가하고, 롤백할 DNS 변경안과 승인자를 준비해야 합니다.
- DNS·메일 플랫폼·보안·마케팅 담당자의 역할 지정
- 발송 서비스 추가·삭제 시 인증 레코드 변경 절차 운영
- selector와 SPF include의 소유 시스템 및 갱신 주기 기록
- DMARC 정책 변경 전후의 승인·검증·롤백 절차 문서화
- 인증 실패를 도달률 문제와 동일하게 단정하지 말고 콘텐츠·평판·수신자 반응과 분리 분석
자주 묻는 질문
SPF, DKIM, DMARC를 모두 설정해야 하나요?
세 기술은 역할이 다르므로 함께 운영하는 것이 일반적입니다. SPF와 DKIM은 발송 주체와 메시지 서명을 인증하고, DMARC는 From 도메인과의 정렬 및 실패 처리 정책을 다룹니다. 실제 발송 경로와 서비스 지원 범위를 확인해 순서대로 적용하세요.
SPF가 pass인데 DMARC가 fail일 수 있나요?
가능합니다. SPF 인증에 사용된 도메인과 From 헤더의 도메인이 정렬되지 않으면 SPF가 pass여도 DMARC 정렬에는 실패할 수 있습니다. DKIM의 d= 도메인도 From 도메인과 일치하거나 허용된 하위 도메인 관계인지 확인해야 합니다.
DMARC를 처음부터 reject로 설정해도 되나요?
모든 발송 경로를 파악하고 인증·정렬 결과를 충분히 검증한 경우가 아니라면 신중해야 합니다. 먼저 보고서를 수집하는 정책으로 정상 발송과 미승인 발송을 구분한 뒤, 차단 영향과 예외 처리 방안을 확인하고 단계적으로 강화하는 방법이 안전합니다.
외부 이메일 발송 서비스가 여러 개면 어떻게 관리하나요?
서비스별 발송 도메인, SPF 항목, DKIM selector, 담당자, 사용 목적을 목록화하세요. 가능하면 서비스마다 전용 하위 도메인을 사용해 변경 영향 범위를 분리하고, 사용하지 않는 서비스의 인증 권한은 정기적으로 제거하세요.