2026년 GoDaddy SPF 레코드 설정 가이드

GoDaddy에 레코드를 등록하고 마지막 캠페인을 발송했는데도, Gmail은 여전히 발송 메일의 절반을 낯선 사람이 보낸 것처럼 취급하고 있습니다. 그 후 누군가 CRM, 뉴스레터 도구, 트랜잭션 플랫폼을 추가하면 전체 설정이 마치 엉킨 전선 더미처럼 작동하기 시작합니다. 보통 이 지점이 바로 GoDaddy SPF 레코드가 단순히 체크리스트 항목에서 벗어나 이메일 도달률을 유지하는 핵심 요소로 변하는 순간입니다.

골치 아픈 점은 SPF 실패가 명확하게 드러나는 경우가 드물다는 것입니다. 발신자가 추가되고 DNS가 한 번 수정된 뒤, 몇 주가 지나서야 팀은 스팸 분류, 인증 오류를 발견하거나 특정 플랫폼은 잘 작동하는데 다른 플랫폼은 목록에서 누락되는 현상을 겪게 됩니다. 만약 이 상황이 익숙하다면, 단순히 “이메일 문제”가 아니라 DNS 소유권, 레코드 구조, 그리고 10개 조회(10 lookup) 제한과 관련된 문제를 겪고 있는 것입니다.

GoDaddy SPF 레코드가 생각보다 중요한 이유

SPF는 개념은 간단하지만 실제 적용은 매우 까다롭습니다. 수신 서버는 DNS에 게시된 도메인의 정책을 확인한 다음, 해당 발신 서버가 해당 도메인을 대신하여 메일을 보낼 권한이 있는지 묻습니다. 답변이 일치하지 않으면 발신자가 합법적이라 하더라도 메시지가 승인되지 않은 것으로 간주될 수 있습니다.

이것이 바로 잘못된 GoDaddy SPF 레코드가 생각보다 큰 피해를 주는 이유입니다. Microsoft 365와 Google Workspace 모두 메일함 제공업체가 백그라운드에서 평가하는 인증 신호에 의존하기 때문에, SPF 레코드가 누락되거나 형식이 잘못되면 눈에 띄는 실패가 나타나기 훨씬 전부터 수신함 도달률에 영향을 줄 수 있습니다. 여기서 hardfail과 softfail의 차이는 중요합니다. 마지막 한정자(qualifier)가 수신자에게 승인되지 않은 메일을 즉시 거부할지 아니면 의심스러운 것으로 처리할지 알려주기 때문입니다.

대부분의 팀이 놓치는 부분

SPF는 단순히 “이 도메인이 당신의 것인가”를 묻는 것이 아닙니다. “이 발신자가 DNS에 게시된 승인 목록에 있는가”를 묻는 것입니다. 나중에 DMARC가 표시되는 From 도메인과 인증된 소스가 일치하는지 확인하기 때문에, 여기서 **SPF 정렬(alignment)**이 중요해집니다.

실무 규칙: 원래 SPF 레코드를 만든 후 스택에 발신자가 추가되었다면, DNS 레코드도 함께 수정되지 않는 한 해당 발신자가 문제의 원인이 되었을 가능성이 높습니다.

GoDaddy의 자체 가이드는 SPF를 별도의 SPF 타입 레코드가 아닌 TXT 레코드로 게시하고, 도메인 포트폴리오 내에서 DNS 편집을 수행하는 현대적인 접근 방식을 반영하고 있습니다. 이 설정은 평범해 보이지만, 바로 그 때문에 SPF가 자주 깨집니다. 레코드는 한 번 추가하기는 쉽지만, 다음 도구가 승인된 후에는 잊어버리기 쉽기 때문입니다.

GoDaddy DNS에 첫 SPF 레코드 추가하기

