이메일 ARF는 스팸 신고와 DMARC 오류를 구조화한다

이메일의 ARF(Abuse Reporting Format)는 스팸 신고와 DMARC 포렌식 보고서를 기계가 읽을 수 있는 형태로 전달하는 IETF 표준(RFC 5965)이다. 발신 시스템 관리자는 보고서의 형식과 필드를 알아두면 수신자가 신고한 메일을 추적하고, 실제로 도착하는 DMARC ruf= 보고서와 ISP 피드백 루프 신고를 구분할 수 있다.

DMARCguard가 2026년 4월 스캔한 도메인 가운데 rua= 통계 보고서 주소를 공개한 곳은 16.3%였고, 그중 일부만 ruf= 포렌식 보고서 주소도 공개했다. 이 수치는 rua= 공개 여부를 대리 지표로 삼은 것으로 ARF 발송량을 직접 측정한 결과는 아니다. 주요 메일함 제공업체 중 포렌식 보고서를 보내지 않는다고 명시적으로 확인한 곳은 마이크로소프트뿐이며, 나머지는 공개적으로 입장을 밝히지 않았다.

ARF의 의미와 형식

ARF는 2010년 RFC 5965가 정의한 MIME 기반 이메일 형식이다. 악용 신고, DMARC 포렌식 보고서, ISP 피드백 루프 알림을 세 부분으로 묶어 악용 대응팀이 자동 처리할 수 있게 한다. AOL은 2005년 자체 형식으로 대규모 불만 피드백 루프를 처음 구축했고, 이후 IETF의 MARF 작업반을 통해 설계를 표준화했다. RFC 5965는 multipart/report; report-type=feedback-report 봉투와 Feedback-Type, Source-IP, Authentication-Results, Reported-Domain 같은 필드의 레지스트리를 정했다. MIME 구조는 RFC 5965 §3.1, 필드 목록은 §3.3에 있다.

ARF는 봉투이며, 그 안에 무엇을 넣는지는 신고 종류에 따라 달라진다. Yahoo 이용자가 ‘스팸 신고’를 누르면 Yahoo의 포스트마스터가 Feedback-Type: abuse인 ARF 메시지를 보낼 수 있다. 수신 서버가 DMARC 레코드 게시자에게 인증 실패 메시지의 일부를 보내는 경우에는 RFC 6591의 AFRF 프로필을 사용하며 Feedback-Type: auth-failure로 표시한다. 봉투는 같고 내용이 다르다.

오래된 M3AAWG·IETF 문서에서 보이는 MARF(Messaging Abuse Reporting Format)는 ARF 계열 RFC(5965, 6591, 6650, 6651, 6652, 6692)를 만든 작업반 이름이다. 형식 자체의 명칭은 ARF다. APRF(Aggregate Performance Reporting)와도 혼동하면 안 된다. APRF는 개별 신고가 아니라 DKIM 도메인의 일일 받은편지함 배치와 참여 횟수를 메일함 제공업체가 보고하는 최신 JSON 형식이다. APRF 안내에서 차이를 설명한다.

RFC 5965 §3.1은 ARF 메시지를 다음 세 MIME 부분이 정해진 순서로 들어가는 multipart/report; report-type=feedback-report로 규정한다. Yahoo, Mail.ru, Seznam, OpenDMARC 필터, Comcast 피드백 루프 등에서 볼 수 있는 기본 구조다.

• text/plain: 악용 대응 담당자가 먼저 보는 사람이 읽을 수 있는 요약
• message/feedback-report: 파서가 읽는 구조화된 키-값 필드
• message/rfc822 또는 text/rfc822-headers: 원본 메시지 전체 또는 개인정보 보호를 위해 헤더만 포함

바깥쪽 MIME 헤더에는 report-type=feedback-report가 들어간다. 일부 피드백 루프는 표준의 multipart/report 대신 multipart/mixed를 사용한다. 이런 메시지는 표준을 엄격하게 적용하는 파서가 거부할 수 있어 별도로 처리해야 한다. Comcast 피드백 루프가 알려진 사례다.

message/feedback-report 부분에는 모든 주요 필드가 담긴다. Version: 1, Feedback-Type, 생성기를 식별하는 User-Agent가 들어가며, 최소한 문제가 된 메시지의 Original-Mail-From, Source-IP, Reported-Domain도 포함한다. RFC 5965 §3.3이 기본 필드 레지스트리를 정의하고, 후속 RFC가 특정 용도의 필드를 확장했다.

