SPF 레코드 문법이란 무엇이며 애플리케이션 이메일에 어떤 영향을 주나요?

SPF 레코드는 순서가 있는 정책 표현식입니다

RFC 7208은 SPF 레코드를 첫 번째 항목이 v=spf1인 DNS TXT 문자열로 정의합니다. 나머지 공백으로 구분된 항목은 일치할 수 있는 메커니즘과 처리 방식을 바꾸는 수정자입니다. 평가는 왼쪽에서 오른쪽으로 진행되며 처음으로 일치하는 메커니즘에서 멈추므로 순서가 곧 정책을 표현합니다. 일반적인 레코드는 고정 주소 범위 두 개를 승인하고, 제공업체 정책 하나를 include한 다음 -all로 끝날 수 있습니다. 이 패턴을 그대로 붙여 넣지 마세요. 올바른 레코드는 정확한 SMTP MAIL FROM 또는 HELO ID와 실제 발송 출처에 따라 달라집니다. 먼저 애플리케이션 제공업체, 메일 서버, 지원 도구, ID 플랫폼, 마케팅 시스템, 전달(forwarding) 경로, 재해 복구용 발신자를 목록으로 만드세요. 정책은 보이는 From 도메인이 아니라 평가 대상 도메인에 게시하세요. 문법적으로 유효한 레코드도 잘못된 출처를 승인하거나, 프로덕션 스트림을 빠뜨리거나, DNS 평가 한도를 초과할 수 있습니다.

한정자는 메커니즘의 일치를 SPF 결과에 대응시킵니다

메커니즘은 한정자로 시작할 수 있습니다. +는 pass, -는 fail, ~는 softfail, ?는 neutral입니다. 한정자가 없으면 +로 간주됩니다. 한정자는 해당 메커니즘이 일치할 때만 적용됩니다. 메커니즘이 일치하지 않을 때 이후 항목의 평가 여부에는 영향을 주지 않습니다. 팀은 흔히 마지막 all 항목에 집중하지만, 그 앞의 모든 include, 주소, a, mx, exists 메커니즘도 한정자를 가지며 평가를 끝낼 수 있습니다. ~all이 테스트 모드라고 가정하거나 -all이 모든 출처를 파악했다는 증거라고 가정하지 말고 명시적으로 검토하세요. fail 결과는 평가한 SMTP ID와 IP에 대한 수신 측의 증거일 뿐, 메일을 삭제하라는 보편적인 명령이 아닙니다. 수신 측은 로컬 정책을 적용합니다. neutral과 softfail은 승인 pass가 아닙니다. 승인된 출처, 승인되지 않은 출처, 일시적으로 해석되지 않은 출처에 대해 의도한 결과를 기록하고 통제된 IP와 ID 픽스처로 검증하세요.

주소 메커니즘은 직접적이지만 소유 관리가 필요합니다

ip4와 ip6 메커니즘은 프로토콜별 문법과 선택적 접두사 길이로 표현한 일치하는 네트워크 범위를 승인합니다. 평가 중 추가 주소 조회가 필요 없지만 송신 네트워크가 바뀌면 오래된 값이 될 수 있습니다. 비공개 런타임 주소가 아니라 공용 발송 주소를 사용하고, 범위는 운영상의 장애 조치가 허용하는 한 좁게 유지하세요. 모든 범위에는 담당자, 발송 시스템, 환경, 변경 절차, 검토 날짜가 있어야 합니다. a 메커니즘은 A 또는 AAAA 이름을 해석하며, 다른 domain-spec을 지정하지 않으면 현재 SPF 도메인을 기본으로 합니다. mx 메커니즘은 MX 호스트와 그 주소를 해석합니다. 이 메커니즘들은 DNS 작업을 추가하며 애플리케이션 릴리스와 무관하게 바뀌는 인프라를 승인할 수 있습니다. 해석된 모든 주소가 그 정확한 SMTP ID로 발송하도록 의도적으로 허용된 경우가 아니라면 a나 mx를 지름길로 사용하지 마세요. 변경을 모니터링하고 IPv4와 IPv6 경로를 모두 테스트하세요.

include는 텍스트 조각이 아니라 다른 정책을 평가합니다

