이메일 SPF 레코드: 업무용 도메인 설정 안내

이메일이 반송되었습니다. 스팸함으로 이동한 것이 아니라 수신 서버에서 거부된 것입니다. 서버는 550 5.7.26 또는 550 5.7.515를 반환했고 메시지는 더 진행되지 않았습니다. 유효한 이메일 SPF 레코드가 없거나 구조에 문제가 있을 수 있습니다. 다만 이 코드만으로 SPF가 유일한 원인이라고 단정할 수는 없습니다. 전체 오류 메시지와 다른 인증 결과도 확인해야 합니다.

2024년 이월부터 Google과 Yahoo는 발신자 인증 요건을 강화했습니다. 적용되는 요건은 발신자 유형과 발송량 등에 따라 달라집니다. 잘못된 SPF 레코드는 거부나 스팸 분류의 원인이 될 수 있지만, 최종 처리는 수신 서버의 정책에 달려 있습니다. 업무용 이메일 도메인도 해당 요건에 맞는 설정이 필요합니다.

Google: 550 5.7.26 - 인증되지 않은 이메일은 허용되지 않음

Microsoft: 550 5.7.515 - 발신자 신원이 인증되지 않음

이 가이드는 바로 실무로 들어갑니다. 환경에 맞는 레코드, 겉보기에는 올바른 설정을 실패하게 만드는 숨은 함정, 실제 발송에서 인증 결과를 확인하는 테스트를 다룹니다. SPF는 세 가지 인증 요소 중 하나입니다. DKIM 및 DMARC와 어떻게 연결되는지는 업무용 이메일 보안의 기본 구성을 참고하세요.

이메일 SPF 레코드란?

SPF 레코드는 도메인을 대신해 이메일을 발송할 수 있는 서버를 지정하는 DNS TXT 항목입니다. Gmail이나 Outlook의 수신 서버는 해당 레코드를 조회하고 발신 IP가 허용된 출처에 해당하는지 확인합니다. 일치하면 일반적으로 pass가 되며, 일치하지 않으면 뒤에 오는 규칙에 따라 결과가 정해집니다. SPF 결과 자체가 메시지의 수락이나 거부를 결정하는 것은 아닙니다.

SPF는 SMTP 봉투 수준에서 MAIL FROM 도메인을 검사합니다. 수신자의 받은편지함에 보이는 "보낸사람" 주소를 직접 검사하지는 않습니다. TXT 레코드는 검사 대상인 봉투 도메인에 게시하며, 기본 도메인이라면 보통 @에 설정합니다. DNS 요소들이 어떻게 연결되는지 알고 싶다면 내 도메인에 이메일 설정하기에서 처음부터 전체 과정을 확인할 수 있습니다.

SPF 레코드는 하나만

SPF 규격인 RFC 7208은 한 도메인에 v=spf1로 시작하는 TXT 레코드를 하나만 허용합니다. 검사하는 도메인에서 두 개의 SPF 레코드를 발견하면 수신 서버의 SPF 평가 결과는 PermError가 됩니다. 중복을 해결할 때까지 SPF를 정상적으로 평가할 수 없습니다. 실제 메시지 거부 여부는 수신 정책과 다른 인증 결과에 따라 달라집니다.

Google Workspace나 다른 호스팅을 이미 사용하는 도메인에 새 서비스를 추가할 때 자주 발생하는 중대한 오류입니다. 기존 레코드를 수정해야 하는데 두 번째 레코드를 추가하는 경우입니다.

수정하기 전에 현재 도메인의 레코드를 확인하세요.

dig +short txt yourdomain.com

v=spf1로 시작하는 줄을 세어 보세요. 두 개라면 PermError의 원인입니다. 다른 SPF 문제를 조사하기 전에 중복부터 해결하세요.

잘못된 예 - 두 레코드는 이 도메인의 SPF 평가에서 PermError를 발생시킵니다.

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

올바른 예 - 이메일 SPF 레코드 하나로 병합합니다.

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

이메일 SPF 레코드: 최소한의 실용적 설정

레코드의 정확한 내용은 실제로 이메일을 전송하는 서버에 따라 달라집니다. 사용하는 출처만 허용하세요. include:를 추가할 때마다 평가 한도를 사용하며, 직접 관리하지 않는 IP 범위까지 허용할 수 있습니다.

