Gmail SPF 레코드: 2026년 단계별 가이드

Gmail에서 고객 업데이트, 채용 이메일 또는 영업 시퀀스를 발송합니다. 문구는 탄탄하고, 수신자 목록도 깔끔합니다. 그런데 답장이 오지 않거나, 더 나쁜 경우 누군가로부터 메시지가 스팸으로 분류되었다는 이야기를 듣게 됩니다.

소규모 팀에서는 보통 제목 줄, 템플릿, 발송량을 먼저 확인합니다. 일리 있는 접근입니다. 하지만 가장 흔한 원인 중 하나는 Gmail 외부, 즉 DNS 설정에 있습니다. SPF 레코드는 수신 메일 서버가 Gmail을 귀하 도메인의 승인된 발신자로 취급할지 여부를 결정합니다.

Gmail 기반의 아웃리치 도구를 조사 중이라면 이 문제는 더욱 중요합니다. 일반적인 명칭처럼 들리는 제품명, 특히 Mail Merge for Gmail을 사용할 때는 주의하세요. 이 문구는 특정 제품뿐만 아니라 카테고리를 설명하기도 하므로, 다른 메일 머지 도구를 위한 설정 조언을 잘못된 시스템에 적용하기 쉽습니다.

Gmail SPF 레코드가 중요한 이유

SPF를 도메인을 위한 ‘게스트 리스트’라고 생각하면 이해하기 쉽습니다. 이메일이 다른 메일 서버에 도달하면, 해당 서버는 발신자가 리스트에 있는지 확인합니다. Gmail이 리스트에 있다면 메시지가 합법적인 것으로 취급될 확률이 훨씬 높아집니다. Gmail이 없다면 수신자는 수신자가 제목을 읽기도 전에 메시지를 불신할 이유를 갖게 됩니다.

이러한 신뢰 문제는 일반적인 비즈니스 상황에서 나타납니다. 창업자가 온보딩 이메일을 보내고, 인사 담당자가 면접 초대장을 보내고, 학교가 학부모에게 행사 업데이트를 보냅니다. Gmail 내부에서는 모든 것이 정상으로 보이지만, 수신 서버는 귀하의 도메인에 대한 명확한 승인을 확인하지 못하고 해당 메시지를 더 조심스럽게 처리하기 시작합니다.

SPF가 보호하는 것

SPF는 두 가지 역할을 동시에 수행합니다.

• 전송 보호: 수신 서버가 Google이 귀하의 도메인을 대신하여 메일을 보낼 수 있음을 인식하도록 돕습니다.
• 브랜드 보호: 다른 사람이 발신 이메일에서 귀하의 도메인을 사칭하기 어렵게 만듭니다.

SPF는 외부 세계에 귀하의 도메인을 대변하는 발신 시스템이 무엇인지, 그렇지 않은 것이 무엇인지 알려줍니다.

이메일 마케팅 성공률을 높이려는 경우, 이는 가장 먼저 수행해야 할 기술적 점검 중 하나입니다. 더 나은 문구도 제대로 인증되지 않은 도메인을 보완할 수는 없습니다.

작은 실수가 큰 고통을 초래하는 이유

좌절스러운 점은 SPF 문제가 종종 SPF 문제처럼 보이지 않는다는 것입니다. 메시지는 여전히 전송될 수 있습니다. 일부 수신자는 메시지를 잘 받을 수도 있습니다. 다른 수신자는 스팸 분류, 경고 또는 침묵 필터링을 경험할 수 있습니다. 이러한 불일치가 사람들을 혼란스럽게 만듭니다.

이메일이 이미 정크 메일함으로 흘러 들어가고 있다면, 이 설정 가이드와 함께 이메일이 스팸으로 분류되는 것을 방지하는 방법에 대한 실용적인 가이드를 함께 확인하는 것이 좋습니다. SPF가 전송 성공의 전부는 아니지만, 콘텐츠를 수정하며 요행을 바라는 대신 도메인 수준에서 직접적으로 신뢰도를 높일 수 있는 몇 안 되는 해결책 중 하나입니다.

핵심 Gmail SPF 레코드 생성하기

귀하의 도메인이 Gmail 또는 Google Workspace를 통해서만 이메일을 발송한다면 설정은 간단합니다. Google의 공식 SPF 레코드는 Google Workspace 관리자 고객센터에 문서화된 정확한 문자열입니다.

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

이 값은 도메인 루트에 단일 TXT 레코드로 게시되어야 합니다. 대부분의 DNS 대시보드에서 호스트는 @입니다. Google은 또한 **3600초(1시간)**의 TTL을 권장하며, 동일한 Google Workspace 문서에 따르면 DNS 변경 사항이 완전히 전파되는 데 제공업체에 따라 최대 48시간이 소요될 수 있습니다.

