SPF와 DKIM이 통과했는데 DMARC가 실패한다? 정렬 수정 방법 (2026)

게시일 2026-07-08

데이터 기준: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인의 집계 센서스 데이터입니다. 등급 방법론 보기.

DMARC는 통과 이상을 필요로 합니다 — SPF 또는 DKIM을 통과한 도메인이 From 도메인과 일치해야 합니다. 대부분의 “SPF 통과, DMARC 실패” 메일은 귀하의 반송 도메인이 아닌 공급업체의 반송 도메인에서 SPF를 통과했습니다. Defaults.Exposed 센서스(2026-06-29)에 따르면 등급을 받은 261,086,232개 도메인 중 7.4%만이 시행 DMARC 정책 아래에서 정렬과 함께 SPF를 통과합니다.

수정 방법은 혼란보다 빠릅니다. Authentication-Results 헤더를 읽어 어느 다리 — SPF 또는 DKIM — 가 잘못된 도메인에서 통과하는지 확인하세요. 그런 다음 발신 서비스의 사용자 지정 도메인 DKIM 서명을 활성화하거나(일반적으로 몇 개의 CNAME, 전달에서도 살아남는 수정), 사용자 지정 return-path를 설정하여 SPF가 귀하의 도메인에서 통과하도록 하세요. 정렬된 다리 하나만 있으면 DMARC가 필요로 하는 전부입니다.

SPF와 DKIM이 모두 통과했는데 DMARC가 실패하는 이유는 무엇인가요?

DMARC는 “SPF가 통과했나요?”를 묻지 않기 때문입니다. DMARC는 묻습니다: SPF 또는 DKIM이 수신자가 보는 From 주소와 일치하는 도메인에 대해 통과했나요? 이 추가 조건을 정렬이라고 하며, 이것이 DMARC의 핵심입니다 — 없다면 누구든 자신이 소유한 도메인에서 SPF를 통과하면서 From 헤더에 귀하의 도메인을 표시할 수 있습니다.

각 검사는 다른 도메인을 인증합니다:

검사	실제로 평가하는 도메인	확인 위치
SPF	Return-Path(RFC5321.MailFrom, 반송/봉투 발신 주소) — From 헤더가 아님	Authentication-Results의 `smtp.mailfrom=`
DKIM	서명의 `d=` 태그의 도메인 — 서명자가 선택한 것	Authentication-Results의 `header.d=`
DMARC	귀하의 From 헤더 도메인 — SPF 도메인 또는 DKIM의 `d=`가 일치해야 함	Authentication-Results의 `header.from=`

다음이 일반적으로 문제가 발생하는 방식입니다: 뉴스레터 플랫폼이나 CRM이 [email protected]과 같은 Return-Path로 발송하고, SPF는 vendor.com에 대해 확인되어 통과하며, DKIM은 d=vendor.com으로 통과합니다 — 그리고 DMARC는 통과한 도메인 중 어느 것도 yourcompany.com과 일치하지 않으므로 실패합니다. 모든 검사가 사실을 말했지만, 귀하를 인증한 것은 없습니다. 자체 SPF 레코드를 편집해서는 이를 수정할 수 없습니다 — 레코드가 참조조차 되지 않았습니다. SaaS 도구에서 SPF 실패와 동일한 함정입니다.

센서스는 얼마나 적은 발신자가 마지막 단계를 완료하는지 보여줍니다: 등급을 받은 261,086,232개 도메인 중 27,640,987개(10.59%)가 시행 DMARC 정책을 가지고 있으며, 7.4%만이 정렬과 함께 SPF를 통과합니다. softfail(~all)로 끝나는 77.5백만 도메인 중 9.2%만이 시행 DMARC 정책 아래 있고; hardfail(-all) 발행자 중 12,142,351개가 시행되는 반면 42,514,532개는 그렇지 않습니다. 대부분의 도메인은 “SPF 통과” 단계에서 멈춥니다 — DMARC 없이는 거의 아무것도 보호하지 않는 것입니다.

Authentication-Results를 어떻게 읽어 어느 다리가 정렬되지 않았는지 확인하나요?

실패 서비스를 통해 자신에게 메시지를 발송하고, 원본 소스를 열고, Authentication-Results 헤더를 찾으세요. 일반적인 정렬되지 않은 결과는 다음과 같습니다:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

세 가지 비교로 읽으세요:

