SPF 레코드 설정: 예시와 오류 점검

2026년에 이메일 인프라를 구성한다면 SPF 레코드를 꼼꼼히 확인해야 합니다. 오류는 수신 정책과 다른 인증 결과에 따라 스팸 분류나 거부로 이어질 수 있습니다. 올바른 레코드만으로 받은편지함 도달을 보장하지는 않습니다.

2024년 초, 특히 그해 이월부터 Google과 Yahoo는 특정 발신자에 대한 인증 요건을 강화했습니다. SPF 누락이나 오류가 영향을 줄 수 있지만 모든 수신자가 자동으로 SMTP 550을 반환하는 것은 아닙니다. 적용되는 규칙과 전체 오류 설명을 확인하세요.

단일 도메인을 운영하는 창업자는 투자자가 발표 자료를 받지 못하는 문제를 겪을 수 있습니다. 고객 도메인 500개를 관리하는 MSP는 월요일 아침부터 Gmail에 메일을 보낼 수 없다는 문의를 받을 수 있습니다. 올바른 구성과 모니터링은 위험을 줄이지만 모든 문제를 예방하지는 못합니다.

이 가이드는 SPF의 역할, 레코드 작성법, 전달률에 영향을 주는 오류와 여러 고객의 설정을 체계적으로 관리하는 방법을 설명합니다.

SPF가 하는 일과 하지 않는 일

Sender Policy Framework (SPF)는 RFC 7208에 정의된 DNS 기반 발송 권한 확인 프로토콜입니다. 평가되는 봉투 발신 신원을 위해 어떤 시스템이 전송할 수 있는지 지정합니다. 포괄적인 보안 장벽이 아니며 표시되는 발신 주소를 독자적으로 인증하지 않습니다.

실제 평가 방식

Gmail은 alice@yourcompany.com의 메시지를 받으면 표시되는 From 주소만 보지 않습니다. SPF에서는 반송 처리에 사용하는 MAIL FROM 봉투 발신자가 중요하며, 배달 후 보통 Return-Path에 기록됩니다. 봉투 발신자가 비어 있으면 해당하는 HELO 신원을 평가할 수 있습니다. 수신자는 그 도메인의 DNS 정책으로 발신 IP를 확인합니다.

적절한 메커니즘이 일치하면 pass가 나올 수 있습니다. 허용되지 않은 발신 IP에는 ~all의 softfail이나 -all의 fail 등이 나올 수 있으며 neutral과 오류도 가능합니다. 결과가 수락이나 거부를 자동으로 명령하지는 않습니다.

From 헤더와 Return-Path의 차이

초보자의 90%가 여기서 실수한다는 표현은 검증된 조사 수치가 아닙니다. 기술적인 핵심은 SPF가 Outlook이나 Apple Mail에 표시되는 From 주소를 확인하는 것이 아니라 봉투 신원을 평가한다는 점입니다.

주의할 점: Mailchimp는 반송 처리를 위해 bounce-mc.us1.mailchimp.com 같은 자체 도메인을 사용할 수 있습니다. 그러면 수신자는 내 도메인이 아닌 Mailchimp의 SPF를 확인합니다. 내 레코드가 올바르더라도 해당 메시지에서는 평가되지 않을 수 있으므로 실제 설정을 확인하세요.

이 정렬 문제 때문에 SPF만으로는 충분하지 않습니다. DKIM과 DMARC의 관계는 SPF, DKIM, DMARC 설정 순서에서 설명합니다.

SPF가 여전히 필요한 이유

DKIM과 DMARC를 구성해도 적용되는 발신자 요건에서 SPF는 중요합니다. 550 5.7.515 Access Denied 같은 응답은 Microsoft의 구체적인 요건과 범위 안에서 조사해야 합니다. 모든 SPF 누락이 모든 수신자에게 이 오류를 일으킨다는 뜻은 아닙니다.

기본 구성: 단일 발송 제공업체

TrekMail, Google Workspace, Microsoft 365 중 한 곳을 주로 사용하고 마케팅 도구 하나를 추가하는 소규모 기업이라면 간결한 구성이 필요합니다. 실제로 같은 봉투 도메인을 사용하는 서비스의 권한을 통합하세요.

기본 원칙: 평가되는 DNS 이름마다 SPF 정책은 정확히 하나여야 합니다.

기존 정책과 합치지 않고 두 번째 SPF TXT 레코드를 추가하면 SPF 평가에서 PermError가 발생합니다. 이는 선택되는 SPF 정책이 여러 개라는 문제이지 일반 TXT 레코드가 여러 개라는 문제가 아닙니다. 이후 처리는 수신 정책에 달려 있습니다.

