RUA 리포트란? 우리 회사 도메인의 인증 결과 읽는 법

RUA는 메일을 받은 서버가 보내는 관찰 기록입니다

RUA는 DMARC 레코드에서 집계 보고서를 받을 주소를 지정하는 rua 항목을 가리킵니다. 실무에서는 이 주소로 받는 DMARC 집계 보고서를 흔히 RUA 리포트라고 부릅니다.

가온상사가 example.com으로 메일을 보낸다고 해 보겠습니다. 회사는 DNS의 DMARC 레코드에 rua=mailto:dmarc-reports@example.com을 적습니다. 이후 보고 기능을 제공하는 수신 서버가 자기에게 들어온 메일의 인증 결과를 모아 그 주소로 보냅니다. 직원용 메일이 Google Workspace에 있어도, 보고서를 만드는 주체는 각 메일을 받은 곳입니다. DMARC의 rua 항목 ↗

보통 XML 파일을 압축한 첨부파일로 받습니다. XML은 항목 이름과 값을 일정한 규칙으로 적는 문서 형식입니다. 분석 서비스는 이 파일을 받아 사람이 읽기 쉬운 표나 그래프로 바꿉니다. 직접 받는다면 담당자 개인 메일보다 전용 수신함을 두는 편이 관리하기 좋습니다. Google의 보고서 수신·분석 안내 ↗

먼저 누가, 어느 기간을 보고했는지 확인합니다

파일 맨 위부터 모든 태그를 외울 필요는 없습니다. 먼저 report_metadata에서 보고 기관과 기간을 확인하고, policy_published에서 관찰 당시 정책을 읽습니다. 아래는 가온상사의 보고서 앞부분을 설명용으로 줄인 것입니다. 전체 XML 파일은 아닙니다.

<report_metadata>
  <org_name>Receiver Example</org_name>
  <email>reports@receiver.example.org</email>
  <report_id>20260918-example.com-01</report_id>
  <date_range>
    <begin>1789689600</begin>
    <end>1789776000</end>
  </date_range>
</report_metadata>
<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <adkim>r</adkim>
  <aspf>r</aspf>
</policy_published>

org_name은 이 파일을 만든 보고 기관입니다. 가온상사의 뉴스레터 업체 이름이 아닙니다. report_id는 보고서를 구분하는 식별자이므로 나중에 중복 수신을 확인할 때 함께 보관합니다.

begin과 end의 큰 숫자는 1970년 1월 1일 00:00 UTC부터 지난 초를 뜻합니다. 이 예시의 범위는 2026년 9월 18일 00:00부터 19일 00:00까지 UTC입니다. 한국 시간으로는 18일 오전 9시부터 19일 오전 9시까지입니다. 보고서가 20일 아침에 도착했더라도 20일의 발송 결과는 아닙니다.

policy_published는 수신 측이 관찰한 정책입니다. 위 파일은 관찰용인 p=none과 완화 정렬 모드인 r을 보여 줍니다. 지금 DNS를 바꿨는데 보고서에 예전 값이 보인다면, 오류로 단정하기 전에 보고 기간과 변경 시각을 비교하세요. 한 기간 중 정책이 달라지면 보고서가 나뉘거나 마지막으로 관찰한 정책이 기록될 수 있습니다. 보고 기간 중 정책 변경의 처리 ↗

그다음에는 record를 하나씩 읽습니다

record 하나는 메일 한 통이 아니라, 같은 발신 IP와 인증 결과 등으로 묶인 메일 여러 통일 수 있습니다. 같은 IP도 From 도메인이나 결과가 다르면 여러 묶음으로 나타납니다. 그래서 XML의 행 수를 세지 않고 각 묶음의 count를 읽어야 합니다.

source_ip는 수신 서버에 접속한 시스템의 주소입니다. 메일이 다른 서버를 거쳐 전달됐다면 최초 발송 서버와 다를 수 있습니다. IP의 회사 이름을 찾았다는 이유만으로 조사까지 끝난 것은 아닙니다. 발신 IP와 집계 건수의 정의 ↗

뉴스레터 150통은 왜 PASS인데 DMARC에 실패했을까요?

