Defaults.Exposed › 수정 › Guides

DKIM은 통과하는데 DMARC는 실패: gappssmtp.com / onmicrosoft.com 기본 서명 함정 (2026)

게시일 2026-07-08

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.

메일이 공급자 기본 서명 — gappssmtp.com(Google Workspace) 또는 onmicrosoft.com(Microsoft 365)으로 끝나는 d= — 으로 DKIM을 통과하지만, 그 도메인이 From 도메인과 일치하지 않아 DMARC가 정렬된 통과를 받지 못합니다. 사용자 정의 도메인 서명을 활성화하여 수정하세요. Defaults.Exposed의 261,086,232개 평가 도메인 센서스에 따르면 Google 메일 서버를 승인하는 12,145,313개 도메인 중 18.5%만이 DMARC를 적용합니다.

수정은 이메일 인증에서 가장 깔끔한 것 중 하나입니다: 사용자 정의 도메인 DKIM 서명을 켜세요. Google Workspace에서는 관리 콘솔의 “이메일 인증” 화면입니다 — 키 생성, TXT 레코드 하나 게시, 켜기. Microsoft 365에서는 Defender 포털의 DKIM 페이지입니다 — 두 개의 셀렉터 CNAME 게시, 활성화. 20분 작업으로 DMARC가 기다리던 정렬된 통과를 드디어 얻게 됩니다.

DKIM은 통과하는데 DMARC가 여전히 실패하는 이유는 무엇인가요?

DMARC는 “유효한 DKIM 서명이 있나요?”를 묻지 않기 때문입니다 — “From 헤더의 도메인에 대한 유효한 DKIM 서명이 있나요?”를 묻습니다. 두 번째 조건을 정렬이라고 하며, 이것이 DMARC의 전체 요점입니다: 수신자가 보는 도메인이 서명한 도메인임을 증명하는 것.

기본적으로 Google Workspace는 yourdomain-com.20230601.gappssmtp.com 같은 도메인으로(날짜 스탬프는 도메인마다 다름), Microsoft 365는 yourtenant.onmicrosoft.com으로 메일을 서명합니다. 두 서명 모두 암호화적으로 유효합니다 — DKIM 확인 도구는 통과라고 합니다 — 하지만 d= 도메인은 여러분이 아닌 Google 또는 Microsoft에 속합니다. 조직 도메인이 일치해야 한다는 DMARC의 완화된 정렬 조건에서도 gappssmtp.com은 yourdomain.com이 아닙니다. 일치 없음, 정렬된 통과 없음, 그리고 SPF도 정렬되지 않으면(종종 그렇습니다 — 수신자는 From 헤더가 아닌 Return-Path 도메인에 대해 SPF를 평가하며, 전달(forwarding)은 완전히 깨뜨립니다), DMARC는 실패합니다.

이것이 공급자 기본값의 핵심 함정입니다: 기본값은 배달성을 제공하고 보호는 제공하지 않습니다 — 정렬이 빠진 열쇠 한 번 더 돌리기입니다. 센서스는 얼마나 많은 발신자가 기본값에서 멈추는지 보여줍니다: _spf.google.com을 통해 Google 메일 서버를 승인하는 12,145,313개 도메인 중(전 세계 138,927,207개 SPF 게시자 중), 18.5%만이 DMARC를 적용합니다. Microsoft 그림도 같은 모양입니다: 10,205,070개 도메인이 spf.protection.outlook.com을 승인하고, 85.0%가 M365 설정이 제공하는 엄격한 SPF 레코드를 가지며 — 21.7%만이 DMARC를 적용합니다. 전체 비교는 이메일 공급자 SPF 리그 테이블에 있습니다.

이 함정은 일상적인 사용에서 보이지 않습니다: 메일이 배달되고, 받은 편지함 테스트는 괜찮아 보이고, 아무것도 오류가 없습니다 — DMARC 정책을 게시하면 자체 메일이 실패하기 시작할 때까지. 무료 스캔이 정확히 이 격차를 드러냅니다.

Authentication-Results에서 기본 서명 함정을 어떻게 발견하나요?