SPF 레코드의 구성 요소

SPF 레코드 설정 가이드의 예시도 참고하세요. 복사하기 전에 현재 제공업체 값, 구문과 실제 발송 경로를 검증해야 합니다.

소규모 기업의 TrekMail 비교

설명용 비교에서 Google Workspace는 사용자당 월 $6-$18이며 사용자 열 명은 연 $720-$2,160입니다. TrekMail Starter는 월 $3.50와 사용자 최대 100명으로 설명됩니다. 과거 설명의 예시이므로 현재 가격, 조건과 포함 서비스를 확인하세요. include:spf.trekmail.net은 지원되는 전송 구성에 맞을 수 있지만 전체 DNS 및 인증 검증을 대신하지 않습니다.

여러 발신자: 에이전시의 관리 방식

MSP와 에이전시는 영업에 HubSpot, 지원에 Zendesk, 마케팅에 Klaviyo, 일상 업무에 TrekMail을 사용할 수 있습니다. 모든 도구가 기본 도메인의 SPF에 자동으로 포함되어야 하는 것은 아닙니다. 각 서비스가 실제 사용하는 봉투 도메인을 확인하세요.

같은 도메인에 적용되는 권한은 하나의 SPF 정책으로 통합해야 하며 관련 DNS 항목 10개 제한을 고려해야 합니다.

10개 DNS 항목 제한 관리

RFC 7208 §4.6.4는 평가 중 DNS 조회를 유발하는 관련 메커니즘과 수정자를 중첩 항목까지 합쳐 10개로 제한합니다. 모든 DNS 패킷 수를 세는 규칙이 아닙니다. DNS 인프라 남용을 줄이는 제한이지만 정상 구성에도 영향을 줄 수 있습니다.

평가될 때 예산에 포함되는 항목: include:, a, mx, exists, redirect. Exists는 A 조회를 사용하고 redirect는 앞선 메커니즘이 일치하지 않을 때 평가를 넘깁니다. 권장되지 않는 ptr도 포함됩니다.

이 DNS 항목 예산을 사용하지 않는 메커니즘: ip4:, ip6:, all

중첩 include의 함정

include:bluehost.com을 추가하면 1개 항목처럼 보입니다. 설명용 중첩 예에서 그 정책이 spf.protection.outlook.com과 mail.bluehost.com을 포함하면 항목 하나가 세 개의 평가로 이어질 수 있습니다. spf.protection.outlook.com도 추가 참조를 가질 수 있습니다. 현재 Bluehost 구성을 확정하는 예가 아니므로 실제 값과 평가 경로를 확인하세요.

평가 경로가 관련 항목 10개를 초과하면 PermError가 반환됩니다. SPF fail과는 다르며 항상 알림 없이 사라지는 것도 아닙니다. 로그, SMTP 응답과 다른 인증 결과로 영향을 조사하세요.

조회 예산 확인

추측하지 말고 CLI나 신뢰할 수 있는 시각화 도구를 사용하세요. Mac과 Linux에서는 다음 명령으로 시작할 수 있습니다.

dig +short txt yourdomain.com

이후 각 include: 도메인을 재귀적으로 조사하고 다른 관련 메커니즘과 수정자도 확인하세요. TXT 조회만으로 예산이 계산되지는 않습니다. SPF 조회 제한 가이드는 전체 평가와 초과 문제를 설명합니다.

평탄화와 하위 도메인 분리

관련 항목 10개 제한을 초과할 위험이 있다면 두 가지 접근을 고려할 수 있습니다. 모든 에이전시가 초과하는 것은 아니며 제한에 도달한 것과 초과한 것도 다릅니다.

선택 1: 유지 관리가 필요한 SPF 평탄화

평탄화는 선택한 include: 참조를 현재 IP로 풀어 ip4: 같은 메커니즘으로 기록합니다. ip4:는 DNS 항목 예산을 사용하지 않지만 수백 개 주소는 다른 한도와 관리 문제를 만들 수 있습니다. 필요한 주소 계열과 원래 정책의 의미도 검토해야 합니다.

문제점: HubSpot과 Klaviyo 같은 서비스가 발신 IP를 바꾸면 정적 목록이 몇 달 후에는 오래된 정보가 될 수 있습니다. 새 IP를 누락하거나 제거된 IP를 계속 허용할 위험이 있습니다. 특정 기간 후 반드시 발생하는 것은 아니지만 지속적인 관리가 필요합니다.

신뢰할 수 있는 원본 감시, 변경 승인, 검증과 복구 계획이 있을 때만 평탄화를 고려하세요. 자동 업데이트는 도움이 될 수 있어도 정확하고 적시인 반영을 보장하지 않습니다.

