SPF 실패 해결: 오류 코드, 원인과 DNS 수정 방법

이메일이 반송되었습니다. 헤더에는 spf=fail이 표시됩니다. 550 5.7.1 또는 550 5.7.26 오류가 눈앞에 있고, 고객은 도착하지 않은 답장을 기다리고 있습니다.

SPF 실패는 콘텐츠 문제가 아닙니다. DNS 인증 실패입니다. 수신 메일 서버가 SPF 레코드를 확인하고 발신 IP가 허용 목록에 없다는 사실을 발견하여 메시지가 스팸 폴더에 도달하기도 전에 거부했습니다.

2024년 이월부터 Google과 Yahoo는 인증되지 않은 이메일을 단순히 의심스럽다고 표시하는 데 그치지 않고 프로토콜 수준에서 거부할 수 있습니다. 이 가이드에서는 표시된 오류 코드를 해석하고, 헤더에서 실패한 IP를 찾는 위치를 알려 주며, 대부분의 SPF 실패 사례를 해결하는 세 가지 DNS 수정 방법을 설명합니다. 추측하지 말고 올바른 해결책부터 적용하세요.

처음으로 도메인에 이메일을 설정하는 경우 실패 원인을 조사하기 전에 기본 DNS 구성을 정확히 갖추세요. SPF 문제는 불완전한 초기 설정에서 비롯되는 경우가 많습니다.

SPF 실패란?

SPF 실패는 수신 메일 서버가 도메인의 Sender Policy Framework 레코드를 평가하고 발신 IP 주소가 허용 대상으로 등록되지 않았다고 판단할 때 발생합니다. SPF는 도메인의 DNS TXT 레코드로 게시되며, 사용자를 대신해 이메일을 보낼 수 있는 모든 IP 주소와 메일 서비스를 나열합니다. 확인에 실패하면 서버가 메시지를 즉시 거부하거나(hard fail) 의심스러운 메시지로 받아들입니다(soft fail). 어느 쪽이든 DMARC 정책에서는 실패로 계산됩니다.

SPF는 수신자가 보는 일반적인 "From" 헤더가 아니라 SMTP 핸드셰이크 중 협상되는 envelope sender, 즉 MAIL FROM 주소를 확인합니다. 오류가 발생한 지점을 추적할 때 이 차이가 중요합니다.

무엇이든 변경하기 전에 오류 코드를 확인하세요

메일 서버마다 SPF 실패에 서로 다른 SMTP 코드를 반환합니다. 오류 코드는 수신자가 어떤 결정을 내렸고 그 이유가 무엇인지 보여 줍니다. 550 5.7.26을 일반적인 550 5.7.1과 똑같이 취급하면 진단 시간을 낭비하게 됩니다. DNS 레코드를 하나라도 건드리기 전에 코드를 원인과 연결하세요.

1단계: 헤더에서 실패한 IP 찾기

어떤 IP가 SPF 실패를 일으켰는지 추측하지 마세요. 반송된 메시지나 반송 알림의 원본 헤더를 열고 Authentication-Results를 검색하세요. 이 헤더에는 수신자가 평가한 정확한 IP와 그 결정이 표시됩니다.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

발신 IP(192.0.2.55)와 확인 대상 도메인(example.com)이라는 두 가지 조사 정보가 바로 여기에 있습니다. 이제 해당 IP의 소유자를 확인하세요.

• 최근 도입한 SaaS 도구입니까? (HubSpot, Zendesk, Shopify)
• 웹 서버입니까? (WordPress, cPanel)
• 메일 전달 서비스입니까? (아래의 전달 함정 섹션 참조)

그런 다음 간단한 조회로 현재 SPF 레코드를 확인하세요.

dig +short txt yourdomain.com | grep spf

v=spf1로 시작하는 줄이 하나보다 많다면 문제 하나는 이미 찾은 것입니다.

2단계: 가장 흔한 세 가지 SPF 실패 해결책

대부분의 SPF 실패는 공급업체 include 누락, 중복 레코드, DNS 조회 한도 10회 초과라는 세 가지 원인 중 하나에서 발생합니다. 1단계에서 확인한 내용에 맞는 해결책을 선택하세요.

해결책 1: 누락된 Include (공급업체 누락)

