DMARC 보고서 분석기

수신자가 보내는 집계 보고서 파일 — .xml, .xml.gz, 또는 여러 개가 든 .zip — 을 끌어다 놓으면 XML이 묻어 두는 정보를 돌려받습니다: 어떤 출처가 내 도메인으로 발송하는지, 그중 얼마나 SPF와 DKIM 정렬을 통과하는지, 둘 다 실패한 것은 무엇인지, 무엇을 먼저 고쳐야 하는지를 쉬운 말로 알려 줍니다. 모든 압축 해제와 파싱은 브라우저 안에서 이루어집니다. 파일은 절대 브라우저를 떠나지 않습니다. DMARC 보고서는 누가 내 메일을 보내는지 — 그리고 누가 보내는 척하는지 — 를 보여 주는 지도이기 때문입니다.

또는 이 상자 안 어디에든 파일을 끌어다 놓으세요. 서로 다른 수신자와 서로 다른 날짜의 보고서는 출처별로 묶여 하나의 표로 합쳐집니다.

샘플은 지어낸 것입니다: 정상 발신자 하나, 전달자 하나, 정렬되지 않은 마케팅 플랫폼 하나, 모든 것에 실패하는 알 수 없는 출처 하나.

집계 보고서란 실제로 무엇인가

DMARC에는 두 개의 절반이 있습니다. 첫 번째는 내가 게시하는 레코드 — 정책, 정렬 모드, 보고 주소 — 로, 이 사이트의 이메일 전달 가능성 검사를 포함해 모든 검사기가 읽을 수 있는 절반입니다. 두 번째 절반은 피드백 루프입니다. 내 도메인에서 온 것이라고 주장하는 메일을 본 대형 수신자는 각각 본 내용을 요약해, 보통 하루에 한 번 XML로 내 rua 주소에 보냅니다. 그 파일이야말로 또 누가 나로서 발송하는지에 대한 유일한 증거입니다. 스푸핑 캠페인, 동료가 2년 전에 연결한 마케팅 플랫폼, 폐기된 서버를 아직 쓰는 모니터링 서비스 — 누군가 읽기만 한다면 이 모든 것은 다른 어디보다 몇 주 먼저 집계 보고서에 나타납니다. 거의 아무도 읽지 않습니다. 중첩된 policy_evaluated 요소를 가진 원시 XML은 거의 읽을 수 없고, 파일은 gzip으로 압축된 채 메일함에 쌓이기 때문입니다. 이 분석기가 메우는 것이 바로 그 간격입니다. 같은 파일을 출처와 판정의 표로 바꾸고, 각 실패를 필요한 수정으로 번역합니다. 함께 제공되는 가이드 DMARC 보고서 읽는 법은 완전히 풀어 낸 예시와 함께 이 형식의 용어 — 처리 방식, 정렬, 인증 결과와 정렬된 결과의 차이 — 를 설명합니다.

두 가지 습관이 보고서의 가치를 높입니다. 첫째, 강제하기 전에 읽으세요. 보고가 딸린 p=none 정책은 감시 시스템이며, 그것이 돌아가는 몇 주가 모든 합법적 발신자를 알게 되는 시간이라, 검역과 거부로 옮겨 가도 진짜인 것은 깨지지 않습니다. 둘째, 알 수 없는 출처는 모두 호기심이 아니라 티켓으로 다루세요 — 식별하거나, 정렬하거나, 강제가 끊는 것을 지켜보되, 인식할 수 없는 흐름을 “아마 괜찮을 것” 더미에 절대 두지 마세요. 스푸핑이 숨어 있는 곳이 바로 그 더미이기 때문입니다. 집계 보고서가 의도적으로 포함하지 않는 것에 주목하세요. 메시지 본문도, 제목 줄도, 수신자 주소도 없습니다. 출처별 개수와 판정이므로 공급업체의 지원 팀과 공유할 수 있습니다 — 도구에 업로드하는 형태가 아니라, 의도적으로 건네는 파일로서 말입니다. 이 페이지는 그 속성을 유지합니다. 분석은 파일이 이미 있는 곳, 내 컴퓨터에서 일어납니다.

