SPF, DKIM, DMARC 간단하게 이해하기 (그리고 5분 만에 직접 확인하는 방법)
SPF, DKIM, DMARC의 역할, Gmail, Yahoo, Outlook이 이제 요구하는 사항, DNS 레코드를 읽는 방법, 그리고 영업을 시작하기 전에 가장 흔한 오류를 해결하는 방법을 알아봅니다.
2026년 11월 10일 발행 · 3분 소요
이메일 도달률을 이야기할 때마다 세 가지 약어가 등장합니다: SPF, DKIM, DMARC. 대개 호스팅 업체의 도움말에서 찾은 줄을 복사해 한 번 설정한 뒤 잊고 지냅니다. 그러다 이메일이 스팸으로 분류되는 날, 도대체 무엇을 설정해 두었는지 아무도 제대로 알지 못하게 됩니다.
하지만 이 세 가지 메커니즘은 이메일을 받는 모든 서버가 던지는 단순한 질문에 답합니다. "이 메시지가 정말로 주장하는 발신자에게서 온 것인가?" 명확한 답이 없으면 그 메시지는 의심스러운 것으로 처리됩니다.
왜 이제 필수가 되었을까
오랫동안 이 레코드들은 강력히 권장되는 수준이었습니다. 이제는 필수입니다. 2024년 2월, Gmail과 Yahoo는 대량으로 이메일을 발송하는 발신자에게 유효한 SPF와 DKIM, 공개된 DMARC 정책, 원클릭 수신 거부 링크, 낮은 신고율을 요구하기 시작했습니다. Microsoft도 Outlook.com에 대해 이와 유사한 요구 사항을 발표했으며, 2025년 5월부터 적용됩니다.
공식 기준은 대량 발신자를 대상으로 하지만, 실제로는 인증이 제대로 되지 않은 도메인은 그런 물량에 이르기 훨씬 전부터 메시지가 필터링됩니다. 영업 활동을 한다면 이 세 가지 레코드를 최소한의 기본으로 여겨야 합니다.
SPF: 허용된 서버 목록
SPF(Sender Policy Framework)는 도메인의 DNS에 공개하는 한 줄의 레코드입니다. 이 레코드는 "이 도메인의 이메일은 지정된 서버에서만 발송될 수 있다"고 알려줍니다. 서버가 귀하의 도메인으로 서명된 메시지를 받으면, 발신 서버가 그 목록에 있는지 확인합니다.
SPF 레코드는 다음과 같습니다:
v=spf1 include:_spf.mail.hostinger.com ~all
왼쪽에서 오른쪽으로 읽어 보세요: 버전, 허용된 서버(여기서는 호스팅 업체의 서버), 그다음 나머지를 어떻게 처리할지가 나옵니다. 마지막의 "~all"은 나머지 서버를 거부하지는 않되 주의 깊게 처리하라는 의미로, 신중한 선택입니다.
가장 흔한 오류:
- 같은 도메인에 SPF 레코드가 두 개 있는 경우: 허용되지 않으며 결과가 무효가 됩니다. 두 개를 한 줄로 합쳐야 합니다.
- 서비스를 빠뜨린 경우: 타사 소프트웨어에서 청구서도 보내고 있는데 목록에 포함되지 않은 경우입니다.
- "include"가 너무 많은 경우: SPF는 DNS 조회 횟수를 10회로 제한합니다. 이를 넘으면 레코드가 실패합니다.
DKIM: 메시지 서명
DKIM(DomainKeys Identified Mail)은 모든 이메일에 암호화된 서명을 추가합니다. 발신 서버는 개인 키로 서명하고, 그에 대응하는 공개 키는 귀하의 DNS에 공개됩니다. 수신자는 서명을 검증합니다. 서명이 유효하면 메시지가 실제로 귀하의 도메인에서 왔고 전송 중에 변경되지 않았다는 것을 알 수 있습니다.
공개 키는 호스팅 업체가 선택한 "셀렉터"로 구성된 특정 DNS 주소에 있습니다. 예를 들면 다음과 같습니다:
hostingermail1._domainkey.votredomaine.fr
DKIM 문제의 대부분은 여기에서 비롯됩니다: 키를 불완전하게 복사했거나(키가 길기 때문에), 실제로 서버가 사용하는 셀렉터와 다른 셀렉터를 입력했거나, 호스팅 업체가 수동 활성화를 기다리고 있어 키가 공개되지 않은 경우입니다. 신뢰할 수 있는 유일한 확인 방법은 실제 이메일을 보내고 도착한 메시지의 헤더를 확인하는 것입니다.
DMARC: 실패 시 처리 지침
DMARC(Domain-based Message Authentication, Reporting and Conformance)는 앞의 두 가지를 연결합니다. 수신 서버에 "메시지가 내 도메인에서 왔다고 주장하지만 SPF와 DKIM에서 실패하면 이렇게 처리해야 한다"고 알려줍니다. 또한 귀하의 이름으로 발송된 메시지에 대한 보고서를 받을 수 있게 해 줍니다.
초기 DMARC 레코드는 다음과 같습니다:
v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr
"p=none"은 아무것도 차단하지 않고 보고서만 보내라는 뜻입니다. Gmail과 Yahoo가 요구하는 최소 정책이며 좋은 출발점입니다. 모든 정상 발송이 인증을 통과한다고 확신이 들면 "p=quarantine"(인증되지 않은 메시지를 스팸으로 분류)으로, 이후 필요하면 "p=reject"로 변경할 수 있습니다.
미묘한 점이 하나 있습니다: DMARC는 SPF나 DKIM으로 인증된 도메인이 발신 주소에 표시된 도메인과 같아야 한다고 요구합니다. 이를 "정렬(alignment)"이라고 합니다. paul@votredomaine.fr에서 보냈지만 호스팅 업체의 기술 도메인으로 DKIM 서명된 이메일은 DKIM은 통과해도 DMARC에서는 실패할 수 있습니다.
5분 만에 레코드 확인하기
시스템 관리자가 아니어도 됩니다. 세 가지만 확인하면 충분합니다:
- 온라인 DNS 조회 도구로 도메인의 TXT 레코드를 확인하세요. "v=spf1"로 시작하는 줄이 하나만 있어야 하고, _dmarc.votredomaine.fr 주소에 "v=DMARC1" 줄이 있어야 합니다.
- 해당 메일함에서 개인 Gmail 주소로 이메일을 보내고, 열어서 원본 메시지를 표시하세요. Gmail은 "SPF: PASS", "DKIM: PASS", "DMARC: PASS"와 함께 각 항목에 사용된 도메인을 명확히 표시합니다.
- DKIM에 표시된 도메인이 호스팅 업체의 도메인이 아니라 귀하의 도메인인지 확인하세요.
SmartOutbound에서는 이 확인이 자동으로 이루어집니다. 모든 도메인을 매일 검사하고, 메일함을 연결할 때 보내는 테스트 이메일로 실제 도착 시 확인된 DKIM 서명을 검증하며, 메일함 페이지의 "DNS 확인" 버튼으로 필요할 때 다시 검사를 실행할 수 있습니다. DMARC가 없고 도메인이 Hostinger에 있다면, 도구가 대신 추가해 주기까지 합니다.
그 외에는?
이 세 가지 레코드가 이메일의 받은편지함 도달을 보장하지는 않습니다. 피할 수 있는 기술적 이유로 거부되지 않는다는 것만 보장합니다. 나머지는 도메인 평판, 목록의 품질, 메시지 내용에 달려 있습니다. 새 도메인이라면 웜업 기간도 고려해야 합니다. 그리고 주 도메인에서 영업을 시작할지 망설여진다면 전용 도메인에 관한 글이 판단에 도움이 될 것입니다.
자주 묻는 질문
+SPF 레코드를 두 개 가질 수 있나요?
아니요. 도메인은 SPF 줄을 하나만 공개해야 합니다. 여러 발송 서비스를 사용한다면 모두 같은 레코드에 여러 개의 "include"로 추가하세요.
+처음에는 어떤 DMARC 정책을 선택해야 하나요?
보고서 주소와 함께 "p=none"을 사용하세요. Gmail과 Yahoo가 요구하는 최소 수준입니다. 모든 정상 발송이 제대로 인증되면 "p=quarantine"으로 전환하세요.
+DNS 변경 사항이 반영되기까지 얼마나 걸리나요?
보통 몇 분, 레코드의 캐시 유효 시간(TTL)에 따라 몇 시간이 걸릴 수 있습니다. 24시간이 지나도 아무 변화가 없다면 레코드를 잘못 입력했을 가능성이 큽니다.
+SPF, DKIM, DMARC만으로 스팸을 피할 수 있나요?
아니요. 필요하지만 충분하지는 않습니다. 도메인 평판, 발송량, 주소 품질, 이메일 내용도 그에 못지않게 중요한 역할을 합니다.