DNS에 입력할 내용

DNS가 GoDaddy, Cloudflare, Namecheap 또는 다른 제공업체에서 관리되든, 필드는 일반적으로 다음과 같이 매핑됩니다.

1. 유형: TXT
2. 호스트 또는 이름: @
3. 값 또는 콘텐츠: 위의 SPF 문자열
4. TTL: 제공업체에서 수동 설정이 가능한 경우 3600

여기서 가장 흔한 실수는 레코드 유형을 너무 복잡하게 생각하는 것입니다. 많은 DNS 패널이 더 이상 별도의 SPF 레코드 유형을 제공하지 않습니다. 이는 정상입니다. TXT 레코드를 선택하면 됩니다.

DNS 편집이 처음이라면 시각적인 가이드가 도움이 될 수 있습니다.

작동하는 것과 작동하지 않는 것

실용적인 버전은 다음과 같습니다.

• 작동함: 도메인 루트에 정확한 Gmail SPF 값이 포함된 TXT 레코드를 하나 추가하는 것.
• 작동하지 않음: 공백을 추가하거나, 값을 별도의 SPF 레코드로 분할하거나, 메일이 메인 도메인에서 발송되는데 서브도메인과 같은 잘못된 호스트 아래에 게시하는 것.

실용적인 규칙: SPF 값을 정확하게 복사하고, 한 번만 게시하며, 나중에 다른 발신자를 추가할 때 두 번째 SPF 레코드를 만들고 싶은 유혹을 참으세요.

단순한 Gmail 전용 환경이라면 이것으로 기본 Gmail SPF 레코드 설정은 충분합니다. 레코드를 저장하고 전파를 기다린 후, 다른 것을 변경하기 전에 확인하세요.

다중 이메일 발신자 및 메일 머지 처리

일반적인 소규모 비즈니스 설정은 다음과 같습니다. 직원은 Google Workspace에서 일반 메일을 보내고, 마케팅 팀은 메일 머지 도구로 캠페인을 운영하며, CRM이나 헬프 데스크는 동일한 도메인에서 자동화된 메시지를 보냅니다. SPF는 이 모든 것을 포함해야 하며, 그렇지 않으면 시스템 중 하나에서 인증 실패가 발생하기 시작합니다.

이것이 많은 Gmail SPF 설정이 실패하는 지점입니다. 기본 Google 레코드는 쉽습니다. 복잡성은 각 새로운 도구가 다른 include: 항목을 추가하도록 요청하고, 아무도 그 추가 사항이 전체 레코드에 어떤 영향을 미치는지 확인하지 않을 때 시작됩니다.

가장 중요한 두 가지 규칙

규칙 1: 도메인에 대해 하나의 SPF TXT 레코드만 게시하십시오.

규칙 2: 전체 SPF 평가를 10개의 DNS 조회 미만으로 유지하십시오. 이 제한에는 각 include: 내부의 중첩된 조회가 포함됩니다. 레코드가 DNS 패널에서는 짧아 보일 수 있지만, 한 공급업체의 SPF 레코드가 여러 개의 추가 확인으로 확장되기 때문에 실패할 수 있습니다. DMARC Report의 이 분석은 Gmail SPF 구성에서 조회 횟수가 중요한 이유를 설명합니다.

다중 발신자 환경은 예상보다 빠르게 이 제한에 도달합니다. Google Workspace에 메일 머지 발신자, CRM, 지원 플랫폼을 더하면 각 공급업체의 지침이 개별적으로는 기술적으로 정확하더라도 문제가 발생할 수 있습니다. 실수는 각 발신자를 하나의 통합된 승인 정책이 아닌 별도의 DNS 프로젝트로 취급하는 것입니다.

올바른 병합의 모습

Gmail과 다른 승인된 서비스가 모두 귀하의 도메인으로 메일을 보낸다면, 두 발신자를 동일한 SPF 레코드에 추가하세요.

시나리오	올바른 병합된 SPF 레코드
Gmail 전용	v=spf1 include:_spf.google.com ~all
Gmail + 타사 발신자 1개	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail + 여러 발신자	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

위 예시는 구조를 보여줍니다. 실제 타사 값은 각 제공업체의 문서에서 가져와야 합니다. 실용적인 핵심은 변하지 않습니다. 하나의 도메인에는 하나의 SPF 레코드가 필요합니다.

실제 상황에서 주로 발생하는 문제

저는 보통 세 가지 실패 패턴을 봅니다.

