SPF, DKIM, DMARC를 네임서버에 직접 등록하는 실무 절차

이메일 인증 설정은 한 번만 등록하면 끝나는 작업처럼 보이지만, 실제로는 네임서버 레코드 형식 하나만 어긋나도 며칠씩 통과가 되지 않는 경우가 흔합니다. 특히 Office 365나 구글 워크스페이스처럼 발송 경로가 여러 갈래로 나뉜 환경에서는 SPF 항목 누락이 가장 흔한 실패 원인입니다. 이 글은 네임서버에 직접 TXT 레코드를 등록하는 IT 담당자 관점에서 순서와 함정을 정리합니다.

SPF, DKIM, DMARC가 각각 하는 역할

SPF(Sender Policy Framework)는 어떤 서버가 해당 도메인을 대신해 메일을 보낼 자격이 있는지 명시하는 레코드입니다. DKIM(DomainKeys Identified Mail)은 발송된 메일에 암호화 서명을 붙여 전송 중 위변조가 없었음을 증명합니다. DMARC(Domain-based Message Authentication)는 SPF와 DKIM 검증 결과를 바탕으로 실패한 메일을 어떻게 처리할지 정책을 정하고, 그 결과를 리포트로 받아볼 수 있게 합니다.

세 레코드는 독립적으로 존재하지만 DMARC가 통과하려면 SPF 또는 DKIM 중 최소 하나가 발신 도메인과 정렬(alignment)되어야 합니다. 그래서 하나만 등록하고 끝내는 것이 아니라 세 개를 한 세트로 설계해야 실제 인증 효과가 납니다.

네임서버에 TXT 레코드를 등록하는 절차

실제 등록은 도메인을 관리하는 네임서버(가비아, 후이즈, 카페24, 또는 자체 DNS 관리 콘솔 등)의 TXT 레코드 항목에서 이루어집니다. SPF는 호스트를 @ 또는 도메인 루트로 지정하고 발송에 사용하는 모든 서버와 서비스를 include 구문으로 나열합니다. DKIM은 발송 서비스에서 발급한 선택자(selector)와 공개키를 selector._domainkey 형태의 서브도메인에 등록합니다.

DMARC는 _dmarc 서브도메인에 정책과 리포트 수신 이메일을 지정하는 방식으로 등록합니다. 세 레코드 모두 등록 직후 바로 전파되지 않고 최대 24~48시간까지 걸릴 수 있으므로, 등록 후 즉시 실패했다고 판단하기 전에 전파 시간을 감안해야 합니다.

• SPF: v=spf1 include:발송서비스도메인 ~all 형태로 TXT 등록, 호스트는 도메인 루트
• DKIM: 발송 서비스가 제공하는 selector._domainkey 호스트에 공개키 TXT 등록
• DMARC: _dmarc 호스트에 v=DMARC1; p=none; rua=mailto:리포트수신주소 형태로 시작
• 레코드 등록 후 24~48시간 전파 대기 후 검증 도구로 재확인

Office 365(Microsoft 365) 연동 시 흔한 실수

Office 365 환경에서 가장 흔한 실수는 SPF 레코드를 도메인당 하나만 둘 수 있다는 점을 놓치고 별도의 TXT 레코드를 새로 추가하는 것입니다. 이미 다른 발송 서비스의 SPF가 등록되어 있는 상태에서 include:spf.protection.outlook.com을 별도 레코드로 추가하면 SPF가 두 개로 중복되어 오히려 인증이 실패합니다. 반드시 기존 SPF 한 줄 안에 필요한 include를 모두 병합해야 합니다.

DKIM은 Microsoft 365 관리 센터에서 두 개의 CNAME 레코드를 발급받아 등록하는 방식인데, 이 CNAME을 TXT로 잘못 등록하거나 값 앞뒤에 불필요한 공백이 들어가는 경우가 자주 발생합니다. 또한 관리 센터에서 DKIM 서명을 활성화하는 버튼을 누르는 마지막 단계를 잊어버려서 레코드는 맞게 들어갔는데도 서명이 실제로 적용되지 않는 경우도 있습니다.

DMARC 정책을 단계적으로 올리는 이유

DMARC를 처음부터 p=reject로 설정하면 SPF나 DKIM 정렬이 완벽하지 않은 발송 경로의 메일이 즉시 차단되어 업무 메일이 통째로 사라질 위험이 있습니다. 그래서 처음에는 p=none으로 시작해 리포트만 수집하면서 어떤 발송 경로가 정렬에 실패하는지 먼저 파악하는 것이 안전한 순서입니다.

리포트를 통해 모든 정상 발송 경로가 정렬되는 것을 확인한 뒤에 p=quarantine으로 올리고, 일정 기간 문제가 없으면 마지막으로 p=reject까지 단계적으로 강화합니다. 이 과정은 보통 몇 주에서 한두 달 정도 걸리는 것이 일반적입니다.

등록 후 검증하는 방법

레코드를 등록한 뒤에는 반드시 외부 조회 도구로 실제 값을 다시 확인해야 합니다. 온라인 SPF/DKIM/DMARC 체커나 명령줄에서 TXT 레코드를 직접 조회하는 방법 모두 가능하며, 특히 여러 담당자가 나눠서 DNS를 관리하는 조직에서는 등록자가 의도한 값과 실제 반영된 값이 다른 경우가 종종 있습니다.

테스트 메일을 실제로 발송해 헤더에 찍히는 spf=pass, dkim=pass, dmarc=pass 결과를 직접 확인하는 절차까지 거쳐야 등록이 완료되었다고 볼 수 있습니다. 콘솔에서 초록불이 떴다고 끝난 것이 아니라 실제 발송 헤더로 마지막 확인을 해야 합니다.

• 외부 체커 도구로 SPF/DKIM/DMARC 조회 결과를 확인한다
• 실제 발송 테스트 메일의 헤더에서 pass 여부를 확인한다
• DMARC 리포트 수신 메일함을 주기적으로 확인해 정렬 실패 경로를 찾는다
• DNSSEC을 사용하는 경우 서명 오류로 레코드 조회 자체가 실패하지 않는지 확인한다

LDM이 인증 설정을 지원하는 방식

LDM은 발송에 사용하는 도메인별로 SPF, DKIM, DMARC 상태를 지속적으로 모니터링하고, 정렬 실패나 레코드 누락이 감지되면 발송 전 단계에서 알려주는 구조를 갖추고 있습니다. 특정 담당자를 대상으로 한 소량 발송이라도 인증 기반이 흔들리면 도달률 전체가 흔들리기 때문에, 새 도메인을 발송에 투입하기 전 인증 상태 점검을 필수 단계로 두고 있습니다.

자주 묻는 질문