Gmail 및 Google 워크스페이스에 대한 SPF 레코드 설정하기

현재 수많은 피싱 및 사기 이메일이 사용자의 받은 편지함으로 유입되어 데이터를 위험에 빠뜨리고 있습니다. Gmail 또는 비즈니스용 Gmail을 사용하는 동안 이메일 보안을 강화하기 위해 SPF 레코드 설정이 중요해졌습니다. 이메일 보안. 2024년에 Google은 업데이트된 발신자 요건 가이드라인을 발표하여 모든 발신자에게 이메일 인증을 의무화했습니다!

현재 상황을 간단히 요약하면 다음과 같습니다: 

• Google은 모든 이메일 발신자에게 SPF 또는 DKIM을 구현하도록 요구합니다. 
• Google은 대량 발신자에게 SPF 또는 DKIM 설정에 더해 최소 p=none의 DMARC 정책을 추가로 구현하도록 요구합니다.

Gmail SPF 레코드는 권한이 없는 사람이 Google Workspace 도메인에서 이메일을 보내지 못하도록 차단합니다. 이 레코드는 도메인에서 보낸 이메일이 고객의 받은 편지함에 도달하기 전에 체크포인트 역할을 합니다. Google Workspace SPF 레코드를 올바르게 구현하면 도메인에서 보낸 이메일이 스팸으로 표시될 가능성이 줄어듭니다.

따라서 Google Workspace용 SPF 레코드를 만들려면 제대로 찾아 오셨습니다. 이 도움말에서는 Google Workspace에 대한 SPF 레코드를 설정하는 방법과 적절한 구현이 필요한 이유를 설명합니다.

Gmail SPF 레코드 이해하기

SPF(발신자 정책 프레임워크) 레코드는 도메인을 대신하여 이메일을 보낼 수 있는 권한이 있는 메일 서버를 지정합니다. 이메일이 수신되면 수신 서버는 '보낸 사람' 주소에 있는 도메인의 SPF 레코드를 확인하여 이메일이 권한이 있는 서버에서 발송되었는지 확인합니다.

SPF 레코드는 도메인의 DNS에 TXT 레코드로 게시됩니다. 여기에는 도메인을 대신하여 이메일을 보낼 수 있도록 허용된 서버의 IP 주소 또는 호스트 이름 목록이 포함되어 있습니다. 이 레코드에는 여러 서버 및 타사 서비스가 포함될 수 있습니다.

권한이 없는 출처에서 이메일을 보낸 경우 수신 서버는 DNS TXT 레코드를 사용하여 도메인의 SPF 레코드를 확인합니다.

PowerDMARC로 SPF 기록을 간소화하세요!

Gmail SPF 레코드의 중요성

Google의 새로운 이메일 인증 규칙을 준수하지 않는 경우 이메일 인증 규칙 을 준수하지 않으면 문제가 발생할 수 있습니다! Google Workspace SPF 레코드를 구현하지 않을 경우 발생할 수 있는 상황은 다음과 같습니다:

1. 이메일이 스팸으로 표시될 수 있습니다. 
2. 도메인/IP 주소가 차단 목록에 추가될 수 있습니다. 
3. 이메일 스팸 불만 증가로 인해 도메인 평판이 타격을 입을 수 있습니다.

SPF의 메커니즘: 작동 원리

SPF 레코드는 다양한 태그를 포함한 한 줄의 일반 텍스트입니다. 태그에는 해당 값(주로 인증된 발신 소스의 IP 주소 및 도메인 이름)이 포함됩니다.

SPF 레코드가 도메인 공급업체에 TXT 레코드로 추가됩니다. 최대 255자까지만 가능합니다. TXT 레코드 파일의 크기는 512바이트 이하여야 합니다.

이메일이 전송되면 수신자의 메일 서버는 발신자 도메인의 SPF 레코드를 확인합니다. 이는 이메일을 보낸 메일 서버의 IP 주소가 SPF 레코드에 나열되어 있는지 확인하기 위해 수행됩니다.

확인 결과에 따라 수신 메일 서버는 다음 결과 중 하나를 할당합니다:

• 패스: 도메인에 대한 이메일을 보낼 수 있는 권한이 있는 IP 주소입니다.
• 실패: IP 주소가 인증되지 않아 이메일 스푸핑 가능성이 있습니다.
• 소프트 실패: IP 주소가 승인되지 않았지만 도메인 소유자가 이메일을 수락하되 의심스러운 것으로 표시해 달라고 요청하는 경우입니다.
• 중립: 도메인이 IP에 대한 인증 정보를 주장하지 않습니다.
• SPF 기록을 찾을 수 없습니다.

Google 워크스페이스에 SPF 레코드 설정하기: 단계별 가이드

설정하려면 다음과 같이 하세요. Google 워크스페이스에 대한 SPF 레코드.

1. 도메인 계정에 로그인합니다.

Google Workspace SPF 레코드를 추가하는 첫 번째 단계는 DNS 관리 콘솔에 로그인하는 것입니다. 도메인의 DNS 설정에 액세스할 수 있어야 합니다. 여기에서 DNS 레코드를 업데이트하여 Google Workspace용 SPF를 추가할 수 있습니다. 이 프로세스는 서비스 공급업체에 따라 다르며 DNS 공급업체마다 다를 수 있습니다.

