이메일 환경별 복사 가능한 SPF 레코드 예시

온라인에서 찾는 SPF 레코드 예시는 지나치게 단순하거나 거의 겪지 않을 예외 상황으로 복잡한 경우가 많습니다. 실제로 필요한 것은 도메인의 95%를 포괄하는 세 가지 인프라 구성용 운영 템플릿입니다. TXT 레코드 하나를 v=spf1로 시작하고 -all로 끝내면 됩니다. 잘못 설정하면 Google이나 Microsoft 같은 수신자가 550 5.7.26처럼 이해하기 어려운 SMTP 오류와 함께 메일을 거부할 수 있습니다.

아래에서 SPF 레코드 예시 템플릿을 확인하세요. 자신의 상황에 맞는 예시를 골라 레코드를 붙여 넣은 뒤, 실제로 주의가 필요한 문제에 집중하면 됩니다.

모든 발신 구성에 맞는 SPF 레코드 예시 템플릿

좋은 SPF 레코드 예시는 여섯 가지 SaaS 도구를 가정한 구성이 아니라 실제 인프라와 일치해야 합니다. 아래 세 가지 시나리오는 단일 발신 도메인, 하이브리드 구성, 복잡한 다중 발신 구성을 다룹니다. 각 템플릿은 루트 도메인의 DNS TXT 레코드로 바로 게시할 수 있습니다.

시나리오 1: 단일 발신자(한 공급자가 모두 처리)

모든 이메일을 하나의 플랫폼을 통해 보냅니다. 가장 깔끔하며 권장하기 쉬운 구성입니다.

TrekMail(Starter, Pro 또는 Agency 요금제):

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

Google Workspace:

v=spf1 include:_spf.google.com -all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

include 하나와 -all 하나면 됩니다. DNS 조회를 1회 사용하며 허용 한도는 10회입니다.

시나리오 2: 하이브리드 발신자(받은편지함 + 트랜잭션 서비스)

기본 받은편지함 공급자와 별도의 트랜잭션 또는 마케팅 서비스를 함께 사용합니다. 자체 SMTP를 쓰는 TrekMail Nano 요금제나 Amazon SES, Mailchimp 같은 도구를 추가한 구성에서 흔합니다.

TrekMail Free + Amazon SES:

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

include 두 개이므로 조회도 두 번이며, 공급자가 발생시키는 중첩 조회는 별도로 더해집니다. 그래도 일반적으로 한도 안에 있습니다.

시나리오 3: 다중 발신 구성(높은 위험)

이 SPF 레코드 예시는 회사 메일, CRM, 헬프데스크, HR 플랫폼을 한 도메인에서 모두 승인합니다. 문제가 자주 생기는 구성입니다.

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

겉으로는 include가 네 개입니다. 하지만 각 include에는 중첩 조회가 들어 있을 수 있습니다. HubSpot만으로도 3-4회의 추가 조회가 연결될 수 있습니다. 전체 체인이 10을 넘으면 수신자가 PermError를 반환하고 메일을 인증되지 않은 것으로 처리합니다. 구성이 이와 비슷하다면 아래의 조회 한도 부분을 반드시 읽으세요.

중요한 SPF 구문이 작동하는 방식

SPF는 RFC 7208에 정의된 DNS 기반 허용 목록입니다. 어떤 IP 주소가 도메인을 대신해 메일을 보낼 수 있는지 수신 서버에 알립니다. 실제 SPF 레코드 예시에서 접하게 되는 구성 요소는 다음과 같습니다.

검증 도구와 플래트닝 위험을 포함한 전체 과정은 SPF 레코드 설정 가이드를 참조하세요.

10회 조회 한도: 대부분의 SPF 레코드가 실패하는 지점

RFC 7208은 SPF 평가 한 번당 DNS 조회를 10회로 제한합니다. 서비스 거부 공격을 막기 위한 제한이지만, 성장하는 기업이 흔히 부딪히는 경계이기도 합니다.

다음 메커니즘은 각각 조회 1회를 사용합니다: include, a, mx, redirect, exists, ptr(지원 중단, 사용하지 마세요).

다음 메커니즘은 조회를 사용하지 않습니다: ip4, ip6, all.

주의할 점은 조회가 재귀적이라는 사실입니다. include:bluehost.com을 추가하면 조회 1회를 사용합니다. Bluehost의 SPF 레코드에 include:spf.protection.outlook.com이 있다면 이 중첩 조회도 자신의 한도에 포함됩니다. 중첩 include가 있는 공급자 3-4곳을 연결하면 이미 10을 넘을 수 있습니다.

놓치기 쉬운 빈 조회 한도

RFC 7208 §11.1에는 보조 한도도 있습니다. 결과가 없는 DNS 조회, 즉 NXDOMAIN이나 빈 결과는 최대 2회입니다. include:spf.trekmaill.net처럼 'l'을 하나 더 넣으면 빈 조회 1회가 됩니다. 오타가 두 개면 전체 레코드가 실패합니다.

플래트닝 없이 조회 한도를 해결하는 방법

SPF 레코드 플래트닝에 의존하기 전에 더 안정적인 대안을 검토하세요. include를 원시 IP로 변환하는 플래트닝은 취약합니다. IP가 예고 없이 바뀌면 플래트닝된 레코드가 오래된 상태로 남기 때문입니다. 다음 두 가지 방법은 운영 중에도 유지하기 쉽습니다.

