기본적인 DMARC 레코드를 게시하고 나면 진짜 작업이 시작됩니다. 모든 도메인과 시스템에 걸쳐 올바르게 구현하는 일입니다.
DMARC(Domain-based Message Authentication, Reporting & Conformance)는 조직 내 모든 메일 발송 소스가 인증되고 정렬되며 모니터링될 때 가장 효과적으로 작동합니다.
이 가이드는 기본을 넘어 DNS에서 DMARC를 구성하고, 여러 도메인 환경을 관리하며, 테스트에서 완전한 정책 적용으로 안전하게 이행하는 방법을 안내합니다.
DMARC의 기본과 정책 게시 방법은 DMARC 최초 활성화에 관한 개요와 5단계 가이드를 참조하세요.
조직이 여러 도메인이나 하위 도메인을 관리한다면, DMARC를 일회성 DNS 레코드가 아니라 장기적인 정책 프레임워크로 다루어야 합니다. 다음을 파악하는 것부터 시작하세요.
부서나 사업부마다 자체 발송 환경을 갖추는 경우가 흔합니다. 하지만 조율된 DMARC 전략이 없으면 보고서가 분산되고 정책 적용이 위험해집니다.
발송자 목록을 작성하고 각 발송자가 어떤 도메인에서 메일을 보낼지 결정하세요. 이것이 완전한 준수를 위한 토대입니다.
DMARC는 메시지 인증을 위해 SPF와 DKIM에 의존합니다. 둘 중 하나라도 실패하거나 정렬되지 않으면 DMARC도 실패합니다.
각 도메인은 승인된 모든 발송자를 나열하는 단일 SPF 레코드를 가져야 합니다.
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all모범 사례:
-all로 끝내세요.
각 이메일 발송 시스템(예: HubSpot 또는 Office 365)은 DNS에 추가할 DKIM 셀렉터를 제공합니다.
selector1._domainkey.yourdomain.comv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9...
다음을 확인하세요:
모든 DKIM 셀렉터를 문서화하고 알려진 발송 소스와 연결하세요. 이렇게 하면 나중에 문제 해결이 쉬워집니다.
DMARC 레코드는 _dmarc.yourdomain.com 아래 DNS에 추가되는 TXT 항목입니다.
구현을 위한 견고한 출발점은 다음과 같습니다.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; aspf=r; adkim=r항목별로 살펴보겠습니다.
여러 도메인을 관리한다면, 서로 구분할 수 있도록 고유한 보고서 주소를 사용하세요.
rua=mailto:dmarc@corp.yourdomain.com,mailto:dmarc@reports.partner.com하위 도메인의 경우 별도의 레코드를 게시하거나(예: _dmarc.mail.yourdomain.com) 조직 도메인의 정책을 상속받을 수 있습니다.
DMARC 레코드를 생성하려면 DMARC 레코드 구성기를 참조하세요.
정책이 적용되면 메일박스 제공업체가 매일 DMARC 집계(RUA) 보고서를 보내며, 어떤 IP가 도메인을 대신해 메일을 발송했고 그 결과가 어떠했는지 요약해 줍니다.
다음을 확인하세요:
각 보고서 항목에는 다음이 포함됩니다:
정상적인 발송자가 정렬에 실패하면, 정책 적용으로 넘어가기 전에 이를 해결하세요.
더 자세한 설명은 DMARC 집계 보고서 읽는 방법 가이드를 참조하세요.
많은 DMARC 문제는 마케팅 도구, CRM, 결제 처리업체처럼 사용자를 대신해 이메일을 발송하는 서드파티 플랫폼에서 비롯됩니다.
이러한 메시지가 DMARC를 통과하도록 하려면:
공급업체가 DKIM 정렬을 지원하지 않는다면, 거부를 피하기 위해 SPF 정렬이 완벽해야 합니다.
팁: 승인된 모든 서드파티 발송자와 그 DNS 구성을 담은 공유 내부 목록을 유지하세요.
보고서에서 모든 정상 발송자가 올바르게 인증되고 있음이 확인되면, DMARC 적용을 시작하세요.
단계적으로 이행하세요:
pct 태그를 사용해 부분 적용을 테스트할 수도 있습니다:
v=DMARC1; p=reject; pct=50; rua=mailto:dmarc-reports@yourdomain.com이는 결과를 모니터링하면서 트래픽의 50%에 정책을 적용합니다.
정책을 강화하는 동안 매일 보고서를 계속 검토하세요.
하위 도메인은 기본 정책을 상속받거나 자체 정책을 가질 수 있습니다. 예를 들면:
v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-reports@yourdomain.com여기서:
기본 도메인에서는 테스트하면서 billing.yourdomain.com과 같은 트랜잭션 하위 도메인에는 더 엄격한 적용을 원할 때 사용하세요.
충분히 준비된 팀도 다음과 같은 실수를 합니다:
rua 태그 누락(보고서 없음).p=none)을 영원히 사용하는 것.DMARC는 능동적으로 모니터링되고 적용될 때만 사용자를 보호합니다. p=none으로 무기한 방치하면 스푸핑에 대한 보호를 전혀 제공하지 못합니다.
DMARC 정책이 완전히 적용된 후에는 지속적인 모니터링을 통해 모든 것이 정상 상태를 유지하도록 합니다.
정기적으로 검토하세요:
DMARC는 "한 번 설정하고 잊어버리는" 시스템이 아닙니다. 도메인 보안 태세의 일부로서 계속 진화합니다.
DMARC 설정부터 지속적인 모니터링과 그 이후까지 이어지는 완전한 로드맵은 DMARC 모니터링 및 준수 가이드를 참조하세요.
설정을 넘어선 더 폭넓은 기본 원칙은 이메일 인증 모범 사례를 참조하세요.
DMARC를 설정하는 것과 여러 도메인 및 플랫폼에 걸쳐 유지 관리하는 것은 별개의 문제입니다. DMARCeye는 다음을 수행하는 AI 기반 DMARC 모니터링 및 관리 플랫폼입니다:
구현이 제대로 작동하고 있는지, 어떤 시스템을 조정해야 하는지, 완전한 준수에 얼마나 가까운지를 손쉽게 확인하세요.