DKIM·SPF·DMARC를 운영 가능한 정책으로 바꾸는 실무 설정 가이드

설정 전에 발신 경로부터 목록화하기

DKIM·SPF·DMARC 설정의 첫 단계는 DNS 값을 바로 입력하는 것이 아니라 회사 도메인에서 이메일을 보내는 모든 경로를 확인하는 것입니다. 마케팅 자동화 도구, CRM, 고객지원 시스템, 거래명세서 발송 서버, 임직원용 메일, 외부 대행사의 발송 서비스를 각각 구분합니다.

서비스별로 발신 주소, From 도메인, Return-Path 또는 MAIL FROM 도메인, DKIM 서명 도메인, SPF에 필요한 include 또는 IP 정보를 기록합니다. 같은 서비스라도 운영·개발 환경이 분리되어 있으면 별도 항목으로 관리해야 누락을 줄일 수 있습니다.

• 발신 서비스명과 담당자
• 사용하는 From 주소와 도메인
• Return-Path 또는 MAIL FROM 도메인
• DKIM selector와 서명 도메인
• SPF에 필요한 include, IP, 호스트명
• 서비스 종료 또는 교체 예정 여부

SPF는 하나의 레코드로 발신 서버를 정리하기

SPF는 수신 서버가 특정 도메인을 대신해 메일을 보낼 수 있는 서버인지 확인하도록 돕습니다. 동일한 도메인에 SPF TXT 레코드를 여러 개 만들면 해석 오류가 발생할 수 있으므로, 기존 레코드를 확인한 뒤 하나의 정책으로 통합해야 합니다.

각 발송 서비스가 제공한 include 또는 고정 IP를 무조건 추가하지 말고 실제 사용 여부와 소유 주체를 확인합니다. 더 이상 사용하지 않는 서비스의 include를 제거하고, DNS 조회가 과도하게 이어지는 구성은 제공업체의 통합 include나 별도 발신 서브도메인으로 재설계합니다.

SPF가 통과해도 From 주소의 도메인과 SPF 검증 도메인이 다르면 DMARC 정렬에서 실패할 수 있습니다. 따라서 SPF 레코드 등록 후에는 인증 결과뿐 아니라 MAIL FROM 도메인과 From 도메인의 관계도 확인해야 합니다.

• 기존 SPF TXT 레코드가 있는지 먼저 조회
• SPF 레코드는 도메인별 1개로 통합
• 사용하지 않는 include와 IP 제거
• 외부 발송 서비스의 변경 공지 확인
• SPF 통과 여부와 From 도메인 정렬 여부를 별도로 확인

DKIM selector를 서비스별로 분리해 관리하기

DKIM은 발송 시스템이 메일에 암호화 서명을 붙이고, 수신 서버가 공개키로 그 서명을 검증하는 방식입니다. 각 발송 서비스가 제시한 selector와 공개키를 해당 selector의 TXT 또는 CNAME 레코드로 등록합니다.

여러 시스템이 같은 도메인을 사용한다면 selector를 서비스별로 분리하면 장애 원인을 추적하기 쉽습니다. 기존 selector를 덮어쓰거나 공개키를 임의로 줄바꿈·수정하지 말고, 제공업체가 안내한 값과 레코드 유형을 그대로 비교합니다.

DKIM 서명 도메인은 From 도메인과 같거나 조직적으로 정렬된 하위 도메인인지 확인합니다. 서비스 교체 시 새 selector를 먼저 등록하고 테스트 발송을 진행한 뒤 기존 selector를 제거하면 전환 중 인증 공백을 줄일 수 있습니다.

• 서비스별 selector와 담당자 기록
• TXT인지 CNAME인지 제공업체 지침 확인
• 공개키의 공백·따옴표·줄바꿈 오류 점검
• 새 selector 검증 후 기존 selector 폐기
• DKIM 서명 도메인과 From 도메인의 정렬 상태 확인

DMARC는 보고부터 시작해 정책을 단계적으로 강화하기