개인정보 보호 규정의 영향을 가장 크게 받은 것은 세 번째 부분이다. 공개된 RFC에는 다음 세 변형이 있다.

RFC 9477 방식은 EU에서 운영할 때 특히 중요하다. 최신 조정 피드백 루프(CFBL)는 원본 메시지를 발송 시 발신자가 넣은 불투명한 태그로 줄이므로 수신자의 개인정보가 수신 서버 밖으로 나가지 않는다.

실제 ARF 보고서와 필드 읽기

실제 ISP ARF 메시지에는 신고자의 개인정보가 들어 있어 공개된 원문 사례는 제한적이다. 공개 RFC 부록에서 그대로 인용할 수 있는 예시는 RFC 5965 부록 B.2에 수록된 기본 ARF 이메일이다. 아래 예시는 원문에 실린 내용이다.

From: <abusedesk@example.com> Date: Thu, 8 Mar 2005 17:40:36 EDT Subject: FW: Earn money To: <abuse@example.net> MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report;      boundary="part1_13d.2e68ed54_boundary" --part1_13d.2e68ed54_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. --part1_13d.2e68ed54_boundary Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 1 Original-Mail-From: <somespammer@example.net> Original-Rcpt-To: <user@example.com> Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT Reporting-MTA: dns; mail.example.com Source-IP: 192.0.2.1 Authentication-Results: mail.example.com;                spf=fail smtp.mail=somespammer@example.com Reported-Domain: example.net Reported-Uri: http://example.net/earn_money.html Reported-Uri: mailto:user@example.com Removal-Recipient: user@example.com --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline From: <somespammer@example.net> Received: from mailserver.example.net (mailserver.example.net      [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;      Thu, 08 Mar 2005 14:00:00 -0400 To: <Undisclosed Recipients> Subject: Earn money [...spam body...] --part1_13d.2e68ed54_boundary--

다음은 보고서 필드의 뜻과 관리자가 취할 조치다.

DMARC 변형은 바깥 봉투를 유지하되 필드 구성이 다르다. 다음 절에서 설명하는 RFC 6591의 AFRF 프로필에서는 abuse 대신 Feedback-Type: auth-failure를 쓰고, DKIM 관련 Auth-Failure: bodyhash, DKIM-Canonicalized-Body, DKIM-Domain, DKIM-Selector 필드가 나타난다. 세 번째 부분은 text/rfc822-headers가 되어 본문은 빠지지만 DKIM-Signature, Received 경로, Subject는 보존된다(RFC 6591 §B.1).

파서를 작성하지 않고 실제 ARF를 살펴보려면 원시 .eml을 DMARCguard ARF 보고서 분석기에 붙여 넣을 수 있다. 이 도구는 세 MIME 부분을 나누고 필드를 해독하며, Date: 헤더 누락이나 base64로 감싼 부분처럼 비표준적인 특성을 표시한다고 DMARCguard는 설명한다.

ARF와 DMARC 포렌식 보고서

DMARC 포렌식 보고서는 Feedback-Type이 auth-failure인 ARF 메시지다. RFC 6591은 AFRF(Authentication Failure Reporting Format) 프로필을 정의하며, DMARC ruf= 보고서는 실제 전송 과정에서 이 형식을 사용한다. 따라서 도메인 DMARC 레코드에 ruf=mailto: 주소를 게시하면 AFRF 형태의 ARF 메시지가 도착할 수 있다.

DMARC의 ruf= 태그는 수신자가 메시지별 포렌식 보고서를 보낼 수 있는 게시자 측 메일함 주소다. fo= 태그는 보고서가 생성되는 조건을 제어한다. RFC 7489 §6.3에 정의된 값은 네 가지다. fo=0(기본값)은 SPF와 DKIM이 모두 실패해야 하고, fo=1은 둘 중 하나만 실패해도 된다. fo=d는 DKIM 실패, fo=s는 SPF 실패가 있을 때 보고하도록 한다. 원문은 발신자가 보통 원하는 값으로 fo=1을 제시하며, fo=0에서는 두 검사가 동시에 실패하는 경우가 드물어 보고서가 거의 생성되지 않는다고 설명한다.

