B2B 발신 도메인 인증 레코드 설정과 검증 절차

설정 전에 발신 경로부터 목록화하기

인증 설정의 첫 단계는 DNS 화면을 여는 것이 아니라 회사 도메인에서 이메일을 보내는 모든 시스템을 찾는 일입니다. 업무용 메일, 마케팅 자동화 도구, CRM, 고객지원 시스템, 청구·알림 서비스, 외부 대행사의 발신 도메인과 발신 주소를 구분해 기록하세요.

각 시스템마다 실제 발신 도메인, Return-Path 또는 Envelope From, DKIM 서명 도메인, 사용하는 발송 서비스, 담당자를 함께 정리하면 이후 SPF 누락과 DMARC 불일치를 빠르게 추적할 수 있습니다.

• 운영·마케팅·개발팀에 외부 발송 시스템 목록을 요청합니다.
• 사람이 읽는 From 주소와 실제 반송 처리 주소가 다른지 확인합니다.
• 서비스별로 회사 주도메인을 사용할지 별도 서브도메인을 사용할지 결정합니다.
• 사용하지 않는 발송 서비스와 오래된 DNS 레코드는 별도로 표시합니다.

SPF는 발신 서버를 하나의 정책으로 관리하기

SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버나 서비스를 DNS에 선언하는 방식입니다. 동일한 도메인에 SPF TXT 레코드를 여러 개 만들면 검증 오류가 발생할 수 있으므로, 기존 레코드를 먼저 확인한 뒤 하나의 정책으로 통합해야 합니다.

외부 발송 서비스가 제공하는 include 값은 해당 서비스의 공식 문서에서 복사하고, 임의의 IP 주소를 추가하지 마세요. 발송 서비스가 바뀌면 SPF에서 더 이상 사용하지 않는 항목을 제거하되, 실제 운영 메일이 중단되지 않도록 변경 전후 발신 경로를 대조해야 합니다.

• 도메인에 SPF TXT 레코드가 이미 있는지 확인합니다.
• 새 서비스 추가 시 기존 SPF 레코드에 항목을 병합합니다.
• 같은 도메인에 SPF 레코드를 중복 생성하지 않습니다.
• DNS 조회 제한에 걸릴 수 있으므로 불필요한 중첩 include를 정리합니다.
• SPF 통과 여부만 보지 말고 From 도메인과의 정렬 여부도 확인합니다.

DKIM은 서비스별 선택자와 공개키를 검수하기

DKIM은 발송 시스템이 메일에 서명하고 수신 서버가 공개키로 그 서명을 확인하도록 구성합니다. 발송 서비스에서 selector를 생성하면 해당 selector와 도메인의 공개키를 DNS에 TXT 또는 CNAME으로 등록합니다. 서비스에 따라 CNAME을 요구할 수 있으므로 레코드 형식을 임의로 바꾸지 않는 것이 안전합니다.

같은 도메인으로 여러 서비스를 운영한다면 서비스별 selector를 분리하세요. 이렇게 하면 한 시스템의 키를 교체하거나 중단할 때 다른 발송 시스템에 영향을 줄 가능성을 줄일 수 있습니다. 개인키는 발송 서비스 또는 조직의 보안 관리 영역 밖으로 공유하지 않습니다.

• 서비스가 안내한 selector, 호스트명, 레코드 형식을 그대로 확인합니다.
• DNS 호스트 입력란이 자동으로 도메인을 붙이는지 관리 콘솔에서 확인합니다.
• 테스트 메일의 DKIM 서명 도메인과 From 도메인이 일치하거나 조직 정책에 맞게 정렬되는지 봅니다.
• 키 교체 시 기존 selector를 즉시 삭제하지 말고 전환 기간을 둡니다.
• 원문 헤더에서 dkim=pass와 서명 도메인을 함께 확인합니다.

DMARC는 모니터링부터 정책 적용까지 단계적으로