가온상사 담당자는 보고된 발신 경로를 회사의 발송 목록과 대조했습니다. 직원용 메일 800통과 마케팅팀이 보낸 뉴스레터 150통은 사용 중인 서비스와 맞았습니다. 나머지 50통은 아직 누구의 발신인지 확인하지 못했습니다.

이제 실패한 뉴스레터 150통을 열어 봅니다. 아래는 그 묶음 하나입니다. 위의 보고서와 같은 기간이며, 읽는 데 필요한 항목만 보여 주는 가상 XML입니다.

<record>
  <row>
    <source_ip>198.51.100.20</source_ip>
    <count>150</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
    <envelope_from>mailer.example.net</envelope_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example.net</domain>
      <selector>news1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>mailer.example.net</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

겉으로 보면 같은 파일에 pass와 fail이 함께 있어 모순처럼 느껴집니다. 하지만 두 결과가 답하는 질문이 다릅니다. auth_results는 SPF나 DKIM 자체의 검사 결과이고, policy_evaluated는 그 인증이 From 도메인과 연결되는지까지 포함한 DMARC 기준의 결과입니다. Microsoft의 집계 보고서 판독 설명 ↗

envelope_from은 서버끼리 메일을 전송할 때 사용하는 MAIL FROM 주소의 도메인입니다. 이 예시에서는 화면에 보이는 From과 다릅니다. 뉴스레터 화면에는 news@example.com이 보이는데, 실제 인증은 모두 mailer.example.net으로 끝났습니다. 기본 완화 모드에서도 이 둘은 별개의 조직 도메인이므로 정렬되지 않습니다. SPF와 DKIM 중 하나라도 통과하면서 회사 도메인과 정렬돼야 DMARC를 통과합니다.

IP를 추가하기 전에, 서명하는 도메인을 고칩니다

이 상황에서 회사 SPF에 뉴스레터 IP를 추가해도 핵심 문제는 그대로입니다. 이 메일의 SPF 검사 대상은 example.com이 아닌 서비스 도메인이기 때문입니다. 담당자는 먼저 마케팅팀의 발송 기록으로 회사가 승인한 서비스임을 확인한 뒤, 그 서비스의 회사 도메인 인증 또는 사용자 지정 DKIM 설정을 진행합니다.

가온상사는 서비스가 발급한 TXT 또는 CNAME 값을 DNS에 등록하고, 서비스 화면에서 검증과 서명 활성화를 마쳤다고 가정하겠습니다. 목표는 유효한 DKIM 서명의 d= 값이 example.com이 되는 것입니다. 예시의 selector나 다른 회사의 발급값을 복사하는 작업이 아닙니다. 서비스가 회사 도메인으로 서명할 수 없다면, 정렬되는 MAIL FROM을 지원하는지 또는 발송에 사용할 From 도메인을 바꿔야 하는지 확인합니다.

설정 화면의 완료 표시만 보고 끝내지는 않습니다. 실제 뉴스레터 경로로 외부 테스트 수신함에 새 메일을 보낸 뒤, 메일 원본에서 수신 서비스가 남긴 Authentication-Results를 확인합니다. 기대하는 결과는 다음과 같습니다.

Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

SPF 도메인은 여전히 서비스의 것이지만 회사 DKIM이 통과해 DMARC도 통과했습니다. 다음 보고 기간에서는 해당 뉴스레터 경로의 policy_evaluated/dkim이 pass로 바뀌는지 확인합니다. 같은 IP에서 옛 실패 묶음과 새 통과 묶음이 함께 보이면 변경 시각을 대조하세요. 수정 전에 보낸 메일이 다음 날 도착한 보고서에 남아 있을 수 있습니다.

다음 날 발송량까지 정확히 150통일 필요는 없습니다. 비교할 것은 같은 발송 경로의 인증 도메인과 결과입니다. 실제 캠페인에서도 회사 서명이 붙는지 확인해야 테스트메일 한 통의 성공을 전체 발송의 성공으로 착각하지 않습니다.

미확인 50통은 무엇부터 조사하면 될까요?

이제 남은 50통을 보겠습니다. 낯선 IP를 검색했더니 유명 클라우드 사업자의 주소로 나옵니다. 이것만으로 정상 발신이라고 허용해서는 안 됩니다. 여러 고객이 쓰는 인프라에서는 다른 조직의 발신도 같은 사업자 이름으로 보일 수 있습니다.

