Defaults.Exposed › 수정 › Guides

전달된 이메일이 SPF에서 실패 — 수정할 수 없는 이유와 실제로 효과적인 방법 (2026)

게시일 2026-07-08

기준일: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인에 대한 집계 센서스 데이터. 등급 산정 방식을 참고하세요.

전달된 이메일이 SPF를 통과하도록 만들 수 없습니다 — 전달은 설계상 SPF를 깨뜨리며, 솔직한 수정 방법은 전달에서 살아남는 정렬된 DKIM입니다. 규모는 센서스 전체에 걸쳐 있습니다: Defaults.Exposed의 261백만 도메인 센서스에 따르면 138,927,207 SPF 게시 도메인 중 7,355,985개가 Namecheap의 전달 include만 승인하고, 엄격한 SPF 비율은 <0.1%입니다.

아래에서: 귀사가 작성할 수 있는 어떤 SPF 레코드도 전달에서 살아남지 못하는 이유, SRS와 ARC가 귀사가 제어하는 도구가 아닌 이유, 효과적인 수정 방법 — DMARC 통과로서 귀사 도메인으로 DKIM 서명 — 그리고 DKIM도 깨뜨리는 하나의 경우(메시지를 다시 작성하는 메일링 리스트)와 그 잔재에 대해 무엇을 할지.

전달이 SPF를 깨뜨리는 이유는?

수신자는 From 헤더가 아닌 Return-Path(RFC5321.MailFrom) 도메인에 대해 SPF를 평가합니다. 귀사가 직접 발송하면, 귀사 서버의 IP가 SPF 레코드에 있고 확인이 통과됩니다. 수신자가 메시지를 자동으로 전달하면 — 개인 Gmail로, 대학 별칭을 통해, 등록기관의 전달 제품을 통해 — 전달자의 서버가 재전송하며, 보통 귀사 도메인을 Return-Path에 유지합니다. 최종 수신자는 이제 묻습니다: 이 전달 서버가 귀사 SPF 레코드에 승인되어 있나요?

없으며, 앞으로도 없을 것입니다: 귀사는 전달자를 선택하지 않았고, 존재를 알지 못하며, 내일 다른 서비스를 통해 전달된 동일한 메시지는 다른 IP에서 실패할 것입니다. SPF는 하나의 질문에 답합니다 — “이 IP가 Return-Path 도메인이 승인한 서버에서 왔는가?” — 전달된 메일에 대한 실제 답은 아니오입니다. 실패는 레코드가 잘못된 것이 아닌 SPF가 명시된 대로 작동하는 것입니다.

센서스는 이 경로가 얼마나 주류인지 보여줍니다: 7,355,985 도메인이 Namecheap의 이메일 전달 include (spf.efwd.registrar-servers.com)를 승인합니다 — 139백만 SPF 게시자 중 단일 공급업체의 전달 제품 — 엄격한 SPF 비율 <0.1%에 DMARC를 집행하는 곳은 0.2%뿐입니다. 그 느슨한 템플릿은 부주의가 아닙니다: 전달은 정확히 엄격한 -all이 오작동하는 곳이고, 제품 자체가 전달인 공급업체는 그에 맞게 제공합니다. 전체 한정자 이야기는 ~all 대 -all 보고서에 있으며, 공급업체별 그림은 가장 강력한 SPF를 제공하는 이메일 공급업체에 있습니다.

전달자의 서버를 SPF 레코드에 그냥 추가하면 안 되나요?

안 됩니다 — 그 이유가 이 글 전체입니다:

1. 전달자를 열거할 수 없습니다. 어디서든 어떤 수신자든 어떤 서비스를 통해 귀사 메일을 전달할 수 있습니다. SPF 레코드는 미리 알 수 없는 서버를 나열해야 할 것입니다.
2. 나열하면 목적이 무색해집니다. 대형 전달 서비스는 수백만 고객을 위해 메일을 릴레이합니다. 해당 범위를 레코드에 넣으면 사용자 중 누군가가 릴레이하는 모든 메시지 — 스푸퍼의 것도 포함 — 가 귀사로서 SPF를 통과합니다.

동일한 논리가 “전달이 작동하게 하기 위해” 한정자를 느슨하게 하는 것을 배제합니다: 한정자가 전달된 메일이 실패하는 이유가 아니며, DMARC가 작동하면 대부분의 가이드가 주장하는 것보다 덜 변합니다 — 한정자 데이터를 참고하세요. 레코드는 여기서 레버가 아닙니다. 당기는 것을 멈추세요.