• 두 번째 SPF 레코드가 게시됨: 기존 레코드를 편집하는 대신 v=spf1로 시작하는 새로운 TXT 항목을 추가하는 경우입니다.
• 오래된 서비스가 계속 승인됨: 비즈니스에서 도구를 사용하지 않게 되었는데도 DNS에 include:가 남아 계속 조회를 소비하는 경우입니다.
• 메일 머지가 “그냥 Gmail”로 취급됨: 일부 도구는 Google의 인프라를 통해 보내지만, 다른 도구는 자체 서버나 연결된 제공업체를 통해 보냅니다. 그 차이에 따라 SPF에 다른 include가 필요한지 여부가 결정됩니다.

세 번째 지점은 자주 간과됩니다. 팀이 시트 기반 워크플로우를 사용한다면, DNS를 건드리기 전에 해당 도구가 메일을 어떻게 보내는지 확인하세요. Google 시트에서 메일 머지하는 방법에 대한 가이드가 워크플로우를 매핑하는 데 도움이 될 수 있지만, SPF는 여전히 해당 워크플로우 뒤의 발송 인프라에 따라 달라집니다.

10개 조회 제한을 유지하는 방법

발신자 인벤토리부터 시작하세요. 귀하의 도메인으로 메일을 보낼 수 있는 모든 시스템을 나열하세요. 마케팅 플랫폼, CRM, 지원 도구, 청구 앱, 웹사이트 양식 및 모든 메일 머지 제품을 포함하세요.

그런 다음 과감하게 줄이세요.

더 이상 사용하지 않는 발신자는 제거하세요. 두 도구가 동일한 제공업체를 통해 메일을 보내는지 확인하여 하나의 include를 불필요하게 만들 수 있는지 확인하세요. 공급업체가 하나 이상의 SPF 옵션을 제공하는 경우, 찾을 수 있는 모든 레코드를 붙여넣기보다는 귀하의 사용 사례에 대해 문서화된 옵션을 선택하세요.

레코드가 여전히 너무 크다면, 답은 두 번째 SPF 레코드가 아닙니다. 승인된 발송 경로의 수를 줄이거나, 경우에 따라 메인 도메인 SPF 레코드를 관리 가능한 상태로 유지하기 위해 별도의 메일 스트림에 서브도메인을 사용하는 것입니다.

새로운 발신자를 추가할 때는 DNS 변경 검토처럼 다루세요. 발신자가 여전히 필요한지 확인하고, 단일 SPF 레코드를 업데이트한 다음, 저장하기 전에 조회 횟수를 확인하세요.

SPF 레코드가 작동하는지 확인하는 방법

레코드를 저장했다고 해서 끝난 것이 아닙니다. 검증은 조용한 실수를 잡아내는 단계이며, 특히 DNS 패널이 항목을 수락했더라도 구문이나 조회 횟수가 여전히 잘못된 경우에 중요합니다.

먼저 유효성 검사기 사용하기

MxToolbox 또는 dmarcian SPF Surveyor와 같은 공개 SPF 검사기부터 시작하세요. 이 도구들은 단순히 TXT 레코드가 존재하는지 확인하는 것 이상을 수행하기 때문에 유용합니다. 구조를 검사하고, 더 고급 조회의 경우 귀하의 include가 너무 많은 DNS 조회를 생성하는지 확인하는 데 도움을 줍니다.

도메인 이름을 입력하고 결과를 주의 깊게 검토하세요. 다음 세 가지를 확인해야 합니다.

• 레코드 발견: 도구가 공개 DNS에서 귀하의 SPF TXT 레코드를 볼 수 있는지 확인.
• 구문 유효성: 잘못된 메커니즘, 불필요한 공백 또는 중복된 SPF 항목이 없는지 확인.
• 체인 관리 가능: include가 깨진 결과로 확장되지 않는지 확인.

좋은 결과란 무엇인가

건강한 검사는 보통 지루해 보이며, 그것이 바로 우리가 원하는 것입니다. 도구가 하나의 SPF 레코드를 찾고, 깔끔하게 구문을 분석하며, 영구적인 오류를 표시하지 않는 상태입니다.

실패한 결과는 보통 다음 범주 중 하나에 속합니다.

• SPF 레코드 없음: 레코드가 아직 전파되지 않았거나, 잘못된 호스트 아래에 저장되었거나, 게시되지 않은 경우.
• 여러 SPF 레코드 발견: 기존 레코드를 편집하는 대신 두 번째 v=spf1 TXT 레코드를 추가한 경우.
• 너무 많은 조회: 결합된 발신자 목록이 너무 크거나 너무 중첩된 경우.

