DMARC 레코드 확인하고 만들기

DMARC 레코드는 최대 11개의 설정이 담긴 한 줄이며, 그중 단 두 개가 이 레코드가 실제로 작동할지를 결정합니다. 이 도구는 그것을 평범한 말로 풀어서 보여준 다음, 보고서가 조용히 도착하지 않게 만드는 그 한 가지 원인을 확인합니다.

도구를 불러오는 중…

작동 방식

  1. 도메인을 입력하고 “Check”(확인)를 누르세요.
  2. 설정값과 진단 내용을 확인하세요. p=(정책)는 수신 서버가 실제로 따르는 값이고, pct=는 이 정책을 적용할 메일의 비율을 제한합니다.
  3. 보고서를 다른 회사의 주소로 받는다면 권한 블록을 확인하세요. 이 레코드가 없으면 보고서는 영영 도착하지 않습니다.

왜 아무것도 업로드되지 않는가

이 페이지가 하는 모든 작업은 브라우저 탭 안에서 도는 코드가 처리합니다. 웹 페이지를 그리는 그 엔진을 그대로 씁니다. 파일은 디스크에서 탭의 메모리로 읽어 들여 거기서 변환한 뒤 다시 다운로드 파일로 내보냅니다. 어디로도 전송되지 않습니다. 우리에게도, 제3자에게도.

직접 확인해 보세요

  1. 브라우저 개발자 도구(F12)를 열고 네트워크(Network) 탭을 선택합니다.
  2. 파일을 올리고 도구를 실행합니다.
  3. 보이는 요청은 도구 자체의 코드를 받아 오는 것뿐입니다. 무거운 몇몇 도구는 공개 CDN에서 오픈소스 엔진을 함께 받아 옵니다. 여기에 loreatec.jp로 가는 작은 방문 집계 신호 하나(페이지 주소와 제목, 그 이상은 없습니다)가 더해집니다. 어느 것도 당신의 파일을 실어 나르지 않습니다.

직접 확인하기 →

자주 묻는 질문

DMARC를 설정했는데 보고서가 하나도 오지 않습니다. 왜 그런가요?

보고서 주소(rua)가 당신의 도메인이 아닌 다른 도메인, 예를 들어 분석 업체나 대행사, 개인 메일함이라면 그 도메인 쪽에서 “당신을 대신해 보고서를 받겠다”는 레코드를 공개해야 합니다. yourdomain._report._dmarc.theirdomain에 v=DMARC1 값으로 등록하는 방식입니다. 수신 서버는 보내기 전에 이것을 확인하고, 없으면 아무 말 없이 그냥 보내지 않습니다. 이 페이지가 그것을 대신 확인해 줍니다. 그 밖의 흔한 원인은 주소 앞에 “mailto:”가 빠진 경우입니다.

adkim과 aspf는 실제로 무엇을 바꾸나요?

SPF나 DKIM을 통과한 도메인이 사람들이 보는 From 주소와 얼마나 정확히 일치해야 하는지를 정합니다. Relaxed(기본값)는 같은 조직의 어떤 하위 도메인이든 인정합니다. mail.example.com도 example.com으로 쳐줍니다. Strict는 정확히 일치해야 합니다. 거의 모든 경우에는 relaxed가 맞고, strict는 모든 하위 도메인을 직접 관리하며 그중 하나가 뚫렸을 때 악용되는 것을 막고 싶은 조직을 위한 것입니다.

p=none은 쓸모없는 설정인가요?

꼭 필요한 첫걸음이지만 끝으로 삼기엔 부족합니다. p=none에서는 당신의 메일에 아무 변화도 없지만 보고서는 받을 수 있습니다. 정당한 발신원을 전부 찾아내는 몇 주 동안 딱 필요한 상태입니다. 하지만 이 상태로 몇 년을 두면 아무것도 지켜주지 않습니다. 여전히 누구나 당신의 도메인으로 메일을 보낼 수 있고, 이제는 당신이 그 사실을 알고 있었다는 기록만 남는 셈입니다.

sp=는 무엇에 쓰나요?

하위 도메인 전용 정책입니다. 지정하지 않으면 하위 도메인은 p= 값을 그대로 물려받습니다. 이것이 중요한 이유는 공격자가 애초에 메일을 보낼 일이 없는 하위 도메인, 예를 들면 invoice.yourdomain.com 같은 것을 악용하기 때문입니다. 이런 하위 도메인은 주 도메인이 아직 none인 상태에서도 sp=reject로 설정해서 잃을 것이 없습니다.

pct는 어떤 역할을 하나요?

실패한 메일 중 일부 비율에만 정책을 적용합니다. 그래서 quarantine을 10%부터 적용해 지켜볼 수 있습니다. 이것은 점진적으로 올라가는 단계이지 목적지가 아닙니다. p=reject에 pct=50이면 위조 메일의 절반은 여전히 통과합니다.