메일 인증 레코드(SPF, DKIM, DMARC)를 정리하는 순서
CloudPlare 편집 노트 · 최초 작성 2026-05-19 · 최종 검토 2026-06-08 · 7분 읽기
도메인을 옮기거나 DNS를 정리할 때 가장 늦게 발견되는 문제는 메일입니다. SPF, DKIM, DMARC는 웹 접속과 무관해 보이지만, 누락되면 정상적인 메일이 스팸으로 분류되거나 발신 자체가 막힙니다.
메일도 도메인 신뢰의 일부다
작은 사이트를 운영하면서 같은 도메인으로 메일도 함께 쓰는 경우가 많습니다. 웹 호스팅이나 DNS 제공자를 옮길 때 A, CNAME 레코드는 신경 써서 옮기지만, 메일 인증과 관련된 TXT 레코드는 화면에서 잘 보이지 않아 그대로 빠뜨리기 쉽습니다.
SPF, DKIM, DMARC는 메일이 실제로 도메인 소유자가 보낸 것인지 수신 서버가 판단하는 데 쓰는 레코드입니다. 이 값이 없거나 잘못되면 메일 자체는 발송되지만 수신함에 도착하지 못하고 스팸함으로 들어가거나 거부될 수 있습니다.
SPF는 발신을 허용한 목록이다
SPF(Sender Policy Framework)는 이 도메인 이름으로 메일을 보낼 수 있는 서버나 서비스를 TXT 레코드 하나에 나열하는 방식입니다. 흔한 실수는 새 메일 서비스를 추가할 때마다 SPF TXT 레코드를 새로 만들어, 같은 도메인에 SPF 레코드가 여러 개 존재하게 되는 경우입니다. 이렇게 되면 검증 자체가 무효로 처리될 수 있습니다.
올바른 방법은 기존 SPF 레코드 안에 include 구문으로 새 서비스를 추가하고, 더 이상 쓰지 않는 서비스의 include는 제거하는 것입니다. 레코드는 항상 도메인당 하나여야 하며, 변경할 때마다 현재 값을 먼저 복사해 두면 실수를 되돌리기 쉽습니다.
DKIM과 DMARC는 서명과 처리 정책이다
DKIM(DomainKeys Identified Mail)은 발신 메일에 암호화 서명을 추가하고, 수신 서버가 도메인에 등록된 공개키 TXT 레코드로 그 서명을 확인하는 방식입니다. 이메일 제공자가 안내하는 선택자(selector) 이름과 값을 정확히 등록해야 하며, 메일 제공자를 바꾸면 이전 선택자 레코드는 정리하고 새 값을 등록해야 합니다.
DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM 검증에 실패한 메일을 어떻게 처리할지 알려주는 정책입니다. 처음에는 p=none으로 설정해 결과를 모니터링만 하고, 정상적인 발신 흐름을 확인한 뒤 quarantine, reject로 단계적으로 강화하는 편이 안전합니다. 처음부터 reject로 시작하면 누락된 발신 경로의 메일이 한꺼번에 막힐 수 있습니다.
운영 체크리스트
- 현재 도메인의 SPF TXT 레코드가 하나만 존재한다.
- 실제로 사용 중인 모든 발신 서비스가 SPF include에 포함되어 있다.
- 더 이상 쓰지 않는 서비스의 SPF include를 제거했다.
- DKIM 선택자 레코드가 이메일 제공자 안내값과 일치한다.
- DMARC 레코드가 존재하고 현재 정책 단계(p값)를 알고 있다.
- DNS 변경 후 테스트 메일을 보내 인증 결과를 확인했다.
확인한 공식 자료
아래 자료를 바탕으로 운영 관점의 설명을 덧붙였습니다. 세부 동작은 서비스와 배포 환경에 따라 달라질 수 있습니다.