include 메커니즘은 참조하는 도메인의 SPF 정책을 평가하며, 그 중첩 평가가 pass를 반환하면 일치합니다. 항목을 현재 문자열에 기계적으로 붙여 넣는 것이 아니며, 다른 중첩 결과에도 정의된 효과가 있습니다. 참조하는 조직이 발송 관계에 대해 해당 도메인을 명시적으로 문서화한 경우에만 include를 사용하세요. 제공업체의 웹사이트 도메인, MX 도메인, 보이는 From 도메인이 자동으로 SPF include가 되는 것은 아닙니다. include는 운영상의 의존성을 만듭니다. 제공업체 레코드가 바뀌면 승인 범위가 달라지거나, 중첩 DNS 조회가 추가되거나, 일시적 및 영구적 오류가 발생할 수 있습니다. 공급업체, 서비스, 정확한 include 도메인, 계약 출처, 담당자, 제거 계획을 기록하세요. 제공업체의 실제 발송 IP와 자사 엔벨로프 도메인으로 결과 정책을 테스트하세요. 모든 제공업체 주소 변경을 추적하고 원래 의미를 보존하는 책임을 받아들이지 않는 한, 제공업체 include를 복사한 IP 목록으로 평탄화하지 마세요.

all, redirect, explanation은 각각 다른 역할을 합니다

all 메커니즘은 항상 일치하며 보통 마지막에 둡니다. 그 뒤의 항목은 평가에 영향을 줄 수 없습니다. 한정자는 앞에서 일치하지 않은 출처의 결과를 결정합니다. redirect 수정자는 현재 레코드의 어떤 메커니즘도 일치하지 않을 때 다른 도메인의 정책을 사용하라고 SPF에 알려 줍니다. redirect는 include와 다릅니다. include는 순서가 있는 메커니즘 하나이고, redirect는 정의된 조건에서 최종 정책 결정을 대체합니다. 레코드에는 redirect 수정자가 여러 개 있어서는 안 됩니다. exp 수정자는 fail 결과에 대한 설명을 참조할 수 있지만 메일을 승인하지 않으며 운영과 개인정보 측면의 고려 사항을 추가로 만듭니다. 설명은 일반적으로 유지하고 발신자나 수신자 데이터를 피하세요. 도메인들이 정책 전체를 의도적으로 공유하고 소유권이 조율되어 있다면 redirect를 선택하세요. 더 넓은 로컬 정책 안에 제공업체 하나의 승인된 출처를 추가한다면 include를 선택하세요. 예상한 pass뿐 아니라 일치하지 않는 경로도 테스트하세요.

ptr은 피하고 exists와 매크로는 고급 기능으로 다루기

RFC 7208은 ptr 메커니즘이 느리고, 신뢰할 수 없고, 부담이 크므로 사용하지 말아야 한다고 설명합니다. 낯선 IP를 통과시키려고 ptr을 추가하지 마세요. exists 메커니즘은 domain-spec을 사용해 DNS 존재 여부를 테스트할 수 있고, SPF 매크로는 지원되는 필드 안에서 ID와 연결 구성 요소를 확장할 수 있습니다. 이런 도구는 위임되거나 고객별 승인을 표현할 수 있지만 복잡성, DNS 작업, 개인정보 노출, 실패 유형을 늘립니다. 매크로 문법은 임의의 문자열 템플릿이 아니며 정의된 문자, 변환자, 구분자, 컨텍스트만 유효합니다. 전체 수신자 주소, 시크릿, 제한 없는 테넌트 입력을 DNS 쿼리에 넣지 마세요. 소유한 IP 범위와 문서화된 제공업체 include의 단순한 조합으로 정책을 표현할 수 있다면 그쪽을 선호하세요. 고급 정책이라면 프로덕션 전에 여러 도메인, 발신자, IP 계열, null reverse-path, 매크로 이스케이프, NXDOMAIN, 타임아웃, 예기치 않은 DNS 응답에 대한 결정적인 픽스처를 만드세요.

DNS 조회 10회 제한 지키기

RFC 7208은 SPF 구현이 한 번의 확인에서 DNS 쿼리를 일으키는 항목을 10개로 제한하며, 여기에는 관련된 include, a, mx, ptr, exists, redirect 처리가 포함됩니다. 중첩된 include도 셈에 들어갑니다. 이 규격은 또한 DNS가 빈 응답이나 이름 오류를 반환하는 void 조회를 2회로 제한하도록 권장합니다. 처리 제한을 초과하면 pass가 아니라 영구 오류가 발생할 수 있습니다. 최상위 TXT 문자열에 보이는 항목만이 아니라 확장된 평가 그래프를 기준으로 세세요. 제공업체 include 하나가 여러 중첩 의존성을 가져올 수 있고, mx 메커니즘은 여러 호스트에 대한 주소 조회를 일으킬 수 있습니다. 캡처한 DNS 픽스처와 함께 표준을 이해하는 평가기를 사용하되 의존성 트리도 직접 확인하세요. 사용하지 않는 제공업체와 중복된 메커니즘을 제거하세요. 제공업체 업데이트를 조용히 놓치는 위험한 평탄화는 피하세요. 정책 변경을 모니터링하고, 한도에 딱 맞춰 배포하지 말고 제공업체의 변화에 대비해 조회 여유를 남겨 두세요.

도메인당 SPF 정책은 정확히 하나만 게시하기

