DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC는 이메일 인증 프로토콜로, SPF(Sender Policy Framework)와 DKIM(DomainKeys Identified Mail)을 기반으로 작동하는 포괄적인 이메일 보안 솔루션이다. 2012년에 공식적으로 도입된 DMARC는 도메인 소유자가 자신의 도메인에서 보내는 이메일을 보호하고, 다른 사람이 해당 도메인을 사칭하여 이메일을 보내는 것을 방지하는 메커니즘을 제공한다.

DMARC는 세 가지 핵심 기능을 제공한다:

  1. 인증 정책 설정: 도메인 소유자가 SPF 및 DKIM 인증이 실패할 경우 수신 서버가 어떻게 대응해야 하는지 명확한 지침을 제공할 수 있다.
  2. 정렬(Alignment) 확인: 이메일의 ‘From’ 헤더가 SPF 및 DKIM에서 인증된 도메인과 일치하는지 확인한다.
  3. 보고 기능: 도메인 소유자에게 자신의 도메인을 사용하여 전송된 모든 이메일(인증 성공 및 실패 모두)에 대한 상세한 보고서를 제공한다.

DMARC의 중요성

DMARC는 현대 이메일 보안 인프라에서 다음과 같은 이유로 중요한 역할을 한다:

  1. 피싱 방지: 도메인 사칭을 통한 피싱 공격을 효과적으로 차단한다.
  2. 이메일 전달률 향상: 합법적인 이메일이 스팸 폴더로 분류되는 것을 줄이고 전달률을 높인다.
  3. 도메인 평판 보호: 사이버 범죄자가 도메인을 악용하여 평판을 손상시키는 것을 방지한다.
  4. 가시성 제공: 도메인 소유자에게 자신의 도메인을 사용한 이메일 트래픽에 대한 통찰력을 제공한다.
  5. 점진적 구현 지원: 전체 이메일 시스템에 영향을 주지 않고 단계적으로 구현할 수 있다.

DMARC 작동 방식 상세 설명

1. DNS 레코드 게시

DMARC는 도메인 소유자가 특수한 DNS TXT 레코드를 게시하는 것으로 시작합니다. 이 레코드는 일반적으로 다음과 같은 형식을 가집니다:

1

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

여기서:

  • _dmarc 접두사는 이것이 DMARC 레코드임을 나타냅니다.
  • v=DMARC1은 DMARC 버전을 지정합니다.
  • p=none은 정책(policy)을 지정합니다(none, quarantine, reject).
  • rua=mailto:reports@yourdomain.com은 집계 보고서를 보낼 이메일 주소를 지정합니다.

2. 인증 과정

이메일이 수신 서버에 도착하면 다음과 같은 단계로 DMARC 검증이 이루어집니다:

  1. SPF 및 DKIM 검증 수행: 수신 서버는 우선 SPF와 DKIM 검증을 별도로 수행합니다.

  2. 정렬(Alignment) 확인: DMARC는 다음 두 가지 유형의 정렬을 확인합니다:

    • SPF 정렬: ‘MAIL FROM’ 도메인이 ‘From’ 헤더의 도메인과 일치하는지 확인
    • DKIM 정렬: DKIM 서명의 ’d=’ 태그가 ‘From’ 헤더의 도메인과 일치하는지 확인

  3. DMARC 결과 결정:

    • SPF 또는 DKIM 중 하나라도 인증에 성공하고 해당하는 정렬이 확인되면 DMARC 검증은 성공합니다.
    • 둘 다 실패하거나 정렬이 확인되지 않으면 DMARC 검증은 실패합니다.

  4. 정책 적용: 수신 서버는 도메인의 DMARC 레코드에 지정된 정책에 따라 조치를 취합니다.

3. 보고 시스템

DMARC는 도메인 소유자에게 두 가지 유형의 보고서를 제공합니다:

  1. 집계 보고서(Aggregate Reports - RUA): 일반적으로 일일 단위로 제공되며, 발신 서버 IP, 인증 결과, 정책 적용 등에 대한 통계 데이터를 포함합니다. XML 형식으로 제공됩니다.

  2. 실패 보고서(Forensic Reports - RUF): 인증에 실패한 개별 이메일에 대한 상세 정보를 제공합니다. 이메일의 전체 헤더와 때로는 일부 본문 콘텐츠가 포함될 수 있습니다.

DMARC 정책 상세 설명

