정확한 SPF 레코드 설정은 수신 메일 서버가 발신 서버의 권한을 판단하는 데 도움이 됩니다. SPF는 여러 검사 중 하나이지 언제나 첫 번째 검사는 아닙니다. 설정 오류가 거부로 이어질 수 있지만, 550 5.7.26 같은 SMTP 코드만으로 SPF가 원인이라고 단정할 수는 없습니다. 2024년 이월부터 Google과 Yahoo의 인증 요건이 적용되고 있으며, 세부 요건은 발송량과 메일 유형 등에 따라 달라집니다.
흔한 문제는 중복 레코드, DNS 조회를 유발하는 항목 10개 제한 초과, 부적절한 마지막 한정자입니다. 이런 오류는 인증과 전달에 영향을 주면서 며칠간 발견되지 않을 수도 있습니다. 반송 메시지에 원인이 명확히 표시되지 않는 경우도 있습니다.
이 가이드는 SPF 구문, TrekMail Managed SMTP와 BYO 구성 예시, DNS 게시, 명령줄 검증까지 설명합니다. 도메인 이메일을 아직 설정하지 않았다면 먼저 내 도메인에 이메일 설정하기를 완료한 뒤 인증 설정을 진행하세요.
SPF가 하는 일
SPF(Sender Policy Framework)는 특정 도메인 신원으로 메일을 보낼 수 있는 서버를 DNS TXT 레코드로 공개합니다. 수신 서버는 발신 IP 주소를 이 정책과 비교합니다. 일치하는 메커니즘과 한정자에 따라 결과가 정해지고, 실제 처리 방식은 수신 서버의 정책에 달려 있습니다. RFC 7208에서 정의한 SPF는 수신자에게 보이는 From 헤더가 아니라 MAIL FROM, 즉 봉투 발신자 신원과 해당되는 경우 HELO를 검사합니다.
SPF가 없으면 도메인을 봉투 발신자로 사용하는 서버의 권한을 판단할 DNS 정책이 없습니다. 다른 인증 수단도 역할을 하지만, SPF는 허용된 발신 서버를 수신 측에 명시하는 방법입니다.
레코드는 하나만 게시
평가 대상 도메인 신원에는 SPF 레코드 하나만 게시할 수 있습니다. v=spf1로 시작하는 별도의 TXT 레코드가 두 개 있으면 PermError가 발생합니다. 반면 같은 TXT 레코드 안에서 따옴표로 나뉜 문자열은 이어 붙여 해석하므로 중복 레코드가 아닙니다. 수신 서버는 자체 정책에 따라 처리합니다. 공급자를 바꾸거나 마케팅 도구를 추가하면서 기존 설정을 통합하지 않으면 이런 오류가 생길 수 있습니다.
| 잘못된 설정: 별도 레코드 두 개 | 올바른 설정: 통합 레코드 하나 |
|---|---|
v=spf1 include:spf.trekmail.net -allv=spf1 include:_spf.google.com -all |
v=spf1 include:spf.trekmail.net include:_spf.google.com -all |
기존 SPF 레코드를 편집해 필요한 메커니즘을 통합하세요. 먼저 삭제한 다음 새로 만들면 SPF 정책이 없는 공백이 생길 수 있습니다. 공급자 이전 중에는 전환 기간에 필요한 기존 발신자와 새 발신자를 모두 반영했는지 확인하세요.
1단계: 도메인으로 발송하는 모든 서비스 확인
DNS를 변경하기 전에 @yourdomain.com으로 발송하는 서비스를 모두 정리하고 실제 봉투 발신자를 확인하세요. 빠뜨린 서비스는 -all 레코드를 적용한 뒤 SPF fail 결과를 받을 수 있습니다. 이것이 거부로 이어지는지는 수신 측 정책에 달려 있습니다. 다섯 분의 점검과 몇 시간의 문제 해결을 비교하는 것은 예시이지 소요 시간 보장이 아닙니다. 실제 점검 범위는 구성에 따라 달라집니다.
다음과 같은 발신 서비스를 확인하세요.
- 업무용 이메일: TrekMail, Google Workspace, Microsoft 365
- 트랜잭션 메일: Amazon SES, SendGrid, Mailgun, Postmark
- 마케팅: Mailchimp, HubSpot, Klaviyo, Brevo
- SaaS 도구: Zendesk, Freshdesk, Shopify, Intercom
일부 서비스는 bounce.mailchimp.com처럼 자체 return-path 도메인을 사용합니다. 이 경우 SPF는 해당 도메인에서 검사하므로 내 SPF 레코드에 그 서비스를 반드시 추가할 필요는 없습니다. 다만 DMARC 정렬을 위해 내 도메인을 사용하도록 설정했다면 달라질 수 있습니다. 제외하기 전에 공급자 문서와 실제 봉투 발신자를 확인하세요.
2단계: SPF 레코드 작성
SPF 레코드는 DNS TXT 값 하나로 구성되며, 같은 레코드 안의 문자열 조각은 이어 붙입니다. 메커니즘은 달라져도 기본 구조는 같습니다. 아래 IP 주소와 CIDR 대역은 문서용 예시이므로 실제 운영 주소로 복사하면 안 됩니다. 주요 구성 요소의 역할은 다음과 같습니다.
| 구성 요소 | 예시 | 역할 |
|---|---|---|
| 버전 | v=spf1 | 필수입니다. 모든 SPF 레코드는 이 값으로 시작합니다. |
| include | include:domain.com | 공급자의 SPF 정책을 DNS로 평가합니다. DNS 조회 유발 항목 10개 제한에 포함됩니다. |
| ip4 | ip4:203.0.113.0/24 | IPv4 주소나 CIDR 대역을 직접 허용합니다. DNS 조회가 필요하지 않습니다. |
| ip6 | ip6:2001:db8::/32 | IPv6에 같은 방식으로 적용합니다. |
| -all | -all | 어느 항목에도 일치하지 않는 발신자에 fail을 반환합니다. 실제 처리는 수신 측이 결정합니다. 정상 발신자를 모두 확인한 뒤 고려하세요. |
| ~all | ~all | 미등록 발신자에 softfail을 반환합니다. 전달을 보장하지 않으며, 관리된 전환 기간에 사용할 수 있습니다. |
3단계: 공급자별 SPF 설정
인프라에 맞는 시나리오를 선택하세요. 아래 레코드는 예시이며, 게시 전에 공급자의 최신 안내와 계정별 설정을 확인해야 합니다. 여러 공급자를 사용한다면 include 메커니즘을 하나의 레코드로 통합하세요.
시나리오 A: TrekMail Managed SMTP(Starter 및 Agency 요금제)
현재 TrekMail 요금제에서 Managed SMTP를 사용할 수 있고 활성화되어 있으며, TrekMail만 발송에 사용한다면 다음 예시를 기본으로 검토할 수 있습니다. 계정의 최신 DNS 안내를 확인하세요.
v=spf1 include:spf.trekmail.net -all해당 발송 IP는 TrekMail이 관리합니다. 다른 정상 발신 서비스가 있다면 함께 반영해야 합니다.
시나리오 B: TrekMail BYO SMTP(직접 구성한 발송 환경)
TrekMail을 받은편지함으로 사용하면서 별도의 SMTP 공급자로 발송한다면, 실제 봉투 발신자에 맞는 공급자의 인증 안내를 따르세요. 최종 전달 단계에서는 해당 SMTP 공급자의 IP가 사용됩니다. 다음 예시가 모든 계정이나 return-path 구성에 그대로 적용되는 것은 아닙니다.
# Amazon SES
v=spf1 include:amazonses.com -all
# SendGrid
v=spf1 include:sendgrid.net -all시나리오 C: Google Workspace
v=spf1 include:_spf.google.com -all시나리오 D: Microsoft 365
v=spf1 include:spf.protection.outlook.com -all시나리오 E: 혼합 구성(TrekMail + 마케팅 플랫폼)
팀 이메일에는 TrekMail을, 캠페인에는 HubSpot을 사용하나요? 필요한 항목을 하나의 레코드로 합치세요. 아래 HubSpot 값은 계정별 값의 예시입니다.
v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -allHubSpot의 include 값은 포털마다 다릅니다. 일반 가이드의 값을 복사하지 말고 HubSpot DNS 설정 화면에서 내 계정의 값을 확인하세요.
4단계: DNS에 게시
도메인의 DNS 공급자에서 SPF 정책을 TXT 레코드로 게시하세요. Cloudflare, Namecheap, GoDaddy, Route 53 등 실제 DNS를 관리하는 서비스에 로그인합니다. 기존 SPF 레코드가 있다면 해당 레코드를 편집하세요.
- 유형: TXT
- 호스트/이름:
@(공급자와 대상 도메인에 따라 빈칸으로 둘 수도 있음) - 값: 전체 SPF 문자열. 예:
v=spf1 include:spf.trekmail.net -all - TTL: 3600(1시간)
권한 있는 담당자가 기존 발신자와 새 발신자를 확인한 뒤 SPF 레코드를 통합한 값으로 바꾸세요. 두 번째 SPF 레코드를 추가하지 말고, 도메인 확인에 쓰이는 다른 TXT 레코드도 삭제하지 마세요. 저장 후 올바른 도메인에 SPF 레코드가 하나만 있는지 확인합니다. 이미 캐시된 이전 값은 기존 TTL이 만료될 때까지 남을 수 있습니다.
5단계: SPF 레코드 검증
게시 후 명령줄에서도 DNS 값을 확인하세요. 웹 검사기의 결과와 비교하는 데 유용하지만, 명령줄 조회도 캐시된 DNS 리졸버를 사용할 수 있습니다. 모든 수신 서버가 지금 보는 값을 그대로 보여 주는 것은 아닙니다.
# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com
# Linux/Mac alternative
dig txt yourdomain.com +short다음 세 가지를 확인하세요.
v=spf1로 시작하는 SPF 레코드가 정확히 하나인지- 필요한
include메커니즘이 모두 있는지 - 의도한
-all또는~all로 끝나는지
v=spf1로 시작하는 별도 레코드가 두 개라면 승인된 발신자를 하나에 통합한 뒤 불필요한 중복 레코드만 제거하세요. 출력 줄이나 따옴표로 나뉜 문자열이 여러 개라는 사실만으로 중복이라고 판단하지 마세요. 중첩 SPF 평가와 실제 메시지의 인증 결과, DMARC 정렬도 확인해야 합니다.
흔한 SPF 오류 해결
SPF 설정 문제는 다음 세 범주에서 자주 발견됩니다. 전체 오류 메시지, 인증 결과, DNS 조회를 함께 확인해 실제 원인을 판단하세요.
1. DNS 조회 유발 항목 10개 제한(PermError)
SPF 평가에서는 DNS 조회를 유발하는 항목을 최대 10개까지 허용합니다. include, a, mx, ptr, exists, redirect 등이 해당하며, 중첩 평가의 항목도 함께 계산합니다. 단순히 DNS 패킷 총수를 세는 제한은 아닙니다. 해당 항목이 10개를 초과하면 PermError가 발생하고 수신 측에서 메일을 거부할 수 있습니다.
증상: 검증 도구가 PermError 또는 "too many DNS lookups"를 표시합니다.
해결: Mailchimp나 Zendesk 같은 서비스를 support.yourdomain.com 같은 하위 도메인으로 분리하는 방안을 검토하세요. 이 하위 도메인에는 별도의 조회 유발 항목 10개 한도가 적용됩니다. 실제 MAIL FROM 또는 return-path도 해당 하위 도메인을 사용하도록 설정하고 DMARC 정렬을 확인해야 합니다. TXT 레코드만 별도로 추가해서는 SPF 평가 대상이 바뀌지 않습니다.
2. Microsoft 개인용 받은편지함(550 5.7.515)
550 5.7.515 코드만으로 SPF가 정상이라거나 IP 평판이 원인이라고 판단할 수 없습니다. Microsoft의 전체 응답을 확인하세요. 개인용 Outlook.com으로 대량 발송하는 발신자는 SPF와 DKIM이 모두 통과해야 하고, 하나 이상의 성공한 검사가 정렬되어 DMARC도 통과해야 합니다. 정렬된 SPF나 DKIM 중 하나가 성공하면 되는 일반 DMARC 규칙과 구분해야 합니다. 인증에 성공해도 평판이나 다른 필터 때문에 받은편지함 도착이 보장되지는 않습니다. DKIM과 DMARC는 업무용 이메일 보안 기본 설정을 참고하세요.
3. SoftFail(~all)과 HardFail(-all)
| 한정자 | 수신 측에 전달하는 의미 | 사용 시점 |
|---|---|---|
~all (SoftFail) | 일치하지 않는 발신자에 softfail을 반환하며, 전달 여부는 수신 측이 결정합니다. | 발신자를 점검하는 관리된 전환 기간. 상황에 맞다면 2~4주 정도를 계획할 수 있습니다. |
-all (HardFail) | 일치하지 않는 발신자에 fail을 반환합니다. 자동 거부를 보장하지는 않습니다. | 정상 발신자를 모두 확인하고 해당 정책이 운영 환경에 적합할 때. |
~all은 SoftFail을, ?all은 Neutral을 반환합니다. Neutral은 부정적인 SPF fail 결과가 아니라 발신자의 권한에 대해 판단하지 않는다는 뜻입니다. 다만 SPF만으로 보이는 발신자 주소의 사칭을 막을 수는 없습니다. 모든 발신자를 확인한 뒤 DKIM, DMARC와 함께 -all 적용을 검토하세요.
TrekMail로 SPF 설정하기
DNS 관리와 SMTP 오류 분석에는 시간이 듭니다. 현재 계정에서 SPF/DKIM/DMARC 설정 마법사를 사용할 수 있다면 Managed SMTP 또는 BYO 환경에 맞는 설정을 찾는 데 도움을 받을 수 있습니다. DNS 검사는 예상 레코드와 비교하는 기능이지 실제 메시지의 서명, DMARC 정렬이나 받은편지함 도착을 검증하는 기능은 아닙니다. 안내된 값과 실제 메시지를 내 구성에 맞춰 확인하세요.
여러 고객 도메인을 관리하는 에이전시에는 일관된 SPF 구성이 중요합니다. 요금제에서 다중 도메인 대시보드를 지원한다면 인증 상태를 모아 확인하는 데 활용하세요. DNS 변경은 담당 DNS 공급자에서 수행합니다. 관련 흐름은 다중 도메인 이메일 호스팅과 맞춤 도메인으로 이메일 만들기를 참고하세요.
과거 상품 안내에는 Managed SMTP가 포함된 Starter가 월 $3.50부터 시작하고, Nano는 신용카드나 체험 만료가 없는 무료 수신 옵션이며, 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 있다고 설명되어 있습니다. 가입 전에 현재 가격, 권한, 한도와 조건을 확인하세요. 설명된 Nano 모델에서만 답장을 포함한 모든 발신에 자체 외부 SMTP가 필요하며, 유료 요금제의 관리형 발신은 실제 권한과 구성에 따릅니다. TrekMail 살펴보기.
SPF 설정 최종 체크리스트
마무리하기 전에 다음 일곱 단계를 확인하세요. 단순한 환경은 15분 안에 설정할 수도 있지만, 발신 서비스가 많거나 DNS 캐시가 남아 있으면 추가 검증 시간이 필요합니다.
- 도메인을 봉투 발신자로 사용하는 모든 서비스 정리
- 기존 SPF 레코드가 없거나 하나뿐인지 확인
- 필요한 공급자를 모두 포함하는 단일
v=spf1문자열 작성 - 대상 도메인의
@에 TTL 3600으로 TXT 레코드 게시 - 기존 레코드를 먼저 삭제하지 않고 편집해 정책 공백 방지
dig txt yourdomain.com +short로 검증v=spf1로 시작하고 선택한-all로 끝나는 SPF 레코드가 하나인지 확인
DNS 설정을 체계적으로 관리하세요. TrekMail로 발송 시작하기.
