DMARC 리포트 읽기
도메인에 DMARC 레코드가 있다면 대형 메일 업체들은 매일 보고서(압축된 XML 파일)를 보내옵니다. 그 도메인의 이름으로 메일을 보낸 모든 서버가 담긴 보고서입니다. 당신의 이름으로 발송되는 모든 것의 목록을 얻을 수 있는 유일한 방법이며, 여기에는 잊고 있던 회사 내부의 발신원도 포함됩니다.
- 브라우저 안에서 전부 처리됩니다
- 오프라인에서도 작동합니다
- 업로드 없음
- 가입 없음
- 워터마크 없음
도구를 불러오는 중…
작동 방식
- DMARC 레코드에 지정된 수신함(rua= 주소)에서 보고서 첨부 파일을 저장하거나, 메시지에서 바로 끌어내세요.
- 한꺼번에 여기로 끌어다 놓으세요. .xml, .xml.gz, .zip 모두 인식합니다.
- 먼저 실패하는 발신원부터 보세요. 각각은 당신 쪽에서 고쳐야 할 것이거나, 누군가 당신의 도메인을 위조해서 보내는 것입니다.
왜 아무것도 업로드되지 않는가
이 페이지가 하는 모든 작업은 브라우저 탭 안에서 도는 코드가 처리합니다. 웹 페이지를 그리는 그 엔진을 그대로 씁니다. 파일은 디스크에서 탭의 메모리로 읽어 들여 거기서 변환한 뒤 다시 다운로드 파일로 내보냅니다. 어디로도 전송되지 않습니다. 우리에게도, 제3자에게도.
직접 확인해 보세요
- 브라우저 개발자 도구(F12)를 열고 네트워크(Network) 탭을 선택합니다.
- 파일을 올리고 도구를 실행합니다.
- 보이는 요청은 도구 자체의 코드를 받아 오는 것뿐입니다. 무거운 몇몇 도구는 공개 CDN에서 오픈소스 엔진을 함께 받아 옵니다. 여기에 loreatec.jp로 가는 작은 방문 집계 신호 하나(페이지 주소와 제목, 그 이상은 없습니다)가 더해집니다. 어느 것도 당신의 파일을 실어 나르지 않습니다.
자주 묻는 질문
보고서가 왜 .gz로 오기도 하고 .zip으로 오기도 하나요?
표준이 각 보고 기관에 선택을 맡기기 때문입니다. Google은 .zip으로, Microsoft를 비롯한 대부분은 .xml.gz로 보냅니다. 이 뷰어는 셋 다 브라우저 안에서 엽니다. gzip은 브라우저 자체의 압축 해제 기능을 쓰고, zip은 함께 포함된 오픈소스 라이브러리를 씁니다.
어떤 발신원은 SPF는 통과했는데 DMARC는 실패로 나옵니다. 어떻게 그럴 수 있나요?
DMARC가 말하는 “정렬(alignment)” 문제입니다. SPF 통과는 어떤 도메인이 그 서버에 발송을 허가했다는 뜻일 뿐입니다. 이때 확인하는 도메인은 수신자에게 보이는 From 줄이 아니라 숨겨진 반송 주소입니다. DMARC는 이 둘이 일치할 것까지 요구합니다. 자신의 반송 주소로 발송하는 메일 발송 서비스는 자기 자신에 대해서는 SPF를 통과하지만 당신 입장에서는 정렬에 실패합니다. 해결책은 그 서비스에 전용 반송 주소(return-path)를 설정하거나, 당신의 도메인으로 서명된 DKIM에 의존하는 것입니다.
p=reject로 넘어가기 전에 무엇을 해야 하나요?
이 표에서 실패하는 발신원을 모두 파악해야 합니다. 오래된 서버, CRM, 결제 대행사, 스캐너처럼 정당한 것들도 있을 겁니다. 이들은 각각 SPF나 DKIM을 제대로 설정해야 합니다. 그러고도 남는 것이 위조이며, 그것을 거부하는 것이 바로 DMARC의 목적입니다. 파악되지 않은 발신원이 목록에 남아 있는 채로 reject로 바꾸면 정상적인 메일도 예고 없이 사라집니다.
이 파일들이 브라우저 밖으로 나가나요?
아닙니다. 압축 해제와 분석 모두 여기서 이뤄집니다. DMARC 보고서는 특히 더 조심해야 하는데, 당신을 대신해 메일을 보내는 모든 것의 IP 주소가 들어 있기 때문입니다. 즉 당신의 인프라 지도나 다름없습니다.
포렌식 보고서(ruf)는 어떤가요?
그것은 요약본이 아닙니다. 실패한 메시지 하나하나가 평범한 메일 형태로 그대로 옵니다. .eml 뷰어나 헤더 분석기로 열어 보세요. 대형 수신 업체 대부분은 개인정보 문제로 아예 보내지 않습니다.