B2B 이메일 도메인 인증 실무: 레코드 설정부터 DMARC 전환까지

1. 레코드보다 먼저 발송 경로를 목록화하세요

인증 설정의 첫 단계는 DNS 화면을 여는 것이 아니라 실제 발송원을 빠짐없이 찾는 일입니다. 마케팅 자동화 도구만 등록하고 CRM 알림 메일이나 영업 담당자의 개별 발송 도구를 누락하면 DMARC 적용 이후 정상 메일까지 영향을 받을 수 있습니다.

다음 표에 발송 시스템, 사용하는 From 주소, 발송 도메인, SPF 지원 여부, DKIM selector, 테스트 담당자를 적어 두면 이후 오류의 원인을 좁히기 쉽습니다. 오래된 서비스와 중단된 계정도 함께 확인해 불필요한 인증 경로를 줄이세요.

• 현재 사용하는 이메일 발송 플랫폼, CRM, 고객지원 도구, 거래성 메일 시스템을 모두 기록합니다.
• 각 시스템의 발송 도메인과 Return-Path 또는 MAIL FROM 도메인을 구분합니다.
• 운영 중인 도메인과 별도로 캠페인용 하위 도메인을 사용할지 결정합니다.
• 도메인 DNS를 수정할 담당자와 발송 플랫폼 설정을 담당할 담당자를 정합니다.

2. SPF는 승인된 발송원만 남기는 구조로 설정하세요

SPF는 수신 서버가 특정 도메인을 대신해 메일을 보낼 수 있는 서버를 확인하는 정책입니다. 예시는 다음과 같은 형태지만, 실제 include 값과 IP는 각 발송 서비스가 제공한 공식 문서를 사용해야 합니다: v=spf1 include:발송서비스.example ip4:203.0.113.10 ~all.

여러 서비스가 각각 SPF TXT 레코드를 만들도록 안내하더라도 도메인에 SPF 레코드를 여러 개 게시하면 검증 오류가 발생할 수 있습니다. 기존 레코드를 확인한 뒤 승인 목록을 하나로 합치고, 변경 전후의 DNS 조회 결과를 저장하세요.

SPF는 DNS 조회가 많아지면 permerror가 발생할 수 있습니다. include 안에 다시 include가 연결되는 구조까지 고려해야 하므로, 단순히 항목을 계속 추가하기보다 사용하지 않는 서비스 제거와 발송 도메인 분리를 먼저 검토하는 것이 좋습니다.

• SPF는 도메인당 하나의 TXT 레코드만 유지합니다.
• 승인할 서비스의 공식 SPF include 또는 고정 IP만 추가합니다.
• SPF include가 DNS 조회 한도에 접근하지 않는지 확인합니다.
• 발송 서비스를 해지했다면 SPF와 관련 DKIM 설정에서 제거합니다.

3. DKIM은 서비스별 selector와 From 도메인 정렬을 확인하세요

DKIM은 발송 서버가 메일에 서명하고 수신 서버가 DNS의 공개키로 서명을 검증하는 방식입니다. 같은 도메인이라도 발송 시스템별로 selector가 다를 수 있으므로, selector를 임의로 통일하기보다 시스템별로 발급된 값을 정확히 게시하세요.

중요한 것은 DKIM 인증 통과만이 아니라 서명 도메인과 수신자에게 보이는 From 도메인의 관계입니다. DMARC 정렬을 고려한다면 플랫폼이 제공하는 기본 서명 도메인 대신 조직의 발송 도메인으로 DKIM을 서명하도록 설정할 수 있는지 확인해야 합니다.

테스트는 제목이나 본문보다 원본 헤더를 기준으로 합니다. Authentication-Results에서 dkim=pass인지, d= 값이 어떤 도메인인지, selector가 예상한 값인지 기록하면 발송 플랫폼이 바뀌었을 때도 비교가 가능합니다.