**도메인 포트폴리오(Domain Portfolio)**에서 시작하여 DNS를 열고 TXT 타입으로 레코드를 추가하세요. GoDaddy의 도움말은 SPF 설정에 대해 이 경로를 보여줍니다. 정책이 전체 도메인에 적용될 때는 호스트를 루트로 설정하고 값(Value) 필드에 SPF 정책을 입력하며, 관련 메일 레코드에 대한 문서화된 예시에서는 TTL을 **기본값(Default)**으로 유지합니다 GoDaddy의 SPF 레코드 도움말 이메일 인증을 위한 GoDaddy DNS 레코드 필드.

중요한 필드

**유형(Type)**은 SPF가 아니라 TXT여야 합니다. GoDaddy의 문서에서 TXT를 사용하는 이유는 이것이 현대 DNS에서 SPF를 위한 표준 게시 형식이며, 이 선택이 검증기 간의 모호함을 방지하기 때문입니다.

**이름(Name)**은 루트 도메인 정책의 경우 보통 **@**여야 합니다. 이는 GoDaddy에게 해당 레코드가 하위 도메인이 아닌 도메인 최상단에 속함을 알려줍니다. **값(Value)**은 SPF 문자열이 들어가는 곳이므로 여기에 정책 자체를 붙여넣습니다.

문제 해결 중이 아니라면 GoDaddy의 문서화된 설정을 따를 때 TTL은 **기본값(Default)**으로 유지해도 됩니다. 정확한 필드 이름은 간과하기 쉽지만, 도메인 루트에 위치하는 레코드와 쓸모없는 곳에 위치하는 레코드의 차이를 만듭니다.

GoDaddy에서 관리하는 간단한 메일 예시는 v=spf1 include:secureserver.net -all과 같으며, 이는 GoDaddy가 호스팅 이메일을 위해 보여주는 형식입니다. 단 하나의 발신 소스만 승인하는 경우, 하나의 레코드, 하나의 정책, 한 곳에서 관리하는 이 형식을 원할 것입니다.

Gmail 전용 변형의 경우, Gmail 사용자를 위한 이 SPF 가이드에서 동일한 TXT 우선 논리를 실제로 보여줍니다.

레코드 유형을 TXT가 아닌 다른 것으로 입력하거나, 정책이 루트에 위치해야 할 때 호스트를 비워두면 UI상에는 레코드가 존재하는 것처럼 보여도 DNS 계층에서는 실패할 수 있습니다.

프로세스 후반부에는 GoDaddy 자체 인터페이스보다 권한 있는 DNS 영역이 더 중요해지지만, 첫 번째 성공은 올바른 호스트에서 올바른 유형으로 올바른 필드에 레코드를 입력하는 것입니다.

사용하는 발신자를 위한 SPF 구문

많은 조직이 하나의 발신자만 운영하지 않습니다. 기본 메일함, 마케팅 플랫폼, CRM, 트랜잭션 시스템을 함께 운영합니다. SPF 레코드는 이 모든 것을 승인하는 단일 문장이므로, 실제 작업은 올바른 메커니즘을 선택하고 GoDaddy DNS가 문제를 일으키기 전에 검증할 수 있을 만큼 목록을 짧게 유지하는 것입니다.

일반적인 발신자 스택을 위한 복사 가능한 SPF 문자열

발신자 설정	SPF 값	사용된 조회 수
Google Workspace	v=spf1 include:_spf.google.com -all	include 1개, 최종 정책 확인
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	include 1개, 최종 정책 확인
Google Workspace 및 마케팅 도구	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	include 2개, 포함된 레코드 내의 중첩 조회 포함
Microsoft 365 및 트랜잭션 발신자	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	include 2개, 포함된 레코드 내의 중첩 조회 포함

이 문자열들은 패턴을 보여주기 때문에 유용합니다. 하나의 레코드, 하나의 정책, GoDaddy에서 제어할 수 있는 한 곳입니다. 스택이 Google Workspace나 Microsoft 365로 시작하여 마케팅 및 트랜잭션 메일로 확장된다면, 레코드는 더 이상 구문의 문제가 아니라 각 제공업체가 백그라운드에서 얼마나 많은 DNS 조회를 소비하는지의 문제가 됩니다.

