발신자가 하나일 때는 SPF 설정이 잘 작동합니다. Google Workspace, Mailchimp, Zendesk와 트랜잭션 API를 더하자 Microsoft가 550 5.7.515로 메일을 반송할 수 있습니다. 처음에는 단순했던 레코드가 조회 10회 제한을 넘어 발신 인증이 조용히 실패하는 상황입니다.
SPF에는 프로토콜 자체의 상한이 있어 세 번째나 네 번째 발신 서비스를 추가할 때 도달하기 쉽습니다. 흔히 쓰는 해결책인 include: 추가가 더는 통하지 않습니다. 문법은 이메일 SPF 레코드 안내서를 참고하세요. 여기서는 여러 발신자와 업체 변경을 감당하면서 반복 수정을 줄이는 구조를 다룹니다.
여러 발신자에서 SPF 설정이 깨지는 이유
RFC 7208은 SPF 평가를 레코드당 DNS 조회 10회로 제한합니다. include, a, mx, exists, redirect가 모두 재귀적으로 계산됩니다. 업체의 include 안에 세 include가 더 있으면 모두 한도를 씁니다. 11회가 되면 수신 서버가 PermError를 반환하고 메일이 거부될 수 있습니다.
처음에는 include 두 개뿐입니다. 마케팅이 HubSpot, 지원팀이 Freshdesk, 개발팀이 SendGrid를 추가합니다. 예상보다 깊은 연결 때문에 어느새 12회가 되고 Google이 550 5.7.26을 반환할 수 있습니다.
| 방식 | 조회 사용 여부 | 운영 참고 사항 |
|---|---|---|
include: | 사용, 중첩 포함 | 업체 연결에 흔하지만 구조가 바뀔 수 있음 |
ip4: / ip6: | 사용 안 함 | 직접 관리하는 고정 발신자에 적합 |
mx | 사용 | 과용되기 쉬움. 가능하면 ip4 사용 |
a | 사용 | SPF에는 비효율적이며 ip4가 나음 |
ptr | 사용 | 폐기된 방식이므로 사용하지 않음 |
redirect | 사용 | 평가를 다른 도메인의 레코드로 넘김 |
-all / ~all | 사용 안 함 | 정책 종료 요소이므로 하나 포함 |
계산은 어렵지 않지만 장애 전까지 보이지 않습니다. 그래서 여러 발신자의 SPF는 복사보다 구조 설계에서 시작해야 합니다.
추가하기 전에 SPF 레코드 점검하기
먼저 필요 없는 항목을 제거하세요. 오래전에 해지한 서비스의 include도 조회 한도를 씁니다. 정리한 뒤 새 구조를 만드세요.
공개된 값을 확인합니다.
dig txt yourdomain.com +short각 include의 깊이도 추적합니다.
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortDMARC 집계 보고서와 대조하세요. 업체 IP에서 트래픽이 없다면 실제로 서비스를 쓰지 않는지 확인한 뒤 제거합니다.
점검 중 바로 적용할 세 가지 방법입니다.
- 직접 관리하는 고정 IP라면
mx를 실제 주소의ip4:로 바꿔 조회를 하나 줄입니다. - 더는 쓰지 않는 서비스의 include를 제거합니다.
- 중복 SPF를 확인합니다. 같은 도메인에
v=spf1로 시작하는 TXT 레코드가 두 개면 PermError가 발생합니다.
이 작업만으로 2-3회의 여유가 생기기도 합니다. SPF 레코드 설정 안내서도 참고하세요.
하위 도메인 분리: 확장 가능한 SPF 구조
하위 도메인 분리는 여러 발신자를 조회 10회 안에서 운영하는 안정적인 방법입니다. SPF는 표시되는 From이 아니라 Return-Path 도메인을 평가합니다. 회사 메일 이외의 흐름을 하위 도메인으로 옮기면 각각 조회 10회의 새 한도를 갖습니다.
다음 구조를 사용합니다.
루트 도메인: 사람이 보내는 메일만
루트에는 기본 사서함 업체만 두어 단순하게 유지합니다.
v=spf1 include:spf.trekmail.net -allinclude 하나, 조회 하나입니다. 마케팅 도구 변경이 경영진 메일의 같은 SPF 레코드를 건드리지 않습니다.
마케팅 하위 도메인: 캠페인과 뉴스레터
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot과 Mailchimp는 루트가 아니라 news.example.com의 한도를 씁니다. 이곳의 제한이 회사 메일을 직접 멈추지는 않지만 더 넓은 평판 신호는 영향을 줄 수 있습니다.
지원 하위 도메인: 티켓 시스템
; help.example.com
v=spf1 include:mail.zendesk.com -all트랜잭션 하위 도메인: 앱 알림과 영수증
; alerts.example.com
v=spf1 include:amazonses.com -allZendesk가 support@help.example.com으로 보내면 수신자는 help.example.com의 DNS를 확인합니다. 루트 SPF는 평가에 쓰이지 않습니다. 이것이 분리의 핵심입니다.
| 기존 방식 | 새 방식 |
|---|---|
| 모든 발신자를 루트 SPF 하나에 추가 | 루트에는 기본 사서함 업체만 유지 |
| 업체 하나의 변경이 전체 발신에 영향 | 문제가 해당 하위 도메인에 주로 격리 |
| 모든 흐름이 한도 공유 | 하위 도메인마다 조회 10회 확보 |
| 도구 추가 때마다 SPF 재작성 | 업체 변경을 더 쉽게 수용 |
SPF 평면화: 마지막 수단
모든 메일을 루트에서 보내야 해 하위 도메인을 쓸 수 없다면 SPF 평면화를 고려할 수 있습니다. 업체 include를 IP 주소로 풀어 조회를 쓰지 않는 ip4:로 나열합니다. 작동하지만 유지 관리가 필요합니다.
SaaS 업체는 IP를 바꿉니다. SendGrid가 내일 새 대역을 추가했는데 레코드가 어제 주소에 머물면 SPF가 실패할 수 있습니다. 자주 확인하지 못한다면 수동 평면화를 피하세요. 업체 IP를 감시하고 TXT를 통제된 방식으로 갱신하는 신뢰할 수 있는 동적 SPF 서비스를 검토하세요.
평면화는 우회책이지 이상적인 설계가 아닙니다. 가능하면 하위 도메인을 사용하세요.
SPF 설정 검증하기
변경 후에는 공개 DNS의 실제 응답을 확인하세요. 등록기관 화면이나 업체의 초록 표시만 믿지 말고 도메인을 직접 조회해 호스트마다 유효한 SPF가 정확히 하나인지 봅니다.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +short호스트마다 v=spf1로 시작하는 TXT 레코드는 하나여야 합니다. 현재 레코드와 오래된 이전 기록을 함께 두지 마세요.
Gmail로 테스트 메일을 보내고 점 세 개 메뉴의 "원본 보기"에서 다음을 찾습니다.
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSFAIL이나 SOFTFAIL은 대량 발신 전에 원인을 조사해야 한다는 뜻입니다. SPF 밖의 문제는 이메일 발신자 평판 신호 안내서를 참고하세요.
TrekMail이 여러 도메인의 SPF를 단순화하는 방식
도메인 하나도 번거롭지만 서로 다른 업체와 DNS를 쓰는 고객 도메인 50개는 많은 시간이 듭니다. TrekMail은 자체 SPF 구성을 작고 예측 가능하게 유지합니다.
핵심 include는 include:spf.trekmail.net입니다. 현재 구성에서는 중첩 redirect 없이 조회 하나를 씁니다. Microsoft 365는 내부 연결에 따라 2-3회를 쓸 수 있고 Google Workspace도 바뀔 수 있으므로 DNS에서 직접 확인하세요.
개인 창업자는 마케팅 도구를 더해도 단순함을 유지하고, 팀은 등록 과정의 DNS 실수를 줄이며, 대행사는 반복 가능한 틀을 얻습니다. TrekMail include를 넣고 다른 업체를 하위 도메인으로 나눈 뒤 조회 수를 계속 감시하세요. 위험은 줄지만 사라지지 않습니다. 여러 도메인 이메일 호스팅도 참고하세요.
TrekMail의 DNS 상태 검사는 지원되는 검사 범위에서 실제 장애 전에 SPF 충돌을 표시할 수 있습니다. 전체 설정은 문서의 필수 DNS 레코드를 확인하세요.
결론: SPF 구조를 정하고 변경을 관리하세요
좋은 SPF는 문법보다 구조에서 시작합니다. 오래된 include를 지우고 발신자를 하위 도메인으로 나눠 각각 조회 10회를 확보하세요. 루트에는 사서함 업체 하나, include 하나와 -all 하나만 둡니다. 관리 화면뿐 아니라 dig로 검증하세요.
TrekMail은 한 도메인부터 백 개까지 사용자별 과금 없이 고정 요금의 여러 도메인 호스팅, 간결한 SPF include, 공유 저장 공간과 DNS 검사를 제공합니다. 설명된 요금제에서 Nano는 직접 연결 SMTP와 도메인 10개를 카드 없이 무료 조건으로 제공합니다. 관리형 SMTP가 포함된 Starter는 월 $3.50부터이며 카드가 필요한 14일 체험을 제공합니다. 최신 요금은 trekmail.net/pricing에서 확인하세요.