포렌식 보고서가 드문 이유

ruf와 fo=1을 게시해도 보고서는 거의 오지 않을 수 있다. 원문은 그 이유로 개인정보 규제, 마이크로소프트의 명시적 미지원, 수신 서비스의 제한적인 보고 발송을 든다.

• GDPR과 개인정보 부담: IETF DMARC 작업반의 draft-ietf-dmarc-failure-reporting-25(스티븐 M. 존스(Steven M. Jones)·알레산드로 베젤리(Alessandro Vesely), 2026년 4월 18일, §7)는 대규모 제공업체 다수가 민감한 내용을 드러내지 않는 통계 보고서를 선호해 실패 보고서 생성을 제한하거나 완전히 중단한다고 적었다. 포렌식 보고서에는 메시지 본문, 수신자 주소, 제목이 들어갈 수 있으며, 이들은 GDPR상 개인정보다.
• 마이크로소프트 365의 미지원: 마이크로소프트는 자사 DMARC 설정 문서에서 유효한 ruf=mailto: 주소가 발신 도메인의 DMARC TXT 레코드에 있어도 Microsoft 365는 DMARC 포렌식 보고서(실패 보고서라고도 함)를 보내지 않는다고 명시했다. 이는 주요 메일함 제공업체 가운데 공개적으로 확인된 유일한 입장으로, 답은 ‘보내지 않는다’다. 마이크로소프트 문서
• 수신 서비스 지원의 불확실성: Gmail, Yahoo/AOL, Microsoft, Apple, Fastmail, Proton, Comcast, iCloud 등 주요 제공업체 8곳 중 공개적으로 입장을 밝힌 곳은 마이크로소프트뿐이며 나머지는 침묵하고 있다. 업계 실무자들의 합의에 따르면 2026년에 AFRF를 보낼 가능성이 있는 곳은 Red Sift 제휴를 통한 Yahoo, NetEase, LinkedIn, Seznam뿐이다. DMARC 실패 경로를 조사할 때는 집계 보고서가 여전히 주요 신호다.

전달 메일에는 또 다른 단서가 있다. AFRF 보고서는 원래의 Authentication-Results와 전달 메일의 ARC 체인을 포함하므로 실패가 발신자 쪽에서 시작됐는지 중간 전달 단계에서 발생했는지 구분하는 데 도움이 된다. ARC는 홉을 거쳐도 판정 결과를 보존하고, AFRF는 체인이 끊긴 시점을 알려준다.

DMARC 집계 보고서와 포렌식 보고서 비교

실무에서는 집계 보고서를 주요 신호로 삼고 포렌식 보고서는 도착하는 경우에만 보조 자료로 다루는 편이 낫다. DMARCguard는 rua= 보고서를 모두 파싱해 색인하고, 도착한 ARF/AFRF 메일은 필드별 해독 자료로 추가한다고 설명한다. 매일의 판단에 포렌식 보고서가 필요한 운영 절차라면 필요한 데이터가 도착하지 않을 수 있다.

2026년에 ARF를 보내는 ISP 피드백 루프

2026년 ARF 트래픽의 대부분은 DMARC 포렌식 보고서가 아니라 사용자가 ‘스팸 신고’를 눌렀을 때 ISP 피드백 루프로 전달되는 불만이다. 각 프로그램은 별도의 등록 절차와 특징이 있으며, 2024~2026년 사이 통합도 진행됐다.

등록 링크는 Yahoo, AOL, AT&T, Comcast의 기준 자료인 Yahoo Sender Hub FAQ와 마이크로소프트의 SNDS 포털에 있다. Mail.ru, La Poste, Seznam은 각자 포스트마스터 사이트를 운영한다.

2024~2026년 사이의 변경 사항은 다음과 같다.

