SPF 레코드 만들기: 발신 서비스와 DNS 조회 수 관리

도메인의 SPF 레코드를 만들 때 목표는 단순합니다. 필요한 발신자만 허용하고, 몇 달 뒤 문제를 일으킬 복잡한 DNS 설정을 피하는 것입니다. 많은 문제는 비슷하게 시작됩니다. 서비스를 하나 추가하고, 또 다른 서비스를 추가합니다. 그러다 Microsoft에서 550 5.7.515, Google에서 550 5.7.26 오류가 나오고, 밤 11시에 TXT 레코드를 뒤지고 있게 됩니다.

SPF가 처음에는 쉬워 보인다는 점이 문제입니다. 루트 도메인의 레코드에 온갖 서비스를 넣고 재귀적인 include가 쌓이면, DNS 조회를 유발하는 항목 하나가 더 평가되는 것만으로도 PermError가 발생할 수 있습니다. 회사 도메인이나 고객 시스템, 여러 브랜드의 메일을 관리한다면 사소한 문제가 아닙니다. 수신 측 정책에 따라 배달에 심각한 영향을 줄 수 있습니다. 도메인 설정의 전체 흐름이 궁금하다면 먼저 소규모 기업을 위한 업무용 이메일을 읽어 보세요.

이 가이드는 오래 유지할 수 있는 구조를 소개합니다. 일반 업무 메일은 루트 도메인에 두고, 대량 메일과 앱 메일은 하위 도메인으로 분리하며, DNS 의존 SPF 항목의 평가 예산을 한정된 자원으로 관리합니다. 그러면 SPF 레코드를 자주 다시 설계할 필요가 줄어듭니다. 단, 분리는 해당 발송 흐름이 실제 MAIL FROM 또는 return-path 도메인으로 하위 도메인을 사용할 때만 적용됩니다.

SPF 레코드가 자주 문제를 일으키는 이유

SPF 평가에서는 수신 서버가 처리할 수 있는 DNS 의존 항목 수가 제한됩니다. 한 도메인에 include를 지나치게 쌓으면 이 한도를 초과해 PermError가 발생할 수 있습니다. 문법이 겉으로는 올바르더라도 수신 측에서 메일을 거부할 수 있지만, PermError가 항상 거부를 뜻하는 것은 아닙니다.

RFC 7208은 이를 명확히 설명합니다. DNS 조회를 유발하는 항목에는 include, a, mx, ptr, exists, redirect가 있습니다. 수신 서버는 재귀 평가까지 포함해 평가된 이러한 항목 수를 10으로 제한해야 합니다. 모든 DNS 패킷의 총수를 세는 규칙은 아닙니다. 한도를 넘으면 경고가 아니라 영구 오류가 됩니다. 같은 RFC에 따르면 한 도메인에 SPF 레코드가 여러 개 있어도 PermError가 발생합니다. 다만 SPF와 무관한 다른 TXT 레코드는 하나의 SPF TXT 레코드와 함께 존재해도 됩니다.

그래서 흔히 보는 조언만으로는 부족합니다. 일반적인 가이드는 @의 TXT 값 하나에 모든 발신자를 넣으라고 합니다. 깔끔해 보이지만, 루트 도메인이 뉴스레터, 고객 지원 시스템, 앱 알림, 영업 메일 도구, 직원 사서함이 공유하는 기반이 됩니다. 공급업체 하나가 include 체인을 늘리면 같은 SPF 도메인을 쓰는 모든 발송 흐름이 영향을 받을 수 있습니다.

취약한 방식: 회사에서 사용했던 모든 도구를 루트 SPF 레코드 하나로 허용하려는 설정.

Google의 발신자 지침도 올바른 인증과 도메인 정렬을 강조하며, 특히 대량 메일에서 중요합니다. SPF는 전체 인증의 일부이지만, 잘못된 SPF가 가장 먼저 드러나는 문제인 경우가 많습니다.

실제 제약: DNS 의존 항목 10개의 평가 예산