메커니즘의 역할

include는 다른 도메인의 SPF 정책을 확인하고 해당 승인 권한을 상속받으라는 의미입니다. 이는 Google Workspace, Microsoft 365, Mailchimp, SendGrid 및 유사 플랫폼의 핵심 작업 방식입니다.

ip4는 고정 발신 주소를 위한 것으로, 소스 IP를 직접 제어하고 다른 제공업체의 정책 체인에 의존하고 싶지 않을 때 도움이 됩니다. 끝에 있는 all은 아직 승인되지 않은 모든 것에 대한 규칙을 설정하며, 한정자는 실패를 얼마나 엄격하게 처리할지 결정합니다.

실무 규칙: 발신자 목록이 안정적일 때는 더 엄격한 종료 한정자를 사용하고, 스택을 정리하는 동안에만 더 느슨한 한정자를 사용하세요.

발신자 계획에 대한 유용한 외부 관점은 소규모 비즈니스 이메일 캠페인을 위한 조언에서 찾을 수 있습니다. 캠페인 팀은 종종 DNS에 미치는 영향을 확인하지 않고 도구를 추가하기 때문입니다.

실제 GoDaddy 설정에서 문제가 되는 부분은 조회 예산입니다. 추가적인 include는 모두 예산을 소비하며, 레코드는 깔끔해 보여도 체인이 너무 깊어지면 실패할 수 있습니다. 운영 중인 스택에 맞춰 구문을 구성하세요.

조회 제한을 초과하지 않고 여러 발신자 병합하기

GoDaddy SPF 레코드의 가장 큰 실패 원인은 구문이 아니라 누적입니다. 도메인이 하나의 발신자로 시작했다가 마케팅 팀이 하나를 더 추가하고, 영업 팀이 CRM을 추가하고, 운영 팀이 트랜잭션 플랫폼을 추가하면, 아무도 SPF가 표준에서 허용하는 것보다 더 많은 시스템을 검증하려고 시도하고 있다는 사실을 알아차리지 못합니다.

규칙은 단호하며 타협하지 않습니다. 같은 이름으로 두 개 이상의 SPF 레코드를 게시하지 마세요. 동일한 도메인에 두 개의 SPF TXT 레코드가 존재하면 수신자는 결과를 유효하지 않거나 모호한 것으로 처리할 수 있으며, 이는 도움이 된다고 생각했던 레코드가 인증을 깨뜨리는 원인이 될 수 있음을 의미합니다.

병합 프로세스 작동 방식

먼저 모든 합법적인 발신자를 나열하세요. 그런 다음 제공업체가 자체 발신 인프라를 관리하는 경우 include 문을 사용하여 하나의 TXT 정책으로 통합하세요. GoDaddy에 이미 레코드가 있다면 두 번째 복사본을 만드는 대신 기존 레코드를 수정하세요.

두 번째 함정은 중첩입니다. 하나의 include는 제공업체의 자체 SPF 정책 내에 여러 개의 조회를 숨길 수 있으며, 이것이 바로 도메인이 팀의 예상보다 빠르게 예산을 소진하는 이유입니다. GoDaddy 중심 가이드는 사용자에게 10개의 DNS 메커니즘 조회 제한을 지킬 것을 경고하며, 이 제한은 사후가 아닌 평가 중에 적용됩니다 GoDaddy 도메인을 위한 SPF 설정 모범 사례 GoDaddy 도메인을 위한 2026년 SPF 가이드.

더 깔끔한 운영 모델

• 모든 발신자를 먼저 감사하세요: 더 이상 메일을 보내지 않는 오래된 도구는 제거하세요. 사용하지 않는 include도 예산을 소비하기 때문입니다.
• 하나의 정책으로 통합하세요: 모든 승인 권한을 올바른 이름의 단일 TXT 레코드에 유지하세요.
• 저장하기 전에 조회 수를 검증하세요: 깔끔해 보이는 레코드라도 중첩된 include가 제한을 초과하면 실패할 수 있습니다.

