DMARC 정책과 보고

DMARC (도메인 기반 메시지 인증, 보고 및 준수)는 SPF와 DKIM을 연결하고 두 기술의 가장 큰 사각지대를 해결합니다.

SPF와 DKIM은 각각 도메인을 인증하지만 사용자가 보는 표시되는 발신자 헤더를 반드시 인증하는 것은 아닙니다. DMARC는 해당 인증이 발신자 도메인과 정렬되도록 요구하고, 메시지가 실패했을 때 수신 서버가 어떻게 처리할지 알려 주며, 보고서도 보냅니다.

정렬은 DMARC의 핵심입니다. 메시지가 SPF 또는 DKIM을 통과하고, 해당 인증 도메인이 표시되는 발신자 도메인과 일치할 때만 DMARC를 통과합니다.

• SPF 정렬 — 봉투 MAIL FROM 도메인이 발신자 도메인과 일치합니다
• DKIM 정렬 — DKIM d= 도메인이 발신자 도메인과 일치합니다

이를 통해 공격자가 자신의 도메인으로 SPF를 통과하면서 발신자에는 사용자의 도메인을 표시하는 일을 막을 수 있습니다.

정렬은 메커니즘별로 설정할 수 있는 두 가지 방식으로 확인됩니다:

• 완화된 방식(기본값) — 조직 도메인이 일치해야 하며 하위 도메인은 허용됩니다(mail.company.com은 company.com과 정렬됩니다)
• 엄격한 방식 — 도메인이 정확히 일치해야 합니다

조직은 하위 도메인과 벤더를 통해 합법적으로 메일을 보내는 경우가 많으므로 완화된 방식이 실용적인 기본값입니다. 엄격한 방식은 정확한 도메인 서명을 보장할 수 있을 때 더 강력한 제어를 제공합니다.

DMARC는 특수한 _dmarc 하위 도메인에 TXT 레코드로 게시됩니다:

핵심 DMARC 태그는 동작과 보고를 제어합니다:

p= 태그는 수신 서버에 DMARC를 통과하지 못한 메시지를 처리하는 방법을 알려 줍니다:

• p=none — 아무 조치도 취하지 않고 보고서만 보냅니다(모니터링 모드)
• p=quarantine — 실패한 메일을 의심스러운 것으로 처리합니다(스팸함으로 보냄)
• p=reject — 실패한 메일을 즉시 거부합니다(가장 강력한 보호)

모든 배포의 목표는 스푸핑된 메일을 실제로 차단하는 p=reject에 도달하는 것입니다. 그러나 처음부터 아무런 확인 없이 이 정책을 사용하면 합법적인 메일이 삭제될 위험이 있습니다.

통합 보고서(rua 주소로 전송됨)는 수신 제공업체가 매일 보내는 XML 요약입니다. 이 보고서는 사용자의 도메인으로 메일을 보내는 모든 출처와 각 출처가 SPF, DKIM, 정렬을 통과했는지를 보여 줍니다.

이 보고서를 통해 다음을 파악할 수 있습니다:

• 승인하는 것을 잊은 합법적인 서비스
• 사용자의 도메인을 대상으로 한 스푸핑 시도
• 정책을 적용하기 전에 설정이 잘못된 발신자

통합 보고서는 DMARC를 안전하게 배포하는 데 가장 유용한 도구입니다.

통합 XML 보고서에는 인증 결과와 함께 출처 IP가 나열됩니다:

포렌식(실패) 보고서(ruf 주소로 전송됨)는 비식별 처리된 헤더를 포함하여 개별 실패에 대한 메시지별 세부 정보를 제공합니다.

이 보고서는 진행 중인 스푸핑 공격을 조사하는 데 유용합니다. 그러나 다음 사항에 유의해야 합니다:

• 많은 제공업체는 개인정보 보호 문제로 인해 이러한 보고서를 보내지 않습니다
• 민감한 수신자 데이터가 포함될 수 있으므로 신중하게 처리해야 합니다

실제로 통합(rua) 보고서가 대부분의 핵심 작업을 담당하며, 포렌식 보고서는 추가적인 수단입니다.

reject로 곧바로 전환하지 마십시오. 보고서에 따라 단계적으로 적용하십시오:

• p=none 정책을 rua와 함께 게시하고 몇 주 동안 모니터링합니다
• 보고서에서 확인된 모든 정상 발신자의 SPF와 DKIM을 수정합니다
• p=quarantine으로 전환하고, 선택적으로 pct를 사용해 점진적으로 비율을 높입니다
• 정상적인 메일이 실패하지 않는다고 확신할 수 있을 때 p=reject로 설정합니다

각 단계에서는 다음 단계로 더 엄격하게 전환하기 전에 집계 보고서를 통해 설정을 검증합니다.

두 가지 실무적인 사항으로 전체 그림을 완성할 수 있습니다:

• 하위 도메인 정책(sp) — 공격자가 random.company.com을 사칭할 수 없도록 하위 도메인에 대한 정책을 설정합니다. 하위 도메인에서 메일을 보내지 않더라도 sp=reject를 사용하십시오.
• BIMI — p=quarantine 또는 p=reject에 도달하면 지원되는 받은편지함에 검증된 로고를 표시하는 BIMI 레코드를 게시할 수 있습니다. 이는 DMARC 정책을 시행하도록 유도하는 비즈니스상의 동기가 됩니다.

DMARC가 정책을 어떻게 적용하고 보고하는지 배웠습니다:

• DMARC는 SPF 또는 DKIM이 표시되는 발신자 도메인과 정렬되도록 요구합니다
• 정렬은 완화된 방식(하위 도메인 허용) 또는 엄격한 방식(정확히 일치)으로 설정할 수 있습니다
• p= 정책은 none에서 quarantine, 다시 reject로 강화됩니다
• 집계(rua) 보고서는 안전한 단계적 적용을 이끌고, 포렌식(ruf) 보고서는 메시지별 상세 정보를 추가합니다
• 하위 도메인 정책을 설정하고 정책을 시행하기 시작한 후 BIMI 사용을 고려하십시오

이로써 이메일 보안 과정이 끝납니다. SPF는 서버를 인증하고, DKIM은 메시지에 서명하며, DMARC는 이를 발신자 정보와 연결해 정책을 적용합니다.