실제 이메일도 확인하기

유효성 검사기는 구조를 확인하는 데 좋습니다. 실제 메시지는 동작을 확인합니다.

접근 가능한 Gmail 받은 편지함으로 테스트 이메일을 보내세요. 메시지를 열고 Gmail의 원본 메시지 보기 옵션을 사용하여 인증 결과를 검사하세요. SPF가 통과된다면 귀하의 공개 DNS와 실제 발송 경로가 정렬되었다는 강력한 신호입니다.

유효성 검사 도구는 DNS 레코드가 게시 가능한지 알려줍니다. 실제 테스트는 귀하의 실제 메일 흐름이 DNS 정책과 일치하는지 알려줍니다.

유효성 검사는 통과했지만 실제 메시지가 여전히 제대로 작동하지 않는다면, 문제는 SPF 단독이 아닌 인증 스택의 다른 곳에 있을 수 있습니다.

일반적인 SPF 레코드 오류 해결

SPF 문제는 보통 변경 직후에 명확해집니다. 소규모 비즈니스가 Google Workspace에서 제안서를 보내기 시작하고, 메일 머지 도구를 추가한 다음, 답장이 느려지거나 메시지가 스팸으로 분류되는 것을 알아차립니다. 실제로는 복잡한 메일 문제가 아니라 하나의 DNS 실수가 원인인 경우가 많습니다.

여러 SPF 레코드 발견

증상: 유효성 검사기가 여러 SPF 레코드를 보고하거나, 수신 서버가 영구적인 SPF 오류를 반환합니다.

원인: 귀하의 도메인에 v=spf1로 시작하는 TXT 레코드가 두 개 이상 있습니다. 저는 비즈니스가 CRM이나 아웃리치 플랫폼과 같은 두 번째 발신자를 추가하고, 새 공급업체의 설정 가이드를 그대로 따랐을 때 이런 현상을 봅니다. SPF는 해당 레코드를 병합하지 않습니다. 수신자는 충돌을 확인하고 이를 유효하지 않은 것으로 취급합니다.

해결책: 도메인에 대해 하나의 SPF 레코드를 유지하고, 모든 승인된 발신자를 해당 단일 TXT 항목에 통합하세요. 이미 별도의 레코드가 있다면 하나를 마스터로 선택하고, 필요한 메커니즘을 결합한 다음 나머지는 삭제하세요.

너무 많은 DNS 조회

증상: 레코드는 완전해 보이지만, SPF가 조회 제한 또는 영구 오류 결과로 실패합니다.

구조: SPF 확인은 제한된 수의 DNS 조회만 따를 수 있습니다. 이것이 기본적인 Gmail SPF 가이드에서 자주 건너뛰는 오류입니다. Google Workspace가 여러 발신자 중 하나일 뿐인 실제 환경, 특히 메일 머지 소프트웨어, 헬프 데스크, 청구 시스템 및 마케팅 플랫폼을 동일한 도메인에서 사용하는 경우에 나타납니다. 각 include:는 그 아래에 더 많은 include를 끌어올 수 있으므로, 짧아 보이는 레코드라도 제한을 초과할 수 있습니다.

해결책: 영리한 방법을 시도하기 전에 발신자 목록을 정리하세요. 더 이상 귀하의 도메인으로 메일을 보내지 않는 서비스는 제거하세요. 각 공급업체에 귀하의 사용 사례에 대해 게시된 모든 include가 필요한지 문의하세요. 스택이 여전히 너무 크다면, 메일 스트림을 서브도메인별로 분할하세요. 예를 들어, 일반 직원 이메일은 메인 도메인에 유지하고 아웃리치나 대량 메일은 자체 SPF 정책을 가진 서브도메인으로 옮기세요. 이 접근 방식은 조회 압력을 줄이고 하나의 비대해진 레코드가 다른 모든 것을 망가뜨리는 것을 방지하기 때문에 다중 발신자 설정에서 가장 깔끔한 해결책인 경우가 많습니다.

구문 문제 및 레코드 누락

증상: DNS에 레코드는 존재하지만, 유효성 검사기가 형식 오류를 표시하거나 SPF 레코드를 전혀 찾지 못합니다.

원인: 이는 보통 잘못된 붙여넣기, 잘못된 호스트 값 또는 잘못된 필드에 SPF 문자열을 게시함으로써 발생합니다. cPanel, GoDaddy, Cloudflare 및 Google Domains 대체 서비스에서 레이블은 초보 관리자를 혼란스럽게 할 만큼 충분히 다릅니다. 루트 도메인을 위한 레코드가 www 아래에 입력되거나, TXT 값이 잘못 분할될 수 있습니다.