SPF 다리: smtp.mailfrom=이 귀하의 도메인으로 끝나나요? 여기서는 bounces.espmail.net — 정렬되지 않음.
DKIM 다리: header.d=가 귀하의 도메인으로 끝나나요? 여기서는 espmail.net — 정렬되지 않음.
DMARC 판정: header.from=이 DMARC가 방어하는 도메인입니다. 어느 다리도 일치하지 않아 dmarc=fail — 두 개별 검사가 pass라고 해도.

이미 귀하의 도메인을 포함하거나 포함할 수 있는 다리가 수정할 것입니다. 하나만 필요합니다.

relaxed 정렬과 strict 정렬의 차이점은 무엇인가요?

DMARC는 DMARC 레코드의 aspf(SPF) 및 adkim(DKIM) 태그로 설정하는 두 가지 매칭 모드를 제공합니다:

Relaxed(r, 기본값): 두 도메인이 동일한 조직 도메인 — 공개 접미사 목록 기준의 등록 가능한 도메인 — 을 공유해야 합니다. bounce.yourcompany.com은 yourcompany.com과 정렬됩니다. DKIM d=mail.yourcompany.com도 마찬가지입니다. 이것이 서브도메인에 있는 공급업체 사용자 지정 return-path와 사용자 지정 DKIM이 작동하는 이유입니다.
Strict(s): 도메인이 글자 하나하나 정확히 일치해야 합니다. bounce.yourcompany.com은 더 이상 yourcompany.com과 정렬되지 않습니다.

레코드에 aspf 또는 adkim이 언급되지 않았다면 relaxed 모드에 있습니다 — 거의 확실히 거기 있어야 합니다. Strict 모드는 대부분의 발신자에게 의미 있는 보안을 추가하지 않으며 설정한 모든 정당한 서브도메인 발신자를 자동으로 끊습니다. DMARC가 실패하고 레코드에 aspf=s 또는 adkim=s가 포함되어 있다면 그것 자체가 버그일 수 있습니다.

DMARC 정렬을 어떻게 수정하나요?

DNS를 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. DMARC 레코드와 정책, SPF 및 DKIM이 정렬되도록 설정되어 있는지, 다른 무엇이 잘못되었는지 보여줍니다 — 올바른 다리를 먼저 수정하도록.
각 발신 서비스를 테스트하고 Authentication-Results를 읽으세요(위와 같이). 모든 소스 — 메일박스 제공업체, 뉴스레터 도구, CRM, 청구 앱 — 을 나열하고 소스별로 smtp.mailfrom과 header.d가 귀하의 도메인인지 공급업체 도메인인지 기록하세요.
각 공급업체에 대해 사용자 지정 도메인 DKIM 서명을 활성화하세요 — 지속되는 수정. 모든 진지한 발신 서비스는 “도메인 인증”을 제공합니다: d=yourcompany.com(또는 relaxed 모드에서 정렬되는 서브도메인)으로 서명할 수 있게 해주는 몇 가지 CNAME 레코드. 정렬된 DKIM은 일반적으로 더 쉬운 수정이며 전달이 SPF를 설계상 끊기 때문에 전달에서도 살아남는 유일한 방법입니다.
SPF 정렬을 위해 공급업체의 사용자 지정 return-path를 활성화하세요(흔히 사용자 지정 반송 도메인이라고 함) — 일반적으로 공급업체를 가리키는 bounce.yourcompany.com과 같은 하나의 CNAME. SPF는 귀하의 조직 도메인에서 통과하고 정렬됩니다. 제공되는 경우 이를 수행하되, 정렬된 DKIM의 대체가 아닌 두 번째 다리로 취급하세요.
특정하고 이해된 이유가 없는 한 정렬을 relaxed 모드로 유지하세요 aspf=s/adkim=s 없이.
재스캔 후 두 다리를 확인하고 시행으로 이동하세요. p=none의 DMARC 정책은 보고하지만 아무것도 차단하지 않습니다. 실제 발신자가 정렬되면 보호하는 정책으로의 전체 경로는 DMARC 수정 페이지에 있으며, IONOS DMARC 설정과 같은 제공업체 연습에서 DNS 패널 클릭을 다룹니다.

SPF 정렬을 수정해야 하나요, DKIM 정렬을 수정해야 하나요?

발신 소스당 하나의 정렬된 다리가 필요합니다. 하나만 할 수 있다면 선택은 명확합니다:

