SPF 레코드가 하는 일
SPF(Sender Policy Framework)는 도메인에 두는 TXT 레코드로, 봉투 발신자 주소에 이 도메인을 사용해 메일을 보낼 수 있는 서버 목록을 담습니다. Gmail이나 Outlook이 메시지를 받으면 이 레코드를 조회해 접속한 IP가 포함되어 있는지 확인합니다. 통과 결과는 DMARC로 이어지고, 실패하거나 레코드가 아예 없는 것은 콜드 이메일이 스팸함으로 가는 가장 흔한 이유 중 하나입니다.
레코드는 v=spf1 으로 시작하는 한 줄이며, 그 뒤에 메커니즘(ip4, ip6, include, a, mx)이 이어지고 all 에 붙은 한정자로 끝납니다. 순서가 중요합니다. 메커니즘은 왼쪽에서 오른쪽으로 평가되고 처음 일치한 항목이 이깁니다.
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -allDNS 조회 10회 한도
RFC 7208은 SPF의 DNS 조회를 10회로 제한합니다. 모든 include, a, mx, ptr, exists, redirect 가 횟수에 포함되며, include 는 그 레코드가 참조하는 것까지 함께 끌고 옵니다. Google Workspace만으로도 여러 단계의 중첩 조회로 확장되므로, Workspace에 SaaS 도구 세 개를 더한 도메인은 아무도 눈치채지 못한 채 한도에 닿을 수 있습니다. 10회를 넘기면 수신 서버는 permerror 를 반환하고, SPF는 사실상 어디에서나 실패합니다.
- 아직 메일을 보내는 서비스만 나열하세요. 옛 ESP와 체험용 도구가 대표적인 원인입니다.
- 제공업체가 안정적인 IP를 공개한다면 include 보다 ip4 대역을 쓰세요. ip4 는 조회를 소모하지 않습니다.
- 마케팅 및 트랜잭션 발신자는 대개 전용 서브도메인을 지원하므로, 루트 레코드를 작게 유지할 수 있습니다.
- 게시한 뒤에는 SPF 검사기로 완전히 펼친 실제 조회 횟수를 확인하세요.
-all, ~all, ?all 중 무엇을 쓸까
마지막 all 메커니즘은 나열하지 않은 발신자를 수신 서버가 어떻게 처리할지 알려줍니다. -all(하드 실패)은 거부하라는 뜻이고, ~all(소프트 실패)은 받아들이되 의심스럽게 취급하라는 뜻이며, ?all(중립)은 아무것도 말하지 않아 레코드를 거의 무의미하게 만듭니다. 모든 발신자를 직접 통제하는 콜드 이메일 도메인이라면 -all 이 정답이며, DMARC에 명확한 SPF 결과를 제공합니다.
물려받은 도메인이라 무엇이 발송하는지 확신이 없을 때만 ~all 로 시작하세요. 몇 주 동안 DMARC 집계 리포트를 지켜보며 정당한 소스를 추가한 뒤 -all 로 전환하세요.
레코드를 올바르게 게시하기
도메인 루트에 TXT 레코드를 하나 만드세요(DNS 제공업체에 따라 호스트는 @ 또는 빈 값). 이미 v=spf1 레코드가 있다면 새로 추가하지 말고 그 레코드를 수정하세요. SPF 레코드가 두 개면 영구 오류가 발생합니다. 255자를 넘는 레코드는 따옴표로 묶은 여러 문자열로 나눠야 하는데, 대부분의 DNS 관리 화면이 알아서 처리해 줍니다.
발신용 서브도메인은 자체 SPF 레코드가 필요합니다. 상위 도메인의 레코드를 물려받지 않습니다. 전파는 보통 빠르지만 기존 레코드의 TTL 만큼 걸릴 수 있습니다. InboxOne을 통해 발송 도메인을 구매하면 프로비저닝 시점에 DKIM, DMARC와 함께 SPF가 자동으로 게시됩니다.