시나리오 A: TrekMail 관리형 SMTP (Starter 및 Agency 요금제)

현재 유료 TrekMail 요금제에 관리형 발송이 포함되어 있고, 발신 출처를 점검한 결과 도메인의 모든 이메일이 TrekMail을 통해서만 발송된다면 다음 한 줄이 적합할 수 있습니다.

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

시나리오 B: TrekMail 무료 요금제 (자체 SMTP 연결)

현재 Nano 요금제에서 지원하는 경우 Amazon SES, SendGrid, Mailgun처럼 직접 선택한 SMTP 제공업체를 연결할 수 있습니다. TrekMail이 아닌 해당 제공업체의 IP를 허용하세요.

v=spf1 include:amazonses.com -all

include:amazonses.com을 제공업체 문서에 명시된 값으로 바꾸세요. 사용하지 않는 IP 범위는 허용하지 마세요.

시나리오 C: 혼합 환경 - TrekMail + Google Workspace

Google에서 이전 중이거나 전환 기간에 두 발송 서비스를 함께 사용하나요? 하나의 레코드에 병합하세요.

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

레코드 구성 요소

~all(softfail)은 해당 출처가 허용되지 않았을 가능성을 알리지만 배달을 보장하지 않습니다. -all은 더 명확한 fail 신호이며, 이것만으로 수신 서버의 거부를 강제하지는 않습니다. 모든 정상 발신 출처를 확인한 후 사용하세요. 새 설정을 배포하거나 문제를 조사하는 동안에는 ~all을 임시로 사용할 수 있습니다.

DNS 관련 항목 10개 한도

SPF 규격(RFC 7208)은 평가 중 실행되는 DNS 관련 항목을 10개로 제한합니다. 모든 개별 DNS 질의의 총수를 뜻하는 것은 아닙니다. include:, a, mx와 수정자 redirect가 포함되며, 참조한 레코드에서 실행되는 중첩 항목도 계산합니다. ip4:와 ip6:는 포함되지 않습니다. 10개를 초과하면 SPF 결과는 PermError입니다.

이 문제는 쉽게 드러나지 않습니다. 문법 자체는 올바르므로 문법 검사에 통과할 수 있습니다. 하지만 수신 서버가 include에서 다른 include로 이어지는 참조를 평가하면서 합계가 10개를 넘으면 SPF 평가가 실패합니다.

한도에 포함되는 항목:

• include:와 그 안에서 실행되는 중첩 include
• a, mx, redirect

한도에 포함되지 않는 항목:

• ip4:와 ip6: - 직접 IP를 지정하므로 이 조회 체인을 사용하지 않음
• all

게시하기 전에 개수를 확인하세요.

dig +short txt yourdomain.com

이 명령은 게시된 TXT 레코드를 보여 주지만 중첩 항목의 전체 개수를 계산하지는 않습니다. 참조가 길다면 연결된 레코드도 조사하세요. include:를 직접 ip4: 항목으로 바꾸는 평탄화도 가능하지만, 제공업체의 IP 범위 변경을 지속적으로 반영해야 합니다. 발송 경로를 별도의 봉투 하위 도메인으로 나누는 방법도 있습니다.

이메일 SPF 레코드 검증하기

DNS 대시보드의 초록색 체크만 믿지 마세요. 보통 문법을 검사할 뿐 실제 인증이나 배달을 검증하지는 않습니다. 실제 SMTP 발송으로 SPF를 테스트하면 Gmail이 해당 발송 경로를 어떻게 평가하는지 확인할 수 있습니다.

1. 내 도메인에서 직접 관리하는 Gmail 계정으로 이메일을 보냅니다.
2. Gmail에서 메시지를 엽니다.
3. 점 세 개 메뉴 → 원본 보기를 클릭합니다.
4. Authentication-Results를 찾습니다.

통과 결과는 다음과 같습니다.

spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)

permerror는 SPF 평가의 구조적 문제를 나타냅니다. 단순히 발신 IP가 빠졌다는 의미가 아닙니다. 다른 변경에 앞서 중복 레코드, 항목 수, 문법을 확인하세요.

