레코드는 DMARC 소유자 이름에 있어야 합니다
example.com의 경우 수신자는 _dmarc.example.com을 조회합니다. 루트 도메인이나 다른 임의 호스트의 v=DMARC1 문자열은 해당 도메인의 DMARC 정책이 되지 않습니다.
적용 가능한 DMARC 레코드는 하나만 반환되어야 합니다. 중복되거나 형식이 잘못된 정책은 계층적 보호가 아니라 불확실성을 만듭니다.
도메인을 입력하면 DMARC 레코드를 가져와 분석합니다. 적용 정책, 정렬 설정, 보고 주소, 구성 상태를 확인하십시오.
DMARC(Domain-based Message Authentication, Reporting and Conformance)는 DNS에 게시되는 이메일 인증 정책입니다. SPF와 DKIM 검사가 실패했을 때 수신 메일 서버가 무엇을 해야 하는지 알리고, 도메인의 인증 활동에 대한 보고서를 보내도록 지시합니다. DMARC는 이메일 인증의 정점입니다. SPF와 DKIM을 하나의 일관된 정책으로 통합합니다.
DMARC 레코드는 _dmarc.yourdomain.com 하위 도메인의 TXT 레코드로 게시됩니다. 가장 중요한 태그는 정책을 설정하는 p=입니다. none은 조치를 하지 않음(모니터링 모드), quarantine은 실패 메시지를 스팸으로 보내고, reject는 완전히 차단합니다. 대부분의 도메인은 none으로 시작한 뒤 모든 정상 발신자가 올바르게 인증되었음을 확인하면서 시간이 지나 reject로 전환합니다.
DMARC의 보고 기능은 특히 가치가 있습니다. rua(집계 보고서용 보고 URI) 주소를 포함하면 Gmail, Outlook, Yahoo를 포함한 주요 ISP가 도메인에서 온 것처럼 메일을 보낸 모든 IP를 보여주는 일일 XML 보고서를 보냅니다. 이 보고서로 무단 발신자를 식별하고, 잘못 구성된 서비스를 발견하며, 시간에 따른 인증 상태를 모니터링할 수 있습니다.
핵심 적용 정책: none, quarantine 또는 reject.
하위 도메인 정책입니다. 설정하지 않으면 p=를 상속합니다.
정책이 적용되는 메시지 비율입니다. 기본값은 100입니다.
일일 집계 보고서를 받을 이메일 주소 또는 URI입니다.
메시지 샘플이 포함된 실패 보고서를 받을 이메일 주소입니다.
r=relaxed(기본값), s=strict. Strict는 정확한 도메인 일치를 요구합니다.
r=relaxed(기본값), s=strict. Strict는 정확한 envelope-from 일치를 요구합니다.
포렌식 보고서를 보낼 시점: 0=둘 다 실패(기본값), 1=하나라도 실패, d=DKIM 실패, s=SPF 실패.
게시된 정책 근거
검사기는 공개 TXT 정책을 가져와 태그를 구문 분석하고, 정렬된 인증에 실패한 메일에 대해 수신자에게 요청하는 조치를 보여 줍니다.
example.com의 경우 수신자는 _dmarc.example.com을 조회합니다. 루트 도메인이나 다른 임의 호스트의 v=DMARC1 문자열은 해당 도메인의 DMARC 정책이 되지 않습니다.
적용 가능한 DMARC 레코드는 하나만 반환되어야 합니다. 중복되거나 형식이 잘못된 정책은 계층적 보호가 아니라 불확실성을 만듭니다.
인증된 SPF 또는 DKIM 식별자가 표시되는 From 도메인과 정렬되면 DMARC가 통과합니다. 검사기는 p=, adkim, aspf를 읽을 수 있지만, 제공되지 않은 메시지의 Authentication-Results는 볼 수 없습니다.
게시된 레코드를 도메인의 지시로 사용한 뒤, 실제 메일을 테스트해 각 소스가 이를 충족할 수 있는지 확인하십시오.
정책 해석
각 결과는 구성을 설명합니다. 적용과 보고는 수신자와 실제 메시지의 인증에 달려 있습니다.
SPF와 DKIM은 여전히 존재할 수 있지만, 수신자는 이 소유자 이름에서 DMARC 지시를 받지 않으며 이 정책에 대한 집계 보고서 대상도 요청되지 않습니다.
정상 발신자를 파악하는 동안 유용한 집계 보고서를 생성할 수 있지만, 정렬된 인증 실패에 대한 격리나 거부를 요청하지는 않습니다.
더 강한 정책을 건전하다고 부르기 전에, 중요한 트랜잭션, 워크스페이스, 마케팅, 지원, 벤더 발송이 정렬된 SPF 또는 DKIM을 통과하는지 확인하십시오.
sp 태그는 하위 도메인 정책을 지정할 수 있습니다. 없으면 DMARC의 정책 발견 규칙이 조직 도메인 정책의 적용 방식을 결정하므로, 메시지가 사용하는 정확한 From 도메인을 확인하십시오.
감사 순서
적용을 변경하기 전에 DNS 정책을 보고서 및 메시지 헤더와 연결하십시오.
From 헤더에서 @ 뒤에 표시된 도메인을 입력하십시오. 하위 도메인의 경우 정확한 이름을 확인하고 직접 정책인지 상속 정책인지 파악하십시오.
모든 태그가 의도한 배포를 반영하는지, rua 또는 ruf 주소가 통제되고 필요 시 승인되었으며 보고서를 안전하게 처리할 수 있는지 확인하십시오.
구성을 수정해야 하면 DMARC 레코드 생성기를 사용해 업데이트된 TXT 레코드 하나를 게시하고, TTL을 기다린 뒤 검사를 반복하십시오.
조회가 증명할 수 없는 것
DNS 정책은 필요한 근거이지만, 운영 준수와는 다릅니다.
활성 소스 IP, 실패 규모, 알 수 없는 벤더, 스푸핑 패턴을 식별할 수 없습니다. 이러한 사실은 참여 수신자가 보내는 rua 보고서에 있습니다.
DMARC는 도메인 소유자 정책을 게시합니다. 각 수신자는 여전히 로컬 전달 및 필터링 결정을 적용하며, 요청된 모든 보고서를 보내지 않을 수 있습니다.
메시지 수준 조사에는 From 도메인, 반환 경로, DKIM 서명, Authentication-Results, 관련 Received 헤더가 필요합니다.
DMARC는 발신자 도메인을 인증합니다. 대상 사서함이 수신 가능한지 평가하려면 이메일 검증기를 사용하십시오.
프로토콜 참조
대시보드 레이블이 정렬, 발견, 보고 세부 사항을 가릴 때 명세를 사용하십시오.
IETF의 RFC 7489는 정책 발견, 정렬된 식별자, 조직 도메인, 수신자 처리, 피드백 보고를 정의합니다.
SPF 권한 부여, DKIM 키 게시, DMARC 정책, 실제 메시지 헤더, 집계 보고서를 확인하십시오. 단일 DNS 결과가 다른 계층을 대체하지 않습니다.
다음 도구를 증거 유형으로 고르십시오. 수신자, 주소 탐색, DNS와 인프라, 또는 발신자 워크플로입니다.
무료 도구
정책, 정렬, 보고 옵션으로 DMARC DNS TXT 레코드를 만듭니다. 도메인 이메일 인증용 무료 생성기입니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
모든 도메인의 SPF 레코드를 확인하고 검증합니다. 전체 SPF 레코드, 메커니즘 분석, 올바른 구성 여부를 확인하십시오. 무료, 가입 불필요.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
모든 도메인과 셀렉터의 DKIM 레코드를 확인합니다. 전체 공개 키 레코드와 DKIM 서명 구성 여부를 검사합니다. 무료, 가입 불필요.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
모든 도메인의 A, AAAA, MX, TXT, NS, CNAME 레코드를 확인하십시오. 실시간 DNS 조회로 즉시 결과를 확인합니다. 무료이며 가입이 필요 없습니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
이메일 도구
raw 이메일 헤더를 붙여넣으면 SPF, DKIM, DMARC 결과, 전달 경로, 스팸 점수, 주요 메타데이터를 구조화해 분석합니다. 무료, 가입 불필요.
발신자 또는 메시지 진단이며, 주소 탐색이 아닙니다.
이메일 도구
실제 메시지 샘플로 이메일 전달성 테스트를 실행하세요. SPF, DKIM, DMARC, DNS, 블랙리스트, 스팸 필터, 헤더, 콘텐츠 증거를 검토합니다.
발신자 또는 메시지 진단이며, 주소 탐색이 아닙니다.
DMARC 레코드가 없으면 DMARC 정책이 없습니다. 수신 서버는 DMARC에 기반한 조치를 적용하지 않습니다. 즉 도메인에서 온 것처럼 위장한 스푸핑 이메일은 SPF와 DKIM 외에 추가 장벽이 없습니다. Google과 Yahoo는 이제 대량 발신자에게 DMARC 레코드(p=none이라도)를 요구합니다. 이메일을 보내는 모든 도메인은 최소한 모니터링용 DMARC 레코드를 게시해야 합니다.
p=none은 DMARC가 모니터링 모드임을 의미합니다. 보고서는 수집하지만 실패 메시지에는 조치를 하지 않습니다. p=quarantine은 수신 서버가 실패 메시지를 스팸 폴더로 전달하도록 지시합니다. p=reject는 실패 메시지가 받은편지함에 도달하기 전에 완전히 차단되어야 함을 의미합니다. none으로 시작한 뒤 2주에서 4주 동안 보고서를 검토한 다음 quarantine과 reject로 단계적으로 전환하십시오.
정렬이란 SPF 또는 DKIM을 통과한 도메인이 표시되는 From 헤더의 도메인과 일치해야 함을 의미합니다. 완화된 정렬은 하위 도메인 일치를 허용합니다. mail.example.com은 example.com과 정렬됩니다. 엄격한 정렬은 정확한 일치를 요구합니다. 전달과 ESP 발송 메일이 깨지지 않도록 대부분의 구성에서는 relaxed를 사용하십시오.
DMARC 레코드에 rua 이메일 주소를 포함하면 주요 ISP가 매일 XML 보고서를 보냅니다. 각 보고서에는 어떤 IP가 도메인에서 메일을 보냈는지, 각각 몇 통을 보냈는지, SPF와 DKIM이 통과했는지 실패했는지가 담깁니다. 이 보고서를 사용해 인증 설정이 필요한 정상 발신자를 찾고 스푸핑 시도를 탐지하십시오.
sp= 태그를 설정하지 않으면 기본 도메인의 DMARC 정책이 하위 도메인에도 적용됩니다. 하위 도메인 보호를 원하면 DMARC 레코드에 sp=reject 또는 sp=quarantine을 추가하십시오. sp=가 없으면 하위 도메인은 완화된 정렬 하에서 p= 정책을 상속합니다.
예. pct=25로 설정하면 DMARC 정책이 실패 메시지의 25%에만 적용됩니다. 점진적 배포에 유용합니다. quarantine 또는 reject를 처음 활성화할 때 10% 또는 25%로 시작해 정상 메일이 잘못 구성된 경우 영향을 제한하십시오. 정상 메일이 실패하지 않음을 확인한 뒤 100으로 올리십시오.