Where do I publish an SPF record?

Publish the generated value as a TXT record at the root of the sending domain, such as example.com. If you send from a subdomain, publish the SPF record on that subdomain instead.

Should I use -all or ~all?

Use -all when you are confident the record includes every legitimate sender. Use ~all while auditing or migrating, because it gives mailbox providers a softer signal during setup.

Can a domain have more than one SPF record?

No. A domain should have one SPF TXT record. If multiple SPF records exist, receiving servers can return a permanent error. Merge all senders into a single record.

Do I still need DKIM and DMARC if SPF is configured?

Yes. SPF authorizes senders, DKIM signs the message, and DMARC connects authentication to domain policy. All three records work together for modern mailbox trust.

SPF 레코드 생성기

도메인에서 메일을 보낼 수 있는 메일 서비스용 SPF TXT 레코드를 만들고, 다음 캠페인이나 제품 이메일을 보내기 전에 DNS에 게시하세요.

무료로 시작하기 요금제 보기 →

핵심 요약

이 SPF 생성기로 도메인을 대신해 메일을 보낼 수 있는 IP 주소, MX 서버, 이메일 플랫폼을 나열하세요.
정상적인 발신자를 모두 알고 있다면 엄격한 정책으로 시작하세요. 소프트 페일은 아직 메일 소스를 점검하는 중일 때만 사용하세요.
레코드를 게시한 뒤 SPF 검사기 및 이메일 상태 점검 을 실행해 DNS에 레코드가 보이는지 확인하세요.

SPF 레코드 설정

IP 주소 (한 줄에 하나씩)

Include 도메인 (한 줄에 하나씩, 예: _spf.google.com)

도메인의 MX 서버를 포함할까요?

실패 정책

-all (하드 페일)

대부분의 설정에 권장해요. SPF 레코드에 없는 서버는 인증 실패로 표시돼요.

~all (소프트 페일)

목록에 없는 서버의 메일은 수신되지만 표시가 붙어요. 엄격한 정책으로 넘어가기 전에 새 SPF 레코드를 테스트할 때 좋아요.

조회 제한

SPF 레코드에는 DNS 조회 10회 제한이 있어요. 이를 넘으면 실패가 발생해요. 이 도구로 제한 안에서 관리하세요.

승인된 발송 출처와 메일함 인증 검사를 보여 주는 SPF DNS 워크플로 — SPF는 완전한 이메일 인증 설정의 첫 번째 DNS 단계예요. 도메인을 대신해 메일을 보낼 수 있는 서버와 서비스를 지정해요.

정상적인 메일을 막지 않는 SPF 레코드 만드는 방법

SPF 레코드는 도메인 루트에 있는 TXT 레코드예요. 수신 메일박스에 어떤 시스템이 이 도메인으로 이메일을 보낼 수 있는지 알려줘요. 보통 팀 메일용 Google Workspace나 Microsoft 365, 뉴스레터용 이메일 서비스 제공업체, 영수증과 비밀번호 재설정용 트랜잭션 메일 서비스, 그리고 경우에 따라 CRM이나 세일즈 인게이지먼트 플랫폼이 포함돼요.

SPF를 가장 안전하게 만드는 방법은 하드 페일 정책으로 바꾸기 전에 모든 발송 소스를 파악하는 거예요. 같은 도메인이나 서브도메인으로 발송하는 이메일 제공업체, CRM, 헬프데스크, 결제 시스템, 제품 앱, 콜드 아웃리치 도구를 모두 확인하세요. SPF에서 빠진 발송 서비스가 있으면 메일박스 제공업체가 정상적인 메일도 인증되지 않은 메일로 처리할 수 있어요.

SPF에는 실질적인 제약도 있어요. include:, a, mx, exists, redirect 같은 메커니즘은 DNS 조회를 발생시킬 수 있고, SPF 평가는 DNS 조회 10회로 제한돼요. 깔끔해 보이는 레코드도 이 제한을 넘으면 메일박스 평가 중에 실패할 수 있어요. 레코드를 간결하게 유지하고, 중복 include를 피하고, 팀이나 도구마다 별도 발송 설정이 필요하면 전용 서브도메인을 사용하세요.

1. 모든 발신자 나열

받은편지함 메일, 뉴스레터, 앱 알림, 청구서, 영업 도구 등 여러분의 도메인으로 발송하는 모든 서비스를 모으세요.

2. TXT 레코드 생성

필요한 IP와 include 도메인을 추가하고, 실패 정책을 고른 뒤 생성된 SPF 값을 복사하세요.

3. DNS 업데이트 후 확인

레코드를 게시하고 DNS 전파를 기다린 뒤, SPF 검사 도구와 DMARC 검사 도구로 결과를 확인하세요.

SPF와 DKIM, DMARC, 리스트 품질의 관계

SPF는 꼭 필요하지만 도달률 설정의 전부는 아니에요. DKIM 은 메시지에 서명해서 수신 서버가 발송 후 이메일이 변경되지 않았는지 확인할 수 있게 해요. DMARC 는 SPF나 DKIM이 눈에 보이는 From 도메인과 일치하지 않을 때 어떻게 처리할지 메일박스 제공업체에 알려줘요. 이 레코드들이 함께 작동하면 메일박스가 메시지가 허가된 것인지 판단하는 데 도움이 돼요.

인증이 나쁜 리스트를 안전하게 만들어주지는 않아요. 오래되었거나 철자가 틀렸거나 위험한 주소로 보내면 인증은 통과해도 반송률과 스팸 신고 신호가 발신자 평판을 해칠 수 있어요. 캠페인과 CRM 내보내기 파일은 발송 전에 먼저 무료 이메일 검증 도구 나 대량 검증으로 리스트를 검증하세요. 반송률 3% 미만은 건강하고, 3-5%는 정리와 점검이 필요하며, 5% 초과는 발신 도메인에 위험도가 높아요.

발신자가 여러 곳인 팀이라면 변경 사항을 게시하기 전에 각 include의 담당자를 기록해 두세요. 업체를 제거하거나, 서브도메인을 추가하거나, 발송 플랫폼이 권장 SPF include를 바꿀 때 이후 점검이 쉬워져요.

SPF 생성기 FAQ

SPF 레코드는 어디에 게시하나요?

생성된 값을 example.com 같은 발신 도메인 루트에 TXT 레코드로 게시하세요. 서브도메인으로 발송한다면 해당 서브도메인에 SPF 레코드를 게시하세요.

-all과 ~all 중 무엇을 써야 하나요?

레코드에 모든 정상 발신자가 포함되어 있다고 확신하면 -all을 사용하세요. 점검이나 이전 작업 중에는 ~all을 사용하세요. 설정 기간 동안 메일박스 제공업체에 더 완화된 신호를 주기 때문이에요.

도메인에 SPF 레코드가 여러 개 있어도 되나요?

아니요. 도메인에는 SPF TXT 레코드가 하나만 있어야 해요. SPF 레코드가 여러 개 있으면 수신 서버가 영구 오류를 반환할 수 있어요. 모든 발신자를 하나의 레코드로 합치세요.

SPF를 설정했어도 DKIM과 DMARC가 필요한가요?

네. SPF는 발신자를 허용하고, DKIM은 메시지에 서명하고, DMARC는 인증을 도메인 정책과 연결해요. 세 레코드가 함께 작동해야 최신 메일박스의 신뢰를 얻을 수 있어요.

발송 전에 실제 리스트를 검증하세요

무료 크레딧 100개로 시작하세요. 신용카드 없이 시작할 수 있어요.

무료로 시작하기