Defaults.Exposed › 수정 › Guides
SaaS 도구에서 SPF가 실패하나요? 원인과 수정 순서 — 유럽 에디션 (2026)
게시일 2026-07-08
데이터 기준: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인의 집계 센서스 데이터입니다. 등급 방법론 보기.
SaaS 도구가 “SPF 실패”를 보고할 때, 레코드가 문제인 경우는 드뭅니다: 메일이 DMARC 정렬에 실패하거나 include 체인이 SPF의 10개 DNS 조회 제한을 초과한 것입니다. Defaults.Exposed의 261,086,232개 도메인 센서스에 따르면 SPF를 발행하는 138,927,207개 도메인 중 2,119,539개가 9–10개 조회에 달해 있습니다 — SaaS include 하나로 절벽에 다가갈 수 있습니다.
아래에서 두 가지 문제 중 어디에 해당하는지 구분하는 방법, 수정 순서 — 먼저 스캔, 도구가 실제로 발신하는 도메인 찾기, 공급업체를 사용자 지정 도메인 DKIM으로 전환, 실제로 도움이 되는 경우에만 SPF include 추가 — 와 HubSpot, Salesforce, Mailchimp, SendGrid의 구체적인 방법을 설명합니다.
SaaS 도구에서 메일이 SPF에 실패하는 이유는 무엇인가요?
세 가지 패턴이 거의 모든 경우를 포함합니다:
| 보고서나 반송이 말하는 것 | 실제로 잘못된 것 | 수정 방법 |
|---|---|---|
| SPF 통과, DMARC 여전히 실패 | 정렬: 도구가 귀하의 반송 도메인이 아닌 자체 반송 도메인에서 SPF를 통과함 | 공급업체의 사용자 지정 도메인 DKIM 활성화(CNAME) |
SPF permerror | include 체인이 SPF의 10개 DNS 조회 제한 초과 | include 정리; 조회 초과 수정 참조 |
SPF fail / softfail | 도구가 실제로 귀하의 return-path로 발송하는데 레코드에 없음 | 공급업체의 include 추가 또는 사용자 지정 반송 도메인 활성화 |
데이터 기준: 2026-06-29.
굵게 표시된 행이 대부분의 사람들이 처한 상황입니다. 모든 도구에 include: 줄을 추가해도 이를 해결하지 못합니다 — 각 줄이 두 번째 행에 더 가까이 이동시킵니다. 적어도 797,263개 도메인이 이미 10개 조회 제한을 초과하여 SPF가 아무것도 보호하지 않는 PermError를 반환합니다. 전체 수치는 SPF PermError 보고서에 있습니다.
SPF는 실제로 어느 도메인을 확인하나요?
From 헤더의 도메인이 아닙니다. 수신자는 Return-Path 도메인(RFC5321.MailFrom, 반송 또는 봉투 발신 주소라고도 함) — 수신자가 보는 From 헤더는 SPF 검사 자체에서 아무런 역할을 하지 않습니다 — 을 기준으로 SPF를 평가합니다.
이 단 하나의 사실이 대부분의 “SaaS SPF 실패”를 설명합니다. 마케팅 플랫폼은 [email protected]과 같은 Return-Path로 메일을 발송합니다. SPF는 vendor.com에 대해 확인되어 깔끔하게 통과됩니다. 그런 다음 DMARC는 SPF가 확인한 도메인이 From 도메인과 일치하는지 묻습니다. 일치하지 않으므로 SPF의 DMARC 다리가 실패하고 대시보드는 “SPF 실패”라고 표시합니다. 자체 SPF 레코드를 편집해서는 해결할 수 없습니다 — 레코드가 애당초 참조되지 않았기 때문입니다.
수정 순서는 어떻게 되나요?
- 먼저 무료 스캔을 실행하세요. SPF가 없거나, 중복되거나, 조회 제한을 초과했는지 혹은 정상인지, 그리고 DMARC 상태를 한 번에 알 수 있습니다 — DNS를 건드리기 전에.
- 도구가 실제로 사용하는 Return-Path를 찾으세요. 도구에서 자신에게 테스트 메일을 발송하고 원본 메시지의 Return-Path 헤더(및 Authentication-Results)를 읽으세요. 위 표의 어느 행에 있는지 알 수 있습니다.
- 공급업체의 사용자 지정 도메인 DKIM을 활성화하세요 — 지속되는 수정. 모든 진지한 SaaS 도구는 “도메인 인증”을 제공합니다: 도메인으로 DKIM 서명할 수 있게 해주는 몇 가지 CNAME 레코드. 해당 서명은 From 도메인과 정렬되어 DMARC가 DKIM을 통해 통과합니다 — 지속적으로, 심지어 메일이 전달될 때도. 이것이 지속되는 수정입니다.
- 도구가 귀하의 return-path를 사용하는 경우에만 공급업체의 SPF include를 추가하세요 — 사용자 지정 반송 도메인을 활성화했거나, 실제로 봉투에 귀하의 도메인을 사용하여 발송하는 경우. 자체 도메인을 통해 반송하는 공급업체의 include는 아무것도 구매하지 않고 조회 예산만 낭비합니다.
- 저장 전 DNS 조회 수를 세세요. 제한은 10개의 확인된 조회이며, include는 재귀적으로 계산되고, 2,119,539개 도메인이 이미 9–10개에 달해 있습니다 — 센서스 p99는 9입니다. 한계에 가까운가요? 먼저 더 이상 사용하지 않는 도구의 include를 제거하세요. 방금 이메일 제공업체를 전환했나요? 남겨진 두 번째 레코드가 있는지 확인하세요 — 두 개의 SPF 레코드는 PermError와 같습니다.
- 재스캔 및 확인하세요. 올바른 도메인에서 SPF 통과, DKIM 정렬, DMARC 통과. 전체 참조는 SPF 수정 방법에 있으며, GoDaddy SPF 설정 및 IONOS DMARC 설정과 같은 제공업체 연습에서 DNS 패널 클릭을 다룹니다.
HubSpot, Salesforce, Mailchimp, SendGrid에서는 어떻게 해야 하나요?
HubSpot. HubSpot 설정에서 발신 도메인을 연결하고 발행하는 두 DKIM CNAME(hs1-… / hs2-…)을 발행하세요. DKIM을 From 도메인과 정렬합니다. HubSpot이 자체 반송 도메인을 사용하도록 구성한 경우가 아니라면 HubSpot SPF include는 필요하지 않습니다.
Salesforce. Salesforce 설정에서 DKIM 키를 만들고 생성되는 CNAME 쌍을 발행하세요. Salesforce가 조직의 return-path로 발송하는 경우 include:_spf.salesforce.com을 추가하고 반송 도메인을 구성하세요 — SPF include가 실제로 필요한 경우가 많은 유일한 대형 CRM입니다.
Mailchimp. 도메인을 인증하고 k2 / k3 DKIM CNAME을 발행하세요. Mailchimp 정렬은 DKIM 전용입니다 — 더 이상 추가할 SPF include가 없으며, 이전 튜토리얼의 것을 추가하면 조회만 낭비됩니다.
SendGrid. 도메인 인증(“자동화된 보안”)을 완료하세요: DKIM과 자체 서브도메인의 return-path를 처리하는 세 개의 CNAME. SPF include는 필요하지 않습니다. sendgrid.net을 승인한 740,321개 도메인 중 18.0%만 시행 DMARC를 가집니다(2026-06-29 기준 데이터) — 대부분의 SendGrid 발신자는 한 단계 앞에서 멈춥니다.
Zendesk 및 기타 모든 것: 동일한 패턴. 도구의 “도메인 인증” 페이지를 찾아 DKIM CNAME을 발행하고, 도구가 return-path에 귀하의 도메인을 사용한다고 문서화한 경우에만 SPF를 건드리세요.
유럽 기업에서 SPF가 다른가요?
아니요 — SPF, DKIM, DMARC는 어디서나 동일하게 작동합니다. 유럽에서 다른 것은 맥락입니다: 누가 묻고 있는지, 이웃들이 이미 무엇을 했는지.
ccTLD가 로컬 기준을 설정합니다. 유럽 ccTLD는 .com 수치보다 훨씬 높게 SPF를 발행하지만, 최종 단계를 완료하는 도메인 — 그 위에 시행 DMARC 정책 — 은 모든 곳에서 소수입니다:
| TLD | SPF 채택률 (등급 도메인 기준) | 시행 DMARC (등급 도메인 기준) |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
데이터 기준: 2026-06-29. 프랑스: 13.65% 시행 DMARC; 이탈리아: 5.24%.
유럽 호스트의 기본값이 중요합니다. 4,346,526개 도메인이 SPF에서 IONOS의 EU 메일 서버(_spf-eu.ionos.com)를 승인합니다 — 0.3%만 엄격한 -all로 끝나며, 1.0%가 DMARC를 시행합니다. OVH의 2,132,049개는 엄격성에서 더 낫지만(43.7%) 2.2%만 DMARC를 시행합니다(2026-06-29 기준 데이터). 레코드를 한 번도 건드리지 않았다면 이러한 기본값에 의존하고 있는 것입니다.
규제 기관이 이제 이를 명시합니다. NIS2 21조(2)(j)는 범위 내 기관이 통신을 보안하도록 요구하며, 집행 규정(EU) 2024/2690은 이메일 및 DNS 보안 조치를 명시합니다. 이메일 인증은 구체적이고 확인 가능한 부분입니다 — 준수 측면에서 드물게도 무료로 수정 가능합니다.
데이터 거주지에 대해: Defaults.Exposed 스캐너와 센서스는 AWS eu-west-1에서 실행되며, 집계 수치만 발행하고, 스캔은 요청한 도메인만 확인합니다.
자주 묻는 질문
내 SPF 검사기는 “통과”라고 하는데 도구 대시보드는 SPF가 실패한다고 합니다 — 왜 그런가요? 검사기는 귀하의 레코드를 테스트했고, 수신자는 도구가 실제로 사용한 Return-Path 도메인을 테스트한 후 DMARC가 From 도메인과 비교했습니다. 레코드 실패가 아닌 정렬 실패입니다 — SPF 편집이 아닌 공급업체의 사용자 지정 도메인 DKIM으로 수정합니다.
사용하는 모든 도구에 SPF include를 추가해야 하나요? 아니요. 각 include는 SPF의 10개 조회 예산의 일부를 재귀적으로 사용합니다: SPF를 발행하는 138,927,207개 도메인 중 2,119,539개가 9–10개 조회에 달해 있고, 적어도 797,263개는 초과하여 SPF가 PermError를 반환하여 아무것도 보호하지 않습니다(2026-06-29 기준 데이터).
include가 DMARC도 수정하나요? 도구가 귀하의 return-path로 발송하여 SPF가 통과하고 정렬되는 경우에만. 대부분의 SaaS 도구는 그렇지 않습니다 — 그것이 바로 SaaS 메일에서 DMARC를 통과시키는 다리가 SPF가 아닌 정렬된 DKIM인 이유입니다.
EU에서는 이것이 법적 요구사항인가요? NIS2 범위 내 기관의 경우, 21조(2)(j)와 집행 규정(EU) 2024/2690이 이메일 보안을 의무화합니다. 범위 밖이더라도 보험사와 고객 설문지가 점점 더 묻고 있습니다 — 2026-06-29 기준으로 어떤 EU ccTLD도 도메인의 3분의 1 이상이 시행 DMARC 정책에 도달하지 못합니다(최선인 .nl이 29.43%; .it가 5.24%).
소유자에게 보고서 보내기
CNAME이 활성화되면 스캔을 다시 실행하고 등급이 매겨진 보고서를 사업 소유자 또는 클라이언트에게 전달하세요. 무엇이 실패했는지, 무엇을 수정했는지, 도메인이 현재 어떤 상태인지를 평문으로 보여줍니다 — 보험 갱신 또는 고객 보안 설문지에 필요한 정확한 증거, 말이 아닌 서면으로.
도메인 무료 확인
SPF, DKIM, DMARC 중 어느 다리가 실패하는지 정확하게 확인하세요 — 비공개로, 소유자만.
도메인 확인 → · SPF 수정 → · SPF PermError: “DNS 조회 초과” → · 등급 방법론 → · 집계 데이터만. 데이터는 EU에서 저장 및 처리됩니다.