SPF 레코드가 실제로 하는 일
SPF(Sender Policy Framework)는 도메인 루트에 두는 TXT 레코드로, 봉투 발신자에 해당 도메인을 사용해 메일을 보낼 수 있는 서버 목록을 담습니다. Gmail이나 Microsoft가 메시지를 받으면 이 레코드를 조회해 접속한 IP를 모든 메커니즘과 순서대로 비교하고, 첫 번째로 일치하는 지점에서 멈춥니다.
결과는 pass, fail, softfail, neutral 중 하나입니다. SPF 단독으로 메일을 차단하는 경우는 드물지만, DMARC가 통과하려면 SPF 또는 DKIM 중 하나가 통과하고 From 도메인과 정렬되어야 합니다. 콜드 이메일에서 SPF 레코드가 망가져 있으면 DMARC는 DKIM 하나에만 의존하게 되고, DKIM까지 잘못 설정되어 있다면 캠페인은 스팸함으로 떨어집니다.
v=spf1 include:_spf.google.com ~allDNS 조회 10회 한도와 레코드가 이를 넘기는 이유
RFC 7208은 중첩된 include를 모두 포함해 레코드 전체에서 DNS를 조회하는 항목 수를 10개로 제한합니다. 횟수에 포함되는 항목은 include, a, mx, ptr, exists, redirect이고, 포함되지 않는 항목은 ip4, ip6, all입니다. 한도를 넘으면 수신 서버는 permerror를 반환하며, 대부분 이를 하드 실패로 취급합니다.
함정은 include가 자신의 조회를 숨기고 있다는 점입니다. 대형 제공업체의 include 하나가 혼자서 네다섯 번을 소모하기도 합니다. CRM, 헬프데스크, 마케팅 플랫폼, 발송 도구 두 개를 덧붙인 에이전시는 자기도 모르는 사이 12~13회에 도달하는 일이 흔합니다.
- 이 도메인에서 더 이상 발송하지 않는 도구의 include는 제거하세요.
- 마케팅 메일이나 트랜잭션 메일은 별도의 서브도메인을 사용해 각 SPF 레코드를 작게 유지하세요.
- 직접 관리할 준비가 되어 있을 때만 제공업체 include를 해당 ip4 대역으로 대체하세요.
- v=spf1 레코드를 두 개 게시하지 마세요. 하나로 병합하세요.
콜드 이메일에서 ~all 과 -all 중 무엇을 고를까
마지막 all 항목은 목록에 없는 서버에 적용할 정책을 정합니다. -all 은 하드 실패, ~all 은 소프트 실패입니다. 둘 다 Gmail과 Microsoft에서 허용되며 DMARC가 제 역할을 하게 해 줍니다. 훨씬 중요한 것은 정당한 발신자가 모두 all 항목 앞에 나열되어 있어야 하고, +all 과 ?all 은 절대 쓰지 않아야 한다는 점입니다.
Google Workspace나 Microsoft 365를 통해 발송하는 아웃리치 도메인이라면, 아직 도구를 추가하는 중일 때는 ~all 이 안전한 기본값입니다. 발신자 목록이 안정되면 -all 로 옮기세요. InboxOne은 메일박스를 프로비저닝할 때 올바른 include가 들어간 SPF 레코드를 자동으로 게시하므로, 새 도메인은 깨끗한 상태에서 시작합니다.
이 검사기가 잡아내는 흔한 SPF 실수
대부분의 SPF 실패는 특별한 것이 아닙니다. 복사·붙여넣기 실수, 남아 있는 include, 제공업체를 바꾼 뒤 갱신하지 않은 레코드에서 비롯됩니다. 검사기는 이런 항목마다 구체적인 해결책과 함께 표시해 줍니다.
- v=spf1 레코드가 여러 개라서 즉시 permerror가 발생하는 경우.
- all 뒤에 놓여 조용히 무시되는 항목.
- 일부 수신 서버가 아예 건너뛰는, 폐기된 ptr 메커니즘.
- include가 SPF 레코드 없는 도메인을 가리키는 void 조회.
- 255자를 넘는 TXT 문자열이나 잘림 위험이 있는 전체 레코드.
- includes: 또는 ip4: 대신 ip4= 같은 오타로 생긴 알 수 없는 토큰.