핵심 규칙은 SPF 레코드를 작성할 때 DNS 의존 항목 10개의 고정 평가 예산을 사용한다는 것입니다. 이 예산은 재귀적으로 적용됩니다. include 안에서 DNS 조회를 유발하는 항목이 더 평가되면 그 항목도 계산에 들어갑니다. DNS 제공업체를 바꾼다고 잘못 계산한 SPF 예산이 해결되지는 않습니다.

예산에 포함되는 항목:

• include
• a
• mx
• ptr (사용하지 않는 것이 좋습니다)
• exists
• redirect

예산에 포함되지 않는 항목:

• ip4
• ip6
• all

유효한 결과가 없는 DNS 조회인 void lookup도 주의해야 합니다. RFC 7208은 이를 두 번으로 제한하도록 권고합니다. include 대상의 오타 하나가 이 허용량 일부를 소모할 수 있습니다. 권고 한도에 도달하는 것 자체가 아니라 이를 초과하면, SPF 평가가 또 다른 PermError로 끝날 수 있습니다.

네다섯 개 공급업체를 통해 발송하는 도메인이라면 평가 예산을 꼼꼼하게 확인할 필요가 있습니다. 공급업체 수만으로 한도 초과가 결정되지는 않습니다. 실제 include 체인과 설계가 중요합니다.

발송 흐름을 분리해 SPF 레코드 만들기

견고한 SPF 설정을 만들려면 직원 간 업무 메일을 대량 메일 및 앱 메일과 분리하세요. 기본 사서함 제공업체는 루트 도메인에 두고, 마케팅, 고객 지원, 앱 발신자는 실제 MAIL FROM 또는 return-path에 적절한 하위 도메인을 사용하도록 설정합니다. 그러면 발송 흐름마다 SPF 예산이 분리되어 한 공급업체의 문제가 다른 흐름에 미칠 영향을 줄일 수 있습니다. 화면에 보이는 From 주소만 바꾸어서는 SPF가 분리되지 않습니다.

구조는 다음과 같습니다.

1. 루트 도메인 @는 일반 업무 메일에 사용합니다.
2. 뉴스레터, 고객 지원, 거래 알림 등 전문 발신자는 하위 도메인을 사용합니다.
3. 호스트 이름마다 SPF 레코드는 하나만 둡니다. 중복되거나 남아 있는 이전 SPF 레코드는 제거하되, 다른 TXT 레코드는 함께 둘 수 있습니다.

TrekMail 관리형 발송을 사용하는 루트 도메인 레코드 예시:

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

include 하나와 명확한 정책으로 구성되어 점검하기 쉽습니다. 그렇더라도 재귀 평가 비용과 필요한 발신자가 모두 포함되는지는 확인해야 합니다.

마케팅 하위 도메인 예시:

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

Mailchimp와 HubSpot이 실제 SPF 발송 도메인으로 marketing.example.com을 사용하도록 설정되어 있다면, 루트 도메인이 아닌 그 하위 도메인의 예산을 사용합니다. 이후 공급업체의 구조가 바뀌어도 example.com의 직원 사서함에 미치는 영향을 줄일 수 있습니다. 이 레코드는 설명용 예시입니다. 각 공급업체의 최신 공식 인증 지침과 사용자 지정 MAIL FROM 설정을 따르세요. DMARC에는 정렬된 SPF 또는 DKIM이 여전히 필요하며, 엄격 정렬과 완화 정렬은 하위 도메인을 다르게 취급합니다.

TrekMail도 이런 구조에 맞춰 사용할 수 있습니다. 도메인 설정 문서에서는 관리형 발송을 위한 기본 참조로 include:spf.trekmail.net을 안내합니다. DNS 검사기는 충돌을 찾는 데 도움이 될 수 있지만 모든 인증 검사를 대신하지는 않습니다. 사서함과 DNS를 설정 중이라면 TrekMail에 도메인 추가하기와 DNS 상태 확인하기를 참고하세요.

단계별 안내: 추측 없이 SPF 값 작성하기

