DMARC 보고서 이해와 Gmail 필터로 자동 정리
어느 날 아침, 받은편지함에 Google이 보낸 « Report domain: votre-domaine.fr Submitter: google.com Report-ID: … »라는 제목의 메일이 도착합니다. 압축된 첨부파일도 있습니다. 다음 날에는 Microsoft, 그다음에는 Yahoo와 다른 업체에서도 비슷한 메일이 옵니다. 설명 없이 파일만 달려 있습니다. 피싱일까요? 해킹일까요? 둘 다 아닙니다. 이것은 DMARC 집계 보고서이며, 오히려 좋은 소식입니다.
보고서의 의미와 2분 만에 읽는 방법, 그리고 잃어버리지 않으면서 받은편지함에서 치우는 방법을 알아봅니다. 거의 알려지지 않은 Gmail 기능인 XML 파일에서 필터 가져오기를 활용합니다.
30초 만에 이해하는 DMARC
서버가 votre-domaine.fr에서 보낸 것처럼 표시된 메일을 받으면 두 가지를 확인합니다.
- SPF: 발신 IP 주소가 해당 도메인에서 허용한 서버 목록에 있나요?
- DKIM: 도메인의 키를 가진 서버가 생성한 유효한 암호화 서명이 메일에 있나요?
DMARC는 이 두 검사를 통합합니다. 적어도 하나가 통과해야 하며, 수신자가 보는 « 보낸사람: » 필드의 도메인과 일치하는 '정렬' 조건도 충족해야 합니다. 실패 시 처리 방식은 _dmarc.votre-domaine.fr에 설정하는 간단한 DNS TXT 레코드로 지정합니다.
v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.frp는 정책을 지정합니다. none(모니터링만), quarantine(스팸함으로 이동), reject(수신 거부)입니다. 그리고 의문의 메일이 도착하는 이유는 rua에 있습니다.
보고서를 받는 이유
rua는 reporting URI for aggregate reports의 약자입니다. 주요 메일 서비스에 해당 도메인 명의로 수신한 메시지의 집계 내역을 보통 하루에 한 번 보내도록 요청합니다. 보고서를 받는다면 이 설정에 내 주소가 등록되어 있다는 뜻입니다.
직접 추가하지 않았을 수도 있습니다. 2024년 2월부터 Gmail과 Yahoo는 대량 발신자에게 DMARC 레코드를 요구하며, 많은 호스팅 업체나 설정 도우미가 도메인의 연락처 주소를 rua에 넣어 자동으로 설정합니다. 그래서 예고 없이 보고서가 도착합니다.
기억할 점은 보고서는 경고가 아니라는 것입니다. 아무 문제 없어도 Google은 보고서를 보냅니다. 사고 신고가 아니라 정기 집계입니다.
도구 없이 보고서 읽기
첨부파일은 압축된 XML입니다. Google은 .zip, Microsoft와 대부분의 다른 업체는 .gz 형식을 사용합니다. 압축을 풀고 브라우저나 텍스트 편집기로 여세요. 발신자와 대상 기간을 나타내는 헤더(온라인 변환기로 날짜를 확인할 수 있는 Unix 타임스탬프) 아래의 각 <record> 블록은 다음과 같습니다.
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>14</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>votre-domaine.fr</header_from>
</identifiers>
</record>뜻은 이렇습니다. IP 주소 203.0.113.25에서 해당 도메인 명의로 메일 14개가 발송됐습니다. DKIM 서명은 유효했고 SPF 검사는 실패했지만, 둘 중 하나만 통과하면 되므로 DMARC 검증은 성공했습니다. disposition은 수신 서버의 처리 결과를 뜻합니다. none이면 정상적으로 전달됐습니다.
알아둘 세 가지 경우
- 메일 호스팅 업체의 IP에서 모두
pass: 정상 상태이므로 조치할 필요가 없습니다. - SPF 실패, DKIM 성공: 자동 전달이나 메일링 리스트에서 흔합니다. 다른 서버가 메일을 재전송하기 때문입니다. DKIM이 유지되면 통과합니다.
- 알 수 없는 IP에서 모두
fail: 등록하지 않은 정상 발송 도구(뉴스레터, CRM, 웹사이트 알림)일 수도 있고 도메인 사칭일 수도 있습니다. IP를 조회하면 대체로 구별할 수 있습니다.
도메인이 여러 개이거나 메일량이 많다면 Postmark, dmarcian, EasyDMARC 같은 전문 서비스가 파일을 보기 쉬운 대시보드로 바꿔 줍니다. 무료 요금제도 흔합니다. rua를 해당 서비스가 제공하는 주소로 변경하면 됩니다.
팁: XML 파일로 Gmail 필터 가져오기
문제가 생겼을 때 보고서는 유용하지만 매일 받은편지함에 쌓일 필요는 없습니다. 직접 필터를 만들 수도 있지만 더 빠르고 공유하기 쉬운 방법이 있습니다. Gmail은 XML 파일에서 미리 만든 필터를 가져올 수 있습니다. 필터 내보내기에 사용하는 것과 같은 형식이어서 다른 계정에도 몇 번의 클릭으로 규칙을 설치할 수 있습니다.
아래 내용을 복사해 filtre-dmarc.xml이라는 텍스트 파일로 저장하세요.
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns='[http://www.w3.org/2005/Atom](http://www.w3.org/2005/Atom)' xmlns:apps='[http://schemas.google.com/apps/2006](http://schemas.google.com/apps/2006)'>
<title>Mail Filters</title>
<id>tag:mail.google.com,2008:filters:1</id>
<updated>2026-11-06T12:00:00Z</updated>
<entry>
<category term='filter'></category>
<title>Mail Filter</title>
<id>tag:mail.google.com,2008:filter:1</id>
<updated>2026-11-06T12:00:00Z</updated>
<content></content>
<apps:property name='subject' value='"Report domain"'/>
<apps:property name='hasAttachment' value='true'/>
<apps:property name='label' value='Rapports DMARC'/>
<apps:property name='shouldArchive' value='true'/>
<apps:property name='shouldMarkAsRead' value='true'/>
<apps:property name='shouldNeverSpam' value='true'/>
</entry>
</feed>조건은 Google, Microsoft 및 대부분의 제공업체가 따르는 DMARC 권장 제목 « Report domain »과 첨부파일 유무를 결합한 것입니다. 동작은 메일에 « Rapports DMARC » 라벨을 붙이고 받은편지함에서 보관처리하며, 읽음으로 표시하고 스팸으로 분류되지 않도록 합니다.
필터 가져오기
- Gmail 왼쪽의 « 라벨 » 옆 + 버튼을 눌러 먼저 Rapports DMARC 라벨을 만듭니다.
- 오른쪽 위 톱니바퀴를 누른 다음 모든 설정 보기를 선택합니다.
- 필터 및 차단된 주소 탭을 엽니다.
- 맨 아래에서 필터 가져오기를 누르고
filtre-dmarc.xml을 선택한 뒤 파일 열기를 누릅니다. - Gmail이 찾은 필터를 표시합니다. 기존 보고서도 정리하려면 기존 대화에도 새 필터 적용을 선택하고 필터 만들기를 누릅니다.
하나의 파일에 여러 <entry> 블록을 넣어 모든 규칙을 묶고 새 계정에 한 번에 설치할 수도 있습니다. 실제 예시가 필요하면 같은 탭에서 기존 필터를 선택하고 내보내기를 누르세요. Gmail이 해당 XML 파일을 제공합니다.
보고서를 아예 받지 않으려면?
DMARC 레코드 자체는 삭제하지 마세요. 도메인 사칭을 방지하고 Gmail과 Yahoo로 보내는 메일의 전달에도 중요합니다. 도메인 DNS 영역의 _dmarc TXT 레코드에서 rua=…만 제거하거나 전용 주소로 바꾸세요. 변경 사항이 전파되면 보통 24~48시간 이내에 보고서가 멈춥니다.
다만 몇 주 동안은 라벨에 보관해 두는 것이 좋습니다. p=none에서 p=quarantine, 이어서 p=reject로 정책을 강화하기 전에 모든 발송 도구가 올바르게 등록됐는지 확인할 수 있기 때문입니다. 마지막 정책이 도메인 사칭을 막는 실질적인 보호 수단입니다.
Korean
French
German
English
Spanish
Hindi
Italian
Japanese
Norwegian
Chinese


