SPF 레코드 확인: SPF 레코드가 제대로 동작하나요?
메일이 스팸함으로 가거나 서비스에서 SPF가 올바르지 않다고 하나요? 아래에 도메인을 입력하세요. 이 검사 도구는 SPF 레코드를 가져와 모든 include를 따라가고, DNS 조회 횟수를 한도인 10회와 비교하며, 고쳐야 할 내용을 쉬운 말로 알려 줍니다.
수신 서버가 SPF 레코드를 사용하는 방법
메시지가 도착하면 수신 서버는 엔벨로프 발신자의 도메인을 보고 그 도메인의 SPF 레코드, 즉 v=spf1로 시작하는 TXT 레코드를 가져옵니다. 그런 다음 방금 접속한 서버의 IP 주소가 목록에 있는지 확인합니다. 결과는 pass, fail, softfail, neutral 중 하나이며, 수신 서버는 다른 신호와 함께 이를 고려해 메시지를 받은편지함에 둘지 스팸함에 둘지 결정합니다.
SPF는 메일 앱에서 사람들이 보는 From 주소가 아니라 엔벨로프 발신자를 검사합니다. 그 간극을 메우는 것이 DMARC의 역할입니다.
SPF 항목 한눈에 보기
| 항목 | 하는 일 |
|---|---|
| ip4:192.0.2.0/24 | IPv4 주소 또는 범위를 허용합니다 |
| ip6:2001:db8::/32 | IPv6 주소 또는 범위를 허용합니다 |
| a | 도메인 자체의 A 및 AAAA 레코드에 있는 주소를 허용합니다 |
| mx | 도메인의 메일 서버 주소를 허용합니다 |
| include:_spf.example.net | 해당 도메인의 SPF 레코드가 허용하는 것도 함께 허용합니다 |
| exists:name | 해당 이름을 DNS로 조회해 주소가 반환되면 허용합니다 |
| ptr | 사용 중단되었습니다. 역방향 DNS로 일치 여부를 판단하며 사용하면 안 됩니다 |
| all | 모든 것과 일치하므로 맨 끝에 두며 기본 결과를 정합니다 |
항목 앞의 한정자는 일치할 때의 결과를 정합니다. +는 pass(기본값), -는 fail, ~는 softfail, ?는 neutral입니다. 보통 ~all(목록에 없는 발신자를 의심스러운 메일로 표시)이나 -all(수신 서버에 거부를 요청)로 끝냅니다.
서비스를 하나 더 추가하면 SPF가 깨지는 이유
SPF는 레코드를 평가하는 동안 DNS 조회를 유발하는 항목을 최대 10개까지만 허용합니다. include, a, mx, ptr, exists가 해당하며 redirect 수정자도 포함됩니다. ip4, ip6, all은 포함되지 않습니다. include된 레코드 안의 조회도 같은 총합에 포함됩니다.
멀쩡하던 레코드가 이렇게 망가집니다. 뉴스레터 도구, 헬프데스크, CRM, 결제 시스템을 추가하고 각각 자체 include를 넣는데, 그중 일부 include 안에 또 다른 include가 들어 있습니다. 10회를 넘으면 SPF는 영구 오류를 반환합니다. 그러면 수신 서버가 모든 메시지를 도메인에 SPF가 전혀 없는 것처럼 처리할 수 있으며, 아무도 알려 주지 않습니다.
- 더 이상 사용하지 않는 서비스의 include를 제거하세요.
- 제공업체의 주소가 안정적이라면 include를 ip4 및 ip6 범위로 교체하세요.
- ptr은 절대 사용하지 마세요.
- 가능하면 발송 서비스마다 별도의 하위 도메인을 부여하세요. 이름마다 한도 10회가 따로 적용됩니다.
- include를 주소로 풀어 쓴다면 제공업체가 범위를 바꾸므로, 풀어 쓴 레코드는 정기적인 업데이트가 필요하다는 점을 기억하세요.
SPF 정책을 안전하게 설정하는 방법
- 이름마다 SPF 레코드를 정확히 하나만 게시하세요. 두 개이면 영구 오류입니다.
- 모든 정상 발신자가 목록에 있는지 확인하는 동안은 ~all로 시작하고, 확신이 서면 -all로 옮기세요.
- SPF는 상속되지 않는다는 점을 기억하세요. 메일을 보내는 하위 도메인에는 자체 레코드가 필요하고, 메일을 보내지 않는 하위 도메인은 v=spf1 -all을 게시할 수 있습니다.
- SPF를 DKIM, DMARC 정책과 함께 사용하세요. 각각이 서로의 약점을 보완합니다.