SRS와 ARC는 어떻나요 — 전달을 수정하지 않나요?

해결하려 시도하지만 — 둘 다 귀사가 배포하는 것이 아닙니다:

데이터 및 메커니즘 상태 기준: 2026-06-29.

SRS는 전달자의 SPF 문제를 없애지, 귀사 것이 아닙니다: Return-Path를 다시 작성하면 어떤 SPF가 확인되는지가 바뀌고, DMARC가 지키는 도메인인 귀사 From 헤더는 그대로입니다. ARC는 인프라 운영자 간의 신뢰 결정입니다. 가이드가 도메인 오너로서 “SRS를 구현하세요”라고 하면, 귀사를 전달 공급업체와 혼동한 것입니다.

이메일이 전달에서 살아남도록 하려면 어떻게 하나요?

귀사 도메인에 정렬된 DKIM을 DMARC 통과로 만드세요. DKIM 서명은 메시지 헤더에 담긴 암호화입니다: 서명된 콘텐츠가 수정되지 않는 한, 메시지가 어디에 도달하든, 몇 개의 서버가 릴레이하든 검증됩니다. DMARC는 하나의 정렬된 통과만 필요합니다 — SPF 또는 DKIM — 따라서 전달이 SPF 다리를 죽이면, 정렬된 DKIM이 메시지를 인증된 상태로 유지합니다.

1. DNS를 건드리기 전에 defaults.exposed에서 무료 검사를 실행하세요. DKIM이 있는지, 귀사 도메인으로 서명하는지, DMARC 상태가 어떤지 보여줍니다 — 따라서 SPF 레코드와 싸우는 대신 실제 미비점을 수정할 수 있습니다.
2. 전달이 실제로 귀사 문제인지 확인하세요. 영향 받는 메시지의 Authentication-Results 헤더에서, 직접 메일은 SPF를 통과하고 전달된 사본은 전달 서비스의 IP에서 실패합니다. SPF 및 DKIM이 통과하지만 DMARC가 여전히 실패한다면, 정렬 문제가 있는 것입니다 — DMARC 실패하지만 SPF와 DKIM은 통과를 참고하세요.
3. 모든 발송 서비스에서 귀사 도메인으로 DKIM 서명을 활성화하세요 — 사서함 공급업체부터, 그 다음 ESP와 트랜잭션 발송자. 공급업체 기본값은 종종 정렬되지 않는 공급업체 도메인으로 서명합니다; 귀사는 d=yourdomain을 원합니다. DKIM 수정 방법으로 시작하고, Google Workspace 및 Microsoft 365의 클릭 경로.
4. 단순 통과가 아닌 정렬을 확인하세요. 서명의 d= 도메인이 귀사 From 도메인과 일치해야 합니다; 다른 사람의 도메인에서 dkim=pass는 귀사 DMARC에 아무 도움이 되지 않습니다.
5. SPF 레코드는 그대로 두세요. 직접 메일에 정확하게 유지하세요 — 여전히 대부분의 트래픽을 인증하고 귀사의 두 번째 DMARC 다리로 남습니다. 전달자를 커버하려는 시도를 멈추세요.
6. 재검사, 그런 다음 DMARC 집행을 의도적으로 단계적으로 적용하세요 — 다음 섹션, 그리고 p=none에서 p=reject 롤아웃 가이드.

이 조합 — SPF와 정렬된 DKIM을 기반으로 한 집행 DMARC — 는 전달에 내성이 있는 패턴이며, 드뭅니다: ~all을 게시하는 77.5백만 도메인 중 집행 DMARC 정책으로 뒷받침하는 곳은 **9.2%(7,116,774)**뿐이며, 센서스(2026-06-29)에 따르면 완전한 SPF + DKIM + 집행된 DMARC 삼중 구조를 갖춘 곳은 **261백만 등급 도메인 중 3.87%(10,092,481)**뿐입니다.

메시지를 다시 작성하는 메일링 리스트는 어떻나요?