• AT&T의 Yahoo 이전: AT&T는 2025년 8월 6일 Yahoo MX로 이전했다. sbcglobal.net, bellsouth.net 등을 포함한 AT&T 소비자 도메인 13개는 이제 Yahoo를 통해 메일을 전달하며 Yahoo CFL을 사용한다. 별도의 AT&T FBL은 없다.
• Microsoft JMRP의 본문 제거(2025년 11월 이후): 2026년 1월 spamresource.com의 설명에 따르면 JMRP ARF 보고서는 이제 원본 메시지 본문을 제거하고 발신자 주소를 가린다. 원본 헤더, Authentication-Results, Received-SPF, DKIM-Signature, ARC만 남는다.
• Yahoo CFL은 DKIM 전용: Yahoo Sender Hub는 더 이상 IP/CIDR 기준 등록을 제공하지 않는다.
• Validity Universal FBL의 유료화: 2023년 9월 21일부터 Universal FBL 대상 서비스(Libero, Telenor, Terra, Fastmail 등)의 원시 ARF 피드는 유료 상품이다. 원문에 따르면 요금은 불만 10만 건당 연간 약 1,500달러다.

Gmail은 의도적으로 FBL 메시지를 보내지 않는 예외다. 2025년 9월 30일 V1이 종료된 뒤 Postmaster Tools v2는 발신자에게 Feedback-ID 기준 집계 대시보드와 API를 제공하지만 ARF 메시지를 보내지는 않는다. Google 도움말에 따르면 발신자는 발송 메일에 Feedback-ID 헤더를 넣으며, 스팸 비율이 비정상적으로 높은 식별자는 Postmaster Tools의 FBL 대시보드에 나타난다. ARF를 발신하지 않는 것은 정책이다.

ARF와 XARF의 차이

XARF(Extended Abuse Reporting Format)는 Abusix가 만든 업체 확장 형식이다. 표준 message/feedback-report 블록에 JSON 페이로드를 더해, 기본 ARF가 표현하지 않는 피싱·악성코드·사기 하위 유형 등 더 세분된 악용 분류를 담는다.

XARF는 더 많은 정보를 표현하지만 도입은 Abusix 고객층에 집중돼 있다. DMARC 포렌식 보고서는 발송하는 수신자가 모두 Feedback-Type: auth-failure인 ARF를 사용한다. 악용 대응팀이 둘 다 받아야 한다면 ARF를 기본 파서로 삼고 XARF는 선택적인 보강 경로로 다루면 된다.

ARF 보고서를 읽는 절차

관리자가 ARF를 받았을 때는 message/feedback-report의 필드를 중심으로 다음 순서로 확인한다.

• 바깥쪽 Content-Type이 multipart/report; report-type=feedback-report인지 확인한다. multipart/mixed라면 Comcast의 예외일 수 있다. 표준 준수 파서는 이를 거부하므로 Comcast만 별도로 처리하거나 건너뛴다.
• 먼저 Feedback-Type을 읽는다. abuse는 사용자 신고이므로 수신자를 즉시 발송 제외 목록에 넣고 전달성 대응 대기열로 보낸다. auth-failure는 AFRF/DMARC 포렌식 보고서이므로 보안 대기열로 보내며 수신자를 발송 제외 처리하지 않는다.
• Source-IP를 해독해 SPF include: 체인과 대조한다. 승인된 발신자 목록에 없는 IP라면 전달 서버, 승인되지 않은 ESP 또는 위조 발신일 수 있다.
• Original-Mail-From과 Reported-Domain을 비교한다. 전자는 RFC 5321 봉투 발신자(반송 경로)이고 후자는 From 헤더의 도메인이다. 둘이 다르면 정렬 불일치의 단서다.
• AFRF라면 Auth-Failure를 확인한다. 값은 spf, dkim, bodyhash, dmarc이며, 각각 수신 서버에서 실패한 인증 방식을 나타내고 필요한 조사를 가리킨다. 해당 방식에 따라 DKIM 정렬 오류 또는 SPF를 확인한다.

수동으로 파싱하는 대신 원시 .eml을 DMARCguard ARF 검사기에 붙여 넣으면 브라우저에서 위 단계를 처리하고 각 필드 옆에 관리 조치를 표시한다고 DMARCguard는 설명한다.

자주 묻는 질문

DMARC에서 ARF란 무엇인가?

DMARC에서 ARF는 메시지 인증 실패 시 수신자가 보낼 수 있는 메시지별 포렌식 알림의 전송 형식이다. RFC 6591(AFRF)은 RFC 5965를 확장해 Feedback-Type: auth-failure와 DKIM·SPF 실패 필드를 정의한다. ARF가 봉투라면 AFRF는 DMARC 보고서에 넣는 내용이다.

ARF와 DMARC 실패 보고서는 같은가?