먼저 해당 From 도메인을 쓰는 부서와 대행사를 찾습니다. 고객지원 도구, 홈페이지 알림, 드물게 보내는 청구서가 발신 목록에서 빠졌는지 확인하세요. 서비스의 발송 이력, 같은 시간에 받은 테스트메일 원본, 실제 계약·계정 정보를 함께 보면 “아는 업체의 IP”와 “우리 계정이 보낸 메일”을 구별할 수 있습니다.

직접 발송이 아닌 전달일 가능성도 있습니다. 수신자가 메일을 다른 주소로 자동 전달하면 최종 서버가 보는 IP가 달라져 SPF에 영향을 줄 수 있습니다. 전달 도중 본문까지 수정되면 DKIM도 실패할 수 있습니다. 보고서의 예외 사유와 확보 가능한 원본 헤더를 함께 살펴야 합니다. RUA에 원문이 없으므로, 이 50통의 내용이나 공격 의도까지 보고서만으로 복원할 수는 없습니다.

disposition은 받은편지함 위치가 아닙니다

앞의 뉴스레터는 DMARC가 실패했지만 disposition=none입니다. 당시 정책이 p=none이므로 DMARC 실패를 이유로 격리나 거부를 적용하지 않은 예시입니다. 이 값이 정상 인증이나 받은편지함 도착을 뜻하지는 않습니다. 수신 측의 스팸 검사와 다른 보안 판단이 별도로 작동합니다.

2026년 RFC 9990은 p=quarantine이나 p=reject 같은 정책이 적용되는 상황에서 DMARC를 통과한 경우를 나타내는 pass 처리 값을 정의합니다. 기존 형식의 보고서에서는 통과한 메일도 none으로 보일 수 있습니다. 따라서 처리 값 하나로 통과율을 계산하지 말고 policy_evaluated의 SPF·DKIM 결과를 함께 읽으세요. 정책과 처리가 다르면 reason에 수신 측 예외 사유가 있는지도 확인합니다. 현행 보고서의 처리 값 ↗

가온상사에서 우선 해결할 일은 “실패율 20%”를 낮춰 보이는 것이 아닙니다. 승인한 발신 950통 중 실패한 뉴스레터 경로를 고치고, 나머지 50통의 분류를 끝내는 것입니다. 이 두 작업을 분리해야 정상 메일의 장애를 공격 차단 성과로 잘못 보고하지 않습니다.

RUA 보고서가 오지 않으면 이 순서로 확인합니다

DNS에 주소를 넣었는데 아무 파일도 오지 않으면 수신함부터 계속 새로 고침하게 됩니다. 그 전에 실제 메일이 어느 도메인으로, 어디까지 나갔는지 확인하세요. 보고서 수신은 발송·DNS·외부 동의·메일 수신이 이어지는 과정이므로 한 단계씩 좁히는 편이 빠릅니다.

1. 실제 From과 외부 발송을 확인합니다

   보고받을 도메인을 From에 사용했는지, 외부 수신 서버까지 발송됐는지 확인합니다. 사내 메일만 주고받았거나 보고 기능이 없는 수신처에만 보냈다면 기대한 보고서가 없을 수 있습니다.

2. 공개 DNS에서 rua를 읽습니다

   관리 화면에 저장한 값과 외부에서 조회되는 값을 비교합니다. mailto: 누락, 주소 오타, DMARC 레코드 중복을 확인하고 서브도메인에 별도의 정책이 있는지도 봅니다.

3. 외부 분석 서비스의 수신 동의를 확인합니다

   보고 주소의 조직 도메인이 회사와 다르면, 보고서를 받는 곳에 DNS 동의가 필요합니다. 서비스의 도메인 등록 상태와 발급 안내를 확인합니다.

4. 수신함과 첨부파일 처리를 확인합니다

   주소가 실제 메일을 받을 수 있는지, 외부 발신자 제한·용량·압축 첨부파일 필터·스팸함 때문에 누락되지 않았는지 확인합니다. 분석 서비스에는 도착했지만 화면 반영이 늦는지도 구분합니다.

