SPF 레코드 확인하고 만들기
SPF는 조용히 고장 납니다. 1년 동안 잘 쓰다가 누군가 서비스를 하나 더 추가하면 레코드가 DNS 조회 10회 한도를 넘기고, 그 순간부터 모든 수신 서버가 이것을 고장 난 것으로 취급합니다. 어디에도 오류 메시지는 뜨지 않습니다. 이 도구는 그 조회 횟수를 보여줍니다.
- 우리 서버가 아니라 당신의 브라우저에서 실행됩니다
- 가입 없음
- 워터마크 없음
도구를 불러오는 중…
작동 방식
- 도메인을 입력하세요. 특정 서버의 발송 허가 여부가 궁금하다면 IP도 추가하세요.
- 결과와 조회 횟수, 진단 내용을 확인하세요. 트리를 펼치면 포함된 각 레코드에 실제로 무엇이 들어 있는지 볼 수 있습니다.
- 아래 생성기로 실제로 쓰는 서비스만 모아 올바른 레코드를 만드세요.
왜 아무것도 업로드되지 않는가
이 페이지가 하는 모든 작업은 브라우저 탭 안에서 도는 코드가 처리합니다. 웹 페이지를 그리는 그 엔진을 그대로 씁니다. 파일은 디스크에서 탭의 메모리로 읽어 들여 거기서 변환한 뒤 다시 다운로드 파일로 내보냅니다. 어디로도 전송되지 않습니다. 우리에게도, 제3자에게도.
직접 확인해 보세요
- 브라우저 개발자 도구(F12)를 열고 네트워크(Network) 탭을 선택합니다.
- 파일을 올리고 도구를 실행합니다.
- 보이는 요청은 도구 자체의 코드를 받아 오는 것뿐입니다. 무거운 몇몇 도구는 공개 CDN에서 오픈소스 엔진을 함께 받아 옵니다. 여기에 loreatec.jp로 가는 작은 방문 집계 신호 하나(페이지 주소와 제목, 그 이상은 없습니다)가 더해집니다. 어느 것도 당신의 파일을 실어 나르지 않습니다.
자주 묻는 질문
10회 조회 한도란 정확히 무엇인가요?
include, a, mx, ptr, exists, redirect 각 항목이 DNS 조회 1회로 계산되며, 포함시킨 레코드 안에 들어 있는 항목들도 마찬가지로 계산됩니다. 표준(RFC 7208)은 전체 합계를 10회로 제한합니다. 한도에 도달한 수신 서버는 검사를 멈추고 오류를 반환하는데, 대부분은 이것을 SPF가 아예 없는 것과 똑같이 취급합니다. include 하나가 조회 3~4회를 숨기고 있는 서비스가 흔한 원인입니다. 해결책은 더 이상 쓰지 않는 서비스를 빼거나, include를 순수 IP 주소로 바꾸는 것입니다. 다만 IP 목록은 시간이 지나면 낡아지므로 신중해야 합니다.
+all은 왜 그렇게 나쁜가요?
인터넷의 모든 서버에게 당신의 도메인 이름으로 메일을 보낼 권한을 주는 것이기 때문입니다. 아예 레코드가 없는 것보다도 나쁩니다. 레코드가 없으면 수신 서버가 다른 신호에 의존하기라도 하지만, +all은 스패머를 명시적으로 보증해 준 셈입니다. 보통 누군가 예시를 복사하다가 엉뚱한 글자를 고치면서 생깁니다.
레코드는 -all로 끝나야 하나요, ~all로 끝나야 하나요?
-all은 “그 외에는 모두 거부”, ~all은 “그 외에는 모두 의심스럽게 취급”이라는 뜻입니다. 무엇이 당신을 대신해 메일을 보내는지 아직 파악하는 중이라면 ~all로 시작한 다음 -all로 넘어가세요. 이 차이는 DMARC가 설정된 뒤에야 의미가 생깁니다. DMARC는 검사에 실패한 메일을 어떻게 처리할지 수신 서버에 알려주는 규칙인데, DMARC 정책이 reject라면 SPF가 ~all이어도 결국 거부됩니다. 조심스럽다는 이유로 ~all에 영원히 머물지 마세요. 그것은 경유지이지 목적지가 아닙니다.
SPF 레코드를 두 개 가질 수 있나요?
안 됩니다. 같은 이름에 v=spf1 레코드가 두 개 있으면 영구적인 오류가 되어 수신 서버가 검사 자체를 멈춰 버립니다. 어떤 서비스가 “이 레코드를 추가하라”고 안내할 때, 기존 레코드에 병합하지 않고 TXT 레코드를 하나 더 추가하면 이런 일이 생깁니다.
이 도구는 무엇을 누구에게 보내나요?
조회할 도메인 이름이 당신이 선택한 공개 DNS 서비스로, 브라우저에서 직접 전송됩니다. 이 사이트의 서버는 관여하지 않으며 아무 기록도 남기지 않습니다.