Mail Merge for Gmail은 이 논리에 완벽하게 부합합니다. Google의 인증된 인프라를 통해 발송되므로 별도의 SPF include가 필요하지 않으며, 이미 Google Workspace를 승인하고 있다면 SPF 예산을 추가로 소비하지 않습니다.

이것이 매우 중요한 이유는 간단합니다. 팀은 몇 달 동안 제한 내에 머물 수 있지만, 새로운 벤더 하나가 레코드를 한계치 너머로 밀어내면 GoDaddy UI에 명백한 DNS 오류가 없어도 SPF가 실패하기 시작합니다.

레코드가 실제로 작동하는지 검증하기

GoDaddy에 레코드를 저장하는 것은 증거가 되지 않습니다. 이는 변경 사항이 입력되었다는 의미일 뿐, 권한 있는 영역이 이를 제공하고 있다는 의미도, 캐시가 업데이트되었다는 의미도, 정책이 깔끔하게 파싱된다는 의미도 아닙니다.

세 가지 확인, 세 가지 다른 답변

첫 번째 확인은 라이브 영역에 대한 DNS 조회입니다. dig 또는 nslookup 쿼리는 권한 있는 네임서버가 무엇을 반환하는지 알려줍니다. GoDaddy 인터페이스는 전파가 완료되기 전에도 값을 보여줄 수 있고, 다른 DNS 호스트가 영역을 소유하고 있는지 알려주지 않기 때문에 중요합니다.

두 번째 확인은 MXToolbox의 SPF 검사와 같은 SPF 파서를 사용하는 것입니다. 이러한 도구는 구문을 읽는 동시에 조회를 계산하므로 중첩된 include와 제한 초과 체인이 나타나는 지점을 정확히 파악하는 데 유용합니다.

세 번째 확인은 메시지 수준의 증거입니다. Gmail로 테스트 메일을 보내고 원본 메시지를 열어 헤더를 검사하세요. Authentication-Results 줄에는 일반적으로 발신 도메인에 대해 SPF가 통과했는지 실패했는지 표시되며, 이는 DNS가 말하는 내용뿐만 아니라 메일함 제공업체가 메시지를 어떻게 평가했는지 알려줍니다.

실무 규칙: DNS는 올바른데 헤더가 여전히 실패한다면, 문제는 보통 GoDaddy UI가 아니라 검증 계층에 있습니다.

팀이 무시하기 쉬운 전파 현실도 있습니다. GoDaddy의 TTL 동작은 보통 빠르지만, 예외적인 DNS 변경 사항은 리졸버 전반에 걸쳐 적용되는 데 시간이 걸릴 수 있습니다. 레코드를 제공업체 간에 이동하는 경우 먼저 권한 있는 네임서버를 확인한 다음, 사용 중인 제어판이 아니라 실제 영역에 대해 검증하세요. 메시지를 끝까지 추적하려면 이 이메일 추적 가이드가 더 깔끔한 동반 자료가 될 것입니다.

SPF 통과에서 전체 이메일 인증으로

SPF 통과는 안심이 되지만 전체 문제를 해결하지는 못합니다. SPF는 발신 소스만 승인할 뿐 메시지에 서명하지 않으며, 메시지가 발신자를 떠난 후 변경되는 것을 막지 못합니다. 이것이 SPF만으로는 여전히 전달(forwarding) 예외 사례와 사칭 구멍을 남길 수 있는 이유입니다.

DKIM과 DMARC의 역할

DKIM은 메시지 자체에 암호화 서명을 추가합니다. GoDaddy 관리 DNS에서 이는 일반적으로 셀렉터 호스트 아래의 TXT 레코드를 의미하며, Google Workspace는 일반적으로 해당 설정의 일부로 google._domainkey를 사용합니다.

