인증 레코드는 등록보다 검증과 운영이 중요합니다. SPF·DKIM·DMARC를 발송 구조에 맞게 설정하고 단계적으로 정책을 강화하는 방법을 살펴봅니다.
1. 먼저 발송 구조와 인증 목표를 정리하기
DNS를 수정하기 전에 실제 발송 경로를 목록으로 만드세요. 뉴스레터 플랫폼, CRM 자동화, 영업 담당자의 메일 서비스, 거래성 알림 시스템처럼 발신 도메인을 사용하는 모든 서비스를 구분해야 합니다.
인증의 목표는 단순히 세 레코드를 등록하는 데 있지 않습니다. 수신 서버가 우리 조직의 정상 발송과 사칭 발송을 구별하고, 정상 메일의 발신 도메인 정렬 상태를 확인할 수 있도록 만드는 것이 핵심입니다.
- 주요 발신 도메인과 캠페인용 하위 도메인을 구분한다.
- 각 서비스의 발송 IP, 반송 주소, DKIM 서명 도메인, Return-Path를 확인한다.
- 마케팅 메일과 거래성 메일을 같은 도메인에서 보낼지 검토한다.
- DNS 관리 권한, 메일 플랫폼 관리자 권한, 검증 담당자를 지정한다.
2. SPF는 발송 서비스 목록을 한 곳에서 관리하기
SPF는 해당 도메인에서 메일을 보낼 수 있는 서버를 DNS의 TXT 레코드로 선언하는 방식입니다. 도메인당 SPF 레코드는 하나만 유지해야 하므로 여러 서비스가 각각 TXT 레코드를 추가하지 않도록 주의하세요.
기본 형태는 v=spf1 include:발송서비스도메인 ip4:허용IP ~all과 같습니다. 실제 값은 사용하는 플랫폼이 안내한 값을 기준으로 작성하고, 사용하지 않는 서비스의 include와 IP는 제거해야 합니다.
- 도메인 루트에 기존 SPF TXT 레코드가 있는지 먼저 조회한다.
- 여러 SPF 값을 하나로 합치고 중복된 include를 정리한다.
- DNS 조회 제한을 초과하지 않는지 발송 서비스와 함께 확인한다.
- 처음에는 ~all을 사용할 수 있지만, 정상 발송 범위를 검증한 뒤 정책 강화를 검토한다.
- SPF가 통과해도 DKIM과 DMARC 정렬이 자동으로 보장되는 것은 아님을 기록한다.
3. DKIM은 서비스별 선택자와 서명 상태를 확인하기
DKIM은 발송 메일에 암호화 서명을 추가하고 공개키를 DNS에 게시하는 방식입니다. 보통 발송 플랫폼이 selector를 생성하며, 수신 서버는 selector._domainkey.example.com에서 공개키를 조회합니다.
동일한 도메인을 여러 서비스가 사용한다면 서비스별 selector가 필요할 수 있습니다. DNS에 공개키를 등록한 뒤 테스트 메일의 DKIM 서명 도메인과 결과를 확인하고, 플랫폼 변경 시 기존 selector의 유지 또는 교체 계획도 남겨야 합니다.
- 플랫폼에서 제공한 selector와 공개키를 그대로 DNS에 등록한다.
- TXT 값이 줄바꿈이나 불필요한 따옴표로 변형되지 않았는지 확인한다.
- 테스트 메일의 Authentication-Results에서 dkim=pass를 확인한다.
- DKIM 서명 도메인인 d= 값이 DMARC 기준 도메인과 정렬되는지 확인한다.
- 발송 서비스 교체 전후에 selector 충돌과 서명 누락을 점검한다.
4. DMARC는 모니터링에서 차단으로 단계적으로 전환하기
DMARC는 SPF 또는 DKIM 인증 결과와 발신 도메인 정렬을 기준으로 수신 서버의 처리 방침을 제시합니다. 처음부터 reject를 적용하면 인증이 누락된 정상 발송까지 영향을 받을 수 있으므로, 먼저 보고서를 수집하는 단계가 안전합니다.
예시로 v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com 형태를 사용할 수 있습니다. 조직의 정책과 보고서 수신 환경에 맞춰 주소를 정하고, 보고서에 포함된 정상 발송·미승인 발송·정렬 실패 원인을 분류한 뒤 quarantine 또는 reject 전환 여부를 결정하세요.
- p=none으로 정상 발송 경로와 사칭 패턴을 관찰한다.
- rua 보고서를 받을 전용 주소와 분석 담당자를 지정한다.
- SPF 또는 DKIM 통과 여부뿐 아니라 From 도메인과의 정렬 상태를 확인한다.
- 정상 발송이 모두 파악된 뒤 일부 하위 도메인이나 제한된 범위에서 정책을 강화한다.
- 정책 변경일, 변경자, 영향받는 발송 서비스와 검증 결과를 운영 로그에 남긴다.
5. 등록 후 검증과 운영 점검을 반복하기
DNS 전파 시간은 환경에 따라 다를 수 있으므로 등록 직후의 조회 결과만으로 성공 여부를 판단하지 마세요. 외부 DNS 조회 도구, 발송 플랫폼의 인증 진단, 실제 수신 메일의 헤더를 함께 사용해야 합니다.
인증 설정은 일회성 작업이 아니라 발송 서비스와 DNS 변경에 대응하는 운영 항목입니다. 새 플랫폼을 추가하거나 From 주소를 바꿀 때마다 테스트 발송과 승인 절차를 거치도록 체크리스트에 포함하세요.
- SPF, DKIM, DMARC 레코드가 각각 올바른 호스트명과 TXT 값으로 조회되는지 확인한다.
- 주요 수신 환경으로 테스트 메일을 보내 Authentication-Results를 검토한다.
- DMARC 집계 보고서에서 새로운 발송 IP와 실패율 변화를 확인한다.
- 반송, 스팸 분류, 인증 실패가 발생하면 발송 중단 기준과 담당자 연락망을 적용한다.
- 분기별로 사용하지 않는 발송 서비스, SPF include, DKIM selector, DMARC 수신 주소를 정리한다.
자주 묻는 질문
SPF와 DKIM 중 하나만 설정해도 DMARC를 사용할 수 있나요?
DMARC는 SPF 또는 DKIM 중 하나가 통과하면서 From 도메인과 정렬되면 통과할 수 있습니다. 다만 한 인증 방식에 장애가 생겨도 정상 발송을 유지하려면 SPF와 DKIM을 모두 설정하고 각각의 정렬 상태를 확인하는 편이 좋습니다.
DMARC를 처음부터 reject로 설정해도 되나요?
모든 정상 발송 경로를 파악했고 인증 및 정렬 실패가 없다는 근거가 있다면 검토할 수 있습니다. 그렇지 않다면 p=none으로 보고서를 수집한 뒤 quarantine, reject 순서로 단계적으로 강화하는 방식이 안전합니다.
SPF 레코드를 두 개 등록하면 안 되나요?
도메인에 SPF 레코드가 여러 개 있으면 수신 서버가 유효한 정책으로 처리하지 못할 수 있습니다. 기존 레코드를 확인한 뒤 모든 허용 발송원을 하나의 SPF 정책에 통합해야 합니다.
DMARC 보고서는 왜 별도로 관리해야 하나요?
집계 보고서는 어떤 IP와 서비스가 도메인을 사용했는지, SPF·DKIM 및 정렬이 어떻게 처리됐는지 파악하는 데 사용됩니다. 보고서 수신 주소의 접근 권한과 보관 기간을 정하고, 신규 발송원과 실패 패턴을 정기적으로 검토해야 합니다.