수정	내용	전달에서 살아남나요?
정렬된 DKIM(사용자 지정 도메인 서명)	공급업체의 “도메인 인증” 패널의 몇 가지 CNAME	예 — 서명이 메시지와 함께 이동합니다
정렬된 SPF(사용자 지정 return-path/반송 도메인)	공급업체가 제공하는 경우 하나의 CNAME	아니요 — 모든 전달자의 IP가 공급업체의 IP를 대체합니다

알아야 할 특수 사례: Google Workspace와 Microsoft 365는 기본적으로 자체 폴백 도메인(gappssmtp.com, onmicrosoft.com)으로 메일을 DKIM 서명합니다 — DKIM이 pass를 표시하는 동안 DMARC는 여전히 실패합니다. 이것이 이 전체 문제의 가장 흔한 특정 사례이며, 자체 가이드가 있습니다: DKIM은 통과하지만 DMARC가 여전히 실패: 기본 서명 함정.

자주 묻는 질문

DMARC가 통과하려면 SPF와 DKIM 모두 정렬해야 하나요? 아니요 — 하나의 정렬된 통과로 충분합니다. 전달이 SPF 다리를 끊을 때 DKIM 다리가 DMARC 통과를 유지하도록 어쨌든 둘 다 정렬하는 것이 모범 사례입니다. 2026-06-29 센서스에서 등급을 받은 261,086,232개 도메인 중 3.87%만이 전체 SPF + DMARC + DKIM 삼위일체를 완료합니다.

ESP 대시보드는 SPF와 DKIM이 “확인됨”이라고 하는데 — 왜 DMARC가 여전히 실패하나요? “확인됨”은 일반적으로 공급업체 자체 발송이 공급업체 도메인에서 통과한다는 의미입니다. 사용자 지정 도메인 단계(DKIM CNAME, 사용자 지정 return-path)를 완료하지 않은 한, 메일은 귀하가 아닌 공급업체로 인증됩니다 — DMARC는 귀하의 From 도메인과 비교합니다.

정렬 없이 엄격한 -all SPF 레코드로 충분한가요? 아니요. 엄격한 한정자는 Return-Path 도메인에 대한 SPF의 판정을 강화하지만 DMARC는 여전히 해당 도메인이 귀하의 것이어야 합니다. 2026-06-29 센서스 기준으로 -all을 발행하는 도메인 중 12,142,351개만 시행 DMARC 정책 아래 있습니다 — 다른 42,514,532개는 어떤 정책도 적용하지 않는 엄격한 레코드를 가집니다.

더 많은 보안을 위해 strict 정렬(aspf=s/adkim=s)로 전환해야 하나요? 거의 아닙니다. Relaxed 정렬은 이미 동일한 등록 가능한 도메인을 요구하며, 스푸퍼는 이를 제어하지 않습니다. Strict 모드는 주로 자체 서브도메인 발신자를 끊습니다 — 정렬이 예상치 않게 실패할 때마다 확인하세요.

수신자가 전달한 메일에서만 DMARC가 실패합니다 — 같은 수정인가요? 이것은 전송 중에 죽어가는 SPF 다리입니다: 전달자의 서버가 귀하의 return-path에 대한 어떤 SPF 레코드에도 없습니다. 전달된 메일의 SPF는 수정할 수 없습니다. 정렬된 DKIM이 답입니다. 서명은 전달에서도 그대로 살아남습니다. 자세한 내용은 전달된 이메일에서 SPF 실패를 참조하세요.

소유자에게 보고서 보내기

클라이언트 또는 고용주를 위해 이를 수정하는 경우 증거로 마무리하세요. CNAME이 착지된 후 무료 스캔을 다시 실행하고 등급이 매겨진 보고서를 사업 소유자에게 전달하세요: 날짜가 있고 평문으로 SPF, DKIM, DMARC가 정렬되어 통과하는 것을 보여줍니다. 사이버 보험 갱신 및 다음 공급업체 보안 설문지에 필요한 증거물 — 단순히 “일부 DNS 레코드를 추가했다”가 아닌 작동하는 구성의 증거입니다.

도메인 확인 → · DKIM은 통과하지만 DMARC가 여전히 실패 → · DMARC 수정 → · 등급 방법론 → · 집계 데이터만. 데이터는 EU에서 저장 및 처리됩니다.