정렬된 DKIM도 살아남지 못하는 하나의 전달 경로: 메시지를 수정하는 메일링 리스트 — [list-name] 제목 태그, 구독 취소 푸터, 제거된 첨부 파일. 서명된 콘텐츠를 변경하면 본문 해시가 더 이상 일치하지 않아 DKIM도 실패합니다(dkim=fail: 본문 해시가 검증되지 않음이 그 실패의 별도 가이드입니다). 이제 두 DMARC 다리가 모두 죽었고, 리스트만이 완화할 수 있습니다(From 재작성, ARC 봉인).

이 잔재가 정확히 DMARC 집행 단계적 적용의 목적입니다. 집계 보고서를 보면서 pct 증가와 함께 p=quarantine을 통과하면 p=reject 정책이 거부하기 시작하기 전에 실제 메일 중 얼마나 많은 것이 다시 작성 리스트를 통해 흐르는지 보여줍니다. 사용자들이 메일링 리스트에 사는 도메인에서 reject로 바로 이동하지 마세요; 하지만 p=none에 영원히 머물지도 마세요. 단계적 롤아웃 가이드가 증가를 안내합니다.

자주 묻는 질문

전달이 DKIM도 깨뜨리나요? 단순 전달은 아닙니다: 서명이 메시지와 함께 이동하고 최종 수신자에서 검증됩니다. DKIM은 서명된 콘텐츠가 전송 중에 수정될 때만 깨집니다 — 메일링 리스트 제목 태그와 푸터가 고전적인 경우입니다 — 이것이 리스트 잔재가 DNS의 무언가가 아닌 DMARC 정책 단계적 적용으로 처리되는 이유입니다.

전달이 실패하지 않도록 -all에서 ~all로 전환해야 하나요? 한정자를 변경해도 전달자가 통과하지 못합니다 — 그것이 실패하는 이유가 아닙니다. Namecheap의 전달 include, 7,355,985 도메인과 센서스의 가장 큰 전용 전달 집단(2026-06-29)이 엄격한 SPF 비율 <0.1%로 제공된다는 것이 시사적입니다: 느슨한 SPF는 틀림없이 전달 제품의 올바른 템플릿입니다. 한정자가 실제로 무엇을 변경하는지는 ~all 대 -all 보고서를 참고하세요.

직접 발송할 때는 SPF를 통과하는데 누군가 전달하면 실패하는 이유는? 수신자는 마지막으로 전송한 서버의 IP가 귀사 Return-Path 도메인의 SPF 레코드에 승인되어 있는지 확인합니다. 직접: 귀사 서버, 레코드에 있음, 통과. 전달됨: 전달자 서버, 레코드에 없음, 실패. 귀사 레코드는 변경되지 않았습니다 — 전송 IP가 변경된 것입니다.

이것을 수정하기 위해 SRS를 설정할 수 있나요? 귀사가 전달자인 경우에만. SRS는 전달을 수행하는 서버에서 실행되며, 실행되는 곳에서도 결과적인 SPF 통과는 전달자 도메인에 속하고 귀사 From과 정렬되지 않습니다 — 귀사 DMARC는 여전히 DKIM 다리가 필요합니다.

전달이 어차피 깨뜨린다면 SPF는 의미가 없나요? 아닙니다. 대부분의 메일은 SPF가 의도한 대로 정확히 작동하는 직접 전달로 이루어지며, 여전히 두 DMARC 다리 중 하나로 남습니다. 센서스(2026-06-29)의 261,086,232 도메인 중 138,927,207개가 SPF를 게시합니다 — SPF 수정 페이지를 통해 귀사 것을 정확하게 유지하고, DKIM이 전달된 나머지를 담당하게 하세요.

보고서를 담당자에게 전달하세요

고객이나 고용주를 위해 이것을 수정하는 경우, 증거로 루프를 닫으세요. 커스텀 도메인 DKIM이 작동하고 DMARC가 단계적으로 적용되면, 무료 검사를 다시 실행하고 비즈니스 오너에게 등급 보고서를 전달하세요: 날짜가 기재되고, 일반 언어로, 메일이 전달되더라도 도메인이 인증된 상태로 유지됨을 보여줍니다. 그것이 사이버 보험 갱신과 다음 공급업체 설문지를 위한 결과물입니다 — 이전-이후가 문서화된, “무언가를 켰어요”가 아닌.

도메인 확인하기 → · DMARC 실패하지만 SPF와 DKIM은 통과 → · DKIM 수정 → · 등급 산정 방식 → · 집계 데이터만 사용. 데이터는 EU 내에서 저장 및 처리됩니다.