B2B 이메일 인증을 운영에 정착시키는 DKIM·SPF·DMARC 설정 순서

세 인증 방식의 역할부터 분리하기

SPF는 특정 도메인에서 이메일을 보낼 수 있는 서버 또는 서비스의 범위를 DNS에 등록하는 방식입니다. 발신 서버의 IP나 포함된 서비스가 목록에 없으면 SPF 검증에 실패할 수 있습니다.

DKIM은 발신 시스템이 메시지에 전자서명을 추가하고 수신 서버가 공개키로 서명을 확인하는 방식입니다. 본문과 헤더의 일부가 전송 중 변경되지 않았는지 확인하는 데 활용됩니다.

DMARC는 SPF 또는 DKIM 검증 결과와 발신 도메인의 정렬 여부를 기준으로 정책을 적용하고, 수신 서버의 처리 결과를 보고받는 체계입니다. 따라서 DMARC는 SPF와 DKIM을 대체하지 않고 두 인증 결과를 운영 기준으로 묶습니다.

• SPF: 발신 서버의 허용 범위 관리
• DKIM: 메시지 서명과 변조 확인
• DMARC: 인증 결과, 도메인 정렬, 처리 정책, 보고서 관리
• 인증 통과와 실제 수신함 도착은 같은 개념이 아니므로 별도 지표로 확인

설정 전에 발신 경로와 도메인을 목록화하기

먼저 회사가 사용하는 모든 발신 경로를 정리합니다. 마케팅 자동화 도구, CRM, 영업 담당자의 메일 서비스, 고객지원 시스템, 거래명세서 발송 시스템, 웹사이트 문의 알림처럼 서로 다른 시스템이 같은 도메인을 사용할 수 있습니다.

각 시스템에 대해 발신 주소, 실제 발신 서버 또는 서비스, DKIM 지원 여부, 반송 주소, 관리 권한을 기록합니다. 이 목록을 만들지 않으면 SPF에 누락된 서비스가 생기거나, 테스트용 발신 시스템이 DMARC 실패를 일으킬 수 있습니다.

운영 도메인과 캠페인용 하위 도메인을 분리하는 것도 검토합니다. 예를 들어 회사 업무 메일과 대량 발송 시스템을 같은 도메인에 모두 의존하면 인증 오류가 발생했을 때 원인과 영향 범위를 구분하기 어렵습니다.

• 발신 시스템별 담당자와 DNS 변경 권한 확인
• 사용하지 않는 발신 서비스와 오래된 SPF include 후보 식별
• From 주소, Return-Path, DKIM 서명 도메인 기록
• 신규 도구 도입 시 인증 레코드와 정렬 조건을 계약·온보딩 체크리스트에 포함
• 테스트 발송과 실제 캠페인 발송의 도메인 차이 확인

SPF와 DKIM을 먼저 설정하고 검증하기

SPF는 도메인의 TXT 레코드로 설정합니다. 기존 SPF 레코드가 있다면 새 레코드를 추가하는 대신 하나의 정책 안에서 발신 서비스를 통합해야 합니다. SPF 레코드를 여러 개 만들면 수신 서버가 이를 무효로 처리할 수 있으므로 DNS 운영 담당자와 기존 값을 먼저 확인합니다.

SPF에는 서비스가 제공하는 공식 include 또는 고정 IP만 반영하고, 사용하지 않는 범용 허용값은 제거합니다. 변경 후에는 실제로 사용하는 모든 발신 경로에서 SPF 결과가 pass인지 확인해야 합니다.

DKIM은 발신 서비스에서 생성한 선택자(selector)와 공개키를 DNS에 등록한 뒤 해당 서비스가 메시지에 서명하도록 활성화합니다. 선택자는 서비스별로 구분할 수 있지만, 키 교체 일정과 담당자를 함께 기록해야 합니다.

테스트 메일의 원문 헤더에서 SPF 결과, DKIM 결과, 서명 도메인과 선택자를 확인합니다. DNS 조회 화면만 보고 완료 처리하지 말고 실제 수신 서버가 받은 메시지를 기준으로 검증합니다.

• 기존 SPF 레코드가 있는지 먼저 조회
• SPF에 발신 시스템을 누락하거나 불필요한 서비스까지 무조건 추가하지 않기
• DKIM 공개키의 오탈자와 TXT 값 분할 여부 확인
• DKIM 서명 도메인과 From 도메인의 관계 기록
• 주요 수신 환경별 테스트 메일에서 Authentication-Results 확인

DMARC는 모니터링에서 정책 적용으로 단계화하기