선택 2: 하위 도메인으로 분리

모든 서비스를 기본 도메인에 넣는 대신 봉투 도메인별로 발송을 나눌 수 있습니다. SPF는 실제 MAIL FROM 신원을 평가하며 그 신원에 하위 도메인을 설정할 수 있습니다.

마케팅이 team@company.com에서 보내야 할까요, 아니면 news@marketing.company.com이 적합할까요? 표시 주소만 바꿔서는 SPF 도메인이 바뀌지 않습니다.

기본 도메인 (company.com): 업무용과 중요 발송 등 해당 권한을 간결하게 유지하세요. 다음은 설명용 예이므로 게시 전에 현재 제공업체 값을 확인해야 합니다.

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

마케팅 하위 도메인 (marketing.company.com): 서비스가 실제 봉투 도메인으로 사용하도록 구성하세요.

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

실제 별도 SPF 도메인은 자체 관련 항목 10개 예산을 갖습니다. 완화 또는 엄격 DMARC 정렬도 확인하세요. marketing.company.com의 평판 문제가 반드시 그곳에만 머무는 것은 아닙니다. 수신자는 조직 도메인과 공유 IP 신호를 합칠 수 있으므로 대표의 기본 주소를 완전히 보호하는 구조는 아닙니다.

추가 예시는 SPF 설정 템플릿과 여러 발신자 구성 가이드를 참고하고 실제 제공업체 설정으로 검증하세요.

게시 후 검증 절차

DNS 편집기에서 저장했다고 끝난 것이 아닙니다. 게시 상태, 구문과 실제 전송을 다음 순서로 확인하세요.

1. DNS 게시와 캐시 확인

TTL과 캐시 때문에 변경이 보이는 시간이 분 또는 시간 단위로 달라질 수 있습니다. 권한 있는 DNS 서버와 함께 공개 리졸버도 확인하세요.

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8은 ISP 리졸버 대신 Google 공개 리졸버를 조회하게 합니다. Google도 캐시를 사용합니다. 여기서 레코드가 보인다고 전 세계의 모든 수신자가 새 값을 본다고 할 수는 없습니다.

2. 구문 검증

구문과 평가 동작을 함께 확인하세요. 자주 발견되는 항목은 다음과 같습니다.

• v=spf1 앞 공백은 SPF 레코드 인식을 방해할 수 있음
• ip4: 192.1.1.1: 콜론 뒤 공백은 유효하지 않음
• 여러 all 메커니즘: all은 항상 일치하므로 뒤의 메커니즘에 도달하지 않음
• 중복 include:는 평가될 때 예산을 낭비할 수 있으며 실제 영향은 평가 경로와 오류에 따라 달라짐

구문 검사기를 사용하고 직접 결과를 확인하세요. TrekMail의 DNS 설정 마법사는 현재 기능에 따라 경고를 제공할 수 있지만 완전한 검증을 대신하지 않습니다.

3. 결과 없는 조회 제한

RFC 7208은 NXDOMAIN이나 관련 데이터가 없는 응답 같은 void lookup을 2개로 제한하도록 권고합니다. 일반적인 DNS 항목 예산과는 별도이며 구현에서 설정 가능할 수 있습니다.

추가 l이 들어간 include:spf.trekmaill.net 같은 오타가 빈 응답을 만들면 void lookup 1개가 됩니다. 빈 응답 두 개만으로 권고 제한을 초과한 것은 아니며 초과하면 PermError가 발생할 수 있습니다. 다만 include 대상에 유효한 SPF가 없으면 그 자체로 더 일찍 오류가 날 수 있습니다.

구문뿐 아니라 현재 DNS 응답도 확인하세요. 구문 검사만으로 모든 런타임 DNS 오류나 빈 대상을 발견할 수는 없습니다.

4. 실제 메시지 헤더 확인

직접 관리하는 Gmail 계정으로 테스트하고 점 세 개 메뉴에서 "원본 보기"를 선택하세요. Authentication-Results를 찾되 수신 서비스가 추가한 신뢰할 수 있는 결과만 사용하세요. 발신자가 임의로 넣은 헤더는 믿을 수 없습니다. 다음은 설명용 예입니다.

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral이나 spf=softfail은 정책, 봉투 도메인과 발신 IP를 조사할 이유지만 항상 설정 오류를 뜻하지는 않습니다. DKIM과 DMARC 정렬도 확인하세요. 추가 점검은 DNS 상태 확인 문서를 참고하세요.

자주 발생하는 문제

