DKIM·SPF·DMARC는 레코드를 한 번 등록하는 작업이 아니라 발신 경로를 정리하고 인증 실패를 관찰하며 정책을 전환하는 운영 과제입니다.
1. DNS 설정 전에 발신 경로부터 목록화하기
인증 설정의 첫 단계는 DNS가 아니라 발신 경로 정리입니다. 마케팅 자동화 도구, CRM, 영업 담당자의 메일 클라이언트, 고객지원 시스템, 거래명세서 발송 서비스처럼 회사 도메인을 사용하는 모든 시스템을 표에 기록하세요.
각 발신 경로마다 사용하는 From 도메인, 실제 발송 서버 또는 서비스, DKIM 지원 여부, SPF에 추가할 도메인, 회신 주소를 확인해야 합니다. 목록에 없는 시스템이 있으면 DMARC 정책을 강화한 뒤 정상 메일이 격리되거나 거부될 수 있습니다.
- 발신 시스템명과 담당 부서를 기록한다.
- 실제 발송 도메인과 From 주소의 도메인을 구분한다.
- 테스트·운영 환경의 발신 경로를 따로 적는다.
- 퇴역한 서비스와 더 이상 사용하지 않는 SPF 항목을 표시한다.
- DNS 변경 권한자와 검증 담당자를 정한다.
2. SPF는 발송 서버를 한 줄의 정책으로 관리하기
SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버나 서비스를 DNS TXT 레코드로 선언하는 방식입니다. 일반적인 형태는 v=spf1 include:발송서비스.example ip4:203.0.113.10 -all과 같습니다. 실제 값은 각 서비스 제공자가 안내한 공식 도메인과 IP만 사용하세요.
같은 도메인에 SPF TXT 레코드를 여러 개 만들면 검증이 실패할 수 있으므로 기존 레코드가 있는지 먼저 확인하고 하나로 합쳐야 합니다. SPF는 DNS 조회 제한의 영향을 받으므로 include를 무분별하게 추가하지 말고, 사용하지 않는 서비스는 정리하세요.
- 기존 SPF 레코드를 조회한 뒤 한 개의 정책으로 통합한다.
- 발송 서비스가 안내한 include 또는 고정 IP를 직접 대체하지 않고 검토 후 반영한다.
- 설정 초기에는 실제 발송 경로를 빠뜨리지 않는 것이 우선이다.
- 모든 경로가 확인된 뒤에만 -all 같은 엄격한 실패 처리를 검토한다.
- SPF만 통과해도 From 도메인과 정렬되지 않으면 DMARC가 통과하지 않을 수 있음을 확인한다.
3. DKIM은 서비스별 선택자와 서명을 검증하기
DKIM은 발송 시스템이 메일에 전자서명을 붙이고 수신 서버가 공개키로 이를 확인하는 방식입니다. 발송 서비스에서 selector와 공개키를 발급받은 뒤 selector._domainkey.example.com 주소에 TXT 또는 CNAME 레코드를 등록합니다.
서비스마다 등록 방식이 다르므로 키 값을 임의로 줄이거나 줄바꿈을 바꾸지 마세요. 2048비트 키를 지원하는 서비스라면 이를 우선 검토하고, 여러 발송 시스템은 서로 다른 selector를 사용해 교체와 장애 대응이 가능하도록 관리합니다.
- selector별 담당 시스템과 생성일을 기록한다.
- DNS에 등록한 공개키와 발송 서비스의 활성화 상태를 함께 확인한다.
- 테스트 메일의 원문에서 dkim=pass와 d=도메인을 확인한다.
- DKIM 서명 도메인이 From 주소의 조직 도메인과 정렬되는지 확인한다.
- 키 교체 시 기존 키를 즉시 삭제하지 말고 기존 메일의 처리 시간을 고려해 단계적으로 정리한다.
4. DMARC는 관찰 모드에서 정책 전환까지 단계적으로 운영하기
DMARC는 SPF 또는 DKIM 인증 결과가 From 도메인과 정렬되는지 확인하고, 실패한 메일을 수신 서버가 어떻게 처리할지 지시합니다. 시작 예시는 _dmarc.example.com의 TXT 레코드에 v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com처럼 관찰 정책을 두는 방식입니다.
보고서 수신 주소는 실제로 모니터링할 수 있어야 하며, 외부 도메인으로 보고서를 받을 때는 해당 수신 도메인의 별도 동의 절차가 필요할 수 있습니다. 집계 보고서에서 정상 발송 경로와 실패 원인을 확인한 뒤 p=quarantine, p=reject 순으로 정책 강화를 검토하세요.
- 처음에는 p=none으로 정상·비정상 발신량과 정렬 실패 원인을 관찰한다.
- rua 보고서가 수신되는지와 담당자가 분석하는 주기를 정한다.
- 정상 발송의 DKIM 정렬 또는 SPF 정렬이 확보된 경로부터 정책 영향을 검토한다.
- 정책 강화 전 영업·고객지원·거래 시스템의 예외 발송을 다시 확인한다.
- pct, sp, adkim, aspf 같은 선택값은 조직의 준비 수준과 하위 도메인 구조를 고려해 사용한다.
5. 설정 완료를 인증 결과와 운영 기록으로 판정하기
DNS 전파만 확인하고 완료 처리하지 말고 실제 메일의 인증 결과를 점검하세요. 동일한 테스트를 내부 주소와 주요 수신 환경에서 수행하고, 메일 원문의 Authentication-Results에서 spf, dkim, dmarc 결과와 도메인을 확인합니다.
정상 메일이 실패하면 From 주소, Return-Path, DKIM 서명 도메인, 실제 발송 IP를 함께 비교해야 합니다. 문제를 수정한 뒤에는 변경일, 레코드 값, 영향받은 발송 경로, 테스트 결과를 기록해 다음 장애나 키 교체 때 재사용하세요.
- DNS 조회 결과와 메일 원문의 인증 결과를 함께 저장한다.
- 발송 시스템별 정상·실패 사례를 최소 한 건씩 남긴다.
- DMARC 실패 원인을 미승인 발송, SPF 미정렬, DKIM 실패, 전달·포워딩으로 구분한다.
- 정책 변경 전후의 반송·스팸 분류·수신 문의를 같은 기준으로 비교한다.
- 인증 레코드 변경 권한과 비상 롤백 절차를 문서화한다.
자주 묻는 질문
SPF와 DKIM 중 하나만 설정해도 DMARC를 사용할 수 있나요?
DMARC는 SPF 정렬 또는 DKIM 정렬 중 하나가 통과하면 인증될 수 있습니다. 다만 전달 과정에서 SPF가 바뀌거나 DKIM이 훼손될 수 있으므로 주요 발송 경로에는 두 방식을 함께 검토하는 편이 안전합니다.
SPF 레코드를 발송 서비스마다 하나씩 만들면 안 되나요?
같은 도메인에 SPF 레코드를 여러 개 두면 수신 서버가 SPF를 무효로 판단할 수 있습니다. 기존 레코드를 확인한 뒤 필요한 메커니즘을 하나의 정책으로 통합해야 합니다.
DMARC를 처음부터 p=reject로 설정해도 되나요?
모든 발송 경로와 정렬 상태를 이미 검증한 경우가 아니라면 위험할 수 있습니다. 일반적으로 관찰 정책으로 실패 원인을 확인하고, 영향 범위를 점검한 뒤 quarantine과 reject를 단계적으로 검토합니다.
DMARC 보고서에는 무엇을 기록해야 하나요?
보고서 수신일, 발송 소스, From 도메인, SPF·DKIM 결과, 정렬 상태, 적용된 정책, 정상 또는 미승인 여부를 기록하세요. 보고서만으로 발송 목적을 확정하기 어려우므로 시스템 담당자 확인도 함께 남기는 것이 좋습니다.