유지 관리하기 쉬운 SPF 레코드를 만들려면 모든 발신자를 먼저 파악하고, 각각에 올바른 발송 도메인을 배정한 다음 TXT 레코드를 작성하세요. DNS부터 수정하지 말고, 각 발송 흐름의 책임과 용도를 먼저 정해야 합니다. 그래야 루트 도메인에 임의의 include가 쌓이지 않습니다.

다음 순서로 진행하세요.

1. 도메인 명의로 메일을 보내는 모든 서비스를 나열합니다.
2. 각 발신자를 업무, 거래, 고객 지원, 마케팅으로 분류합니다.
3. 발신자마다 실제 MAIL FROM에 사용할 호스트 이름을 정합니다.
4. 해당 호스트 이름의 모든 정상 발신자를 허용하는 최소한의 유효 SPF 정책을 사용합니다.
5. 호스트 이름마다 SPF TXT 레코드 하나를 게시합니다. 다른 TXT 레코드가 함께 있어도 됩니다.

그다음 각 공급업체가 실제 발송 도메인에 대해 안내하는 최신 설정에 따라 레코드를 작성합니다.

TrekMail 관리형 SMTP 예시:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Nano 요금제 또는 혼합 구성에서 TrekMail과 외부 SMTP를 함께 사용하는 설명용 예시:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

이 조합을 그대로 적용해야 한다는 뜻은 아닙니다. 실제 SMTP 제공업체만 해당 MAIL FROM 도메인에서 허용하고, 그 제공업체의 사용자 지정 MAIL FROM 지침을 따르세요. 원문이 설명하는 Nano 발송 모델에서는 외부 SMTP 제공업체가 필요하며, 그것만으로 TrekMail과 SES를 모두 허용해야 하는 것은 아닙니다. 원문에 제시된 유료 요금제는 월 $3.50부터 시작하고 관리형 SMTP를 포함합니다. Nano는 계속 무료로 제공되는 요금제로 소개되며, 유료 요금제의 무료 체험은 14일이고 신용카드가 필요하다고 설명합니다. 선택하기 전에 현재 제공 내용과 조건을 확인하세요. 설정은 외부 SMTP 사용하기(BYO)와 TrekMail 관리형 SMTP를 참고하세요.

레코드 게시 및 확인

SPF 값을 TXT 레코드로 게시한 뒤 공용 DNS 리졸버가 실제로 반환하는 값을 확인하세요. 등록업체 화면, 캐시된 대시보드, 한 공급업체 도구의 녹색 표시만 믿지 마세요. TXT 값을 조회해 유효한 SPF 레코드가 하나인지 확인합니다. 아래 명령은 보통 리졸버를 사용하며 캐시된 결과를 보여줄 수 있으므로, 권한 있는 네임서버를 직접 확인하거나 변경 사항이 정확한 시점에 모든 곳에 반영됨을 보장하지 않습니다.

Mac 또는 Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

v=spf1으로 시작하는 SPF 값이 하나 있어야 합니다. 중복 SPF 값이나 삼 년 전 이전 작업에서 남은 레코드가 있어서는 안 됩니다. SPF와 무관한 다른 TXT 레코드는 함께 있어도 정상입니다.

빠른 확인 항목:

• v=spf1으로 시작하는가
• 모든 정상 발신자를 파악하고 테스트한 뒤 -all로 끝나는가
• 실제로 사용하는 발신자만 포함하는가
• 호스트 이름마다 SPF 레코드가 하나뿐인가

다른 제공업체에서 이전할 때는 남아 있는 MX와 SPF 레코드가 혼란을 일으킬 수 있습니다. TrekMail의 DNS 문서도 이 문제를 다룹니다. 특히 단계적으로 이전한다면 어떤 레코드가 아직 필요한지 먼저 판단하세요. 전체 메일 플랫폼을 옮기는 경우 자체 도메인으로 이메일 만들기와 여러 도메인의 이메일 호스팅도 도움이 됩니다.

흔한 SPF 오류와 해결 방향

많은 SPF 문제는 DNS 의존 항목 과다, 여러 SPF 레코드, 잘못된 발송 도메인, include 오타에서 발생합니다. 발신자 구성이 명확하면 이런 원인을 찾기 쉽습니다. 즉흥적으로 설정하면 문제 해결에 많은 시간이 들 수 있습니다.