다음 패턴은 SPF 문의에서 자주 나타납니다. 미리 이해하면 문제가 발생했을 때 원인을 조사하기 쉽습니다.

1. 전달 시 SPF 문제

SPF는 봉투 신원에 대해 발신 IP를 평가하므로 기존 방식의 전달에서 문제가 생길 수 있습니다.

Alice가 Bob에게 보내고 Bob이 Charlie로 자동 전달합니다. 원래 봉투 발신자가 유지되면 Charlie는 Bob 서버의 IP를 보면서 원래 도메인의 정책을 평가할 수 있습니다. 정상적인 메시지라도 실패할 수 있으며 실제 결과는 구성에 달려 있습니다.

SPF만으로 모든 전달 문제를 해결하지는 못합니다. DKIM은 관련 서명 헤더와 본문이 유효하게 유지되면 전달 후에도 통과할 수 있습니다. DMARC에는 정렬도 필요합니다. SRS는 전달 서비스의 SPF를 위해 봉투 주소를 다시 쓸 수 있지만 원래 From 정렬을 복구하지 않습니다.

도메인 이메일 전달과 전달률에서 자세히 설명합니다. 어느 방식도 받은편지함 도달을 보장하지는 않습니다.

2. ptr 메커니즘

2000년대 초에는 역방향 DNS를 사용하는 ptr가 더 흔했습니다.

v=spf1 ptr -all

RFC는 신뢰성과 DNS 부담 때문에 ptr 사용을 권장하지 않지만 구문에서 없앤 것은 아닙니다. Gmail이 모든 관련 정책을 무시하거나 불이익을 준다고 단정하지 마세요. 기존 ptr 권한을 목록화하고 적절한 대체 메커니즘으로 테스트하며 바꾸세요. 메일 서버의 역방향 DNS PTR 필요성과는 별개의 문제입니다.

3. +all의 위험

다음은 안전하지 않은 설명용 예입니다. 제공업체 값을 확인하지 않고 그대로 게시하지 마세요.

v=spf1 include:spf.google.com +all

한정자의 의미는 다음과 같습니다.

• -all = 앞에서 일치하지 않은 IP에 fail, 자동 거부 명령은 아님
• ~all = 앞에서 일치하지 않은 IP에 softfail, 수락이나 표시를 보장하지 않음
• +all = 이 메커니즘까지 도달한 모든 IP에 pass

+all은 해당 봉투 신원에 대해 임의의 IP를 허용합니다. +all 정책은 남용을 쉽게 할 수 있지만 앞선 실패나 오류와 수신자의 다른 검사를 무효화하지는 않습니다. +all이 있다면 정상 발신원을 확인하고 -all 같은 적절한 정책으로 테스트와 복구 계획을 갖춰 변경하세요.

4. 외부 발송 서비스의 Return-Path

사용자 지정 반송 설정이 없으면 마케팅 서비스가 자체 Return-Path를 사용할 수 있습니다. 이 경우 내 도메인 대신 그 도메인의 SPF를 평가합니다. 추적 도메인은 봉투 또는 반송 도메인과 다릅니다. 기본 반송이 정렬되지 않아도 유효하고 정렬된 DKIM으로 DMARC가 통과할 수 있으며 SPF 정렬은 완화 또는 엄격 비교를 따릅니다.

ESP가 bounce.yourcompany.com 같은 사용자 지정 Return-Path 하위 도메인을 지원하는지 확인하고 필요한 DNS를 설정하세요. DMARC 정렬과 도메인 평판을 참고하세요.

생성 도구 사용 시 확인할 점

SPF 생성 도구의 품질과 기능은 다양합니다. 관리에 도움이 되는 도구도 있지만 결과를 검토하지 않고 게시해서는 안 됩니다.

유용한 도구

시각화 도구는 중첩 include:를 보여 줍니다. 다른 관련 메커니즘과 평가 경로도 계산하는지 확인하세요. 일부 이메일 전달률 도구가 이 기능을 제공합니다.

구문 검사기는 빠진 콜론이나 유효하지 않은 문자를 찾을 수 있습니다. 빈 조회는 DNS 평가도 필요합니다. 변경할 때마다 도구가 실제 지원하는 범위에서 검증하세요.

주의할 도구

원클릭 마법사가 모두 같은 정책을 기본값으로 사용하는 것은 아닙니다. ?all은 앞서 일치하지 않은 IP에 neutral을 제공합니다. 발신원 목록을 확인해 정책을 선택하세요. -all과 ~all의 결과는 다르지만 어느 것도 전달을 보장하지 않습니다.

