Defaults.Exposed › 수정 › Guides

"DMARC 정책 미활성화": 검사기가 의미하는 것과 솔직한 5분 첫 번째 단계 (2026)

게시일 2026-07-08

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

“DMARC policy not enabled”는 두 가지 다른 의미 중 하나입니다: 도메인에 DMARC 레코드가 전혀 없거나, p=none으로 설정된 레코드가 있습니다. Defaults.Exposed 센서스에 따르면 DMARC 정책을 적용하는 도메인은 261,086,232개 중 27,640,987개 — 10.59%에 불과합니다. 모니터링 레코드 게시에는 5분이 걸리며; 적용은 프로젝트입니다.

이 가이드는 경고를 해독하고, 게시할 정확한 TXT 레코드와 정확히 어디에 넣을지 알려주고, 첫 시도를 실패하게 하는 구문 오류를 안내하고, 첫 주의 DMARC 보고서가 어떻게 보이는지에 대한 솔직한 기대치를 설정합니다. 의도적으로 “5분에 DMARC 수정” 가이드가 아닙니다 — 5분은 가시성을 제공하지, 보호를 제공하지 않습니다.

”DMARC policy not enabled”는 실제로 무슨 의미인가요?

MXToolbox 같은 검사기들은 두 가지 다른 결과를 하나의 주황색 경고로 합칩니다. 수정 경로는 어느 것을 가지고 있느냐에 달려 있습니다:

2026-06-29 기준 데이터.

첫 번째 행이 대부분의 인터넷이 있는 곳입니다: 평가된 도메인의 75.11%가 DMARC 레코드를 전혀 게시하지 않으며, 또 다른 14.29%가 p=none에 있습니다. 마지막 행의 역이 중요한 숫자입니다: 센서스의 261,086,232개 평가 도메인 중 89.41%의 도메인에 적용된 DMARC 정책이 없습니다. 검사기가 경고를 표시하면 압도적 다수에 속합니다. 그것은 안심이 아닙니다; 사칭이 저렴하게 유지되는 이유입니다.

나중에 혼란을 없애는 한 가지 설명: DMARC는 수신자가 실제로 보는 From 헤더에 대해 확인되는 SPF와 DKIM 위의 정책 레이어입니다. “Not enabled”는 수신자에게 아직 아무것도 하라고 말하지 않았다는 의미입니다. 세 가지 정책 값이 새로운 경우 알기 쉬운 설명은 DMARC란 무엇인가: none, quarantine, reject에 있습니다.

5분 안에 솔직하게 무엇을 수정할 수 있나요?

레코드를 게시하는 것. 그것이 전체 솔직한 주장입니다.

v=DMARC1; p=none; rua=mailto:[email protected]

이 TXT 레코드가 활성화되고 5분 후, DMARC를 확인하는 수신자들이 여러분의 도메인으로 메일을 보내는 사람 — 합법적인 서버와 사칭자 모두 — 에 대한 일일 보고서를 컴파일하기 시작합니다. 그 가시성은 진정으로 가치 있고 진정으로 즉각적입니다.

하지 않는 것: p=none은 아무것도 보호하지 않습니다. 사칭 메일은 어제처럼 배달되며, 내일 다시 스캔하는 검사기가 여전히 “정책 미활성화”라고 할 수 있습니다 — 올바르게, 녹색 체크는 quarantine 또는 reject을 위한 것이기 때문입니다. p=none이 보호가 아닌 이유에 이유를 설명했습니다; 실제로 사칭을 차단하는 정책으로의 단계적 경로는 p=none에서 p=reject로에 있습니다. 아래의 5분 단계는 시작하는 방법이며; 그 가이드는 마치는 방법입니다.

첫 번째 DMARC 레코드를 어떻게 게시하나요?