5. 보고 기간이 끝났는지와 제공 여부를 확인합니다

   보통 하루 단위로 오지만 모든 수신자가 같은 시각에 보내는 것은 아닙니다. 첫 발송과 DNS 반영 시각을 적어 두고, 집계·전송 시간을 고려해 확인합니다.

가온상사의 DMARC 값은 아래처럼 확인할 수 있습니다. 명령의 도메인은 실제 회사 도메인으로 바꿉니다. 보고서를 추가하려고 기존 p=reject를 아래의 p=none으로 낮출 필요는 없습니다. 예시는 신규 관찰 설정이며, 기존 정책이 있다면 그 레코드의 rua를 확인합니다.

dig +short TXT _dmarc.example.com

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

다른 회사 주소로 받을 때는 수신 측의 동의가 필요합니다

예를 들어 example.com의 보고서를 aggregate@reports.example.net으로 받는다면, 아래 동의 레코드는 보고서를 받는 곳의 DNS에 있어야 합니다. 회사의 example.com 영역에 같은 이름을 넣는 것이 아닙니다.

Name: example.com._report._dmarc.reports.example.net
Type: TXT
Value: v=DMARC1;

이 절차는 누군가 관계없는 주소를 RUA 수신처로 지정해 보고서를 쏟아 보내는 일을 막기 위한 것입니다. 분석 업체가 동의를 이미 처리하거나 여러 고객을 위한 방식으로 제공할 수 있으므로, 자체 추측으로 레코드를 만들기보다 업체의 도메인 연결 안내를 확인하세요. 외부 보고 목적지 검증 ↗

보고서가 없다는 사실만으로 “주소 도용이 없다”거나 “DMARC가 작동하지 않는다”고 결론 내릴 수는 없습니다. 새 테스트메일의 인증 결과와 보고서 전달 경로를 따로 확인해야 어디가 막혔는지 알 수 있습니다.

받아 두는 데서 끝내지 말고 담당자와 조치 기록을 남기세요

가온상사의 첫 보고서 검토는 세 줄의 업무 기록으로 끝낼 수 있습니다. 직원 메일은 정상 기준으로 등록하고, 뉴스레터는 마케팅 담당자가 DKIM을 수정한 뒤 재확인합니다. 미확인 발신은 IT 담당자가 관련 부서와 전달 경로를 조사합니다. 각 기록에 보고 기간, From 도메인, 발신 서비스, 발견한 문제, 변경 시각과 확인할 날짜를 남기면 다음 담당자가 같은 조사부터 반복하지 않아도 됩니다.

여러 보고서를 합칠 때는 중복도 확인합니다. report_id 하나를 모든 보고 기관에 걸친 고유 번호라고 가정하지 말고, 보고 기관·대상 정책 도메인·기간·원문을 함께 대조하세요. 같은 파일을 두 번 받았다면 두 번 더하지 않습니다. 서로 다른 파일의 기간이 일부 겹치는 경우에도 단순 합산이 건수를 부풀릴 수 있습니다. 중복 보고서 처리 ↗

운영 초기와 설정 변경 직후에는 매일 새 발신처와 정상 발신의 실패를 확인하는 방식을 권합니다. 안정된 뒤에도 정기적으로 변화와 누락을 살펴보고, 월말 청구서처럼 드물게 발송되는 업무는 해당 주기가 지난 뒤 확인합니다. 하루 통과율이 높다는 이유만으로 정책을 강화하면 작은 건수의 중요한 메일을 놓칠 수 있습니다.

원본 보고서는 회사 도메인과 발송 인프라 정보를 담습니다. 필요한 담당자만 접근하도록 하고, 원본과 분석 결과의 보관 기간, 외부 서비스의 처리 범위를 정해 두세요. 본문이 없다고 아무 곳에나 업로드해도 되는 자료는 아닙니다. 집계 보고서와 정보 관리 ↗

RUA를 제대로 읽으면 “메일 인증에 문제가 있다”는 막연한 상태가 “어느 서비스의 무엇을 고칠지”라는 작업으로 바뀝니다. 승인한 발신이 모두 설명되고 수정 결과까지 확인됐다면, DMARC 정책을 강화할 근거가 마련된 것입니다. 이후에도 새 서비스를 도입할 때마다 이 확인을 이어갑니다.