DMARC 실패 보고서, 포렌식 보고서, ruf 보고서는 Feedback-Type: auth-failure인 ARF 메시지다. 따라서 DMARC 실패 보고서는 모두 ARF 보고서지만, ARF 보고서가 모두 DMARC 실패 보고서는 아니다. ARF 트래픽 대부분은 웹메일에서 수신자가 ‘스팸 신고’를 눌렀을 때 생성되는 Feedback-Type: abuse 보고서다.

RFC 5965는 무엇을 정의하는가?

RFC 5965(2010)는 ARF 자체를 정의한다. 여기에는 multipart/report; report-type=feedback-report 외부 봉투, message/feedback-report MIME 유형, Feedback-Type, User-Agent, Source-IP, Reported-Domain 같은 초기 필드 레지스트리가 포함된다. RFC 6591과 RFC 9477은 이후 필드 집합을 확장했다.

내 도메인에 ARF 보고서가 도착하지 않는 이유는 무엇인가?

주요 메일함 제공업체 다수는 DMARC 포렌식 보고서를 보내지 않는다. Gmail, Microsoft 365, Apple, Fastmail, Proton이 이에 포함되며, 마이크로소프트는 미지원 사실을 문서로 확인했다. ruf=mailto: 태그를 게시하지 않았을 수도 있다. ISP 피드백 루프는 Yahoo Sender Hub, Microsoft JMRP, Mail.ru, La Poste, Seznam 등 제공업체마다 별도 등록해야 한다.

ARF와 XARF는 어떻게 다른가?

ARF(RFC 5965)는 IETF 표준 MIME 형식이다. XARF는 Abusix의 업체 확장으로, 피싱·악성코드·사기 유형을 더 세분해 기록하는 JSON 페이로드를 추가한다. DMARC 포렌식 보고서에는 ARF가 사용되며, XARF는 Abusix 고객층을 중심으로 도입돼 있다.

ARF 보고서를 프로그램으로 파싱하려면 어떻게 해야 하는가?

multipart/report MIME 메시지에서 message/feedback-report 부분을 추출하고 RFC 5965 §3.3에 따라 키-값 필드를 파싱한다. DMARC 포렌식 보고서에는 RFC 6591 §3.2의 AFRF 필드 확장도 적용한다. DMARCguard의 ARF 보고서 분석기는 설치나 언어별 SDK 없이 브라우저에서 처리한다고 안내한다.

MARF, 즉 Messaging Abuse Reporting Format은 무엇인가?

MARF는 2007~2012년 ARF 계열 RFC(5965, 6591, 6650, 6651, 6652, 6692)를 만든 IETF 작업반의 이름이었다. 형식은 ARF이며 MARF는 작업반 이름이다. 오래된 M3AAWG·IETF 문서에서 두 용어를 볼 수 있지만, 같은 작업반과 형식 계열을 가리킨다.

2026년 DMARC 운영에서 ARF가 뜻하는 것

ARF는 RFC 5965가 정의한 MIME 형식으로, 악용 신고와 DMARC 포렌식 보고서를 기계가 읽을 수 있게 한다. 사람이 읽는 요약, 구조화된 message/feedback-report, 원본 메시지 또는 헤더라는 세 부분을 multipart/report; report-type=feedback-report 봉투로 묶는다.

DMARC ruf= 보고서는 RFC 6591의 AFRF 변형을 쓰지만 2026년에는 드물게 도착한다. Gmail, Microsoft 365, Apple, 그리고 대부분의 EU 수신자는 이를 보내지 않는다고 원문은 설명한다. 실제 ARF 트래픽은 Yahoo Sender Hub, Microsoft JMRP, Mail.ru, La Poste, Seznam 등 ISP 피드백 루프에 더 많이 남아 있으며, 각 프로그램마다 등록 절차와 특성이 다르다. DMARC에서는 rua= 집계 보고서를 주된 신호로 삼고, 도착하는 포렌식 자료는 보조 자료로 다뤄야 한다.

DMARCguard는 DMARC 집계 보고서와 도메인에 도착한 포렌식·피드백 루프 메시지를 함께 받아 필드별 관리 조치를 표시한다고 소개한다. 더 자세한 프로토콜 설명은 RFC 5965 필드 목록과 AFRF·CFBL 확장을 다루는 ARF 안내 페이지에서 확인할 수 있다.