인증 기록을 추가하는 것만으로는 충분하지 않습니다. 발송 서비스와 도메인의 관계를 정리하고, 인증 결과와 정책 보고서를 확인하며 단계적으로 DMARC를 강화해야 합니다.
1. 세 인증의 역할과 확인 순서부터 구분하기
SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버를 지정하는 방식입니다. 수신 서버는 메일의 발송 경로가 해당 도메인의 SPF 정책에 포함되는지 확인합니다.
DKIM은 발송 서버가 메일 본문과 주요 헤더에 전자서명을 붙이고, 수신 서버가 공개키로 서명을 검증하는 방식입니다. 발송 중 일부 내용이 변경되면 검증에 실패할 수 있습니다.
DMARC는 SPF 또는 DKIM 인증 결과와 사용자에게 보이는 From 도메인의 일치 여부를 판단하고, 실패한 메일을 어떻게 처리할지 정책으로 전달합니다. 따라서 설정 순서는 발송원 파악, SPF와 DKIM 구성, 정렬 확인, DMARC 모니터링 순서가 적절합니다.
- 사용 중인 발송 도구, CRM, 거래처 알림 시스템, 웹서버, 고객지원 솔루션을 모두 목록화합니다.
- 각 발송원이 사용하는 From 주소, Return-Path 또는 envelope-from 주소, DKIM 서명 도메인을 기록합니다.
- 테스트 메일의 헤더에서 SPF, DKIM, DMARC 결과와 인증에 사용된 도메인을 함께 확인합니다.
2. SPF 레코드는 발송원을 통제할 수 있게 작성하기
SPF는 발신 도메인의 DNS에 TXT 레코드로 등록합니다. 기본 구조는 v=spf1로 시작하며, 실제 사용하는 메일 서비스가 제공한 include 또는 고정 IP를 필요한 범위에서만 추가합니다. 서비스 제공업체의 공식 문서에 없는 항목을 임의로 넣지 않는 것이 안전합니다.
한 도메인에는 SPF 정책을 여러 개 등록하기보다 하나의 정책으로 통합해야 합니다. 여러 TXT 레코드에 각각 v=spf1이 있으면 수신 서버가 SPF를 무효로 판단할 수 있습니다. 발송원을 삭제하기 전에는 해당 시스템의 자동 알림과 예약 발송이 중단되지 않는지 확인해야 합니다.
SPF는 전달 서버나 일부 중계 환경에서 원래 발송 IP를 확인하지 못할 수 있습니다. 따라서 SPF만으로 모든 발송을 보호하려 하지 말고, DKIM 서명과 DMARC 정렬을 함께 설계합니다.
- DNS에 이미 등록된 SPF 레코드가 있는지 먼저 조회합니다.
- 더 이상 사용하지 않는 서비스의 include와 IP는 소유자 확인 후 제거합니다.
- SPF 조회 한도 초과 가능성이 있는 복잡한 구성을 검토하고, 사용하지 않는 중첩 include를 정리합니다.
- 변경 후 정상 발송, 반송 안내, 비밀번호 재설정 메일 등 주요 유형을 각각 테스트합니다.
3. DKIM은 선택자와 서명 도메인을 함께 관리하기
DKIM은 보통 발송 서비스가 제공하는 선택자(selector)와 공개키를 DNS에 등록하는 방식으로 설정합니다. DNS 호스트명은 일반적으로 선택자와 _domainkey를 조합하지만, 정확한 이름과 키 형식은 서비스 제공 문서를 따라야 합니다.
중요한 것은 DKIM이 통과하는지뿐 아니라 서명 도메인이 어떤 값인지 확인하는 것입니다. DMARC 정렬을 고려하면 사용자에게 보이는 From 도메인과 같거나 조직적으로 연결된 서명 도메인을 사용해야 합니다.
발송 서비스를 교체하거나 여러 서비스를 병행할 때는 선택자를 분리하면 변경 범위를 관리하기 쉽습니다. 기존 선택자를 즉시 삭제하지 말고, 해당 선택자를 사용하는 발송이 더 이상 없다는 사실을 로그와 테스트로 확인한 뒤 정리합니다.
- 발송 서비스별 선택자, 공개키 등록 위치, 키 교체 주기를 문서화합니다.
- 테스트 메일의 DKIM 서명 도메인과 d= 값을 확인합니다.
- 메일 본문이나 추적 링크를 발송 후 수정하는 시스템이 DKIM 검증에 영향을 주는지 확인합니다.
- 개인키는 발송 서비스 또는 보안 저장소에서 관리하고 DNS에는 공개키만 등록합니다.
4. DMARC는 모니터링에서 차단으로 단계적으로 전환하기
DMARC 레코드는 보통 _dmarc 하위 도메인에 TXT로 등록합니다. 처음에는 p=none으로 인증 결과를 수집하고, 정상 발송원과 실패 원인을 구분한 뒤 quarantine 또는 reject로 정책을 강화합니다.
정책 전환 전에 SPF 또는 DKIM 가운데 하나가 From 도메인과 정렬된 상태로 통과하는지 확인해야 합니다. SPF와 DKIM이 각각 통과하더라도 다른 도메인을 기준으로 인증되면 DMARC 정렬에 실패할 수 있습니다.
rua를 사용하면 집계 보고서를 받을 주소를 지정할 수 있습니다. 보고서에는 여러 발송 시스템의 정보가 포함될 수 있으므로 전용 수신함이나 분석 도구를 사용하고, 내부 접근 권한과 보관 기준을 정합니다. 보고서 수신 주소가 외부 도메인이라면 해당 수신을 허용하는 추가 절차가 필요할 수 있습니다.
- 초기에는 p=none으로 정상 발송원, 제3자 발송원, 전달·포워딩에 따른 실패를 관찰합니다.
- 실패 건수만 보지 말고 발송량, From 도메인, DKIM 서명 도메인, SPF 통과 여부를 함께 분류합니다.
- 영향이 큰 메일 유형부터 별도 테스트한 뒤 quarantine을 검토합니다.
- 오류 원인이 해소되고 모니터링이 안정되면 reject 전환 여부와 예외 범위를 결정합니다.
- 필요한 경우 하위 도메인 정책과 pct 적용 범위를 별도로 검토합니다.
5. 배포 전후 검증과 운영 책임을 고정하기
DNS 변경은 TTL과 캐시 영향으로 즉시 모든 수신 서버에 반영되지 않을 수 있습니다. 설정 직후 한 곳의 테스트 결과만 보고 성공으로 판단하지 말고, 주요 수신 환경과 실제 발송 유형에서 결과를 확인합니다.
인증 설정은 일회성 작업이 아니라 발송원 변경 때마다 점검해야 하는 운영 기준입니다. 신규 도구 도입 양식에 From 도메인, SPF 포함 여부, DKIM 선택자, DMARC 정렬 방식, 담당자를 필수 항목으로 넣으면 누락을 줄일 수 있습니다.
정책을 reject로 운영하더라도 오설정된 내부 시스템이나 새로운 SaaS가 차단 대상이 될 수 있습니다. 발송 변경 전 사전 테스트와 변경 후 보고서 확인을 운영 절차에 포함하세요.
- DNS 조회 도구와 실제 수신 메일 헤더에서 레코드와 인증 결과를 교차 확인합니다.
- 테스트 항목에 일반 발송, 대량 발송, 자동 알림, 전달 메일, 회신 메일을 포함합니다.
- DMARC 보고서 검토 주기와 담당자를 정하고, 이상 발생 시 에스컬레이션 기준을 문서화합니다.
- 발송 서비스 해지 시 SPF include, DKIM 선택자, 관련 API와 자동화도 함께 정리합니다.
- 인증 실패가 발생하면 정책을 즉시 완화하기보다 발송원과 정렬 조건을 먼저 확인합니다.
자주 묻는 질문
SPF, DKIM, DMARC를 반드시 모두 설정해야 하나요?
세 기술의 역할이 다르므로 함께 운영하는 것이 일반적입니다. SPF와 DKIM은 발송 인증의 기반이고, DMARC는 From 도메인과의 정렬 및 실패 시 처리 정책을 담당합니다. 하나만 설정하면 확인 범위와 통제력이 제한됩니다.
DMARC를 처음부터 reject로 설정해도 되나요?
모든 발송원을 파악하고 SPF 또는 DKIM 정렬을 검증했다면 가능하지만, 신규 시스템이나 누락된 자동 발송이 차단될 위험이 있습니다. 보통 p=none으로 결과를 관찰한 뒤 단계적으로 정책을 강화합니다.
SPF와 DKIM이 모두 통과하면 DMARC도 통과하나요?
반드시 그렇지는 않습니다. SPF 또는 DKIM 인증이 통과하면서 동시에 해당 도메인이 사용자에게 보이는 From 도메인과 DMARC 기준에 맞게 정렬되어야 합니다. 메일 헤더의 인증 도메인을 함께 확인해야 합니다.
메일 전달이나 포워딩에서 SPF가 실패하면 어떻게 하나요?
전달 과정에서는 원래 발송 IP 기준의 SPF가 실패할 수 있습니다. DKIM 서명이 유지되고 From 도메인과 정렬되면 DMARC 통과에 도움이 되므로, 전달 환경까지 고려해 DKIM을 우선 점검하고 실제 수신 결과를 확인합니다.