SPF·DKIM·DMARC, 순서대로 설정해서 발신 도메인 인증 끝내기

발신 도메인에 SPF, DKIM, DMARC가 제대로 설정되어 있지 않으면 아무리 잘 쓴 콜드메일도 스팸함으로 직행하거나 아예 반송됩니다. 세 레코드는 개념은 비슷해 보여도 등록 위치와 문법이 서로 다르고, 순서를 잘못 잡으면 발신 자체가 막히는 경우도 있습니다. 이 글에서는 실제 DNS 등록 순서와 각 단계에서 흔히 발생하는 오류를 정리합니다.

SPF·DKIM·DMARC가 각각 하는 일

SPF(Sender Policy Framework)는 이 도메인을 대신해 메일을 보낼 수 있는 서버 목록을 DNS에 명시하는 레코드입니다. 수신 서버는 메일이 도착하면 발신 IP가 SPF에 등록된 목록에 있는지 대조하고, 없으면 위조 가능성이 있다고 판단합니다.

DKIM(DomainKeys Identified Mail)은 메일 본문과 헤더 일부에 암호화 서명을 붙여, 전송 중 내용이 변조되지 않았고 실제로 해당 도메인에서 발송됐음을 증명하는 방식입니다. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM 검증 결과를 종합해 실패한 메일을 어떻게 처리할지 정책으로 지정하고, 그 결과를 리포트로 받아볼 수 있게 해줍니다.

세 레코드는 독립적으로도 동작하지만, DMARC가 제 역할을 하려면 SPF와 DKIM이 먼저 설정되어 있어야 합니다. 그래서 설정 순서는 SPF, DKIM, DMARC 순으로 진행하는 것이 원칙입니다.

1단계: SPF 레코드 등록

도메인을 관리하는 DNS(가비아, 카페24, Route 53, Cloudflare 등)에 접속해 TXT 레코드를 하나 추가합니다. 이미 SPF 레코드가 있다면 새로 만들지 말고 기존 레코드에 발신 서버를 추가해야 합니다. 도메인 하나에 SPF 레코드는 하나만 존재해야 하며, 여러 개를 등록하면 검증 자체가 실패합니다.

메일을 실제로 발송하는 모든 경로를 빠짐없이 포함하는 것이 핵심입니다. 사내 메일 서버, ESP나 발송 대행 플랫폼, CRM에 연동된 릴레이 서버까지 전부 SPF에 반영되어야 합니다. B2B 콜드메일은 여러 발신 계정과 워밍업 서버를 병행하는 경우가 많아, 이 목록을 누락하면 정상 발송임에도 인증에 실패하는 상황이 자주 생깁니다.

• TXT 레코드 이름은 도메인 루트(@) 또는 발신에 쓰는 서브도메인
• 값 예시: v=spf1 include:도메인.com ~all
• include 구문으로 외부 발송 서비스를 추가
• SPF는 DNS 조회(lookup) 10회 제한이 있어 include를 무분별하게 쌓으면 초과 오류가 남
• ~all(soft fail)로 시작해 안정화 후 -all(hard fail)로 전환 고려

2단계: DKIM 서명 키 등록

DKIM은 발신에 사용하는 메일 서비스(구글 워크스페이스, 아웃룩, CRM의 발송 모듈 등)에서 공개키를 발급받아 DNS에 등록하는 방식으로 진행합니다. 서비스마다 발급 화면에서 셀렉터(selector)와 공개키 문자열을 제공하며, 이를 그대로 TXT 레코드로 옮기면 됩니다.

셀렉터는 도메인당 여러 개를 운영할 수 있어, 발신 계정이나 플랫폼별로 서로 다른 셀렉터를 쓰는 것이 일반적입니다. 등록 후에는 발신 서비스 쪽에서 DKIM 서명 기능을 켜야 실제로 서명이 붙습니다. DNS 등록만 하고 서비스 쪽 설정을 빠뜨리는 실수가 잦습니다.

• 셀렉터._domainkey.도메인.com 형태로 TXT 레코드 등록
• 발신 서비스 관리 화면에서 DKIM 서명 기능 활성화 확인
• 여러 발신 서비스를 쓰면 서비스별로 별도 셀렉터 사용
• 키를 교체(로테이션)할 때는 이전 셀렉터를 바로 삭제하지 말고 병행 기간을 둘 것

3단계: DMARC 정책 등록

SPF와 DKIM이 정상 동작하는 것을 확인한 뒤 DMARC 레코드를 등록합니다. 위치는 _dmarc.도메인.com이며, 정책 값(p=)으로 none, quarantine, reject 중 하나를 지정합니다. 처음 등록할 때는 반드시 p=none으로 시작해야 합니다.

p=none은 아무것도 차단하지 않고 리포트만 수집하는 모드입니다. 이 기간 동안 rua 태그로 지정한 이메일 주소로 집계 리포트가 오는데, 이를 통해 정상 발신 경로를 놓치지 않았는지, 혹은 실제로 도메인을 사칭한 시도가 있는지 확인할 수 있습니다. 이 단계를 건너뛰고 바로 reject로 걸면 미처 SPF에 등록하지 못한 정상 발신 경로까지 전부 막혀버릴 위험이 있습니다.

• 1차: p=none으로 등록하고 2~4주간 리포트 수집
• 2차: 정상 발신원이 모두 확인되면 p=quarantine으로 전환
• 3차: 안정적으로 통과율이 유지되면 p=reject로 강화
• rua 태그로 리포트 수신 주소 지정 필수

설정 후 확인 방법과 도달률 변화

설정을 마쳤다면 실제 테스트 발송으로 헤더에 SPF=pass, DKIM=pass가 찍히는지 확인해야 합니다. 대부분의 웹메일은 원본 메시지 보기에서 인증 결과를 확인할 수 있고, 무료 온라인 체커로도 확인할 수 있습니다.

세 레코드를 모두 갖춘 도메인과 그렇지 않은 도메인은 받은편지함 도달률에서 체감할 수 있는 차이를 보입니다. 특히 처음 사용하는 발신 도메인이나 워밍업 초기 단계에서는 인증 여부가 스팸 판정에 미치는 영향이 더 크게 나타나는 경향이 있습니다.

설정 중 자주 하는 실수

실무에서 인증 설정 오류의 상당수는 레코드 문법보다 관리 실수에서 비롯됩니다. 아래 항목만 피해도 흔한 문제의 대부분을 예방할 수 있습니다.

• 도메인 하나에 SPF 레코드를 두 개 이상 등록
• SPF에 실제 발신 서비스를 빠뜨려 정상 메일도 인증 실패
• DKIM은 DNS에만 등록하고 발신 서비스에서 서명 기능을 켜지 않음
• DMARC를 곧바로 p=reject로 설정해 정상 메일까지 차단
• 서브도메인 발신을 쓰면서 루트 도메인 SPF만 설정하고 서브도메인은 방치

LDM이 인증 설정을 다루는 방식

LDM은 콜드메일을 발송하는 각 발신 도메인에 대해 SPF, DKIM, DMARC 설정 상태를 발송 전에 점검하고, 인증이 불완전한 도메인은 본 발송 전 워밍업 단계에서 먼저 안정화합니다. 특정 담당자에게 보내는 타겟형 발송이라도 인증되지 않은 도메인에서 나가면 스팸 판정 위험은 동일하게 존재하기 때문에, 발송량과 무관하게 인증 설정을 발송의 전제 조건으로 다루고 있습니다.

자주 묻는 질문