B2B 이메일 인증 레코드를 설정하고 검증하는 실무 순서

먼저 발송 구조와 인증 범위를 정리하기

DKIM·SPF·DMARC 설정 전에 어떤 도메인에서 누구에게 이메일을 보내는지부터 목록화합니다. 대표 발송 서비스, CRM, 영업 자동화 도구, 고객지원 시스템, 사내 메일 서버처럼 실제로 외부 메일을 전송하는 시스템을 빠뜨리면 SPF 누락이나 DKIM 미서명 문제가 발생할 수 있습니다.

From 주소에 표시되는 도메인과 Return-Path 또는 envelope-from 도메인이 서로 다를 수 있다는 점도 확인해야 합니다. DMARC는 수신자가 확인하는 From 도메인과 SPF 또는 DKIM의 도메인 정렬을 기준으로 판단하므로, DNS 레코드가 존재하는 것만으로 인증이 완료되지는 않습니다.

• 사용 중인 발송 시스템과 담당자를 한 표에 기록합니다.
• 각 시스템의 공식 설정 문서에서 SPF 포함값, DKIM selector, 사용자 지정 발송 도메인을 확인합니다.
• 운영·테스트·거래성 메일의 발송 도메인을 구분합니다.
• 현재 From, Return-Path, DKIM d= 값이 무엇인지 샘플 메일의 원문에서 확인합니다.

SPF는 발송 서버의 허용 범위를 정확히 정의하기

SPF는 특정 도메인을 대신해 메일을 보낼 수 있는 서버나 서비스의 범위를 DNS TXT 레코드로 선언하는 방식입니다. 도메인당 SPF 레코드는 하나만 두어야 하며, 여러 TXT 값을 나누어 등록하면 수신자가 정상적으로 해석하지 못할 수 있습니다.

여러 발송 서비스를 사용한다면 각 서비스가 안내한 include 또는 IP 정보를 기존 SPF 정책에 합칩니다. 무작정 서비스를 추가하면 DNS 조회 제한에 걸릴 수 있으므로 사용하지 않는 항목은 정리하고, 실제 발송이 확인된 서비스만 남깁니다.

• 도메인 루트에 SPF TXT 레코드가 하나만 있는지 확인합니다.
• 기존 SPF 값을 덮어쓰지 말고 현재 발송 서비스 목록과 대조해 수정합니다.
• 서비스를 중단할 때 관련 include나 IP를 함께 제거합니다.
• dig TXT example.com 또는 DNS 조회 도구로 게시 결과를 확인합니다.
• 일시적으로 모든 발송을 허용하는 형태의 완화 설정을 운영 정책처럼 사용하지 않습니다.

DKIM은 selector와 서명 도메인을 함께 검증하기

DKIM은 발송 시스템이 메일에 암호화 서명을 추가하고, 수신자가 DNS에 게시된 공개키로 서명을 확인하는 방식입니다. 발송 서비스에서 제공한 selector와 공개키를 정확히 등록해야 하며, selector가 다르면 올바른 키를 찾지 못합니다.

설정 후에는 단순히 DKIM 레코드가 조회되는지보다 실제 메일에 DKIM-Signature가 포함되는지 확인해야 합니다. 특히 d= 값이 From 도메인과 같거나 조직적으로 정렬되는지 살펴보세요. 발송 서비스의 기본 공유 도메인으로 서명되고 있다면 사용자 지정 DKIM 도메인을 적용할 수 있는지 확인합니다.

• 서비스가 안내한 selector._domainkey 하위 이름을 그대로 사용합니다.
• 공개키의 공백·따옴표·줄바꿈 처리 방식이 DNS 제공업체에서 올바른지 확인합니다.
• 테스트 메일 원문에서 DKIM 서명, d= 도메인, selector를 확인합니다.
• 키를 교체할 때 기존 selector를 즉시 삭제하지 말고 기존 메일의 검증 기간을 고려해 교체합니다.
• 발송 도구의 DKIM 상태가 인증됨으로 바뀌었는지와 수신자 측 Authentication-Results를 함께 확인합니다.

DMARC는 관찰부터 정책 적용까지 단계적으로 운영하기

DMARC는 From 도메인을 기준으로 SPF와 DKIM의 인증 및 정렬 결과를 검사하고, 실패한 메일을 수신자가 어떻게 처리할지 정책으로 제시합니다. 처음부터 강한 차단 정책을 적용하면 누락된 정상 발송 시스템까지 영향을 받을 수 있으므로, 새 도메인이나 복잡한 발송 구조에서는 보고 중심으로 시작하는 편이 안전합니다.

먼저 p=none으로 보고서를 수집해 승인되지 않은 발송원을 파악합니다. 이후 정상 발송원이 모두 정리되고 정렬 실패 원인을 설명할 수 있을 때 quarantine 또는 reject로 강화합니다. pct를 사용하는 경우에도 적용 범위와 변경 시점을 운영 기록에 남겨야 합니다.

rua 보고서에는 발송량과 인증 결과가 포함될 수 있으므로 외부 분석 서비스로 전달할 때 개인정보와 보관 정책을 검토합니다. DMARC 정책은 SPF·DKIM을 대체하지 않으며, 두 인증 체계를 먼저 정상화해야 해석이 쉬워집니다.

• 초기 예시: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
• rua 주소가 실제 수신 가능한지와 보고서 분석 담당자를 지정합니다.
• 보고서에서 낯선 발송원, SPF 실패, DKIM 실패, 정렬 실패를 구분합니다.
• 정상 발송원과 미승인 발송원을 분류한 뒤 SPF·DKIM 설정을 보완합니다.
• 정책 변경 전 내부 알림, 거래성 메일, 고객지원 메일의 예외 여부를 점검합니다.

설정 완료를 DNS 조회가 아닌 실제 수신으로 판정하기

인증 레코드는 DNS 전파와 수신자별 캐시 영향으로 즉시 동일하게 보이지 않을 수 있습니다. 한 곳의 DNS 조회 결과만으로 완료를 선언하지 말고 주요 수신 환경에 테스트 메일을 보내 헤더와 DMARC 결과를 확인합니다.

검증용 테스트는 정상 발송, 잘못된 발송원, 여러 발송 시스템, 회신 주소가 다른 메일을 나누어 진행합니다. 오류가 발생하면 SPF 레코드, DKIM selector, 서명 도메인, From 도메인, DMARC 정렬 모드를 순서대로 대조하면 원인을 좁히기 쉽습니다.

• Gmail 등 주요 수신 환경에서 원문을 열어 SPF=pass, DKIM=pass, DMARC=pass를 확인합니다.
• Authentication-Results의 header.from, smtp.mailfrom, header.d 값을 비교합니다.
• 발송 서비스별 테스트 결과와 DNS 변경 시각을 기록합니다.
• DMARC 집계 보고서와 개별 반송 메시지를 함께 검토합니다.
• 변경 후 정상 메일이 스팸함으로 이동하는지, 거래성 메일이 누락되는지도 확인합니다.