다음 두 가지 실무 원칙을 기억하세요.

1. 직접 관리하는 고정 발신 주소에는 ip4를 사용하세요. DNS 의존 항목 예산을 소모하지 않습니다.
2. 충분한 이유가 없다면 마케팅 플랫폼이 임원 메일과 같은 SPF 발송 도메인을 사용하게 하지 마세요.

Google의 발신자 문서는 실제 목표가 SPF 단독 통과가 아닌 인증과 정렬임을 설명합니다. SPF가 통과해도 화면에 보이는 From 도메인이 인증된 도메인과 적절히 정렬되지 않으면 정책 검사를 통과하지 못할 수 있습니다. DMARC는 정렬된 SPF 또는 DKIM으로 통과할 수 있으며, 하위 도메인의 정렬 여부는 엄격 모드와 완화 모드에 따라 달라집니다. 대량 메일 배달 문제를 해결한다면 Google 이메일 발신자 가이드라인 FAQ를 읽어 보세요.

TrekMail이 관리를 단순하게 만드는 경우

TrekMail은 여러 도메인에서 SPF 구성을 일정하게 유지하려는 경우 도움이 될 수 있습니다. 원문이 소개하는 장점은 운영 측면에 있습니다. 관리형 발송의 중앙 include, 공유 저장 공간, 사용자별 과금이 없는 모델, 내장 IMAP 이전 기능, 요금제와 발송 모델에 따른 외부 SMTP 또는 관리형 SMTP 선택입니다. 현재 기능과 조건을 확인하세요. include 하나라는 사실만으로 재귀 평가 비용이 작다고 보장되지는 않습니다.

개인 창업자에게는 단순한 관리가 장점입니다. 루트 도메인의 업무 메일을 분리하고 TrekMail을 사서함 호스팅에 사용하며, 현재 조건에 맞는 사용자별 과금 없는 요금제를 선택할 수 있습니다. 팀에는 일관된 온보딩과 DNS 실수 감소가 도움이 될 수 있습니다. 대행사와 MSP에는 수십 또는 수백 개 도메인에서 전체 메일 구조를 매번 다시 만들지 않고 재사용할 수 있는 설계가 중요합니다.

고객마다 서로 다른 취약한 SPF 구성을 만드는 대신, 반복 가능한 구조와 하나의 대시보드, 검증된 루트 include를 운영하는 방식입니다. 더 나은 TXT 문자열만이 아니라 더 나은 관리 모델입니다. 다만 정기적인 점검은 계속 필요합니다.

원문에 소개된 Nano 제공 내용은 도메인 10개, 공유 저장 공간 5GB, 외부 SMTP이며 신용카드 없이 시작할 수 있다고 설명합니다. 관리형 발송과 더 높은 한도가 필요하다면, 원문은 TrekMail 유료 요금제가 월 $3.50부터 시작하고 신용카드가 필요한 14일 무료 체험을 제공한다고 안내합니다. 현재 요금제, 한도 및 조건은 TrekMail 가격 안내에서 확인하세요.

결론: 유지 관리 부담이 적은 SPF 구조 만들기

오래 사용할 SPF 설정을 만들려면 루트 도메인의 거대한 허용 목록이 아니라 전체 구조를 생각하세요. 일반 업무 메일은 루트 도메인에, 전문 발신자는 실제 MAIL FROM 하위 도메인에 배치합니다. 필요한 include만 최소한으로 사용하고, 모든 정상 발송 흐름을 확인한 뒤 명시적인 -all을 적용합니다. 게시 후에는 캐시, TTL과 DMARC 정렬을 고려하며 DNS 결과를 확인하세요.

이 접근법은 평가 한도를 관리하고 예상치 못한 문제를 줄이며 공급업체 변경을 더 쉽게 다루는 데 도움이 됩니다. SPF 유지 관리가 영원히 필요 없어지는 것은 아닙니다. 메일 시스템을 다시 구성하고 있다면 TrekMail을 살펴보고 성장 방향과 현재 발송 요구에 맞는 모델을 선택하세요.