DMARC 정책은 도메인 소유자가 인증에 실패한 이메일을 어떻게 처리할지 수신 서버에 지시합니다:

  1. 없음(none - p=none):

    • 아무런 조치를 취하지 않습니다.
    • 모니터링 모드로, 보고서만 수집합니다.
    • DMARC 구현 초기 단계에 권장됩니다.

  2. 격리(quarantine - p=quarantine):

    • 인증에 실패한 이메일을 의심스러운 것으로 처리하도록 요청합니다.
    • 일반적으로 스팸 폴더로 이동됩니다.
    • 시스템에 영향을 주지 않고 정책을 강화하는 중간 단계입니다.

  3. 거부(reject - p=reject):

    • 인증에 실패한 이메일을 완전히 거부하도록 요청합니다.
    • 가장 강력한 보호를 제공하지만, 잘못 구성된 경우 합법적인 이메일이 차단될 수 있습니다.
    • 철저한 테스트 후에만 사용해야 합니다.

하위 도메인 정책

DMARC는 하위 도메인에 대해 별도의 정책을 지정할 수 있습니다:

1

v=DMARC1; p=none; sp=reject; rua=mailto:reports@yourdomain.com

여기서 sp=reject는 하위 도메인에 대한 정책을 지정합니다.

백분율 태그

DMARC 정책을 전체 이메일의 일부에만 적용할 수 있습니다:

1

v=DMARC1; p=reject; pct=10; rua=mailto:reports@yourdomain.com

여기서 pct=10은 인증에 실패한 이메일의 10%에만 정책을 적용하라는 의미입니다.

DMARC 레코드 태그 상세 설명

DMARC DNS 레코드는 다양한 태그로 구성되며, 각 태그는 특정 기능을 제어합니다:

태그설명예시
v필수. 프로토콜 버전v=DMARC1
p필수. 정책 (none/quarantine/reject)p=reject
sp선택. 하위 도메인 정책sp=quarantine
pct선택. 정책 적용 백분율 (0-100)pct=20
rua선택. 집계 보고서 수신 이메일rua=mailto:reports@example.com
ruf선택. 실패 보고서 수신 이메일ruf=mailto:forensics@example.com
fo선택. 실패 보고 옵션fo=1
adkim선택. DKIM 정렬 모드 (r=relaxed, s=strict)adkim=r
aspf선택. SPF 정렬 모드 (r=relaxed, s=strict)aspf=r
ri선택. 보고서 간격 (초)ri=86400

정렬 모드 설명

정렬 모드는 도메인 일치를 어떻게 평가할지 결정합니다:

  1. 엄격(Strict - s):

    • 도메인이 정확히 일치해야 합니다.
    • 예: mail.example.com은 example.com과 일치하지 않습니다.

  2. 완화(Relaxed - r):

    • 조직 도메인만 일치하면 됩니다.
    • 예: mail.example.com은 example.com과 일치합니다.
    • 기본값이며 대부분의 경우 권장됩니다.

DMARC 구현 단계

효과적인 DMARC 구현을 위한 단계별 접근법:

1. 현재 상태 평가

  • 전송하는 모든 이메일 소스 식별 (내부 서버, 서드파티 서비스 등)
  • SPF 및 DKIM이 올바르게 구성되었는지 확인

2. 모니터링 모드로 시작

1

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
  • 영향 없이 데이터 수집
  • 최소 2주 이상 운영

3. 보고서 분석

  • 합법적인 이메일 소스가 SPF 및 DKIM을 통과하는지 확인
  • 실패하는 소스 식별 및 수정

4. 단계적 정책 강화

  • 백분율 태그로 점진적 테스트
1

v=DMARC1; p=quarantine; pct=5; rua=mailto:reports@yourdomain.com
  • 점진적으로 백분율 증가 (5% → 25% → 50% → 100%)

5. 전체 DMARC 거부 정책 구현

1

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com
  • 철저한 테스트 후 모든 이메일에 적용

DMARC 보고서 이해 및 분석

집계 보고서(RUA) 형식

집계 보고서는 XML 형식으로 제공되며 다음 섹션을 포함합니다:

  1. 보고 메타데이터: 보고 기간, 보고 조직 등
  2. 정책 게시자 정보: DMARC 정책이 게시된 도메인
  3. 레코드별 데이터: 각 발신 IP 주소에 대한 세부 통계