문자열 분할 생성기: DNS TXT의 문자열당 한도는 255옥텟으로, Unicode 문자 수와 항상 같지는 않습니다. 긴 SPF는 별도 정책 두 개가 아니라 하나의 TXT 레코드 안에 여러 문자열로 나눌 수 있습니다.

• 올바른 구조: "v=spf1 include:a..." "include:b... -all" (문자열 두 개, 레코드 하나인 도식적 예시; 실제로는 결합 경계에 필요한 공백을 넣어야 함)
• 잘못된 구조: 별도의 SPF TXT 레코드 두 개는 선택 시 PermError를 일으킴

문자열은 자동 공백 삽입 없이 이어 붙습니다. 최종 결합 값, 경계 공백과 구문을 확인하세요. 생성 결과는 게시 전 검증하고 게시 후 DNS에서도 확인해야 합니다.

추가 도구 설명은 SPF 생성기와 설정 가이드를 참고하세요.

TrekMail에서 설정 통합하기

대형 업무 제품이 나쁜 것은 아닙니다. 여러 기능을 묶어 사용자별로 과금하는 모델이 고객에게 적합한지 실제 요구와 현재 계약으로 평가해야 합니다.

해당 TrekMail 관리형 SMTP로 보내는 도메인에 다음 설명용 정책이 적합할 수 있습니다. 현재 값과 추가 서비스를 검증하세요.

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

이 한 줄이 자체 SMTP나 외부 서비스까지 포함한 모든 도메인의 완전한 설정은 아닙니다. IP, 역방향 DNS와 피드백 루프 관리는 실제 발송 경로와 서비스에 달려 있습니다. 관리형 환경에서도 수신 동의, 대상, 적절한 양의 증가와 신고 처리가 필요하며 권한 부여가 전달을 보장하지 않습니다.

동일한 구성을 쓰는 MSP가 고객 도메인 50개에 비슷한 정책 50개를 관리하면 표준화가 도움이 될 수 있습니다. 그러나 고객별 발송 경로 차이와 요금제 조건을 확인해야 합니다. 같은 줄을 백 번 사용했더라도 새 도메인을 검증하세요.

이전 시 IMAP 이전 개요와 필수 DNS 레코드 가이드로 사서함 데이터와 MX, SPF, DKIM, DMARC를 별도로 계획하고 시험하세요. IMAP은 DNS나 앱 설정을 옮기지 않으며 MX는 주로 수신 라우팅입니다. 인증과 사전 검증 후 적절한 전환을 계획하고 현재 대시보드 기능은 도메인 일괄 가져오기에서 확인하세요.

지속적인 SPF 관리

2024년 이후 특정 발신자의 인증 요건이 강화되었습니다. 잘못된 SPF 레코드는 점검해야 하지만 실제 영향은 수신자, 인증 경로와 정책에 따라 다릅니다. 보편적인 유예 기간을 가정하지 말고 구성을 관리하세요.

핵심 점검은 다음과 같습니다.

1. 정책을 조사하세요. dig +short txt yourdomain.com을 실행하고 일반 TXT가 아닌 선택되는 SPF 정책만 셉니다. 같은 이름에 SPF가 하나보다 많으면 PermError입니다.
2. 관련 권한을 통합하세요. 실제 같은 봉투 도메인을 사용하는 서비스를 하나의 SPF TXT 정책으로 구성합니다.
3. DNS 예산을 평가하세요. 경로가 관련 항목 10개를 넘으면 간소화나 실제 봉투 하위 도메인을 검토하세요. 평탄화에는 지속적인 관리가 필요합니다.
4. -all을 신중히 선택하세요. 발신원 검증과 테스트 후 ~all에서의 변경을 검토합니다. +all은 우선 점검하되 안전한 변경 계획을 마련하세요.
5. Return-Path 정렬을 확인하세요. Mailchimp나 HubSpot이 지원하는 자체 반송 도메인을 검토하고 DMARC를 위한 유효한 정렬 DKIM도 확인합니다.
6. SPF에서 멈추지 마세요. 전달은 SPF 실패를 유발할 수 있고 변경은 DKIM도 무효화할 수 있습니다. SPF, DKIM, DMARC 세 가지를 구성하고 실제 경로를 시험하세요.

50바이트 SPF는 설명용 크기이지 실제 레코드의 고정 크기가 아닙니다. 올바른 구성은 고객 관계의 위험을 줄이는 데 도움이 됩니다. 발송 구성을 바꿀 때와 정기적으로 확인하세요. 연간 점검만으로는 부족할 수 있습니다.

DNS 관리를 체계화하세요. TrekMail 무료 상품과 최신 플랫폼 가격, 조건, SPF, DKIM, DMARC 지원 범위를 확인하세요.