B2B 이메일 DKIM·SPF·DMARC 설정과 검증을 위한 실무 가이드

세 인증 기술의 역할부터 구분하기

SPF는 해당 도메인에서 메일을 보낼 수 있는 발송 서버를 DNS에 등록하는 방식입니다. 수신 서버는 메일의 발송 IP가 SPF 정책에 포함되어 있는지 확인합니다. 다만 SPF만으로는 전달 과정에서 주소가 변조되지 않았는지, 실제 발신 도메인과 연결되는지를 충분히 판단하기 어렵습니다.

DKIM은 발송 시스템이 메일 본문과 주요 헤더에 디지털 서명을 붙이고, 수신 서버가 공개키로 이를 검증하는 방식입니다. DKIM은 메일 내용을 암호화하는 기술이 아니며, 서명 대상이 전송 과정에서 변경되었는지 확인하는 데 초점이 있습니다.

DMARC는 SPF 또는 DKIM 검증 결과와 수신자에게 보이는 발신 도메인의 정렬 상태를 확인하고, 실패한 메일을 어떻게 처리할지 정책으로 선언합니다. 또한 집계 보고서를 통해 어떤 서버가 도메인을 사용해 메일을 보내는지 파악할 수 있습니다.

• SPF: 승인된 발송 서버를 선언하는 레코드
• DKIM: 발송 도메인과 메일 무결성을 검증하는 서명
• DMARC: 인증 결과, 도메인 정렬, 실패 처리 정책을 관리하는 레코드
• 세 기술은 서로 대체 관계가 아니라 함께 운영하는 인증 체계

설정 전에 발송 경로와 도메인 구조 정리하기

먼저 회사가 사용하는 모든 발송 경로를 목록화합니다. 사내 메일 서버, CRM, 마케팅 자동화 도구, 고객지원 시스템, 청구서 발송 서비스처럼 서로 다른 시스템이 같은 발신 도메인을 사용할 수 있습니다. 목록에 빠진 서비스가 있으면 SPF가 실패하거나 DMARC 보고서에 예상하지 못한 발송원이 나타날 수 있습니다.

발신 주소의 도메인과 실제 발송 서비스가 서명하는 도메인을 확인합니다. 예를 들어 From 주소는 mail.example.com인데 DKIM 서명은 vendor-service.com으로 남을 수 있습니다. 이 경우 DMARC 정렬을 맞추려면 사용자 지정 DKIM 도메인이나 사용자 지정 반환 경로 설정을 지원하는지 발송 서비스에 확인해야 합니다.

• 사용 중인 발송 서비스와 용도별 발신 주소를 표로 정리하기
• 각 서비스가 제공하는 SPF include 값과 DKIM selector 확인하기
• From 도메인, Return-Path 도메인, DKIM d= 도메인의 관계 확인하기
• DNS를 관리하는 계정과 변경 승인 담당자를 사전에 지정하기
• 기존 SPF 레코드가 있는지 먼저 조회하고 새 레코드를 무작정 추가하지 않기

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

SPF는 발송 서비스가 안내한 include 또는 IP 정보를 기준으로 하나의 TXT 레코드로 구성합니다. 같은 도메인에 SPF 레코드를 여러 개 만들면 수신 서버가 정책을 무효로 해석할 수 있으므로, 기존 정책이 있다면 내용을 통합해야 합니다. 사용하지 않는 발송 서비스의 항목은 정기적으로 제거하는 편이 안전합니다.

SPF의 마지막 메커니즘은 운영 의도에 맞춰 선택합니다. 설정 초기에는 변경 영향을 확인할 수 있도록 신중하게 적용하고, 모든 정상 발송원이 확인된 뒤 엄격한 정책으로 전환합니다. SPF 조회가 지나치게 복잡해지지 않도록 불필요한 중첩 include와 오래된 서비스를 정리해야 합니다.

DKIM은 발송 서비스에서 생성한 selector와 공개키를 DNS에 TXT 레코드로 등록하는 방식이 일반적입니다. 개인키는 발송 서비스가 보관하므로 DNS에 입력하지 않습니다. selector를 서비스별로 구분하면 키 교체와 장애 원인 추적이 수월합니다.

