B2B 이메일 인증은 DNS 레코드를 추가하는 것보다 모든 발신 경로를 빠짐없이 식별하고, 인증 결과와 도메인 정렬을 검증하는 과정이 중요합니다. SPF·DKIM·DMARC의 설정 순서와 운영 점검 기준을 정리합니다.
설정 전에 모든 발신 경로를 목록화하세요
인증 설정의 첫 단계는 DNS에 레코드를 추가하는 일이 아니라 우리 도메인으로 발송되는 메일을 빠짐없이 찾는 일입니다. 사내 메일 시스템뿐 아니라 CRM, 뉴스레터 플랫폼, 고객지원 도구, 청구 시스템, 채용 서비스, 웹사이트 문의 알림도 별도 발신 경로로 기록해야 합니다.
각 경로마다 발신 도메인 또는 하위 도메인, 사용 중인 발송 업체, 발신 주소, SPF 필요 여부, DKIM 지원 여부, DMARC 정책 적용 대상, 담당자를 표로 관리합니다. 테스트용 서비스와 운영용 서비스를 구분하지 않으면 나중에 DMARC 보고서에 나타난 미확인 발송원을 해석하기 어렵습니다.
- 도메인별 발신 시스템과 담당자 확인
- 외부 발송 서비스의 SPF include 및 DKIM 안내 문서 확보
- 운영·개발·테스트 환경의 발신 주소 분리
- 사용하지 않는 발신 계정과 오래된 DNS 레코드 식별
- 고객에게 직접 전달되는 메일과 내부 알림 메일 구분
SPF는 발신 서버 목록을 하나의 정책으로 관리하세요
SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버를 DNS TXT 레코드로 선언하는 방식입니다. 도메인 하나에 SPF 레코드를 여러 개 만들면 수신 서버가 정책을 무효로 판단할 수 있으므로 기존 레코드를 먼저 확인하고 필요한 발송 서비스를 하나의 레코드로 통합해야 합니다.
외부 서비스의 IP 주소를 임의로 복사하기보다 해당 서비스가 제공하는 공식 include 값을 사용하고, 서비스 변경 시 갱신 절차를 담당자와 함께 정합니다. SPF는 DNS 조회 수 제한도 있으므로 여러 include가 겹치는 구조라면 조회 수를 점검하고 사용하지 않는 항목을 정리해야 합니다.
- TXT 레코드가 중복으로 존재하지 않는지 확인
- 모든 승인된 발송 경로를 포함하되 미사용 서비스는 제거
- SPF 조회 수 제한 초과 여부 점검
- 메일 전달이나 포워딩 환경에서 SPF만으로 인증이 보장되지 않는 점 확인
- 변경 전 기존 레코드를 저장하고 변경 일시와 담당자 기록
DKIM은 서비스별 selector와 도메인 정렬을 확인하세요
DKIM은 발송 시스템이 메일에 전자서명을 붙이고 수신 서버가 공개키로 서명을 검증하는 방식입니다. 발송 서비스마다 selector가 다를 수 있으므로 selector와 공개키를 서비스 안내에 맞춰 등록해야 합니다. 동일한 selector를 여러 시스템에서 재사용하면 키 교체나 장애 원인 추적이 어려워질 수 있습니다.
가능하면 조직의 주 도메인과 마케팅·거래성 메일의 하위 도메인을 목적에 맞게 분리합니다. DKIM 서명이 성공하는 것만으로 충분하지 않고, 서명에 사용된 d= 도메인이 From 주소의 도메인과 DMARC 기준에서 정렬되는지도 확인해야 합니다.
- 서비스가 요구하는 selector별 CNAME 또는 TXT 레코드 등록
- 공개키 값의 줄바꿈·따옴표·공백 오류 점검
- 서명 도메인 d=와 From 도메인의 정렬 확인
- 키를 정기적으로 또는 서비스 정책에 따라 교체할 절차 마련
- 발송 서비스별 selector와 키 소유자를 문서화
DMARC는 모니터링부터 단계적으로 정책을 강화하세요
DMARC는 SPF 또는 DKIM 인증 결과가 From 도메인과 정렬되는지 확인하고, 실패한 메일을 어떻게 처리할지 수신 서버에 제시합니다. 처음부터 강한 차단 정책을 적용하면 등록하지 않은 정상 발신 경로까지 거부될 수 있으므로 먼저 p=none으로 보고서를 수집하고 누락된 발신원을 정리하는 방식이 안전합니다.
보고서 수신 주소인 rua를 운영할 때는 보고서가 대량으로 들어올 수 있으므로 전용 수신함이나 분석 서비스를 준비합니다. 보고서에는 발신 IP와 인증 결과 등 운영에 필요한 정보가 포함될 수 있으므로 접근 권한과 보관 기간도 정해야 합니다. 정상 발신 경로가 확인된 뒤 quarantine, reject 순서로 전환하되 정책 변경일과 관찰 기간을 기록합니다.
- 처음에는 모니터링 목적의 p=none으로 시작
- rua 수신 주소와 보고서 확인 담당자 지정
- SPF 또는 DKIM 중 하나가 통과하면서 From 도메인과 정렬되는지 확인
- 예상하지 못한 발신 IP는 즉시 차단하지 말고 소유 시스템부터 조사
- 정상 발송률과 오탐 여부를 확인한 뒤 정책을 단계적으로 강화
DNS 등록 후 실제 헤더와 수신 결과로 검증하세요
DNS 검사 도구의 성공 메시지만으로 운영 검증을 끝내면 안 됩니다. 실제 발송 메일의 원문 헤더에서 Authentication-Results를 열고 spf, dkim, dmarc 결과와 적용된 도메인을 확인해야 합니다. 테스트 대상은 같은 조직 주소뿐 아니라 주요 외부 수신 서비스와 개인 메일 주소를 포함하는 편이 좋습니다.
변경 직후에는 DNS 캐시와 수신 서버별 처리 차이로 결과가 즉시 같지 않을 수 있습니다. 테스트 시간, 수신 서비스, From 주소, 사용한 발송 시스템, 헤더 결과를 기록하고 실패 원인을 레코드 오타, 서명 도메인 불일치, 누락된 발송 경로, 전달 과정으로 나눠 조사합니다.
- 실제 메일 원문에서 SPF·DKIM·DMARC 결과 확인
- d=, header.from, envelope-from 도메인의 관계 기록
- 주요 수신 서비스별 테스트 결과 비교
- DMARC 집계 보고서의 발신 IP와 사내 발신 목록 대조
- 정책 변경 전후 반송, 스팸함 분류, 정상 수신 여부 관찰
변경 이후 운영 루틴과 장애 대응 기준을 정하세요
이메일 인증은 일회성 설정이 아니라 발송 시스템이 추가되거나 도메인이 변경될 때마다 검토해야 하는 운영 항목입니다. 신규 SaaS 도입 승인 절차에 SPF·DKIM·DMARC 요구사항을 포함하고, 캠페인 발송 전에는 새 From 도메인과 selector가 등록됐는지 확인합니다.
인증 실패가 확인되면 먼저 영향 범위를 구분합니다. 특정 서비스의 메일만 실패하는지, 특정 수신자군에서만 문제가 생기는지, 전체 도메인에서 발생하는지 확인한 후 DMARC 정책을 임시로 완화할지 발송 시스템을 수정할지 결정합니다. 정책을 되돌릴 때도 원인과 재적용 조건을 함께 남겨야 같은 문제가 반복되지 않습니다.
- 월별 또는 분기별 DMARC 보고서 검토 일정 등록
- 발송 서비스 추가·삭제 시 DNS와 인증 문서 동시 갱신
- 키 교체와 selector 폐기 절차를 별도로 관리
- 인증 실패·반송·스팸함 유입을 하나의 장애 기록에 연결
- 정책 변경 승인자, 롤백 조건, 재검증 담당자 지정
자주 묻는 질문
SPF, DKIM, DMARC는 어떤 순서로 설정하는 것이 좋나요?
발신 경로를 먼저 목록화한 뒤 SPF와 DKIM을 발송 시스템별로 설정하고, 실제 헤더에서 두 인증 결과와 도메인 정렬을 확인한 다음 DMARC를 모니터링 정책으로 시작하는 방식이 일반적입니다. 정상 경로가 확인되면 DMARC 정책을 단계적으로 강화합니다.
SPF 레코드를 발송 서비스마다 하나씩 추가해도 되나요?
권장하지 않습니다. 같은 도메인에 SPF 레코드가 여러 개 있으면 검증 오류가 발생할 수 있으므로 하나의 정책에 승인된 발송 경로를 통합해야 합니다. include가 많아질 때는 DNS 조회 수 제한도 함께 점검해야 합니다.
DKIM이 통과하면 DMARC도 자동으로 통과하나요?
항상 그렇지는 않습니다. DKIM 서명이 유효하더라도 DKIM의 d= 도메인이 From 주소의 도메인과 DMARC 기준에 맞게 정렬되지 않으면 DMARC에 기여하지 못할 수 있습니다. 실제 메일 헤더에서 두 도메인을 함께 확인해야 합니다.
DMARC를 처음부터 reject로 설정하면 안 되나요?
등록되지 않은 정상 발신 경로가 남아 있으면 메일이 거부될 수 있어 위험합니다. 먼저 p=none으로 보고서를 수집하고 발신원을 정리한 뒤 quarantine 또는 reject로 단계적으로 전환하는 편이 운영상 안전합니다.