HelpScout, HubSpot, Zendesk, Shopify 거래 이메일 같은 새 이메일 도구를 추가했지만 DNS를 업데이트하지 않았습니다. 서비스가 허용되지 않은 IP를 사용해 사용자를 대신하여 발송합니다. 새 공급업체를 도입한 뒤 SPF가 실패하는 가장 흔한 원인입니다.

실패하는 레코드:

v=spf1 include:spf.trekmail.net -all

통과하는 레코드 (HelpScout 추가 후):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

공급업체 문서에서 필요한 SPF include 문자열을 찾으세요. 기존 SPF TXT 레코드에 추가하고 새 레코드를 만들지 마세요. 발송에 사용하는 모든 서비스를 나열해야 합니다.

해결책 2: 중복 레코드 (치명적인 구문 오류)

도메인마다 SPF 레코드는 하나만 둘 수 있습니다. 새 도구의 내용을 기존 레코드에 합치지 않고 두 번째 TXT 레코드를 추가하면 수신자가 서로 충돌하는 두 정책을 보고 모두 무효로 처리합니다. 그 결과 PermError가 발생합니다. 이전까지 정상적으로 전달되던 메일을 포함해 도메인의 모든 이메일에 SPF hard fail이 발생합니다.

잘못된 예 - 별도 레코드 두 개:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

올바른 예 - 하나로 통합:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

DNS 제공업체에 로그인해 SPF TXT 레코드 하나만 남기고 나머지는 삭제한 다음 모든 내용을 한 줄로 통합하세요. 중복 레코드로 발생한 PermError는 수정할 때까지 모든 발신자에게 눈에 띄지 않는 SPF 실패를 일으킵니다.

해결책 3: 조회 한도 10회 (아키텍처 실패)

RFC 7208은 SPF 평가를 DNS 조회 10회로 제한합니다. 이는 서버가 DNS 증폭에 악용되는 것을 막기 위한 것입니다. include, a, mx 같은 메커니즘은 각각 한도에 포함되며, 공급업체가 다른 공급업체의 레코드를 포함하는 중첩 include도 계산됩니다.

조회가 10회를 넘으면 PermError가 발생하고 모든 발신자의 SPF가 실패합니다. 레코드를 추적해 현재 조회 횟수를 확인하세요.

dig +short txt yourdomain.com

각 include, a, mx 메커니즘을 직접 세고 공급업체별 중첩 include도 따라가세요. 한도를 넘었다면 다음 두 가지 방법을 고려할 수 있습니다.

1. 발신자를 하위 도메인으로 분리합니다. 대량 마케팅 도구를 marketing.yourdomain.com으로 옮기세요. 이 하위 도메인에는 기본 도메인의 레코드와 완전히 별개인 새 조회 한도 10회가 주어집니다.
2. 레코드를 평면화합니다. include 체인을 실제로 확인되는 IP로 바꾸고 ip4: 또는 ip6: 메커니즘을 사용하세요. 이는 조회 횟수에 포함되지 않습니다. 단, 공급업체가 IP를 변경할 때 레코드를 직접 업데이트해야 합니다.

빈 조회 한도라는 함정도 있습니다. 체인에서 두 번보다 많은 조회가 NXDOMAIN을 반환하면 - 예를 들어 include:spf.gogle.com 같은 오타가 있으면 - RFC 7208 §11.1에 따라 레코드가 무효화됩니다. 중첩된 공급업체 include 어디에서든 오타 하나가 전체 SPF 평가를 실패하게 만들 수 있습니다.

전달 함정: 정상 이메일에서 SPF가 실패하는 이유

다음 SPF 실패는 DNS 구성과 무관합니다. 동문 주소(alice@university.edu)로 이메일을 보냈는데 이 주소가 Gmail(alice@gmail.com)로 자동 전달합니다. Gmail에는 대학 서버의 IP에서 이메일이 도착합니다. SPF 레코드는 이 IP를 허용하지 않으므로 모든 설정을 올바르게 했어도 SPF가 실패합니다.

경로: 사용자 서버 → 대학 서버 → Gmail. 확인 방식: Gmail은 마지막 구간을 평가합니다. SPF는 원래 발신 IP만 허용하므로 전달로 인한 실패를 SPF로 해결할 수 없습니다. 전달 서버가 개입하는 순간 IP 확인이 깨집니다.