• 도메인에 SPF TXT 레코드가 하나만 존재하는지 확인하기
• 발송 서비스가 요구한 include 값과 IP를 공식 문서에서 다시 대조하기
• DKIM selector와 공개키의 철자, 따옴표 처리, 줄바꿈 여부 확인하기
• 테스트 메일의 헤더에서 SPF와 DKIM 결과가 pass인지 확인하기
• 발송 서비스 변경 시 기존 DKIM 키와 SPF 항목의 폐기 일정을 기록하기

DMARC를 관찰 모드에서 정책 적용으로 전환하기

DMARC 레코드는 일반적으로 _dmarc 하위 도메인에 TXT로 등록합니다. 초기에는 p=none으로 보고서를 수집해 정상 발송과 미승인 발송을 구분합니다. rua에는 집계 보고서를 받을 주소를 지정할 수 있지만, 보고서에는 발송 메타데이터가 포함될 수 있으므로 전용 수신함과 접근 권한을 별도로 관리하는 것이 좋습니다.

보고서에서 정상 발송원의 SPF 또는 DKIM 통과 여부와 도메인 정렬 상태를 확인한 뒤 정책을 강화합니다. p=quarantine은 실패 메일을 의심 메일로 취급하도록 요청하는 단계이고, p=reject는 실패 메일을 거부하도록 요청하는 단계입니다. 정상 발송이 확인되지 않은 상태에서 reject를 적용하면 거래성 메일이나 내부 알림이 차단될 수 있습니다.

DMARC의 adkim과 aspf는 DKIM 및 SPF 정렬의 엄격도를 조정합니다. 조직의 서브도메인 운영 방식과 발송 서비스 지원 범위를 확인한 뒤 설정해야 하며, pct를 사용할 때도 일부 비율 적용이 실제 수신 서버에서 동일하게 처리된다고 가정해서는 안 됩니다.

• 처음에는 p=none으로 보고서를 수집하고 예상 발송원을 분류하기
• 보고서 수신 주소가 실제로 운영되고 개인정보 접근 권한이 제한되어 있는지 확인하기
• 정상 발송원의 SPF 또는 DKIM 통과와 From 도메인 정렬을 함께 확인하기
• quarantine 적용 후 거래성·마케팅·내부 알림 메일을 별도로 점검하기
• reject 전환 승인 기준과 롤백 절차를 문서화하기

검증 결과를 읽고 지속 운영하기

DNS 변경 후에는 전파 시간을 고려해 여러 조회 도구와 실제 테스트 메일로 확인합니다. 단순히 DNS에 레코드가 보이는 것만으로는 충분하지 않습니다. 수신 메일의 Authentication-Results 헤더에서 spf, dkim, dmarc 결과와 실패 사유를 함께 읽어야 합니다.

DMARC 보고서에서 갑자기 새로운 발송 IP가 나타나거나, 특정 서비스의 DKIM 정렬이 반복적으로 실패하면 발송 중단 여부와 도메인 사용 권한을 확인합니다. 인증 실패만으로 곧바로 공격이라고 단정하지 말고, 외부 대행사·포워딩·메일링 리스트의 특성도 함께 조사해야 합니다.

인증 레코드는 한 번 설정하고 끝나는 항목이 아닙니다. 신규 발송 도구 도입, 서브도메인 추가, 대행사 교체, 브랜드 도메인 변경 때마다 영향 범위를 검토하고 변경 전후 결과를 기록해야 합니다.

• 실제 수신 메일의 Authentication-Results 헤더 확인하기
• SPF pass 여부와 DMARC SPF 정렬 여부를 구분해서 보기
• DKIM pass 여부와 서명 도메인 정렬 여부를 함께 확인하기
• DMARC 보고서의 발송 IP·도메인·실패 사유를 정기적으로 검토하기
• DNS 변경 전 레코드 백업, 변경 담당자, 검증 결과를 운영 문서에 남기기