애플리케이션 이메일의 SPF 레코드는 어떻게 확인하나요?

SPF가 실제로 확인하는 ID부터 시작하세요

SPF 검사에는 세 가지 입력이 필요합니다. SMTP 클라이언트의 IP 주소, 승인 정책을 평가할 도메인, 그리고 발신자 ID입니다. 일반적인 애플리케이션 메일에서 이 도메인은 엔벨로프 발신자 또는 반환 경로(return path)라고도 하는 SMTP MAIL FROM 주소에서 가져옵니다. 이 도메인은 사용자에게 보이는 메시지의 From 헤더 주소와 다를 수 있습니다. 배달 상태 알림(DSN)처럼 MAIL FROM이 비어 있으면, SPF는 MAIL FROM 검사에 HELO ID를 사용합니다. DNS를 조회하기 전에, 수신된 테스트 메시지 또는 발송 제공업체 설정에서 실제 연결 IP와 엔벨로프 ID를 기록해 두세요. 애플리케이션이 실제로 bounce.provider.test나 bounces.example.test의 MAIL FROM으로 발송하는데 From에 나타난다는 이유로 example.test를 확인하면 결론을 내릴 수 없습니다.

정확한 MAIL FROM 도메인에서 TXT를 조회하세요

첫 번째 단계에서 선택한 정확한 도메인에서 DNS TXT를 조회하세요. RFC 7208은 SPF 버전 1 정책을 해당 정책이 적용되는 소유자 이름의 TXT 레코드로 게시하도록 요구합니다. 관련 없는 TXT 값은 무시하고, 버전 섹션이 정확히 v=spf1인 레코드를 선택하세요. 선택된 레코드가 없으면 SPF none 결과가 나옵니다. 선택된 SPF 레코드가 둘 이상이면 permerror가 발생하며, 벤더마다 별도의 레코드를 게시하는 것은 이를 결합하는 올바른 방법이 아닙니다. 하나의 TXT 리소스 레코드는 DNS 도구에 의해 따옴표로 묶인 여러 문자열로 나뉘어 있을 수 있지만, SPF를 파싱하기 전에 이 문자열들은 공백 없이 이어 붙여집니다. 변경 후에 검사를 반복할 수 있도록 전체 응답, 리졸버, 조회 시각, TTL을 기록해 두세요.

구문을 검증하고 항목을 왼쪽에서 오른쪽으로 평가하세요

SPF 레코드는 순서가 없는 제공업체 목록이 아니라 순서가 있는 정책입니다. v=spf1 뒤의 메커니즘은 하나가 일치할 때까지 왼쪽에서 오른쪽으로 평가됩니다. 앞에 붙은 한정자가 결과를 결정합니다. +는 pass이며 기본값이고, -는 fail, ~는 softfail, ?는 neutral입니다. ip4와 ip6 메커니즘은 클라이언트 주소를 주소 또는 네트워크와 비교합니다. a와 mx 메커니즘은 DNS를 조회하고, include는 다른 도메인의 SPF 정책을 평가하며 include 규칙에 따라서만 일치합니다. exists는 DNS 기반 테스트를 수행합니다. all은 항상 일치하며 보통 레코드를 마무리합니다. 구문 오류가 어디에 있든 일반 평가에 앞서 permerror가 발생합니다. 좋은 검사 도구는 색상 배지만 반환하지 않고, 어떤 메커니즘이 일치했는지, 그 한정자, 확장된 각 도메인을 보고해야 합니다.

include와 redirect를 별칭처럼 취급하지 말고 추적하세요

모든 include와 redirect를 동일한 평가 컨텍스트로 따라가세요. include는 메커니즘입니다. 포함된 정책이 현재 클라이언트와 발신자에 대해 pass를 반환하는지 확인하고, 일치하지 않으면 원래 레코드에서 계속 진행합니다. redirect는 수식어(modifier)로, 현재 레코드의 메커니즘이 모두 일치하지 않은 뒤에 고려되며, 클라이언트 IP와 발신자를 유지한 채 평가를 다른 정책으로 넘깁니다. 레코드 어디에든 all이 있으면 redirect는 무시됩니다. 이 차이는 마이그레이션 중에 중요합니다. include:vendor.test를 redirect=vendor.test로 바꾸면 벤더를 추가하는 데 그치지 않고 도메인 소유자의 전체 대체 정책이 교체될 수 있습니다. 순환, 존재하지 않는 대상, 잘못된 대상, 중첩된 영구 또는 일시적 오류를 감지하고, 제공업체 측 정책 변경이 드러나도록 결과에 의존 관계 체인을 보존하세요.