샘플 구조:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1596240000</begin>
      <end>1596326399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.1</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>pass</result>
        <selector>default</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

보고서 분석 도구

DMARC 보고서는 XML 형식으로 제공되어 수동으로 분석하기 어렵습니다. 다음과 같은 도구가 분석을 도울 수 있습니다:

  1. 상업용 서비스:

    • Dmarcian
    • Valimail
    • Agari
    • PowerDMARC
    • Proofpoint

  2. 오픈 소스 도구:

    • ParseDMARC
    • DMARC Analyzer
    • OpenDMARC

보고서에서 확인해야 할 핵심 지표

  1. SPF 및 DKIM 통과율: 도메인의 합법적인 이메일이 모두 통과하는지 확인
  2. 주요 실패 원인: SPF 불일치, DKIM 서명 누락, 정렬 실패 등
  3. 상위 발신 IP: 합법적인 소스인지 확인
  4. 위조 시도: 알려진 발신자가 아닌 경우 잠재적 위조 식별

DMARC와 이메일 전달 문제

이메일 전달은 DMARC 구현 시 특별한 고려가 필요한 영역입니다:

전달의 문제점

  1. SPF 검증 실패: 전달 시 원래 발신자의 IP 주소가 아닌 전달 서버의 IP 주소로 이메일이 전송됩니다.
  2. DKIM 서명 유지: DKIM 서명은 이메일 헤더나 본문이 수정되지 않는 한 전달 과정에서 유효합니다.

해결 방법

  1. ARC(Authenticated Received Chain):

    • 이메일의 인증 상태를 전달 체인 전체에 걸쳐 보존
    • 전달 과정에서 추가 서명 제공

  2. SRS(Sender Rewriting Scheme):

    • ‘Return-Path’ 주소를 재작성하여 전달 서버가 SPF를 통과하도록 함
    • 원래 발신자 정보 보존

  3. 간접 이메일 흐름 설계:

    • 전달이 필요한 시스템에 대한 명시적 SPF 허용
    • 전달 시나리오를 고려한 DKIM 구현

DMARC 구현 사례 및 통계

구현 성공 사례

  1. 금융 서비스:

    • 한 대형 은행은 DMARC p=reject 정책 구현 후 피싱 공격이 97% 감소
    • 고객 신뢰 상승 및 지원 문의 감소

  2. 정부 부문:

    • 미국 DHS(Department of Homeland Security)는 모든 연방 기관에 DMARC 구현 의무화
    • BOD 18-01을 통해 이메일 보안 강화

  3. 전자 상거래:

    • 한 글로벌 리테일러는 DMARC 구현 후 이메일 전달률 12% 향상
    • 브랜드 평판 보호 및 고객 참여 증가

업계 통계

  1. DMARC 도입 추세:

    • Fortune 500 기업의 약 80%가 DMARC 레코드 보유
    • 그러나 강력한 정책(p=reject)을 사용하는 비율은 약 28%에 불과

  2. 효율성 데이터:

    • p=reject 정책 사용 시 사칭 이메일이 평균 98% 감소
    • p=none에서 p=reject로 이동하는 데 평균 3-6개월 소요

  3. 분야별 도입률:

    • 금융 서비스: 가장 높은 도입률(약 85%)
    • 의료: 상대적으로 낮은 도입률(약 50%)
    • 공공 부문: 빠르게 증가 중

DMARC와 관련된 새로운 동향 및 기술

BIMI(Brand Indicators for Message Identification)

BIMI는 DMARC를 확장하여 인증된 이메일에 브랜드 로고를 표시합니다:

  1. 요구 사항:

    • 강력한 DMARC 정책(p=quarantine 또는 p=reject)
    • 유효한 DKIM 서명
    • DNS에 게시된 BIMI 레코드
    • SVG 형식의 로고

  2. 이점:

    • 브랜드 가시성 향상
    • 수신자의 신뢰 증가
    • 피싱 이메일과의 차별화

TLS-RPT(SMTP TLS Reporting)

TLS-RPT는 전송 계층 보안에 초점을 맞춘 보고 메커니즘입니다:

  1. 기능:

    • SMTP TLS 연결에 대한 통계 보고
    • TLS 실패 식별
    • MTA-STS 정책 검증

  2. DMARC와의 통합:

    • 이메일 전송 보안의 추가 계층 제공
    • 엔드 투 엔드 이메일 보안 향상

ARC(Authenticated Received Chain)

