DMARC 레코드가 활성화되면 사서함 공급업체로부터 도메인이 이메일 전송에 어떻게 사용되고 있는지 보여주는 일일 데이터 파일, 즉 집계 보고서를 받기 시작합니다 .
언뜻 보기에 이러한 XML 파일은 압도적으로 보일 수 있습니다. 하지만 그 안에 무엇이 있는지 이해하면 해당 정보를 사용하여 권한이 없는 발신자를 찾아내고, 구성 문제를 해결하고, 자신 있게 DMARC 정책을 강화할 수 있습니다.
DMARC 활동의 일일 요약본인 DMARC 집계 보고서는 특정 문제에 초점을 맞춘 실시간 알림인 DMARC 포렌식 보고서와는 다릅니다. 포렌식 보고서에 대해 자세히 알아보려면 DMARC 포렌식 보고서에 대한 전체 가이드를참조하세요 .
DMARC 집계 보고서(RUA 보고서라고도함)는특정 날짜 동안수신 메일 서버가 도메인의 메시지를 어떻게 처리했는지를 요약한것입니다.
각 보고서에는 다음이 포함됩니다:
메시지 콘텐츠는 포함되지 않고 메타데이터만 포함되지만, 누가 사용자를 대신하여 메시지를 보내는지, 그리고 해당 메시지가 제대로 인증되었는지 파악하는 데는 충분합니다.
DMARC 보고서는 세 가지 중요한 사항에 대한 가시성을 제공합니다:
이러한 보고서를 검토하지 않으면 DMARC 설정이 실제로 제대로 작동하고 있는지 알 수 없습니다.
DMARC 구현에 대한 전체 개요와 로드맵은 DMARC 모니터링 및 규정 준수 가이드를참조하세요 .
원시 XML 파일을 한 줄씩 읽을 필요는 없습니다. 다음은 수행해야 할 작업과 살펴봐야 할 사항입니다:
사서함 제공업체는 DMARC 레코드의 rua 태그에 나열된 이메일 주소로 집계 보고서를 보냅니다(예:
이러한 파일은 텍스트 또는 스프레드시트 편집기에서 수동으로 열거나 무료 DMARC 보고서 뷰어를 사용하여 읽을 수 있는 표로 변환할 수 있습니다. 원하는 경우 데이터를 수집하고 시각화하는 자동화된 도구를 사용할 수도 있지만, 먼저 원시 데이터가 어떤 모습인지 이해하는 것이 좋습니다.
각 레코드에서 이러한 요소를 찾아보세요:
SPF와 DKIM이 모두 통과하고 정렬되면 이메일이 완전히 인증된 것입니다.
마케팅 자동화 플랫폼이나 헬프데스크 소프트웨어 등 실제로 사용하는 서비스에 속한 IP 또는 도메인을 확인하세요. 이 중 하나가 SPF 또는 DKIM에 실패하면 해당 시스템의 DNS 또는 키 설정을 업데이트하세요.
지속적으로 인증에 실패하는 알 수 없는 IP는 스푸핑 시도의 징후인 경우가 많습니다. 이러한 IP가 표시되면 합법적인 공급업체의 것이 아닌지 확인한 다음 DMARC 정책을 조정하여 차단하는 것이 좋습니다.
시간이 지남에 따라 보고서에 인증 실패 횟수가 줄어들고 정렬된 메시지의 비율이 높아져야 합니다. 모든 합법적인 발신자가 보호되고 있다는 확신이 들면 DMARC 정책을 없음에서 격리, 그리고 최종적으로 거부로 안전하게 변경할 수 있습니다.
이러한 패턴을 이해하면 실제 위협과 무해한 기술적 노이즈를 구분하는 데 도움이 됩니다.
여러 도메인을 관리하거나 하루에 많은 보고서를 수신하는 경우, XML을 수동으로 읽는 것은 금방 관리가 불가능해집니다.
이럴 때 DMARCeye와 같은 DMARC 보고 플랫폼이 도움이 될 수 있습니다. 모든 보고서에서 데이터를 수집하고 시각화하여 전송 소스, 통과율, 시간 경과에 따른 추세를 체계적으로 파악할 수 있습니다.
처음 시작할 때는 필요하지 않지만, DMARC 프로그램이 성숙해지면 자동화를 통해 시간을 절약하고 능동적인 자세를 유지할 수 있습니다.
지금 DMARCeye 무료 평가판을 다운로드하여 이메일 도메인 보호를 시작하세요.