전체 DNS 조회 예산을 세세요

최상위 레코드뿐 아니라 전체 재귀 평가에 걸쳐 DNS 조회를 유발하는 항목을 세세요. RFC 7208은 한 번의 SPF 평가에서 include, a, mx, ptr, exists, redirect 항목을 10개로 제한하며, 이 한도를 넘으면 permerror가 되어야 합니다. all, ip4, ip6 메커니즘은 이 항목 예산을 소모하지 않습니다. MX와 PTR 처리에는 주소 조회에 대한 추가 제한이 있습니다. RFC는 또한 성공했지만 비어 있는 응답이나 이름 오류를 뜻하는 void 조회를 2회로 제한하고, 초과하면 permerror를 내도록 권장합니다. ptr 메커니즘은 느리고 신뢰할 수 없으므로 권장되지 않습니다. 레코드는 짧아 보여도 제공업체의 include가 중첩된 항목으로 확장되면서 한도를 넘어 실패할 수 있으므로, 총계, 기여한 각 항목, void 조회, 테스트한 IP에 대해 실제로 거친 분기를 보고하세요.

SPF 결과를 과대 해석하지 말고 해석하세요

표준 결과 용어를 사용하세요. Pass는 테스트한 클라이언트가 확인 대상 SMTP ID를 사용하도록 승인되었다는 뜻입니다. Fail은 일치하는 부정 승인이 발견되었다는 뜻입니다. Softfail은 약한 부정 표현이고, neutral은 도메인이 해당 클라이언트에 대해 아무런 주장을 하지 않는다는 뜻입니다. None은 선택된 SPF 레코드가 없다는 뜻입니다. Temperror는 일반적으로 DNS에서 발생하는 일시적인 평가 문제를 나타내고, permerror는 올바르게 평가할 수 없는 정책을 나타냅니다. 일치하는 메커니즘도 없고 적용되는 redirect도 없으면 결과는 암묵적인 ?all에 해당하는 neutral입니다. 결과는 ID, 클라이언트 IP, 일치한 항목, DNS 추적, 시각과 함께 보고하세요. SPF는 이러한 결과를 결정하지 않으므로, pass를 안전한 메시지, 원하는 메일, 제공업체의 접수, 메일함 전달, 받은편지함 도달로 해석하지 마세요.

게시된 레코드만이 아니라 실제 메시지를 확인하세요

정적인 레코드 검사는 정책을 찾아서 파싱할 수 있는지에 답할 뿐입니다. 애플리케이션이 예상한 MAIL FROM 도메인이나 발신 IP를 사용했는지는 증명하지 못합니다. 실제 프로덕션 경로마다 관리하는 수신자 계정으로 통제된 메시지를 보낸 다음, 수신된 헤더를 살펴보세요. 연결 IP, 엔벨로프 발신자, 수신 측의 Authentication-Results 항목을 DNS 평가와 비교하세요. 반환 경로를 바꿀 수 있는 모든 제공업체, 리전, 전용 또는 공유 풀, 대체 경로, 메시지 유형마다 반복하세요. 주소와 라우팅 세부 정보는 민감할 수 있으므로 헤더는 접근이 제한된 저장소에 보관하세요. 제공업체 대시보드와 수신된 메시지가 서로 다르면, 실제로 실행된 경로에 대해서는 메시지가 더 강력한 증거입니다. 다만 단일 수신 측의 결과를 보편적인 전달 동작으로 일반화해서는 안 됩니다.

DMARC 정렬은 별도의 단계로 평가하세요