1. DNS를 건드리기 전에 무료 스캔을 실행하세요. 실제로 어떤 두 가지 결과를 가지고 있는지 — 레코드 없음 vs. p=none — 그리고 SPF와 DKIM이 아래에 있는지 알려줍니다. 나중에 얼마나 빨리 적용으로 이동할 수 있는지를 결정합니다.
2. 보고서를 받을 주소를 선택하세요. dmarc-reports@yourdomain 같은 전용 사서함으로 시작하면 됩니다. 대신 보고서 분석 서비스를 사용한다면 아래 FAQ를 참조하세요 — 제3자 주소에는 조용한 함정이 있습니다.
3. 호스트 _dmarc에 TXT 레코드를 추가하세요. 대부분의 DNS 제어 패널에서(IONOS DMARC 설정 가이드에서 실제 예시 참조) 호스트/이름 필드에 _dmarc를 입력하면 패널이 도메인을 자동으로 추가하여 _dmarc.yourdomain.com을 생성합니다. 값: v=DMARC1; p=none; rua=mailto:[email protected]
4. 해석되었는지 확인하세요. dig TXT _dmarc.yourdomain.com(또는 온라인 검사기)이 v=DMARC1로 시작하는 정확히 하나의 레코드를 반환해야 합니다. 대부분의 DNS 변경은 몇 분 안에 보입니다; 낮은 TTL이 도움이 됩니다.
5. 재스캔하세요. 보고서에 모니터링 모드로 DMARC가 존재한다고 표시됩니다 — 현재 위치의 솔직한 반영: 보고 활성, 적용 대기 중.

하나의 레코드가 하위 도메인도 커버합니다: mail.yourdomain.com에서 레코드를 찾지 못하는 수신자는 조직 도메인의 정책으로 폴백하므로, 모니터링을 시작하기 위해 하위 도메인마다 레코드가 필요하지 않습니다.

레코드를 추가할 때 가장 흔한 실수는 무엇인가요?

거의 모든 첫 번째 시도 실패는 이것들 중 하나입니다 — 파싱할 수 없는 레코드는 레코드가 없는 것으로 처리되기 때문에 중요합니다. 센서스는 파싱에 실패하는 48,648개의 게시된 DMARC 레코드를 집계합니다; 실제로 게시되는 오타는 DMARC 오타 센서스에 카탈로그화되어 있습니다.

• 잘못된 호스트. 레코드는 apex가 아닌 _dmarc.yourdomain.com에 있어야 합니다. 기본 도메인에서는 아무것도 하지 않으며, 검사기는 계속 “no DMARC record found”를 보고합니다.
• 도메인 이중 추가. 자동 추가하는 패널에 _dmarc.yourdomain.com을 입력하면 _dmarc.yourdomain.com.yourdomain.com이 됩니다. _dmarc만 입력하세요.
• 세미콜론 대신 쉼표. 태그는 ;로 구분됩니다. 파싱할 수 없는 레코드는 레코드가 없는 것으로 처리됩니다.
• v=DMARC1 누락 또는 잘못된 위치. 첫 번째 태그여야 하며 정확히 그 철자여야 합니다; p=로 시작하는 레코드는 파싱에 실패합니다.
• rua에서 mailto: 누락. rua=dmarc@yourdomain은 유효하지 않습니다; rua=mailto:[email protected]이어야 합니다.
• 두 개의 DMARC 레코드. 하나 이상의 v=DMARC1 레코드를 찾는 수신자는 모두 무시합니다 — 다중 레코드 SPF와 같은 오류 패밀리.
• 복사-붙여넣기의 스마트 따옴표. 문서에서 몰래 들어온 구부러진 따옴표나 줄 바꿈 없는 공백이 파싱을 깨뜨립니다. 검사기에서 올바르게 보이는데 잘못된 형식이라고 하면 레코드를 다시 입력하세요.

1주차 rua 보고서는 어떻게 보이나요?

지금 기대치를 설정하여 깨졌다고 결론 내리지 않도록 하세요:

• 대략 일별로, 수신자별로 도착합니다. Google은 일반적으로 24시간마다 하나의 집계 보고서를 보냅니다; Microsoft, Yahoo 등은 자체 주기로. 소규모 도메인의 경우 1주차는 보통 몇 통의 이메일로, 대부분 [email protected]에서.
• 압축된 XML 첨부 파일입니다, 대시보드가 아닙니다. 원시 상태에서는 거의 읽을 수 없습니다; 무료 파서가 발신자 테이블로 변환합니다.
• 볼륨은 메일 볼륨을 추적합니다. 메일을 적게 보내거나 주로 보고하지 않는 공급자에게 보낸다면 드문 데이터를 예상하세요. 저볼륨 도메인의 경우 조용한 2주가 정상입니다 — 실패했다고 가정하기보다 dig으로 레코드를 확인하세요.
• 놀라움을 예상하세요. 대부분의 도메인이 잊혀진 발신자를 발견합니다 — CRM, 인보이스 도구, 문의 양식. 각각은 적용하기 전에 SPF 또는 DKIM이 정렬되어야 합니다. 보고서에서 SPF와 DKIM이 개별적으로 통과하는데 DMARC가 실패한다면 정렬 문제입니다 — DMARC는 실패하지만 SPF와 DKIM은 통과 참조.