DMARC는 SPF 또는 DKIM 결과가 From 도메인과 정렬되는지 확인하고, 검증에 실패한 메일을 수신 서버가 어떻게 처리할지 제시합니다. 처음부터 거부 정책을 적용하기보다 현재 발신 경로와 실패 원인을 파악할 수 있도록 모니터링 정책으로 시작하는 편이 적절합니다.

DMARC 보고서를 받을 주소를 정할 때는 보안과 개인정보 처리 방식을 함께 검토하세요. 집계 보고서에는 발신 IP와 도메인 정보가 포함될 수 있으므로 내부 수신함을 보호하고, 외부 분석 서비스 사용 시 데이터 처리 조건을 확인해야 합니다.

보고서에서 정상 발신 시스템의 통과 여부와 정렬 실패를 확인한 뒤, 조직 상황에 맞춰 완화 정책을 거쳐 거부 정책으로 강화합니다. 정책 변경일, 변경자, 관찰 결과를 운영 기록에 남기면 장애 원인을 추적하기 쉽습니다.

• DMARC 정책의 적용 도메인과 하위 도메인 정책을 구분해 결정합니다.
• 집계 보고서 수신 주소가 실제로 보고서를 처리할 수 있는지 확인합니다.
• 정상 발신 서비스가 모두 SPF 또는 DKIM 정렬을 통과하는지 확인합니다.
• 실패한 발신 IP가 승인된 서비스인지, 위조 발송인지 분류합니다.
• 정책을 강화하기 전 영업·지원·거래처 알림 메일의 예외 경로를 재검증합니다.

DNS 반영 후 실제 헤더와 수신 환경에서 검증하기

DNS 변경은 사용 중인 DNS 사업자와 TTL에 따라 반영 시간이 달라질 수 있습니다. 설정 직후 한 곳의 테스트 결과만으로 완료를 판단하지 말고, 실제 사용하는 발송 서비스별로 테스트 메일을 보내 원문 헤더를 확인하세요.

검증 항목은 SPF 결과, DKIM 결과와 selector, DMARC 결과, From·Return-Path·서명 도메인의 관계입니다. 메일이 받은편지함에 도착했는지만 확인하면 인증 실패나 특정 수신 사업자에서의 차이를 놓칠 수 있습니다.

• 각 발송 시스템에서 테스트 메일을 한 통씩 발송합니다.
• 수신 메일의 원문에서 spf, dkim, dmarc 결과를 확인합니다.
• 주요 거래처 또는 사용하는 수신 서비스별로 결과 차이를 기록합니다.
• 실패한 메일의 발신 IP, 도메인, 시간, Message-ID를 보관합니다.
• DNS 레코드 변경 전 값을 캡처해 롤백 기준을 남깁니다.

설정 완료 후 주간 운영 기준 세우기

인증 설정은 일회성 프로젝트가 아니라 발신 시스템 변경을 통제하는 운영 절차입니다. 새 마케팅 도구나 고객지원 솔루션을 도입할 때 도메인 인증 검토를 배포 체크리스트에 포함하고, 발송 종료 시 관련 DNS와 계정을 함께 정리하세요.

DMARC 보고서는 절대적인 평판 점수로 해석하기보다 승인되지 않은 발신, 정렬 실패, 갑작스러운 트래픽 변화를 찾는 자료로 활용합니다. 변경이 있었던 주에는 평소보다 자주 확인하고, 이상이 없을 때도 정해진 주기로 담당자가 검토하도록 책임자를 지정하세요.

• 주간 단위로 DMARC 보고서의 신규 발신원을 확인합니다.
• 새 발송 서비스가 추가되면 SPF·DKIM·DMARC 정렬을 배포 전에 검증합니다.
• DKIM selector와 DNS 레코드의 소유자를 문서화합니다.
• 정책 변경과 예외 승인 내역을 티켓이나 변경 이력에 남깁니다.
• 인증 실패를 발견하면 먼저 정상 발신 경로인지 확인한 뒤 차단 정책을 조정합니다.