• 발송 플랫폼에서 DKIM을 활성화하고 selector와 공개키를 발급받습니다.
• selector._domainkey 형태의 TXT 또는 CNAME 레코드를 DNS에 게시합니다.
• 공개키가 줄바꿈이나 따옴표 오류 없이 등록됐는지 확인합니다.
• 실제 테스트 메일의 Authentication-Results에서 dkim=pass와 서명 도메인을 확인합니다.

4. DMARC는 차단 정책이 아니라 관찰에서 시작하세요

기본 형식은 v=DMARC1; p=none; rua=mailto:dmarc-report@example.com처럼 구성할 수 있습니다. 실제 보고서 주소는 조직에서 관리 가능한 주소를 사용하고, 외부 도메인으로 보고서를 받을 때는 해당 수신 도메인의 승인 절차가 필요한지 확인하세요.

p=none은 인증 실패 메일을 바로 차단하지 않고 보고서를 수집하는 단계입니다. 일정 기간 동안 발송원별 수신량, SPF·DKIM 통과 여부, From 도메인 정렬 여부를 분류한 뒤 누락된 시스템을 보완합니다. 보고서에 낯선 IP가 보인다고 즉시 차단하지 말고 거래성 메일, 외부 대행사, 전달 경로인지 먼저 확인하세요.

정상 발송이 안정적으로 확인되면 일부 트래픽에 quarantine을 적용하거나 pct 값을 활용해 영향을 관찰할 수 있습니다. 이후 내부 수신자와 주요 고객의 테스트 결과까지 확인한 뒤 reject를 검토하세요. 정책 전환일과 되돌림 조건을 운영 문서에 함께 남겨야 합니다.

• _dmarc 하위 도메인에 TXT 레코드를 만들고 p=none으로 모니터링을 시작합니다.
• 보고서 수신 주소를 별도 분석용 메일함이나 DMARC 분석 도구로 지정합니다.
• adkim과 aspf의 정렬 모드, pct 적용 범위, 하위 도메인 정책을 문서화합니다.
• 정상 발송원이 모두 확인된 뒤 quarantine과 reject 전환 여부를 검토합니다.

5. 설정 완료 기준을 ‘등록’이 아니라 ‘검증’으로 정하세요

DNS가 전파됐다는 사실만으로 운영 준비가 끝난 것은 아닙니다. 실제 메일을 여러 수신 환경으로 보내고 원본 헤더를 확인해야 합니다. 특히 마케팅 메일과 비밀번호 재설정 같은 거래성 메일이 서로 다른 플랫폼에서 발송된다면 각각 별도로 검증하세요.

점검 결과는 다음 네 가지로 판정하면 실무에서 관리하기 쉽습니다. 첫째, SPF와 DKIM 중 DMARC에 필요한 인증 경로가 통과하는가. 둘째, 인증 도메인이 From 도메인과 정렬되는가. 셋째, 등록하지 않은 발송원이 보고서에 나타나는가. 넷째, 정책을 강화했을 때 정상 메일의 수신 실패를 되돌릴 방법이 있는가.

월별 또는 발송 플랫폼 변경 시점에 레코드를 재검토하세요. 신규 도구를 도입할 때는 먼저 테스트용 하위 도메인이나 제한된 발송 범위에서 인증 결과를 확인한 뒤 운영 도메인에 반영하는 방식이 안전합니다.

• 테스트 수신 계정을 Gmail, Microsoft 365, 기업 메일 등 주요 환경에 준비합니다.
• 메일 원본에서 spf, dkim, dmarc 결과와 도메인 정렬을 확인합니다.
• 정상 캠페인, 거래성 알림, 포워딩, 하위 도메인 발송을 각각 시험합니다.
• DNS 변경 시각, TTL, 레코드 값, 테스트 결과, 담당자를 변경 이력에 기록합니다.
• DMARC 보고서에서 새로운 발송원과 인증 실패 비율을 정기적으로 검토합니다.