SPF 레코드 빌더

어떤 호스트가 내 도메인으로 메일을 보낼 수 있는지 수신 서버에 알려 주는 v=spf1 TXT 레코드를 만들어 줍니다. 직접 쓰는 발송 주소는 ip4나 ip6로 넣고, 외부 발송 업체는 include: 메커니즘으로 끌어오고, 레코드를 어떻게 끝낼지 고릅니다. 출력 옆에는 조회 횟수 카운터가 붙어 있고, 흔한 함정에 경고가 켜집니다. 255바이트를 넘긴 레코드, 아무것도 주장하지 않는 ?all, 그리고 누구든 내 이름으로 보내도 좋다고 세상에 알리는 +all입니다.

사람들이 걸려 넘어지는 제약은 조회 예산입니다. RFC 7208은 한 번의 평가에서 DNS 조회를 최대 열 번까지만 허용하고, include, a, mx, ptr, exists, redirect가 각각 한 번씩 씁니다. 여기에 그들 자신의 레코드가 재귀적으로 쓰는 횟수까지 더해집니다. ip4와 ip6는 비용이 0인데, 한도를 넘어 자란 레코드를 푸는 표준적인 방법이 업체의 include를 그 실제 IP 대역으로 바꾸는 것인 이유가 이것입니다. 열 번을 넘기면 결과는 부드러운 실패가 아닙니다. 평가가 permerror를 돌려주고, 이를 실패로 취급하는 수신 서버는 배달되었어야 할 메일을 거부합니다.

이 레코드가 생각대로 작동하는지를 가르는 세부가 둘 있습니다. SPF는 봉투 발신자, 즉 수신된 메시지에서 Return-Path로 나타나는 MAIL FROM 주소를 인증하지, 수신자가 실제로 읽는 From: 헤더를 인증하지 않습니다. 어떤 메시지든 SPF를 깨끗이 통과하면서 화면에는 전혀 다른 발신 주소를 표시할 수 있고, DMARC의 정렬 검사가 존재하는 이유가 바로 이 틈입니다. 그리고 SPF는 단순 전달에서 깨집니다. 메일링 리스트나 전달 설정된 사서함은 자기 서버에서 메시지를 중계하는데, 봉투 발신자를 다시 쓰지 않는 한 내 잘못이 아닌 이유로 검사가 실패합니다. 누가 내 이름으로 보내는지 아직 파악하는 중이라면 -all 대신 ~all로 끝내라는 권고의 근거가 이것입니다.

도메인마다 v=spf1 레코드는 정확히 하나만 게시하세요. 두 개는 병합이 아니라 permerror입니다. 그리고 RFC 자신이 쓰지 말라고 하는 ptr은 넣지 마세요. TXT 문자열은 하나당 255바이트가 상한이고, 더 긴 레코드는 여러 문자열로 나뉘어 수신 측에서 이어 붙여지지만, 그게 필요한 레코드는 대개 평탄화가 필요한 레코드입니다.