B2B 이메일 DKIM·SPF·DMARC를 운영 환경에 맞게 설정하는 법

먼저 발송 도메인과 전송 경로를 목록화하기

인증 설정 전에 회사가 사용하는 모든 발송 경로를 정리합니다. 마케팅 자동화 도구, CRM, 거래명세서 발송 시스템, 고객지원 플랫폼, 임직원 메일 서버, 외부 대행사의 발송 도메인을 한 표에 기록해야 합니다.

각 시스템마다 From 주소, 실제 발송 서버 또는 서비스, Return-Path, DKIM 서명 도메인, 관리 담당자를 확인합니다. 이 단계가 빠지면 SPF에는 없는 서버가 메일을 보내거나, DKIM은 통과하지만 수신자가 보는 From 도메인과 서명 도메인이 달라지는 문제가 생길 수 있습니다.

• 발송 시스템별 From 도메인과 하위 도메인을 구분한다.
• 외부 서비스가 회사 도메인을 대신해 발송하는지 확인한다.
• 운영·개발·테스트 발송을 같은 도메인에서 처리하지 않는지 점검한다.
• DNS 변경 권한과 각 발송 서비스의 인증 설정 권한을 확인한다.

SPF는 발송 서버를 한 번에 하나의 정책으로 관리하기

SPF는 수신 서버가 특정 도메인을 대신해 메일을 보낼 수 있는 서버를 확인하는 방식입니다. 일반적으로 Envelope From 또는 Return-Path에 사용되는 도메인의 TXT 레코드에 설정하며, 사용 중인 발송 서비스가 안내한 include 또는 ip4 값을 반영합니다.

같은 호스트명에 SPF 레코드를 여러 개 만들면 해석이 불안정해질 수 있으므로 하나의 정책으로 합칩니다. 서비스가 늘어날 때마다 무조건 include를 추가하지 말고, 실제 사용 여부와 DNS 조회 증가를 함께 확인합니다. SPF의 DNS 조회 제한을 초과하면 인증이 실패할 수 있으므로 불필요한 중첩 include와 오래된 서비스를 정리해야 합니다.

• 동일한 도메인에 SPF TXT 레코드가 여러 개 없는지 확인한다.
• 현재 사용하지 않는 발송 서비스와 IP를 제거한다.
• 발송 서비스가 안내한 include·ip4·ip6 값을 임의로 바꾸지 않는다.
• SPF만 통과해도 From 주소의 도메인 정렬까지 보장되는 것은 아님을 구분한다.

DKIM은 selector별 공개키와 서명 도메인을 맞추기

DKIM은 발송 시스템이 메일에 서명하고, 수신 서버가 DNS의 공개키로 그 서명을 검증하는 방식입니다. 발송 서비스에서 selector와 공개키를 발급받은 뒤 selector._domainkey 하위 호스트에 TXT 또는 CNAME 레코드를 등록합니다.

가능하다면 발송 서비스가 지원하는 충분한 키 길이를 사용하고, 서비스별 selector를 분리합니다. 키를 교체할 때는 새 selector를 먼저 게시하고 검증한 뒤 기존 selector를 제거해야 이미 발송된 메일이나 지연된 메일의 검증 실패를 줄일 수 있습니다. DKIM의 d= 도메인이 수신자가 보는 From 도메인과 정렬되는지도 확인합니다.

• selector 철자, 언더스코어, 공개키 전체 문자열을 대조한다.
• TXT 값이 여러 문자열로 나뉘어도 DNS 제공업체의 입력 방식에 맞게 등록한다.
• 발송 서비스 화면에서 DKIM이 verified 또는 active 상태인지 확인한다.
• 키 교체 시 기존 selector를 즉시 삭제하지 않고 전환 기간을 둔다.

DMARC는 관찰 모드에서 정책 강화로 단계적으로 전환하기

DMARC는 수신자가 보는 From 도메인과 SPF 또는 DKIM의 인증·도메인 정렬 결과를 함께 판단하고, 실패한 메일을 어떻게 처리할지 지시합니다. 우선 _dmarc 도메인에 p=none 정책을 게시해 합법적인 발송 경로와 실패 원인을 관찰합니다.

집계 보고서를 받을 rua 주소를 별도로 준비하고, 보고서에 포함된 발송 IP·인증 결과·From 도메인을 실제 발송 목록과 대조합니다. 정상 경로가 확인된 뒤 필요에 따라 quarantine, reject로 강화합니다. 하위 도메인에 다른 정책을 적용하려면 sp 값을 검토하고, 조직의 운영 역량에 맞춰 pct를 사용합니다.

보고서 수신 주소에는 개인정보나 메일 본문이 포함될 수 있는지 서비스별 차이를 확인합니다. DMARC 정책을 강화하기 전에 거래성 메일, 지원 답변, 전달·포워딩 경로가 영향을 받지 않는지 별도로 점검해야 합니다.

• 처음에는 p=none으로 실패 원인을 수집한다.
• rua 보고서를 읽을 담당자와 검토 주기를 정한다.
• SPF 또는 DKIM 중 하나만 통과해도 From 도메인과 정렬되는지 확인한다.
• 오탐이 남아 있으면 정책을 강화하지 않고 원인을 먼저 수정한다.
• 정책 변경일, 영향 범위, 되돌림 기준을 운영 기록에 남긴다.

DNS와 실제 수신 헤더로 설정을 검증하기

DNS 등록 직후에는 TXT·CNAME 응답이 예상한 값인지 확인하고, 테스트 메일을 여러 수신 환경으로 보냅니다. DNS 전파 지연을 고려해 결과가 한 곳에서만 보인다고 즉시 성공 또는 실패로 단정하지 않습니다.

수신한 메일의 원본 헤더에서 Authentication-Results를 열어 spf, dkim, dmarc 결과와 header.from, smtp.mailfrom, d= 도메인을 함께 확인합니다. 발송 서비스의 자체 검증 화면만 보지 말고 실제 수신 서버가 평가한 결과를 기준으로 판단합니다.

실패가 발견되면 SPF 미등록 발송 서버, DKIM 서명 누락, selector 오탈자, From 도메인 불일치, 포워딩에 따른 SPF 실패를 각각 분리해 수정합니다. 설정 변경 후에는 같은 테스트를 반복하고, DMARC 집계 보고서에서 예상하지 못한 발송원이 계속 나타나는지도 추적합니다.

• dig 또는 nslookup으로 SPF, DKIM, DMARC 레코드를 조회한다.
• 테스트 메일의 Authentication-Results를 저장한다.
• 주요 수신 환경에서 From·Return-Path·DKIM d= 값을 비교한다.
• 정상 메일과 실패 메일의 헤더 차이를 기록한다.
• 인증 레코드와 발송 서비스 변경 이력을 함께 관리한다.