자주 묻는 질문

DMARC 집계 보고서란 무엇인가요?

수신자(Google, Microsoft, Yahoo 등)가 내 DMARC 레코드의 rua 태그에 있는 주소로 매일 보내는 피드백 파일입니다. 내 도메인이라고 주장하며 메일을 보낸 각 출처에 대해 보고서는 출처 IP, 메시지 수, 수신자가 적용한 처리 방식, 그리고 SPF와 DKIM이 내 From 도메인과 정렬되었는지를 나열합니다. 내 도메인의 스푸핑이 혼란스러운 고객의 불평이 아니라 데이터로 드러나는 유일한 장소입니다. 가이드 DMARC 보고서 읽는 법은 실제 보고서를 한 줄씩 따라갑니다.

내 도메인에 대한 이 보고서를 받으려면 어떻게 하나요?

보고 주소가 있는 DMARC 레코드 — v=DMARC1; p=none; rua=mailto:[email protected] — 를 게시하면 수신자는 하루쯤 뒤부터 보내기 시작합니다. 아직 레코드가 없거나 있는 레코드를 확인하고 싶다면 먼저 이메일 전달 가능성 검사를 실행하세요. 레코드와 정책, 보고 주소가 게시되었는지를 읽어 줍니다. 보고서는 작은 XML 파일로 도착하는데, 보통 gzip으로 압축되었거나 zip으로 묶여 있으며, 바로 이 분석기가 여는 형식입니다.

여기서 보고서를 열어도 안전한가요? 파일은 어디로 가나요?

아무 데도 가지 않습니다. 파일은 이 페이지 안, 브라우저에서 압축이 풀리고 파싱됩니다. 업로드도, 전송도, 저장도 되지 않습니다. 의도적인 설계입니다. 집계 보고서는 내 메일 인프라의 지도 — 내가 쓰는 모든 발송 서비스, 모든 IP, 나를 겨냥한 모든 스푸핑 — 이기 때문입니다. 그 지도를 낯선 사람의 서버에 업로드하거나 로그를 남기는 AI 채팅에 붙여넣는 것은, 지도를 애초에 받을 사람이 아닌 이들에게 건네는 일입니다.

모르는 출처가 SPF와 DKIM 둘 다 실패합니다. 스푸핑인가요?

스푸핑이거나 아무도 알려 주지 않은 발신자입니다 — 그리고 보고서만으로는 둘을 가를 수 없습니다. 그래서 분석기는 이를 판정이 아니라 추적해야 할 질문으로 표현합니다. 순서대로 확인하세요. 그 IP가 내 조직이 비용을 내는 공급업체(CRM, 지원 데스크, 오래된 마케팅 도구, 잊힌 모니터링 서비스)의 것인가요? 양은 꾸준하고 적은가요(잘못 구성된 내부 시스템), 아니면 폭발적이고 많은가요(캠페인)? 정책이 p=none인 동안 그 메일은 어느 쪽이든 배달됩니다. 모든 합법적 출처가 정렬되고 검역이나 거부를 강제하게 되면, 인식할 수 없는 흐름은 둘 중 무엇이었든 거부됩니다.

내 합법적인 메일이 실패하고 있습니다. 무엇을 먼저 고쳐야 하나요?

정렬입니다. 거의 항상 공급업체 쪽에서 고칩니다. SPF가 정렬되지 않는 것은 공급업체가 자기 반송 도메인으로 보내기 때문인데, 사용자 지정 return-path 하위 도메인으로 봉투 도메인을 내 것으로 만들면 고쳐집니다. DKIM이 정렬되지 않는 것은 공급업체가 자기 도메인으로 서명하거나 아예 서명하지 않기 때문인데, 공급업체 설정에서 내 도메인으로 DKIM 서명을 켜면 고쳐집니다. 하나의 메커니즘만 정렬되어도 DMARC를 통과하지만, DKIM은 전달을 견뎌 내므로 둘 중 더 튼튼합니다. 발신자를 양이 많은 순으로 고치고, 다음 보고서가 깨끗해지는 것을 지켜본 뒤에야 정책을 올리세요.