RFC 7208은 SPF에 DNS TXT 레코드를 사용하며 v=spf1로 시작하는 레코드를 선택하도록 요구합니다. 같은 정확한 소유자 이름에 SPF 레코드가 여러 개 있으면 승인이 합쳐지지 않고 영구 오류가 발생합니다. 조율된 소유권 아래에서 기존 정책을 수정하세요. 다른 애플리케이션이 접근이 필요하다는 이유로 두 번째 TXT 레코드를 추가하지 마세요. 그 이름에 서로 무관한 다른 TXT 레코드는 공존할 수 있지만 선택되는 SPF 정책은 하나만 있어야 합니다. DNS 제어 플레인의 따옴표 처리와 문자열 분할 동작을 확인하고, 권한 있는 서버를 조회한 다음 독립적인 재귀 리졸버를 조회하세요. 롤백을 위해 이전 값과 TTL을 보존하세요. DNS 전파는 즉시 이루어지지 않으며 네거티브 캐시가 남을 수 있습니다. 대시보드의 초록색 확인은 그 도구가 관찰한 쿼리와 파서 동작만 입증합니다. 별도의 정책을 게시할 수 있는 서브도메인과 반송 주소를 포함해, 원본 수신 헤더와 제공업체 로그에서 실제 프로덕션 엔벨로프 도메인을 검증하세요.

SPF 문법을 DMARC와 혼동하지 않고 연결하기

SPF는 프로토콜 규칙에 따라 보통 MAIL FROM 도메인이나 HELO ID를 평가합니다. DMARC는 보이는 RFC 5322 From 도메인을 사용하며, SPF로 인증된 도메인이 그 보이는 도메인과 정렬될 때만 SPF를 하나의 경로로 인정합니다. 따라서 제공업체의 Return-Path는 SPF를 통과하면서도 DMARC에서는 정렬되지 않을 수 있습니다. 반대로 SPF가 실패하거나 정렬되지 않았을 때 정렬된 DKIM pass가 DMARC를 충족할 수 있습니다. SPF 결과, 평가한 도메인, 연결한 IP, 보이는 From, DKIM 결과, 정렬, DMARC 결과를 각각 따로 기록하세요. 전달(forwarding)은 흔히 연결 IP를 바꾸며, 원래 발신자가 승인되었더라도 SPF를 깨뜨릴 수 있습니다. 임의의 전달 서버를 포함하도록 SPF를 넓히지 마세요. DKIM을 사용하고, 적절한 경우 인증 체인 메커니즘과 수신 측 증거를 활용하세요. SPF pass는 메시지 무결성, 콘텐츠 안전, 수신자 동의, 서버의 수락, 받은편지함 도달을 증명하지 않습니다.

결정적인 워크플로로 변경 검증하기

DNS를 수정하기 전에 현재 레코드를 내보내고 각 메커니즘과 수정자를 담당자와 목적과 함께 나열하세요. 후보를 RFC 7208 문법으로 파싱하고, 통제된 스냅샷으로 DNS 의존성을 확장하고, 조회를 일으키는 항목을 세고, 승인된 IPv4와 IPv6 픽스처와 승인되지 않은 픽스처를 테스트하세요. 중첩된 include의 pass, fail, neutral, softfail, 일시적 오류, 영구 오류 동작을 확인하세요. HELO를 통한 null reverse-path 처리, 서브도메인, 제공업체 Return-Path, all로 넘어가야 하는 출처를 테스트하세요. 일반적인 변경 통제를 거쳐 게시한 다음 권한 있는 DNS와 재귀 DNS를 조회하고, 실제 스트림마다 통제된 메시지를 보내세요. 신뢰할 수 있는 수신 측의 원본 Authentication-Results를 보존하고 예상한 ID와 비교하세요. 프로덕션 출처 누락, 다중 레코드 선택, 조회 한도 오류, 광범위한 temperror, 의도하지 않은 승인이 있으면 롤백하세요. 원치 않는 메일을 보내는 방식으로 테스트하지 마세요.

SendHQ로 SPF 설정

SendHQ는 발신자 ID 설정의 일부로 SPF TXT 정책을 프로비저닝합니다. 충돌하는 SPF 정책이 있으면 설정을 중지하고 관련 없는 정책을 조용히 덮어쓰는 대신 권장 병합 SPF 값을 보고합니다. 선택 가능한 SPF 정책은 정확히 하나만 유지하고 설정 및 복구 상세 정보는 Domains and DNS 문서를 참고하세요.

자주 묻는 질문

출처

• RFC 7208: 발신자 정책 프레임워크(Sender Policy Framework) — RFC Editor
• RFC 7489: 도메인 기반 메시지 인증, 보고 및 준수(DMARC) — RFC Editor
• RFC 5321: 단순 메일 전송 프로토콜(SMTP) — RFC Editor