해결책: 게시된 TXT 값을 의도한 레코드와 문자 단위로 비교하세요. 인증하려는 도메인에 대해 호스트가 올바른지 확인하고, 다른 레코드 유형이 아닌 TXT 레코드를 생성했는지 확인하세요. 구문은 괜찮은데 메일이 여전히 실패한다면, SPF 레코드는 유효하지만 다른 인증 제어가 문제를 일으키고 있을 수 있으므로 사용자 지정 도메인에 대한 이메일 인증 설정을 더 넓게 검토하세요.

실용적인 문제 해결 순서

SPF가 실패할 때 이 순서를 사용하세요.

1. 중복 SPF 레코드 확인: 가장 빠르고 쉽게 확인하고 수정할 수 있는 문제입니다.
2. 레코드 텍스트 면밀히 검토: 오타, 누락된 공백, 추가 따옴표 또는 잘못된 호스트를 찾으세요.
3. 모든 발송 서비스 매핑: Google Workspace, 메일 머지 도구, CRM, 지원 플랫폼 및 귀하의 도메인으로 메일을 보내는 모든 것을 포함하세요.
4. 조회수가 많은 include 계산: 목록이 복잡하다면 단순화하거나 일부 발신자를 서브도메인으로 옮기세요.

이 순서는 현장에서 SPF가 실패하는 방식과 일치하기 때문에 시간을 절약해 줍니다. 소규모 팀은 종종 가장 최근에 추가한 도구가 문제를 일으켰다고 가정하지만, 오래된 DNS 정리 상태도 그만큼 흔한 원인입니다. 정리하는 동안 더 광범위한 운영 체크리스트가 필요하다면 Simply Tech Today의 이메일 보안 가이드가 유용한 참고 자료가 될 것입니다.

SPF를 넘어선 이메일 인증의 다음 단계

소규모 비즈니스는 올바른 SPF 레코드를 게시하고도 송장, 아웃리치, 후속 조치가 다른 시스템에서 발송되기 시작하면 메시지가 스팸으로 분류되는 것을 지켜볼 수 있습니다. 이는 보통 혼합 설정에서 발생하며, 특히 Google Workspace가 일상적인 메일을 처리하고 다른 도구가 동일한 도메인에서 캠페인이나 메일 머지를 보낼 때 발생합니다.

SPF는 수신 메일 서버가 내리는 결정의 일부만 다룹니다. 발신 서버가 귀하의 도메인을 사용할 권한이 있는지 확인합니다. 이는 중요하지만, 메시지가 올바르게 서명되었음을 증명하거나 인증 실패 시 수신 서버에 무엇을 해야 할지 알려주지는 않습니다.

이것이 DKIM과 DMARC가 필요한 이유이며, 다중 발신자 환경에서는 더욱 중요합니다.

DKIM은 메시지에 암호화 서명을 추가하여 수신 서버가 메시지가 합법적이며 시스템을 떠난 후 변경되지 않았음을 확인할 수 있도록 합니다. DMARC는 SPF와 DKIM 위에 위치하여 메일함 제공업체에 귀하의 도메인에 대해 이러한 확인을 어떻게 평가할지 알려줍니다. 또한 보고 기능을 제공하는데, 이는 종종 귀하의 도메인을 사용하고 있다는 사실을 잊고 있었던 발신자를 확인하는 첫 번째 명확한 방법이 됩니다.

이 지점이 많은 기본 SPF 가이드가 놓치는 부분입니다. Google Workspace, 메일 머지 도구, CRM 및 지원 플랫폼을 사용하는 경우, 10개 조회 제한 때문에 SPF를 유지 관리하기 어려울 수 있습니다. DKIM은 SPF에만 의존해야 하는 부담을 줄여주며, DMARC는 정책 계층을 제공하여 귀하의 도메인이 하나의 복잡한 TXT 레코드만으로 판단되지 않도록 합니다.

SPF 이후의 다음 기술적 단계를 위해 사용자 지정 도메인에 대한 이메일 인증 가이드를 검토하세요. SPF 레코드가 제자리에 배치된 후 DKIM 및 DMARC를 위한 실용적인 설정 경로를 제공합니다.

더 광범위한 운영 체크리스트를 원하신다면 Simply Tech Today의 이메일 보안 가이드를 함께 읽어보시는 것이 좋습니다.

실용적인 결론은 간단합니다. SPF는 권한을 설정합니다. DKIM은 메시지 무결성을 증명합니다. DMARC는 제어, 가시성 및 하나 이상의 시스템에서 메일을 보내는 도메인을 관리하는 더 안전한 방법을 제공합니다.