하위 도메인으로 발신자 분리

모든 도구를 루트 도메인에 넣지 마세요. 각 하위 도메인은 10회의 새로운 조회 한도를 갖습니다.

• 회사 메일: @company.com: TrekMail이나 Google 같은 기본 공급자만 사용
• 마케팅: @news.company.com: Mailchimp, HubSpot
• 지원: @support.company.com: Zendesk, Freshdesk

확장하기 좋은 전략입니다. 여러 도메인이나 고객 계정을 관리할 때 하위 도메인 분리는 각 SPF 레코드를 간결하고 감사하기 쉽게 유지합니다. 도메인 평판도 격리하므로 문제가 생긴 마케팅 캠페인이 트랜잭션 메일의 전달 성능까지 훼손할 위험을 줄입니다.

DNS 조회를 IP 메커니즘으로 교체

고정 메일 서버가 있다면 a 메커니즘 대신 IP를 직접 지정하세요.

조회 1회 사용:

v=spf1 a:mail.company.com -all

조회 0회 사용:

v=spf1 ip4:192.0.2.55 -all

ip4 또는 ip6로 바꿀 때마다 include가 필요한 SaaS 도구에 쓸 조회가 하나 확보됩니다.

전달 성능을 심각하게 해치는 SPF 오류

오류 1: 같은 도메인에 SPF 레코드 두 개 게시

SPF 레코드 예시에서 가장 흔한 실수입니다. 같은 도메인에 v=spf1로 시작하는 TXT 레코드를 두 개 게시할 수 없습니다. 둘 다 PermError로 실패합니다.

잘못된 예:

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

올바른 예:

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

하나로 합치세요. 레코드는 항상 하나여야 합니다. 발생 원인과 전체 예시는 이메일용 SPF 레코드에서 확인할 수 있습니다. SPF 레코드 설정 가이드는 처음부터의 전체 구성 과정을 다룹니다.

오류 2: +all 사용

+all은 사용하지 마세요. 모든 발신자를 통과시키므로 누구나 해당 도메인으로 보낼 수 있다고 모든 메일 서버에 알리는 셈입니다. 항상 -all(HardFail)을 사용하세요.

오류 3: 전달 메일에서 SPF에만 의존

SPF는 봉투 발신자 도메인을 기준으로 발신 IP를 확인합니다. 메일이 전달되면 IP는 바뀌지만 봉투 발신자는 바뀌지 않으므로 SPF가 실패합니다.

이 때문에 DKIM이 필요합니다. 메시지 내용에 서명하므로 전달 후에도 서명이 유지될 수 있습니다. 메일링 리스트나 이메일 전달에 의존한다면 SPF만으로는 부족합니다. DKIM과 함께 둘 중 하나를 인정하는 DMARC 정책을 사용하는 것이 좋습니다. 전달 문제의 또 다른 요소인 Sender Rewriting Scheme(SRS)은 봉투 발신자를 다시 작성해 다음 홉에서 SPF가 통과하도록 합니다.

TrekMail이 SPF 관리를 단순화하는 방법

도메인 하나의 DNS 레코드 관리도 번거롭습니다. 고객 도메인이 50개 또는 100개라면 실수가 빠르게 누적됩니다.

TrekMail의 방식은 요금제에 따라 달라집니다.

• Free($0/mo, 카드 불필요): 자체 SMTP를 사용합니다. 자신의 공급자 SPF 레코드를 include하므로 비용 없이 직접 관리할 수 있습니다.
• Starter($3.50/mo) 및 Pro($10/mo): 관리형 SMTP입니다. include:spf.trekmail.net을 추가하면 기반 IP 인프라를 TrekMail이 관리합니다. 서버가 교체되어도 DNS는 그대로 유지됩니다.
• Agency(.25/mo): 같은 관리형 SMTP를 여러 도메인 관리에 맞게 제공합니다. 표준 SPF 템플릿을 모든 고객 도메인에 적용할 수 있습니다. include 하나만 사용해 고객의 다른 도구에 충분한 조회 한도를 남깁니다.

모든 유료 요금제에는 카드가 필요한 14일 무료 체험이 포함됩니다. 내장 SPF/DKIM/DMARC 마법사가 DNS 구성을 단계별로 안내하고 운영에 반영하기 전에 발견한 오류를 표시합니다.

SPF 점검 목록

이 가이드의 모든 SPF 레코드 예시는 같은 원칙을 따릅니다. 불필요하게 복잡하게 만들지 않으면 좋은 레코드는 어렵지 않습니다. 다음 순서로 점검하세요.

1. 조회 횟수를 계산합니다. dig TXT yourdomain.com을 실행하거나 온라인 SPF 검증기를 사용하세요. 10을 넘으면 이미 실패하는 구성입니다.
2. 중복 레코드를 합칩니다. 한 도메인에는 v=spf1 레코드 하나만 둡니다.
3. 조회가 많은 발신자를 분리합니다. 마케팅과 지원 도구를 하위 도메인으로 옮깁니다.
4. 고정 서버에서는 a 메커니즘을 ip4로 교체합니다.
5. -all로 끝냅니다. 예외는 없습니다.

DNS 편집을 모두 생략하고 싶다면 TrekMail 무료 요금제로 초기 비용 없이 작동하는 이메일 환경을 이용할 수 있습니다. 유료 요금제에서는 SPF 인프라를 관리해 줍니다.