DMARC 레코드는 일반적으로 _dmarc 하위 도메인에 TXT로 등록합니다. 초기에는 실패 메일의 처리보다 현황 파악이 우선이므로 모니터링 정책으로 시작하고, 보고서를 받을 주소와 담당자를 정합니다.

보고서에서 발신 소스, SPF·DKIM 통과 여부, From 도메인과 인증 도메인의 정렬 여부를 확인합니다. 정상 발송 서비스가 누락되어 있거나 제3자 발송 도구의 서명 도메인이 정렬되지 않은 상태에서 차단 정책을 적용하면 정상 메일에도 영향을 줄 수 있습니다.

오류 원인을 정리한 뒤 정책 강도를 단계적으로 높입니다. 조직의 발신 경로와 수신 환경에 따라 순서는 달라질 수 있으므로, 기간을 정해 보고서를 검토하고 예외를 문서화한 후 다음 단계로 넘어갑니다.

DMARC의 정렬 모드는 SPF와 DKIM 각각에 대해 설정할 수 있습니다. 현재 시스템이 어떤 인증 방식을 안정적으로 통과시키는지 확인한 뒤 엄격한 설정을 바로 적용하지 말고 변경 영향부터 검증합니다.

• 처음에는 rua 등 집계 보고서 수신 경로와 접근 권한 확인
• 보고서에 나타난 정상 발신 소스를 내부 발신 시스템 목록과 대조
• 실패율만 보지 말고 실패한 소스, 수신량, 정렬 상태를 함께 검토
• 정책 변경 전 거래명세서·비밀번호 재설정 등 중요 메일을 별도 테스트
• 정책 적용 단계와 변경일, 담당자, 확인 결과를 변경 이력에 기록

DNS 설정과 메시지 인증을 검증하는 체크리스트

설정 직후에는 DNS 전파만 기다리는 것으로 끝내지 말고, 실제 발송과 수신 결과를 반복해서 확인합니다. 여러 수신 사업자와 내부 테스트 계정에서 확인하면 특정 환경에만 나타나는 문제를 발견하기 쉽습니다.

검증 결과는 레코드 존재 여부와 메시지 결과를 나누어 기록합니다. 레코드가 보인다는 사실은 설정의 한 단계일 뿐이며, 실제 발송 메시지에 DKIM 서명이 붙었는지와 DMARC 정렬이 통과했는지가 최종 확인 대상입니다.

• SPF TXT 레코드가 하나인지, 실제 발신 서비스가 모두 포함됐는지 확인
• DKIM selector에 대한 공개키 조회와 실제 서명 존재 여부 확인
• From 도메인과 SPF 인증 도메인의 정렬 상태 확인
• From 도메인과 DKIM d= 도메인의 정렬 상태 확인
• DMARC 보고서가 의도한 수신 주소로 도착하는지 확인
• 정상 메일, 뉴스레터, 자동 알림, 반송 메일을 유형별로 테스트
• 테스트 결과에 발송 시각, 수신 사업자, 메시지 ID, 오류 원인 기록

운영 중 오류를 발견했을 때의 대응 순서

DMARC 보고서에서 새로운 발신 소스가 발견되면 먼저 해당 소스가 승인된 시스템인지 확인합니다. 승인된 시스템이면 SPF 허용 범위, DKIM 활성화, From 도메인 정렬 중 어느 단계에서 실패했는지 분리해 수정합니다.

승인되지 않은 소스라면 즉시 차단만 결정하기보다 계정 탈취, 외부 대행사 사용, 오래된 시스템의 잔존 여부를 확인합니다. 도메인 정책 변경은 보안 조치이면서 정상 메일의 전달에도 영향을 줄 수 있으므로 서비스 담당자와 수신 영향을 함께 검토합니다.

인증 설정은 발송 플랫폼을 추가하거나 발신 도메인을 바꿀 때 다시 검토해야 합니다. 월간 또는 캠페인 전 점검일을 정하고, 정책 변경과 예외 사항을 한 곳에서 관리하면 담당자 변경 뒤에도 운영 기준을 유지할 수 있습니다.

• 새로운 발신 소스를 승인·미승인으로 분류
• SPF 실패, DKIM 실패, 정렬 실패를 각각 원인 분석
• 외부 발송 대행사의 DKIM 서명 및 From 도메인 지원 조건 확인
• 키 교체와 폐기된 selector 처리 일정 관리
• DMARC 보고서 검토 담당자와 에스컬레이션 기준 지정
• 인증 통과율과 함께 반송, 스팸 분류, 중요 메일 수신 여부를 추적