보낸 메시지를 열고(Gmail 또는 Outlook 사서함으로), 원본/원시 소스를 보고, Authentication-Results 헤더를 찾으세요. 징후는 잘못된 d=와 함께 DKIM 통과 — Gmail에서 받은 예시:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

세 가지 질문으로 읽으세요:

Microsoft에서 받은 메일에서는 compauth=fail과 함께 dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com으로 같은 이야기가 나타납니다 — Outlook 거부 가이드에서 다루는 패턴.

헤더에 대신 두 개 dkim=pass와 spf=pass 및 DMARC 실패가 표시되면 더 넓은 정렬 경우입니다 — SPF와 DKIM은 통과하는데 DMARC가 실패 가이드에서 완화된 vs 엄격한 정렬을 완전히 설명합니다.

사용자 정의 도메인 DKIM 서명을 어떻게 활성화하나요?

1. 무언가 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 도메인에 정렬된 DKIM이 있는지, DMARC 정책이 실제로 어떤지, 이 수정 후에 무엇이 여전히 차단하는지(SPF, DMARC 레코드 구문) 보여줍니다 — 전체 작업을 한 번에 하도록.
2. 어떤 기본값으로 서명하는지 확인하세요. 위처럼 Authentication-Results에서 header.d=를 확인하세요: gappssmtp.com은 Google Workspace 기본값, onmicrosoft.com은 Microsoft 365 기본값을 의미합니다.
3. Google Workspace: 자체 키를 생성하고 게시하세요. 관리 콘솔에서 앱 → Google Workspace → Gmail → 이메일 인증으로 이동하고, 도메인을 선택하고 새 레코드 생성을 클릭하세요(DNS 호스트가 저장할 수 없지 않은 한 2048비트). 제공되는 TXT 레코드를 google._domainkey.yourdomain.com에 게시하고, DNS를 기다리고(최대 48시간), 그런 다음 — 사람들이 놓치는 단계 — 인증 시작을 클릭하세요. 레코드를 생성한다고 서명이 켜지지 않습니다. 전체 안내: Google Workspace에서 DKIM 설정.
4. Microsoft 365: 두 개의 셀렉터 CNAME을 게시하고 활성화하세요. Defender 포털에서 이메일 및 공동 작업 → 정책 및 규칙 → 위협 정책 → 이메일 인증 설정 → DKIM으로 이동하고, 사용자 정의 도메인을 선택하고 키를 생성하세요. Microsoft가 보여주는 대상을 가리키는 두 CNAME — selector1._domainkey와 selector2._domainkey — 을 게시하고(포털에서 정확한 대상을 복사하세요 — 2025년 5월 이전에 활성화된 도메인은 테넌트의 .onmicrosoft.com으로 끝나고; 더 새로운 것은 .dkim.mail.microsoft로 끝남), 그런 다음 서명을 켜세요. 셀렉터 두 개는 선택 사항이 아닙니다: Microsoft가 그 사이에서 키를 교체합니다. 전체 안내: Microsoft 365에서 DKIM 설정.
5. 새 서명을 확인하세요. 외부 사서함에 새 메시지를 보내고 Authentication-Results를 다시 확인하세요: dkim=pass에 이제 header.d=yourdomain.com이 표시되어야 합니다. DNS 패널이 CNAME 대상에 영역을 자동 추가하거나 긴 TXT 값을 손상시킨 경우 서명이 전환되지 않습니다 — 대부분의 실패 여기에서는 공급자가 아닌 패널 특이사항이 원인입니다.
6. 재스캔 및 정렬된 통과 활용. 스캔에 정렬된 DKIM이 표시되는지 확인하고 활용하세요: p=none의 DMARC 정책은 아무것도 보호하지 않습니다. 평가된 261,086,232개 도메인 전체에서 10.59%만이 DMARC를 적용합니다(2026-06-29 기준 데이터) — 정렬된 DKIM은 적용을 안전하게 강화할 수 있게 하는 것입니다. DMARC 수정 방법에서 시작하세요.

사용자 정의 DKIM 활성화가 무언가를 깨뜨리나요?