DMARC는 SPF 또는 DKIM 인증 결과가 From 도메인과 정렬되는지 확인하고, 조건을 충족하지 못한 메일을 어떻게 처리할지 수신 서버에 전달합니다. 처음부터 강한 정책을 적용하기보다 발신 경로와 실패 원인을 파악할 수 있도록 p=none으로 보고를 수집하는 방식이 실무적으로 안전합니다.

DMARC 레코드에는 최소한 정책 대상 도메인과 정책값을 명확히 작성합니다. aggregate report 수신 주소인 rua를 사용할 때는 보고서를 실제로 검토할 담당자와 보관 기간을 정하고, 외부 분석 서비스로 전송한다면 해당 서비스의 외부 보고 권한 설정도 확인합니다.

보고서에서 정당한 발송 경로가 모두 DKIM 또는 SPF 정렬을 통과하는지 확인한 뒤, 일부 트래픽에 quarantine을 적용하고 문제를 관찰합니다. 정상 발송의 범위와 예외 경로를 확인한 후 reject로 강화하며, 정책 변경일과 근거를 운영 기록에 남깁니다.

• 1단계: p=none으로 발신 경로와 실패 원인 수집
• 2단계: 정당한 발송 경로의 DKIM·SPF 정렬 수정
• 3단계: 필요 시 pct를 활용해 일부 트래픽부터 적용
• 4단계: quarantine 적용 후 오탐과 반송 확인
• 5단계: 운영 기준이 충족되면 reject 검토
• 보고서 수신 주소와 개인정보 접근 권한 관리

DNS 반영 후 인증 결과를 실제 메일로 검증하기

DNS 도구에서 레코드가 보인다는 사실만으로 설정이 완료된 것은 아닙니다. 각 발송 시스템에서 테스트 메일을 보내고, 수신 헤더의 Authentication-Results에서 spf, dkim, dmarc 결과와 header.from, smtp.mailfrom, d 값을 함께 확인해야 합니다.

검증 대상은 한 번의 테스트 메일에 한정하지 않습니다. 마케팅 발송, 임직원 발송, 시스템 알림처럼 경로가 다른 메일을 각각 확인하고, Gmail·Outlook 등 주요 수신 환경에서 헤더와 전달 결과를 비교합니다. 전달되지 않은 메일은 반송 코드와 수신 서버 응답을 기록합니다.

DNS TTL과 캐시 때문에 변경 직후 결과가 일치하지 않을 수 있으므로 변경 시각, 확인 시각, 조회 위치를 기록합니다. 레코드가 올바른데도 실패하면 발송 서비스가 다른 Return-Path를 사용하거나 DKIM 서명을 비활성화했는지 먼저 확인합니다.

• 테스트 메일마다 발신 서비스 기록
• Authentication-Results 헤더 확인
• spf와 dkim뿐 아니라 dmarc 정렬 확인
• 주요 수신 환경별 전달 결과 비교
• 반송 코드와 수신 서버 응답 보관
• 변경 시각과 DNS TTL 기록

월간 운영 체크리스트로 인증 상태 유지하기

인증 레코드는 한 번 설정한 뒤 방치하면 신규 SaaS 도입, 메일 서버 이전, 대행사 계약 종료 과정에서 다시 깨질 수 있습니다. 발신 서비스 추가와 종료를 DNS 변경 요청과 연결하고, 레코드 소유자와 승인자를 정해 변경 이력을 남깁니다.

DMARC 보고서는 단순히 통과율을 보는 자료가 아니라 승인되지 않은 발신원과 설정 누락을 찾는 운영 자료로 활용합니다. 새로운 발신 IP나 서비스가 발견되면 실제 회사 발송인지, 위탁 발송인지, 스푸핑 시도인지 확인한 후 조치합니다.

• 매월 SPF include와 고정 IP의 사용 여부 검토
• 활성 DKIM selector와 서비스 매핑 확인
• DMARC 보고서의 신규 발신원 확인
• 정책 변경 후 반송·스팸함 배치 점검
• 퇴사·계약 종료 서비스의 DNS 권한 회수
• 레코드 변경 이력과 담당자 최신화