제공업체가 소유한 반환 경로 도메인에 대해 SPF가 pass하더라도 DMARC는 그 결과를 사용하지 못할 수 있습니다. 현재 DMARC 규칙은 SPF 인증에 성공한 RFC5321.MailFrom 도메인을 화면에 표시되는 RFC5322.From 필드의 작성자 도메인과 비교합니다. 엄격한(strict) 정렬은 동일한 DNS 도메인을 요구합니다. 완화된(relaxed) 정렬은 DMARC의 검색 규칙에 따라 같은 조직 도메인으로 확인되는 도메인을 허용합니다. 예를 들어 relaxed 모드에서는 bounces.example.test와 example.test가 정렬될 수 있지만, bounce.provider.test와 example.test는 정렬되지 않습니다. DMARC 결과는 정렬되고 검증된 DKIM 서명에 의존할 수도 있으므로, SPF 정렬이 안 된다고 해서 그 자체로 DMARC가 실패한다는 뜻은 아닙니다. 인증과 정렬을 독립적으로 보고하고, 마지막 두 레이블을 고정해서 비교하지 말고 현재의 도메인 검색 절차를 사용하세요.

제공업체별 MAIL FROM 구성을 테스트하세요

제공업체 설정이 실제 전송에 나타나는 SPF ID를 결정합니다. 예를 들어 Amazon SES는 자체 MX 레코드와 SPF TXT 레코드가 필요한 사용자 지정 MAIL FROM 도메인을 문서화하고 있습니다. SES는 사용자 지정 도메인의 MX가 잘못 구성되어 있으면 구성된 동작에 따라 리전별 amazonses.com MAIL FROM 도메인으로 대체하거나 발송을 거부할 수 있습니다. 이런 대체가 일어나면 화면에 표시되는 From 주소가 그대로여도 DMARC 정렬이 바뀔 수 있습니다. 어떤 제공업체든 구성된 반환 경로 도메인, 필요한 DNS 값, 대체 동작, 발송 리전, 소유권을 기록하세요. DNS나 제공업체를 변경한 뒤에는 관련 캐시 응답이 만료될 때까지 기다린 다음 DNS 평가와 통제된 발송을 반복하세요. 그것이 실제 ID이고 도메인의 전체 발신자 목록이 이를 뒷받침하는 경우가 아니라면, 벤더 include를 화면에 표시되는 From 도메인에 그대로 복사하지 마세요.

변경 중에는 재현 가능한 SPF 감사를 사용하세요

발송 경로마다 한 행씩 두고, 소유자, 애플리케이션, 메시지 유형, 화면에 표시되는 From 도메인, MAIL FROM 도메인, HELO 도메인, 예상 발신 범위, 제공업체 의존성, 마지막 통제 테스트 시각을 관리하세요. 각 SPF 검사는 선택된 레코드, 재귀 추적, DNS 조회 횟수, 일치한 메커니즘, 결과, 정렬 판정, 민감하지 않은 테스트 식별자와 함께 저장하세요. 마이그레이션 중에는 정상적인 기존 발신원과 새 발신원을 필요한 전환 기간 동안만 승인하고, 새 경로를 검증한 뒤 오래된 승인을 의도적으로 제거하세요. 거부(reject)에만 반응하지 말고 영구적 및 일시적 인증 오류를 모니터링하세요. 제공업체 변경, IP 풀 이동, 도메인 변경, DNS 수정, 새 애플리케이션이 생길 때마다 감사를 다시 실행하세요. 이 워크플로는 정상 경로를 막는 지나치게 좁은 정책과, 사용하지 않는 승인을 남겨 두는 지나치게 넓은 정책을 모두 잡아냅니다.

동일한 증거 기준으로 SendHQ 확인

SendHQ는 직접 발송에 검증된 워크스페이스 도메인의 주소가 필요하다고 문서화합니다. 이는 발신자 ID를 검증하지만 SPF 평가를 대체하지는 않습니다. 제어된 SendHQ 메시지도 위에서 설명한 동일한 DNS 추적, 수신 헤더 검사, SPF 결과, DMARC 정렬 검사가 필요합니다.

자주 묻는 질문

출처

• RFC 7208: 발신자 정책 프레임워크 — IETF
• RFC 5321: 간이 메일 전송 프로토콜 — IETF
• RFC 9989: 도메인 기반 메시지 인증, 보고 및 적합성 — RFC Editor
• Amazon SES에서 사용자 지정 MAIL FROM 도메인 사용하기 — Amazon Web Services
• SendHQ OpenAPI 계약 — SendHQ