아닙니다 — 이것은 사실상 영향 범위가 없는 드문 이메일 인증 수정입니다: 기본 서명으로 보내진 메일은 단순히 더 나은 서명으로 보내지며, 공급자가 계속 키를 관리합니다(Microsoft는 두 셀렉터 사이에서 자동으로 교체합니다). 실제 실패 모드는 절반만 하는 것 — Google TXT를 게시하고 인증 시작을 클릭하지 않거나, 두 개 모두 대신 M365 셀렉터 하나만 게시하는 것. 그리고 나중에 “정리하려고” DNS 레코드를 삭제하지 마세요; 키가 사라지는 순간 서명이 멈춥니다.

범위 참고: 이것은 Google 또는 Microsoft를 통해 보내는 메일을 수정합니다. 뉴스레터 도구와 CRM도 자체 기본값으로 서명하며, 각각 자체 사용자 정의 도메인 DKIM이 켜져야 합니다 — 그 패턴과 이제 그것을 요구하는 Gmail 대용량 발신자 규칙은 550-5.7.26 가이드에서 다룹니다.

자주 묻는 질문

DKIM은 모든 테스트 도구에서 “통과”로 표시됩니다 — 왜 무언가를 수정해야 하나요? 도구들이 DMARC보다 좁은 질문에 답하기 때문입니다. 서명은 유효합니다 — 하지만 그것은 gappssmtp.com의 또는 onmicrosoft.com의 것이지, 여러분의 것이 아니므로 DMARC 정렬에서 아무 의미가 없습니다. 이것이 많은 발신자가 기본값에서 멈추는 이유입니다: Google을 승인하는 12,145,313개 도메인 중 18.5%만이 DMARC를 적용합니다(2026-06-29 기준 데이터).

완화된 DMARC 정렬이 기본 서명을 통과시키나요? 아닙니다. 완화된 정렬은 조직 도메인으로만 일치를 완화합니다 — mail.yourdomain.com은 yourdomain.com과 정렬됩니다. 기본 서명의 조직 도메인은 gappssmtp.com 또는 onmicrosoft.com이며, 여러분의 것과 공유하는 것이 없습니다. 어떤 정렬 모드도 제3자 d=를 구제하지 않습니다.

gappssmtp.com / onmicrosoft.com 서명이 나쁜가요? 제거해야 하나요? 나쁘지 않습니다 — 메일에 어떤 유효한 서명이 있음을 보장하며, 스팸 필터링에 도움이 됩니다. 단지 여러분의 것이 아닐 뿐입니다. 제거하지 마세요; 사용자 정의 도메인 서명을 활성화하여 교체하세요.

내 도메인이 엄격한 SPF를 가진 Microsoft 365에 있습니다 — 이미 보호받고 있나요? 아마 아닙니다: 그 엄격한 레코드는 하나의 역할을 하는 M365 기본값입니다. spf.protection.outlook.com을 승인하는 10,205,070개 도메인 중 85.0%는 엄격한 SPF를 가지지만 21.7%만이 DMARC를 적용합니다(2026-06-29 기준 데이터). SPF는 From 헤더가 아닌 Return-Path에 대해 평가되기 때문에 전달(forwarding) 시 깨지며 — 정렬된 DKIM이 살아남는 요소입니다. 바로 이것이 이 수정이 중요한 이유입니다.

수정하는 데 얼마나 걸리나요? 콘솔 작업은 공급자당 몇 분입니다. DNS가 기다림입니다: Google은 인증을 시작하기 전에 최대 48시간을 허용하라고 합니다; Microsoft CNAME은 보통 몇 시간 안에 활성화됩니다. 대부분 기다리는 시간인 종일 하루를 예산하세요.

소유자에게 보고서 전달

클라이언트나 고용주를 위해 수정하는 경우 증거로 마무리하세요. 새 서명이 활성화되면 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 날짜 기록, 알기 쉬운 언어, 도메인과 정렬된 DKIM 표시. 사이버 보험 갱신과 다음 공급업체 보안 설문지를 위한 증거물입니다 — gappssmtp.com의 하위 테넌트가 아닌 자체 도메인으로 인증함을 증명합니다.

DKIM 정렬 무료 확인

메일이 자체 도메인으로 서명되는지 — 그리고 정확히 무엇을 수정해야 하는지 — 비공개로, 소유자만 확인하세요.

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