발송 도메인의 신뢰도를 관리하려면 세 인증 기술을 따로 등록하는 데서 끝나지 않고, 실제 발신 주소와 서명 도메인의 정렬, 외부 발송 서비스 범위, DMARC 보고서까지 함께 확인해야 합니다.
1. DNS를 바꾸기 전에 발송 경로를 정리하세요
인증 설정의 첫 단계는 레코드 입력이 아니라 자산 확인입니다. 같은 회사라도 마케팅 메일, 영업 메일, 거래성 알림이 서로 다른 플랫폼을 거치면 SPF와 DKIM의 설정 위치가 달라질 수 있습니다.
최근 캠페인의 원본 헤더에서 From, Return-Path, DKIM 서명 도메인과 발송 IP를 확인하면 문서에 없는 경로를 찾는 데 도움이 됩니다. 테스트 메일만으로 판단하지 말고 실제 사용하는 모든 발송 유형을 구분해 기록하세요.
- 회사에서 사용하는 모든 발송 경로를 먼저 목록화합니다: 사내 메일 서버, CRM, 뉴스레터 도구, 영업 자동화 도구, 고객지원 시스템 등
- 헤더의 From 주소와 실제 발송 도메인이 서비스별로 어떻게 표시되는지 확인합니다.
- 개인 Gmail이나 임시 SMTP처럼 승인되지 않은 발송 경로는 공식 캠페인에서 제외합니다.
- 운영 담당자, DNS 관리자, 각 이메일 서비스 담당자를 지정해 변경 승인과 장애 대응 책임을 나눕니다.
2. SPF는 허용 발송 서버 목록으로 관리합니다
SPF는 발신 도메인을 대신해 메일을 보낼 수 있는 서버나 서비스를 DNS에 선언하는 방식입니다. 예시 형식은 v=spf1 include:발송서비스.example ~all처럼 서비스 제공업체가 안내한 값을 기준으로 작성해야 하며, 임의의 IP나 include 값을 추측해 넣어서는 안 됩니다.
여러 발송 서비스를 사용한다면 각각의 안내 값을 하나의 SPF 레코드에 통합합니다. 서비스 계약이 끝났거나 더 이상 메일을 보내지 않는 도구의 허용 항목은 제거하고, 전달·포워딩 환경에서는 SPF만으로 인증이 유지되지 않을 수 있다는 점도 고려하세요.
- 호스트명: 일반적으로 도메인 자체 또는 DNS 관리 화면의 안내에 따른 이름
- 유형: TXT
- 값: 메일 서비스가 제공한 SPF 문자열
- 하나의 도메인에 SPF TXT 레코드를 하나만 유지
- 신규 서비스 추가·삭제 때 기존 값을 덮어쓰지 말고 전체 허용 목록을 다시 검토
3. DKIM은 서비스별 서명과 키 교체 절차를 준비합니다
DKIM은 메일 내용이 발송 후 변조되지 않았는지 검증할 수 있도록 발송 시스템이 서명하는 방식입니다. 보통 selector._domainkey 형태의 호스트명에 공개키를 TXT로 등록하며, 개인키는 이메일 서비스가 관리하고 조직은 DNS에 공개키만 게시합니다.
DKIM의 핵심은 등록 자체보다 지속적인 서명입니다. 서비스 설정에서 서명이 켜져 있는지, From 도메인과 서명 도메인이 조직의 정책에 맞는지, 키 교체 시 새 선택자와 기존 선택자가 겹치지 않는지 운영 절차에 포함하세요.
- 발송 서비스에서 DKIM 활성화 기능을 켭니다.
- 서비스가 제공한 선택자(selector)와 공개키를 DNS에 등록합니다.
- 호스트명과 TXT 값의 줄바꿈·따옴표 처리는 DNS 업체 안내를 따릅니다.
- 테스트 메일의 DKIM 서명 도메인과 결과가 정상인지 확인합니다.
- 서비스 변경 시 기존 선택자를 즉시 삭제하지 말고 전환 완료 후 정리합니다.
4. DMARC는 모니터링에서 차단까지 단계적으로 전환합니다
DMARC는 SPF 또는 DKIM 중 하나가 통과하는지만 보는 것이 아니라, 인증된 도메인이 사용자에게 보이는 From 도메인과 정렬되는지도 판단합니다. 따라서 SPF가 통과해도 Return-Path 도메인이 From과 맞지 않거나, DKIM 서명 도메인이 별도 도메인이면 DMARC 정렬에 실패할 수 있습니다.
처음부터 강한 차단 정책을 적용하면 정상적인 CRM·알림 메일이 누락될 수 있습니다. 모니터링 정책으로 실제 발송 경로를 관찰하고, 실패 원인을 수정한 뒤 일부 적용과 격리 정책을 거쳐 차단 정책을 검토하세요. 정책 전환은 캠페인 일정과 고객 알림 시스템의 영향까지 고려해 진행해야 합니다.
- DMARC 호스트명: _dmarc.발신도메인
- 정책 값은 처음에 모니터링 중심으로 시작하고 정상 발송 확인 후 강화
- rua에는 집계 보고서를 받을 전용 주소를 사용
- adkim과 aspf의 정렬 모드, pct 적용 범위, 하위 도메인 정책을 조직 기준에 맞춰 결정
- 보고서에서 인증 실패가 아닌 정상 발송도 함께 확인
5. 설정 완료보다 운영 점검이 중요합니다
인증 레코드가 조회된다는 사실만으로 전달 가능성이 보장되지는 않습니다. 실제 메시지 헤더, 발송량 변화, 반송, 스팸 신고, 수신거부와 DMARC 보고서를 함께 봐야 어떤 경로가 문제인지 구분할 수 있습니다.
특히 대량 캠페인 직전에는 신규 도구나 하위 도메인을 추가하지 않는 편이 안전합니다. 변경이 필요하다면 소규모 테스트, 헤더 검증, 보고서 확인, 전체 발송 순서로 진행하고 문제가 생겼을 때 이전 설정으로 되돌릴 담당자와 시간을 정해 두세요.
- DNS 전파 후 SPF, DKIM, DMARC 레코드가 외부에서 조회되는지 확인합니다.
- 주요 수신 서비스로 테스트 메일을 보내 Authentication-Results 헤더를 확인합니다.
- SPF pass, DKIM pass, DMARC pass와 From 도메인 정렬 여부를 각각 기록합니다.
- DMARC 집계 보고서에서 새 발송 IP·도메인·서비스가 나타나는지 주기적으로 검토합니다.
- 캠페인 발송 전 발신 주소, Reply-To, 링크 도메인, 수신거부 주소의 일관성을 확인합니다.
- 도메인·DNS·발송 서비스 변경 시 변경 이력과 롤백 방법을 남깁니다.
자주 묻는 질문
SPF, DKIM, DMARC의 차이는 무엇인가요?
SPF는 해당 도메인에서 메일을 보낼 수 있는 서버를 지정합니다. DKIM은 발송 시스템이 메일에 전자서명을 붙이고 수신 서버가 이를 검증하도록 합니다. DMARC는 SPF 또는 DKIM 인증 결과가 수신자에게 보이는 발신 도메인과 정렬되는지 확인한 뒤, 실패한 메일을 어떻게 처리할지 정하는 정책입니다.
세 가지 인증은 어떤 순서로 설정해야 하나요?
먼저 실제 발송 경로와 서비스 목록을 확정한 뒤 SPF와 DKIM을 설정하고, 인증 결과와 정렬 상태를 확인하면서 DMARC를 모니터링 모드로 시작하는 편이 안전합니다. 정상 발송이 확인되면 조직의 오발송 위험과 보고서 결과를 바탕으로 quarantine 또는 reject 전환을 검토합니다.
외부 이메일 서비스를 여러 개 사용할 때 SPF는 어떻게 관리하나요?
SPF에는 동일한 도메인의 TXT 레코드를 여러 개 만들지 말고 하나로 통합해야 합니다. 여러 서비스가 필요하면 각 서비스가 제공한 include 값을 하나의 SPF 레코드에 합치되, 사용하지 않는 발송 서비스는 제거합니다. DNS 제공업체의 문법과 SPF 조회 한도도 함께 확인해야 합니다.
DMARC 보고서는 어디로 받아야 하나요?
DMARC 보고서는 인증 실패가 발생한 발송 경로와 정렬 상태를 파악하는 자료입니다. 수신자 주소로 직접 받기보다 전용 보고서 분석 서비스나 사내 수집 주소를 사용하고, 보고서에 포함될 수 있는 발송 IP·도메인 정보의 보안과 보관 기준도 정해야 합니다.