ARC는 이메일 전달 문제를 해결하기 위해 개발되었습니다:

  1. 작동 방식:

    • 이메일이 전달될 때마다 인증 결과를 체인으로 추가
    • 원래 인증 상태 보존
    • 수신자가 전체 인증 내역 확인 가능

  2. 이점:

    • DMARC 실패 감소
    • 합법적인 전달된 이메일의 전달률 향상
    • 더 정확한 이메일 인증

DMARC 구현 시 흔한 문제 및 해결 방법

문제 1: 모든 합법적인 소스 식별

문제: 일부 합법적인 이메일 발신자가 DMARC 실패로 차단됨

해결 방법:

  1. 장기간(최소 30일) p=none 모드로 운영
  2. 모든 서드파티 서비스 및 내부 시스템 목록 작성
  3. 이메일 흐름 다이어그램 생성

문제 2: 서드파티 서비스

문제: 마케팅, CRM, 지원 서비스 등이 도메인을 사용하지만 SPF/DKIM이 제대로 구성되지 않음

해결 방법:

  1. 모든 서드파티 공급업체 목록 작성
  2. 각 서비스에 대한 SPF 및 DKIM 설정 확인
  3. 필요한 경우 통합 이메일 게이트웨이 사용

문제 3: 이메일 전달

문제: 전달된 이메일이 DMARC 검증 실패

해결 방법:

  1. ARC 지원 확인
  2. 중요한 전달 시나리오에 대한 별도 하위 도메인 사용
  3. 전달 서버에 SRS 구현

문제 4: 보고서 처리

문제: XML 형식의 대량 DMARC 보고서 처리 어려움

해결 방법:

  1. 자동화된 보고서 처리 도구 사용
  2. 보고서 전달용 별도 이메일 주소 설정
  3. 정기적인 보고서 검토 일정 수립

DMARC 모범 사례

구현 모범 사례

  1. 단계적 접근법:

    • p=none → p=quarantine (낮은 pct) → p=quarantine (100%) → p=reject
    • 각 단계에서 충분한 시간을 두고 문제 해결

  2. 모니터링 및 분석:

    • 정기적인 보고서 검토
    • 인증 실패 트렌드 모니터링
    • 주요 성과 지표 설정

  3. 도메인 분리:

    • 마케팅, 거래 및 내부 통신에 대한 별도 하위 도메인 사용
    • 다양한 이메일 유형에 맞게 정책 조정

  4. 문서화:

    • 이메일 인프라 및 흐름 문서화
    • 문제 해결 절차 수립
    • 공급업체 구성 정보 유지

조직적 모범 사례

  1. 교차 기능 팀:

    • IT, 보안, 마케팅 및 비즈니스 이해관계자 포함
    • 명확한 책임 및 역할 정의

  2. 공급업체 관리:

    • 이메일 서비스 공급업체와의 DMARC 요구 사항 문서화
    • 정기적인 규정 준수 검토
    • 계약에 DMARC 지원 포함

  3. 교육 및 인식:

    • 기술 및 비기술 직원 대상 이메일 보안 교육
    • DMARC 구현 상태 및 혜택에 대한 정기적인 업데이트

  4. 지속적인 개선:

    • 정기적인 DMARC 상태 검토
    • 새로운 이메일 소스 추적 프로세스
    • 새로운 기술 및 모범 사례 채택

결론

DMARC는 이메일 인증의 세 가지 핵심 기둥(SPF, DKIM, DMARC) 중 하나로, 포괄적인 이메일 보안 프레임워크를 완성합니다. 도메인 소유자에게 명확한 정책 설정, 풍부한 보고 기능, 그리고 도메인 사칭 방지를 위한 강력한 메커니즘을 제공합니다.

DMARC의 효과적인 구현은 단순한 기술적 과제가 아니라 조직적인 노력이 필요한 과정입니다. 점진적인 접근법, 철저한 테스트, 그리고 지속적인 모니터링을 통해 조직은 이메일 보안을 강화하고, 고객 신뢰를 구축하며, 브랜드 평판을 보호할 수 있습니다.

현대 디지털 커뮤니케이션 환경에서 DMARC는 더 이상 선택이 아닌 필수가 되고 있으며, 이메일 인증의 미래는 BIMI 및 ARC와 같은 새로운 기술과의 통합을 통해 계속 발전할 것입니다.

용어 정리

용어설명

참고 및 출처