Sender Policy Framework 레코드 검증
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터SPF(Sender Policy Framework)는 어떤 호스트가 도메인을 대신해 이메일을 보낼 수 있는지를 수신 메일 서버에 알려 줍니다. SPF 레코드가 중복되거나, DNS 조회 횟수가 너무 많거나, 'all' 메커니즘이 누락되어 잘못 구성되면 정상적인 메일이 스팸으로 분류됩니다. IPeek는 도메인의 SPF 레코드를 찾아 모든 메커니즘을 분석하고, 전달성을 떨어뜨리는 문제를 짚어 줍니다.
SPF는 루트 도메인의 TXT 레코드로 게시되며 v=spf1로 시작합니다. 서버가 귀하의 도메인을 사칭한 메일을 수신하면 이 레코드를 조회해 발신 IP가 인증되었는지 확인합니다. v=spf1 include:_spf.google.com ip4:198.51.100.10 -all 같은 레코드는 "Google 호스트와 이 IP 하나는 허용하고 나머지는 모두 거부"한다는 의미입니다. 메커니즘은 왼쪽에서 오른쪽으로 평가되며, 가장 먼저 일치하는 항목이 적용됩니다. 마지막의 all 메커니즘은 명시적으로 나열되지 않은 호스트의 기본 처리 결과를 결정하는 포괄 규칙입니다.
all 메커니즘이 정책을 정합니다. -all은 하드페일(나열되지 않은 발신자 거부), ~all은 소프트페일(수신하되 의심스러운 것으로 표시), +all은 누구나 허용하므로 절대 사용해서는 안 됩니다. 또한 SPF는 DNS 조회를 일으키는 메커니즘(include, a, mx, ptr, exists, redirect)을 총 10회로 제한하며, 이를 초과하면 결과가 permerror가 되어 실패로 처리됩니다. 중첩된 include도 함께 계산되므로 여러 벤더를 추가하다 보면 조회 한도가 조용히 소진됩니다. IPeek는 모든 조회 횟수를 집계해 한도에 도달하기 전에 경고해 줍니다.
SPF만으로는 충분하지 않습니다. SPF는 사용자에게 보이는 From 주소가 아니라 봉투 발신자(return-path)를 인증하므로, 사칭 발신자가 SPF를 통과하면서도 브랜드를 위조할 수 있습니다. DMARC는 SPF 도메인과 From 도메인 간의 정렬(alignment)을 요구하고, SPF와 DKIM을 결합해 둘 중 하나로 메시지를 인증하도록 함으로써 이 빈틈을 메웁니다. SPF는 세 가지 보호 계층 중 하나로 다뤄야 합니다. SPF는 호스트를 인증하고, DKIM은 콘텐츠에 서명하며, DMARC는 이를 From 도메인에 묶어 정책을 강제합니다.
SPF는 평가당 DNS 조회를 일으키는 메커니즘을 최대 10회까지 허용합니다. include, a, mx, ptr, exists, redirect 메커니즘이 각각 조회 횟수를 소모하며, 중첩된 include도 같은 한도에 포함됩니다. 10회를 초과하면 permerror가 발생하고 수신 서버는 이를 인증 실패로 처리합니다. include를 평탄화하거나 통합해 한도 이내로 유지하세요.
차이는 강제 수준에 있습니다. -all은 하드페일로, 레코드에 나열되지 않은 호스트의 메일을 거부하라고 수신 서버에 지시합니다. ~all은 소프트페일로, 메일을 수신하되 의심스러운 것으로 취급하라고 지시합니다. 테스트 중에는 ~all을 사용하고, 모든 정상 발신자가 인증됨을 확인한 뒤 -all로 전환하세요. 누구나 허용하는 +all은 피해야 합니다.
SPF 레코드만으로는 받은편지함 도착이 보장되지 않습니다. 흔한 원인으로는 10회 조회 한도 초과(permerror), all 메커니즘 누락 또는 지나치게 허용적인 설정, 실제로 인증되지 않은 발신 호스트, 같은 도메인에 중복된 SPF 레코드 등이 있습니다. 또한 SPF는 사용자에게 보이는 From 주소를 보호하지 않으므로, 강력한 전달성을 위해서는 DKIM과 DMARC를 함께 사용해야 합니다.
아니요. 도메인은 정확히 하나의 SPF(v=spf1) TXT 레코드만 게시해야 합니다. SPF 레코드가 둘 이상이면 permerror가 발생하고, 수신 서버가 메일을 거부하거나 인증에 실패할 수 있습니다. 여러 발신자를 인증해야 한다면 두 번째 레코드를 추가하지 말고, 추가 include나 ip4/ip6 메커니즘을 사용해 하나의 레코드로 합치세요.
아니요. SPF는 사용자가 실제로 보는 From 헤더가 아니라 봉투 발신자(return-path 또는 MAIL FROM)를 인증합니다. 그래서 SPF만으로는 브랜드 사칭을 막을 수 없습니다. DMARC는 SPF 정렬을 추가해 SPF 도메인이 사용자에게 보이는 From 도메인과 일치하도록 요구하며, 이를 통해 프로토콜 수준의 검사와 사용자가 실제로 보는 내용 사이의 빈틈을 메웁니다.