DNS 관리 콘솔에서 이 옵션을 찾을 수 없는 경우 DNS 공급업체에 문의하여 DNS 설정을 찾으세요.

2. 구글 워크스페이스 SPF TXT 레코드 만들기

DNS 관리 콘솔에 로그인한 후 TXT 레코드 섹션으로 이동하여 다음 값을 사용하여 새 TXT 레코드를 추가합니다.

• 유형: TXT
• 호스트: (또는 하위 도메인에 SPF 레코드를 설정하는 경우 특정 하위 도메인)
• 가치: 구글 워크스페이스에서 이메일을 보내는 도메인의 경우, SPF 레코드 "v=spf1 포함: _spf.google.com ~all"를 사용해야 합니다. 추가 이메일 발신자를 사용하는 경우에는 다른 타사 이메일 공급업체를 포함한 모든 발신 소스를 포함하는 하나의 통합 SPF 레코드가 도메인에 있어야 합니다. 이 작업은 여러 개의 "포함:" 메커니즘을 사용하여 수행할 수 있습니다.
• TTL: 1시간 또는 3600초로 설정합니다.

3. 하위 도메인에 대한 Google 워크스페이스 SPF 레코드 설정

루트 도메인에 SPF 레코드를 추가한다고 해서 하위 도메인에 적용되는 것은 아닙니다. 하위 도메인에는 SPF 정책이 자동으로 상속되지 않기 때문입니다. 따라서 하위 도메인을 사용하는 경우에는 각 하위 도메인에서 Gmail에 대한 SPF 레코드를 별도로 설정해야 합니다. 그러나 도메인 공급업체에서 하위 도메인에 대한 SPF 설정을 직접 허용하는 경우에만 이 작업을 수행할 수 있습니다.

앞서 언급했듯이 하위 도메인에 SPF를 설정하는 단계는 비슷합니다. 일부 도메인 공급업체는 하위 도메인에 SPF를 직접 적용하는 것을 지원하지 않습니다. 이러한 경우에는 루트 도메인에 Gmail SPF 레코드를 만든 다음 나중에 호스트 설정을 "@" 대신 하위 도메인을 가리키도록 조정할 수 있습니다.

4. SPF 기록 저장

SPF 레코드를 생성한 후 변경 사항을 저장합니다. DNS 공급업체 측에서 변경 사항을 전파하는 데 걸리는 시간에 따라 레코드는 저장한 후 48시간 이내에 활성화되어야 합니다. 

Gmail의 SPF 기록 확인

설정 후 Gmail SPF 레코드를 확인하려면 도메인이 SPF로 제대로 인증되었는지 확인해야 합니다.

 인증은 다음 단계에 따라 수행할 수 있습니다.

● 당사의 SPF 조회 도구를 사용하여 Gmail SPF 레코드 설정을 즉시 확인할 수 있습니다.

구현한 SPF 레코드의 TXT 항목을 검토하여 상태가 유효한지 확인하세요.

이메일 전송에 사용하는 모든 승인된 IP 주소와 타사 공급업체가 기록에 포함되어 있는지 다시 확인하세요.

단일 도메인에 대해 여러 개의 SPF 레코드를 게시하지 않았는지 확인하세요. 이메일 마케팅에 Google Workspace 이외의 타사 공급업체를 추가로 사용하는 경우 아래 예와 같이 동일한 SPF 레코드에서 "포함" 메커니즘을 사용하여 해당 공급업체를 인증할 수 있습니다: 

v=spf1 include: _spf.google.com include:spf.thirdpartydomain1.com include:spf.thirdpartydomain2.com ~all

● 적절한 서식을 유지하세요.

SPF 레코드에서 불일치하는 부분이 발견되면 Gmail의 SPF 레코드를 업데이트하여 이러한 오류를 제거하고 설정을 다시 확인하세요. 

PowerDMARC로 DMARC 및 SPF 구현하기 

마지막으로 Gmail에 SPF 레코드를 구현하면 Google의 요구 사항을 성공적으로 준수하여 원활한 전달을 보장하고 스팸 불만을 줄일 수 있습니다. 이를 DMARC 설정과 결합하면 발신 조직은 스푸핑, 피싱 및 BEC와 같은 이메일 기반 사이버 공격으로부터 도메인을 보호할 수 있습니다. 

Google Workspace SPF 레코드를 설정하는 것은 도메인 보호를 위한 첫 단계일 뿐입니다. 도메인 보안과 가시성을 강화하려면 15일간의 무료 평가판 으로 여정을 시작하세요!

• 정보
• 최신 게시물

유네스 타라다

도메인 및 이메일 보안 전문가 PowerDMARC

Yunes는 이메일 인증 및 보안에 대한 전문 지식을 갖춘 PowerDMARC의 운영 팀장입니다. Yunes는 CompTIA A+ 등의 자격증을 보유한 Microsoft 인증 Azure 관리자 어소시에이트입니다.

Yunes Tarada의 최신 글 (전체 보기)

• 이메일 솔팅 공격: 숨겨진 텍스트가 보안을 우회하는 방법 - 2025년 2월 26일
• SPF 평탄화: 평탄화란 무엇이며 왜 필요한가요? - 2025년 2월 26일
• DMARC와 DKIM: 주요 차이점 및 함께 작동하는 방법 - 2025년 2월 16일