DMARC는 SPF와 DKIM 위에 위치합니다. 인증이 실패할 때 수행할 작업과 보고서를 보낼 위치를 수신 시스템에 알려주며, 보통 도메인의 _dmarc에 있는 TXT 레코드를 통해 이루어집니다. DMARC가 없으면 SPF나 DKIM이 일치하지 않을 때 메일함 제공업체가 따라야 할 공유 정책이 없습니다.

핵심은 SPF가 신뢰의 한 계층일 뿐이라는 것입니다. DKIM이 제자리에 있지 않으면 위조된 메시지가 여전히 약한 정렬을 악용할 수 있으며, 전달된 메시지는 소스에서 SPF가 깨끗했더라도 원본 발송과는 다르게 작동할 수 있습니다.

실무적인 스택은 간단합니다. SPF는 발신자를 승인하고, DKIM은 메시지에 서명하며, DMARC는 두 가지가 일치하지 않을 때 수신자가 어떻게 행동해야 할지 알려줍니다. 모든 합법적인 발신자가 인증되고 있다는 것을 알기 전까지는 정책을 강화하고 싶지 않을 것이므로, 앞서 언급한 검증 섹션이 중요합니다.

전체 스택에 대한 자세한 내용은 이 이메일 인증 가이드에서 SPF, DKIM, DMARC를 하나의 워크플로우로 연결하는 방법을 확인하세요.

실제 메일 머지 캠페인 중 SPF를 깨끗하게 유지하기

메일 머지 캠페인은 DNS 작업에 빠르게 압박을 가합니다. 영업, 채용 또는 이벤트 팀은 어느 날 Gmail에서 깔끔한 시퀀스를 보냈다가 다음 주에 회신율이 떨어지면 콘텐츠를 탓할 수 있지만, 더 깊은 문제는 인증 드리프트(authentication drift)일 수 있습니다.

Mail Merge for Gmail은 Google의 인증된 인프라를 통해 발송되므로 자체 SPF include가 필요한 별도의 발신자를 만들지 않습니다. 더 큰 위험은 주변 스택이 변경되고 도메인 소유자가 다른 플랫폼을 추가하여, 메일함 제공업체가 더 이상 일관되게 보이지 않는 메시지 기록을 평가하기 시작하는 것입니다.

실제로 도움이 되는 캠페인 전 체크리스트

• 발신 Google 계정에 대해 SPF가 통과하는지 확인하세요: 무작위 별칭이 아니라 캠페인을 보낼 정확한 메일함을 테스트하세요.
• Google Workspace 관리자에서 DKIM이 활성화되어 있는지 확인하세요: SPF만으로는 전달되거나 재포장된 메일에 너무 취약합니다.
• DMARC가 보고 기능과 함께 최소 p=none으로 설정되어 있는지 확인하세요: 이는 정책을 강화하기 전에 가시성을 제공합니다.

SPF 결과가 녹색이라고 해서 캠페인을 시작해도 안전하다는 의미는 아닙니다. 단지 발신자가 그 순간의 현재 DNS 정책과 일치했다는 의미일 뿐입니다.

가장 좋은 습관은 SPF 레코드를 배관처럼 취급하는 것입니다. 캠페인 전에 확인하고, 새 발신자가 추가될 때 확인하고, 플랫폼이 발송 경로를 변경할 때 다시 확인하세요. 그것이 GoDaddy SPF 레코드가 노후화되어 도달률 문제를 일으키지 않도록 하는 방법입니다.

---

Mail Merge for Gmail은 팀이 Gmail에서 개인화된 캠페인을 보내면서 발송 경로를 Google Workspace에 묶어둘 수 있도록 도와줍니다. 이는 도메인 스택이 복잡해질 때 SPF를 더 쉽게 이해할 수 있게 해줍니다. 다음 아웃리치를 시작하기 전에 GoDaddy DNS 설정을 정리하고 있다면 Mail Merge for Gmail을 방문하여 SPF, DKIM, DMARC를 깨끗하게 유지하는 워크플로우에 어떻게 부합하는지 검토해 보세요.