SPF 레코드 검사 도구

SPF 게시 후 확인할 사항

SPF 실수는 보통 팀이 새 발송 서비스를 추가하고 DNS 업데이트를 잊었을 때, 또는 두 업체가 각자 SPF 레코드를 요구해서 둘 다 게시했을 때 생겨요. 메일박스 제공업체는 도메인당 SPF 레코드 하나를 기대해요. 레코드 두 개가 모두 v=spf1로 시작하면, 각 레코드가 그럴듯해 보여도 SPF가 실패할 수 있어요.

도메인을 입력한 뒤 원본 레코드와 메커니즘을 점검하세요. include: 메커니즘은 보통 외부 발송 플랫폼을 가리켜요. ip4: 와 ip6: 는 고정된 발송 인프라를 허용해요. mx 는 도메인의 메일 교환 서버를 허용해요. 마지막 정책은 보통 -all 또는 ~all이며, 목록에 없는 시스템에서 온 메일을 얼마나 엄격하게 다룰지 수신 측에 알려줘요.

검사 결과 SPF 레코드가 없다면 도메인이 발송 준비가 됐다고 가정하지 마세요. SPF 레코드 생성기로 레코드를 만들어 TXT 레코드로 게시하고, DNS 전파 후 다시 테스트하세요. 레코드는 있는데 정상적인 플랫폼이 빠져 있다면, 캠페인을 시작하기 전에 그 발송 서비스를 추가하세요.

발신자를 바꿀 때마다 SPF를 점검하세요

새 이메일 서비스를 추가하면 인증 구성이 바뀔 수 있어요. 뉴스레터 플랫폼, CRM, 헬프데스크, 이커머스 알림 앱, 세일즈 시퀀서가 여러분의 도메인으로 메일을 보낼 수 있어요. 이럴 때는 SPF와 더불어 DKIM 와 DMARC도 점검해야 해요. 그래야 받은편지함 제공업체 전반에서 발신자 정체성이 일관되게 유지돼요.

SPF가 주소 리스트가 깨끗하다는 걸 증명하지는 않아요. 런칭을 준비한다면 수신자도 검증하세요. 도메인 단위 점검에는 이메일 상태 점검 을, 대용량 CSV 리스트에는 대량 검증 워크플로 를 사용하세요. 인증은 메일이 신뢰받도록 돕고, 리스트 관리는 반송과 부정적인 참여 신호를 통제하도록 도와줘요.

캠페인 전 SPF 운영 체크리스트

대규모 리스트로 발송하기 전에 발신 도메인과 전용 서브도메인을 확인하세요. SPF 레코드가 하나인지, 사용 중인 모든 발송 서비스가 포함되어 있는지, 쓰지 않는 업체는 제거되었는지 확인하세요. CRM이나 마케팅 플랫폼이 브랜드 서브도메인으로 발송한다면, 루트 도메인이 커버한다고 가정하지 말고 해당 서브도메인을 따로 확인하세요.

다음으로 SPF 레코드를 실제 캠페인 발송 경로와 비교하세요. 캠페인이 세일즈 인게이지먼트 플랫폼을 거친다면 그 플랫폼이 허용되어 있어야 해요. 제품 알림이 트랜잭션 메일 제공업체를 거친다면 그 제공업체도 허용되어 있어야 해요. 이 목록을 최신으로 유지하면 팀이 도구를 바꿀 때 막판에 도달률 문제로 당황할 일이 없어요.

마지막으로 수신자 리스트를 확인하세요. SPF는 메일박스에 발신자가 허가받았다고 알려줄 뿐, 내보낸 파일에서 유효하지 않은 주소를 제거해주지는 않아요. CRM, 뉴스레터, 잠재고객 리스트라면 발송 전에 파일을 검증하고 캠페인 후 반송 결과를 다시 확인하세요. 반송률 3% 미만은 건강하고, 3-5%는 정리가 필요하며, 5% 초과는 위험도가 높아요.

도메인을 여러 팀이 함께 쓴다면 이 체크리스트를 발신자 온보딩 과정에 포함하세요. 영업, 마케팅, 지원, 제품 팀이 모두 같은 브랜드 도메인을 쓰면, 누락된 발송 서비스 하나가 모두에게 영향을 줄 수 있어요. 캠페인을 이미 보낸 뒤 인증 실패를 진단하는 것보다 런칭 전 짧은 SPF 점검이 훨씬 저렴해요.