그리고 보고서를 요청하세요: DMARC 레코드가 있는 도메인의 64.3%는 rua= 주소를 게시하지 않아 보고서를 받지 못합니다 — 그에 대한 센서스 분석은 DMARC 맹목적 게시에 있습니다. 여기서 배우는 모든 것이 적용 전환을 위한 것입니다 — 모니터링은 그 프로젝트의 1주차이지, 목적지가 아닙니다. p=none에 무기한 머무는 것이 도메인이 89.41%에 속하게 되는 가장 흔한 방법입니다.

자주 묻는 질문

p=none을 게시하면 이메일 배달성이 저하되나요? 아닙니다. p=none은 수신자가 메일을 처리하는 방식을 전혀 변경하지 않습니다 — 보고만 요청합니다. 도움이 될 수 있습니다: Google과 Yahoo의 대량 발신자 요구사항은 대용량 발신자에게 최소한 p=none DMARC 레코드를 요구하므로, 게시하는 것은 위험이 아닌 규정 준수 기준선입니다.

레코드를 게시했는데 검사기가 여전히 “정책 미활성화”라고 합니다 — 왜 그런가요? 사실을 말하고 있기 때문입니다: 정책이 none이며, 검사기는 quarantine 또는 reject을 위해 통과를 남겨둡니다. 모니터링하지만 적용하지 않는 도메인에 합류했습니다 — 2026-06-29 기준으로 평가된 261,086,232개 도메인 중 10.59%만이 적용합니다. 적용 전환을 완료하면 경고가 사라집니다.

DMARC를 추가하기 전에 SPF와 DKIM을 설정해야 하나요? 메일이 DMARC를 통과하려면 최소 하나가 정렬되어 있어야 합니다 — 하지만 p=none을 게시하기 전에 완벽할 필요는 없습니다. 모니터링은 정확히 무엇이 깨졌는지 찾는 방법입니다: 평가된 261,086,232개 도메인 중(2026-06-29 기준) 70,368,600개는 소프트 SPF와 DMARC 적용이 없으며, 보고서가 그들을 막는 것을 알아내는 방법입니다.

자체 사서함 대신 제3자 분석기에 보고서를 보낼 수 있나요? 예 — 하지만 다른 도메인의 rua 주소는 벤더가 인증 레코드(yourdomain._report._dmarc.vendor.com)를 게시해야 하며, 그렇지 않으면 수신자가 조용히 보고서를 보류합니다. 평판 좋은 서비스는 자동으로 이를 수행합니다; 보고서가 도착하지 않으면 먼저 이것을 확인하세요.

소유자에게 보고서 전달

클라이언트나 고용주를 위해 수정하는 경우 작업이 보이지 않게 두지 마세요. 레코드가 해석되면 무료 스캔을 다시 실행하고 등급 보고서를 전달하세요: DMARC가 없음에서 모니터링으로 이동하는 것이 타임스탬프와 알기 쉬운 언어로 보이고 — 적용 경로에서 다음 단계도 보여줍니다. 소유자들은 사이버 보험 갱신과 공급업체 보안 설문지를 위해 정확히 이 증거가 점점 더 필요하며, 한 페이지 등급 보고서가 DNS 패널 스크린샷보다 그 질문에 훨씬 잘 답합니다.

도메인 무료 확인

두 가지 결과 중 어느 것을 가지고 있는지 — 레코드 없음 또는 p=none — 그리고 그 아래 무엇이 있는지 비공개로, 소유자만 확인하세요.

도메인 확인하기 → · DMARC 수정 → · p=none에서 p=reject로 → · 평가 방식 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.