올바른 해결책은 DKIM입니다. DKIM은 메시지 본문과 헤더에 암호화 서명을 적용합니다. 전달 서버는 일반적으로 본문을 변경하지 않으므로 DKIM 서명은 릴레이 구간을 통과해도 유지됩니다. SPF가 실패해도 유효한 DKIM 서명이 있으면 DMARC에서 메시지가 유효하게 처리될 수 있습니다.

인프라 수준의 전달을 운영하며 SPF 호환 재작성을 원한다면 Sender Rewriting Scheme (SRS)을 이해하는 것이 좋습니다. 전달 서버가 envelope sender를 다시 작성하여 최종 목적지에서 SPF가 통과하도록 하는 방식입니다. 더 넓은 범위의 전달 실패는 이메일 전달 설정 및 해결 가이드에서 전체 진단 과정을 확인하세요.

다음 단계로 넘어가기 전에 수정 결과 확인

DNS 레코드를 업데이트한 뒤 전파를 기다리세요. 대부분의 제공업체에서는 보통 5-30분이 걸리지만 일부 예외적인 상황에서는 몇 시간이 걸릴 수 있습니다. 완료했다고 판단하기 전에 수정 사항이 실제로 반영되었는지 확인하세요.

Gmail 주소로 테스트 이메일을 보내고 원본 헤더를 여세요. Authentication-Results를 검색해 다음 내용을 확인해야 합니다.

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

여전히 spf=fail 또는 spf=softfail이 보인다면 수정 사항이 아직 전파되지 않았거나 레코드에 문제가 남아 있습니다. 헤더의 IP와 업데이트된 레코드의 내용을 비교하세요. 서로 일치해야 합니다.

레코드를 직접 확인할 수도 있습니다.

dig +short txt yourdomain.com

v=spf1로 시작하는 레코드가 정확히 하나인지, 모든 발송 서비스가 포함되어 있는지, 레코드가 -all(hard fail) 또는 ~all(soft fail)로 끝나는지 확인하세요.

여러 도메인의 SPF 관리

도메인 하나의 SPF 관리는 한 번으로 끝나는 작업입니다. include를 추가하고 중복 레코드를 통합하며 조회 횟수를 바로잡으면 됩니다. 그러나 각각 별도의 SPF 레코드와 SaaS 공급업체를 사용하는 도메인 10개, 50개 또는 500개의 이메일을 관리한다면 모든 SPF 실패를 직접 조사하는 일이 상당한 운영 부담이 됩니다.

TrekMail 관리형 SMTP는 Starter의 월 $3.50 이상 요금제에서 제공되며 - 도메인마다 include 하나만 사용하도록 구성을 단순화합니다. TrekMail은 IP 교체, 반송 모니터링, DKIM 정렬, 기반 전달 인프라를 관리합니다. Agency 요금제(월 $23.25)를 사용하는 대행사는 수백 개의 개별 레코드에서 SPF 실패를 추적하는 대신 모든 고객 도메인에 표준 DNS 템플릿 하나를 적용할 수 있습니다.

관리형 전달이 실제로 어떻게 작동하는지 확인하려면 14일 무료 평가판을 시작하세요.

SPF 실패: 간단한 요약

SPF 실패는 수신 서버가 DNS를 확인하고 발신 IP가 목록에 없음을 발견하여 정책을 적용했다는 뜻입니다. Hard fail(-all)은 거부를 의미합니다. Soft fail(~all)은 스팸 폴더를 의미합니다. PermError는 레코드가 잘못되어 레코드를 직접 수정할 때까지 모든 발신자의 SPF가 실패한다는 뜻입니다.

다음 순서대로 해결하세요.

1. Authentication-Results 헤더에서 실패한 IP를 찾습니다
2. 새 서비스로 SPF가 실패했다면 누락된 공급업체 include를 추가합니다
3. 중복 SPF 레코드를 하나로 통합합니다
4. DNS 조회를 10회 미만으로 줄이거나 대량 발신자를 하위 도메인으로 분리합니다
5. 전달된 메일에서 SPF가 실패한다면 DKIM을 구현합니다. SPF는 릴레이 구간을 통과할 수 없습니다

먼저 올바른 수정 사항을 적용하고 헤더로 확인하면 됩니다.