흔한 SPF 실수

많은 SPF 문제는 다섯 가지 실수에서 비롯됩니다. 원인을 알면 10분 안에 수정할 수 있는 경우도 많지만, DNS 전파나 추가 조사에는 더 오래 걸릴 수 있습니다.

include 오타는 일부 검사기가 문법만 확인하고 참조 도메인의 유효한 SPF 레코드까지 검증하지 않아 발견하기 어렵습니다. 제공업체 문서에 나온 정확한 include 문자열과 항상 대조하세요.

여러 도메인의 이메일 SPF 레코드 관리

도메인 하나의 SPF 설정은 10분 작업일 수 있습니다. 하지만 고객 도메인 50개를 관리하는 일은 지속적인 책임입니다. 고객이 새 마케팅 도구를 추가할 때마다 인증 설정이 불완전해질 수 있습니다. 메일이 왜 반송되는지 문의를 받고 나서야 알게 될 수도 있습니다.

에이전시와 MSP에는 표준화가 도움이 됩니다. 현재 이용 중인 요금제에서 지원한다면 TrekMail의 다중 도메인 대시보드와 SPF/DKIM/DMARC 마법사로 일관된 설정을 적용할 수 있습니다. 적용되는 상품 조건에 따라 월 $3.50부터 시작하는 유료 요금제에는 관리형 SMTP 발송이 포함될 수 있습니다. Nano 요금제에서는 지원되는 경우 자체 SMTP 제공업체를 연결해 해당 발송 경로의 IP 평판을 관리합니다. 충분히 예열되어 발송 한도가 높은 SES나 Mailgun 계정이 있다면 유용할 수 있습니다.

고객 도메인이 같은 발송 서비스를 사용한다면 TrekMail로 이전하고 공통 템플릿을 적용해 관리를 단순화할 수 있습니다. 단, 각 도메인의 정상 발신 출처가 모두 포함되어 있는지 확인해야 합니다. 규모가 커졌을 때의 운영 방식은 에이전시의 고객 이메일 관리를 참고하세요. 새 도메인 이메일 환경을 처음부터 만든다면 내 도메인으로 이메일 만들기에서 전체 과정을 확인할 수 있습니다.

이메일 SPF 레코드: 게시 전 체크리스트

SPF 레코드를 게시하기 전에 다음 항목을 순서대로 확인하세요.

1. 기존 레코드 확인: dig +short txt yourdomain.com - v=spf1 줄은 하나만 있어야 합니다.
2. 도메인을 대신해 발송하는 모든 서비스를 파악합니다. 트랜잭션 메일, 마케팅, 지원 도구를 포함합니다.
3. 모든 출처를 포함하는 레코드 하나를 작성합니다. 별도로 쌓지 말고 병합하세요.
4. 전체 발신 출처를 확인한 뒤 -all을 사용합니다. 전환 중 ~all은 의도적으로 선택하고 +all은 피하세요.
5. 실행되는 DNS 관련 항목을 세어 10개 한도 이내로 유지합니다.
6. 봉투 도메인에 TXT를 게시합니다. 기본 도메인은 DNS의 @에 설정합니다.
7. Gmail로 테스트 메일을 보내고 원본 보기에서 spf=pass를 확인합니다.

Google의 이메일 발신자 가이드라인은 발신자 유형에 따라 요구사항을 구분합니다. 대량 발신자에게는 SPF, DKIM, DMARC가 함께 요구되며, 다른 발신자의 최소 요건은 다릅니다. 올바른 SPF는 첫 단계입니다. DKIM과 DMARC가 인증 체계를 보완하지만, 모두 통과하더라도 받은편지함 도착이 보장되지는 않습니다.

SPF를 제대로 설정하면 안정적인 기반을 마련할 수 있습니다. 발송 제공업체나 IP 범위가 바뀌면 다시 검토하세요. 잘못된 설정은 반송 로그 조사와 업무용 이메일 장애로 이어질 수 있습니다. 현재 Nano 상품이 카드 없이 제공된다면 TrekMail을 무료로 사용해 보세요. 적용 조건에 따라 유료 요금제는 월 $3.50부터 시작하며 14일 무료 체험이 제공될 수 있으니 최신 상품 조건을 확인하세요.