DKIM·SPF·DMARC는 한 번 설정하고 끝나는 항목이 아닙니다. 사용하는 발신 서비스와 도메인 구조를 먼저 정리한 뒤, 검증 가능한 순서로 적용하고 변경 이후에도 실패 원인을 추적해야 합니다.
설정 전에 발신 경로와 도메인 구조를 목록화하세요
인증 설정의 첫 단계는 DNS 값을 입력하는 일이 아니라 실제 발신 경로를 확인하는 일입니다. 마케팅 자동화 도구, CRM, 고객지원 시스템, 영업 담당자의 메일 서버, 트랜잭션 메일 서비스처럼 회사 도메인으로 메일을 보내는 모든 시스템을 한 표에 정리합니다.
각 시스템마다 발신 주소, 사용하는 하위 도메인, SPF에 포함할 호스트, DKIM 활성화 여부, Return-Path 또는 envelope-from 도메인을 기록하세요. 이 목록이 없으면 운영 중인 발신원을 빠뜨리거나 사용하지 않는 서비스가 계속 인증 정책의 예외로 남을 수 있습니다.
- 주 발신 도메인과 캠페인 전용 하위 도메인을 구분합니다.
- 외부 발신 서비스별 관리자 계정과 DNS 변경 담당자를 확인합니다.
- 현재 DNS에 SPF, DKIM, DMARC 레코드가 이미 있는지 조회합니다.
- 중단된 서비스의 include, DKIM selector, 예외 정책이 남아 있는지 점검합니다.
- 발신 시스템별 테스트 수신 주소와 확인할 메일 헤더를 지정합니다.
SPF는 허용된 발신 서버를 하나의 정책으로 관리하세요
SPF는 특정 도메인의 메일을 보낼 수 있는 서버 또는 서비스를 DNS TXT 레코드로 선언하는 방식입니다. 예를 들어 사용하는 서비스가 하나라면 v=spf1 include:_spf.example.com ~all과 같은 형태를 검토할 수 있습니다. 실제 include 값은 각 공급업체가 제공한 공식 값을 사용해야 하며, 예시 값을 그대로 등록해서는 안 됩니다.
도메인에는 SPF 레코드를 여러 개 만들지 말고 기존 TXT 레코드에 허용 대상을 합쳐야 합니다. DNS 조회가 과도하게 늘어나면 SPF 평가가 실패할 수 있으므로 include, redirect, a, mx 등의 참조 구조를 함께 확인하세요. 사용하지 않는 발신 서비스를 제거하는 것이 예외를 계속 추가하는 것보다 안전합니다.
- 기존 SPF 레코드가 있으면 새 TXT 레코드를 추가하기 전에 통합 방식을 정합니다.
- 서비스 제공업체가 안내한 include 도메인의 철자와 위치를 확인합니다.
- 처음 변경할 때는 ~all처럼 관찰 가능한 정책을 검토하고, 실패 로그를 확인한 뒤 강도를 조정합니다.
- SPF가 통과해도 From 주소와 인증 도메인의 정렬이 맞지 않을 수 있으므로 DMARC 결과를 별도로 확인합니다.
- DNS 제공업체가 TXT 값을 자동으로 분할하거나 따옴표를 처리하는 방식을 확인합니다.
DKIM은 selector별 공개키와 발신 시스템을 연결하세요
DKIM은 발신 시스템이 메일에 서명하고 수신 서버가 DNS의 공개키로 서명을 검증하는 방식입니다. 일반적으로 selector._domainkey.example.com 위치에 TXT 공개키를 등록하며, selector는 시스템별 또는 환경별로 다를 수 있습니다. 따라서 같은 도메인에 여러 발신 서비스가 있다면 selector 충돌 여부를 확인해야 합니다.
대부분의 외부 발신 서비스는 관리자 화면에서 DKIM 활성화와 DNS 등록값을 제공합니다. 키를 직접 생성해야 하는 환경에서는 개인키를 발신 시스템에만 보관하고 공개키만 DNS에 게시하세요. 키 교체가 필요할 때는 새 selector를 먼저 게시하고 서명을 전환한 뒤 기존 selector를 제거하는 순서가 안전합니다.
- 발신 서비스가 요구하는 selector, 호스트명, TXT 값을 그대로 대조합니다.
- DKIM 서명 도메인 d= 값이 실제 From 도메인과 어떻게 정렬되는지 확인합니다.
- 공개키가 잘렸거나 줄바꿈 때문에 변형되지 않았는지 DNS 조회로 검증합니다.
- 키 교체 시 기존 selector를 즉시 삭제하지 말고 잔여 메일 처리 시간을 고려합니다.
- 메일 헤더에서 dkim=pass와 서명 도메인, selector 값을 함께 확인합니다.
DMARC는 모니터링에서 차단으로 단계적으로 전환하세요
DMARC는 SPF 또는 DKIM 인증 결과가 From 도메인과 정렬되는지 확인하고, 실패한 메일을 수신 서버가 어떻게 처리할지 안내합니다. 시작 단계에서는 p=none으로 보고서를 수집해 합법적인 발신원을 찾고, 누락된 서비스가 없는지 확인한 뒤 격리 또는 거부 정책을 검토하는 방식이 적합합니다.
기본 형식은 _dmarc.example.com의 TXT 레코드에 v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com처럼 등록하는 것입니다. rua 수신 주소를 운영할 때는 보고서 처리 담당자, 보관 기간, 개인정보 접근 권한을 정해 두세요. p=quarantine 또는 p=reject로 전환할 때는 내부 사용자, 거래처 안내 메일, 시스템 알림 등 비정기 발신도 포함해 영향 범위를 확인해야 합니다.
- 보고서 수신 주소가 실제로 수신 가능하고 담당자가 정해져 있는지 확인합니다.
- 정렬 모드, pct 적용 범위, 하위 도메인 정책이 조직의 발신 구조와 맞는지 검토합니다.
- 보고서에서 SPF 실패, DKIM 실패, 정렬 실패, 미등록 발신 IP를 구분합니다.
- 정상 발신원이 모두 확인되기 전에는 강한 차단 정책으로 서두르지 않습니다.
- 정책 변경일, 변경자, 변경 전후 인증 결과를 운영 기록에 남깁니다.
배포 후에는 헤더와 수신 로그를 기준으로 검증하세요
DNS 검사 도구의 통과 결과만으로는 충분하지 않습니다. 실제로 각 발신 시스템에서 테스트 메일을 보내고 수신 메일의 Authentication-Results 헤더를 확인해야 합니다. dkim=pass, spf=pass, dmarc=pass 여부뿐 아니라 어떤 도메인과 IP가 판정에 사용됐는지 함께 기록하세요.
변경 후 특정 수신처에서만 실패한다면 DNS 전파, 전달 과정에서의 서명 변경, 중계 서버의 From 또는 Return-Path 변환을 구분해야 합니다. DMARC 집계 보고서는 즉시 발생한 장애 알림과 성격이 다르므로, 긴급 대응은 수신 서비스 로그와 실제 테스트 메일로 먼저 진행하세요.
- 주요 발신 서비스별로 내부 계정과 외부 테스트 계정에 메일을 보냅니다.
- 메일 헤더에서 Authentication-Results, DKIM-Signature, Return-Path를 저장합니다.
- SPF 조회 한도 초과, DKIM selector 불일치, From 도메인 불일치를 별도 원인으로 분류합니다.
- 정상 발신이 확인되지 않은 상태에서 레코드나 정책을 연속으로 여러 개 바꾸지 않습니다.
- 월 1회 이상 발신 서비스 목록과 DNS 레코드의 일치 여부를 재검토합니다.
자주 묻는 질문
SPF, DKIM, DMARC를 반드시 같은 날 설정해야 하나요?
아닙니다. 발신원 목록을 정리한 뒤 SPF와 DKIM을 먼저 검증하고, DMARC를 모니터링 정책으로 시작한 다음 보고서를 바탕으로 강도를 높이는 방식이 일반적으로 관리하기 쉽습니다.
SPF 레코드를 서비스별로 여러 개 등록해도 되나요?
피하는 것이 좋습니다. 같은 도메인에 SPF 레코드가 여러 개 있으면 수신 서버가 정책을 무효로 판단할 수 있으므로 기존 레코드에 허용 대상을 통합해야 합니다.
DKIM이 통과하면 DMARC도 자동으로 통과하나요?
항상 그렇지는 않습니다. DKIM 서명이 유효해도 서명 도메인과 From 도메인의 정렬이 맞지 않으면 DMARC에서는 실패할 수 있습니다. 인증 결과와 도메인 정렬을 함께 확인해야 합니다.
DMARC를 바로 p=reject로 설정하면 안 되나요?
합법적인 발신원을 모두 파악했고 SPF 또는 DKIM 정렬을 검증한 경우에 검토할 수 있습니다. 발신 경로가 확인되지 않은 상태에서 적용하면 정상적인 영업, 알림, 거래처 메일이 거부될 위험이 있으므로 먼저 보고서와 테스트 결과를 확인하세요.