발송 도메인 인증 운영표: SPF·DKIM·DMARC 설정 순서

1. DNS를 수정하기 전에 발송 경로를 목록화하세요

인증 설정의 첫 단계는 레코드 입력이 아니라 발송 자산 확인입니다. 여러 팀이 서로 다른 서비스를 사용하면 일부 메일만 인증되고, DMARC 정책 전환 때 정상 메일이 영향을 받을 수 있습니다.

특히 웹사이트 폼, CRM, 뉴스레터 도구, 고객지원 솔루션이 같은 회사 도메인을 사용한다면 각각의 발송 도메인과 인증 방식을 확인해야 합니다. 서비스별 공식 문서에서 요구하는 SPF include, DKIM selector, bounce 도메인도 함께 기록하세요.

• 현재 사용하는 이메일 발송 플랫폼과 SMTP 서버를 모두 적습니다.
• 마케팅 자동화, 영업 발송, 고객지원, 트랜잭션 메일을 발송 경로별로 구분합니다.
• From 주소, Return-Path 또는 envelope-from, DKIM 서명 도메인을 확인합니다.
• 사용하지 않는 발송 서비스와 오래된 DNS include 항목은 별도로 표시합니다.

2. SPF는 ‘허용 서버 목록’으로 단순하게 관리하세요

SPF 예시는 다음과 같은 구조입니다. `v=spf1 include:발송서비스.example -all` 실제 값은 사용하는 서비스가 제공한 값으로 바꿔야 하며, 예시를 그대로 복사하면 안 됩니다.

SPF를 여러 TXT 레코드로 나누면 수신 서버가 유효한 정책으로 해석하지 못할 수 있습니다. 발송 서비스가 늘어날 때마다 기존 레코드를 덮어쓰지 말고, 현재 값에 필요한 include를 통합한 뒤 중복과 미사용 항목을 검토하세요.

SPF만 통과해도 From 주소와 인증 도메인의 정렬이 맞지 않으면 DMARC가 실패할 수 있습니다. 따라서 SPF 결과와 함께 envelope-from 도메인이 조직의 From 도메인과 어떻게 연결되는지 확인해야 합니다.

• SPF는 도메인당 TXT 레코드 하나만 유지합니다.
• 기존 SPF가 있다면 새 값을 추가해 하나의 레코드로 합칩니다.
• 실제 발송에 필요한 서버와 include만 남기고 불필요한 항목은 제거합니다.
• DNS 호스트명, TTL, 따옴표 처리 방식은 DNS 관리 서비스의 입력 규칙에 맞춥니다.

3. DKIM은 selector와 서명 도메인을 맞추세요

DKIM은 발송 시스템이 개인키로 메시지에 서명하고, 수신 서버가 DNS의 공개키로 이를 검증하는 방식입니다. 개인키는 발송 서비스 또는 조직의 보안 저장소에서 관리하고 DNS에는 공개키만 게시해야 합니다.

selector가 다르면 공개키를 찾지 못하므로, 서비스가 안내한 selector를 정확히 사용해야 합니다. 여러 발송 시스템을 운영한다면 selector를 서비스별로 분리하면 교체와 장애 원인을 추적하기 쉽습니다.

테스트 메일을 보낸 뒤 원문에서 `dkim=pass`인지 확인하고, `d=` 값이 실제 From 도메인 또는 DMARC 정렬이 가능한 하위 도메인인지 확인하세요.

• 발송 서비스에서 제공한 selector별 공개키를 DNS에 등록합니다.
• DKIM 공개키가 들어갈 호스트명은 일반적으로 `selector._domainkey` 구조를 사용합니다.
• 메일 헤더의 `DKIM-Signature`에서 selector와 서명 도메인을 확인합니다.
• 본문 수정, 링크 추적, 중계 서버 변경이 서명을 깨뜨리지 않는지 테스트합니다.

4. DMARC는 관찰에서 강제까지 단계적으로 전환하세요

기본적인 DMARC 레코드 형태는 `v=DMARC1; p=none; rua=mailto:dmarc-report@발신도메인`입니다. 보고서 주소와 정책 값은 조직의 운영 방식에 맞게 설정하고, 외부 도메인으로 보고서를 받을 경우 해당 수신 서비스의 승인 절차가 필요한지 확인하세요.

DMARC는 From 주소의 도메인과 SPF 또는 DKIM 인증 도메인의 정렬을 판단합니다. SPF 또는 DKIM 중 하나가 통과하면서 정렬되면 DMARC 통과가 가능하지만, 인증 결과만 보고 정렬을 생략하면 안 됩니다.

보고서에서 정상 발송 IP와 실패 원인을 구분한 뒤 예외 경로를 보완합니다. 모든 합법적 발송 경로가 확인되기 전에는 강제 정책을 서두르지 말고, 정책 적용 범위를 하위 도메인이나 일부 발송 도메인부터 나누는 방법도 검토하세요.

• DMARC 레코드는 `_dmarc.발신도메인` 위치에 TXT로 등록합니다.
• 초기에는 `p=none`으로 시작하고 집계 보고서 수신 주소를 지정합니다.
• 정상 발송 경로가 모두 확인되면 `p=quarantine`, 이후 `p=reject` 전환을 검토합니다.
• 정책 변경 때마다 주요 발송 유형별 테스트 메일을 보내 결과를 기록합니다.

5. 설정 완료보다 ‘검증 기록’이 운영의 기준입니다

설정을 저장했다고 인증이 즉시 완료되는 것은 아닙니다. DNS 전파와 수신 사업자의 검사 시점이 다를 수 있으므로, 한 곳의 검사 결과만으로 판단하지 말고 여러 수신 환경에서 테스트하세요.

운영 기록에는 레코드 변경일, 변경자, 발송 서비스, selector, SPF 구성, DMARC 정책, 테스트 결과를 남기면 좋습니다. 이후 새 CRM이나 자동화 도구를 추가할 때 같은 체크리스트를 적용하면 인증 누락을 조기에 발견할 수 있습니다.

문제가 발생했을 때는 ‘메일이 스팸함에 들어갔다’는 결과만 기록하지 말고 원문 헤더와 발송 IP, From 도메인, DKIM selector, DMARC 보고서의 실패 사유를 함께 보관해야 정확한 수정이 가능합니다.

• DNS 조회로 SPF, DKIM, DMARC 레코드가 공개되어 있는지 확인합니다.
• 테스트 메일 원문에서 `Authentication-Results`를 확인합니다.
• SPF 통과 여부와 SPF 도메인, DKIM 통과 여부와 서명 도메인, DMARC 정렬 결과를 따로 기록합니다.
• DMARC 보고서의 발송 IP가 내부 승인 목록과 일치하는지 대조합니다.
• 정상 메일이 실패하면 정책을 되돌리기 전에 발송 서비스의 도메인 인증 상태와 리다이렉트 여부를 확인합니다.