우리 도메인 DMARC 레코드, 제대로 등록됐는지 조회하고 확인하는 법

DMARC를 등록해 두었다고 안심하는 담당자 중 상당수는 실제로 조회해보면 레코드가 잘못 들어가 있거나, 몇 달째 p=none에 머물러 있어 사실상 아무 효과가 없는 경우가 많습니다. DMARC는 설정 한 번으로 끝나는 항목이 아니라 조회, 확인, 정책 강화를 반복하는 운영 항목입니다. 이 글에서는 이미 등록된 DMARC 레코드를 조회하고 값을 해석하는 방법과, 정책을 안전하게 강화해 나가는 절차를 정리합니다.

DMARC 레코드 조회, 어디서 어떻게 하나

DMARC 레코드는 도메인 DNS에 _dmarc.도메인.com이라는 이름으로 등록된 TXT 레코드입니다. 조회하는 방법은 여러 가지가 있는데, 가장 빠른 것은 터미널에서 nslookup -type=txt _dmarc.도메인.com 명령을 실행하는 것입니다. 리눅스나 macOS라면 dig txt _dmarc.도메인.com도 동일한 결과를 보여줍니다.

명령줄이 익숙하지 않다면 MXToolbox, DMARC Analyzer, Google Admin Toolbox의 Dig 페이지 같은 무료 온라인 조회 도구에 도메인만 입력해도 됩니다. 이런 도구들은 TXT 레코드 원문뿐 아니라 태그별로 값을 풀어서 보여주기 때문에 문법을 직접 해석할 필요가 없어 실무에서 더 자주 쓰입니다.

여러 도메인을 운영하는 조직이라면 조회를 한 번으로 끝내지 말고 주기적으로 반복하는 것이 좋습니다. DNS 관리 권한이 여러 사람에게 있는 경우 누군가 실수로 레코드를 지우거나 값을 바꿔도 알아차리기 어렵기 때문입니다.

조회 결과 읽는 법: 태그별 의미

DMARC 레코드는 세미콜론으로 구분된 태그 조합으로 이루어져 있습니다. 조회 결과에 나온 문자열을 그대로 읽을 줄 알아야 지금 상태가 안전한지 판단할 수 있습니다.

가장 먼저 봐야 할 것은 v=DMARC1로 시작하는지 여부입니다. 이게 없거나 다른 값이면 레코드 자체가 무효로 처리됩니다. 그다음은 p= 태그로, none·quarantine·reject 중 하나가 들어가며 이 값이 현재 정책 수준을 그대로 보여줍니다.

• v=DMARC1 — 필수 시작 값, 없으면 레코드 무효
• p= — 정책: none(관찰만)/quarantine(스팸함 격리)/reject(반송)
• rua= — 집계 리포트를 받을 메일 주소
• ruf= — 개별 실패 사례 포렌식 리포트 수신 주소(선택)
• pct= — 정책을 적용할 메일 비율, 기본값은 100
• sp= — 서브도메인에 별도로 적용할 정책

레코드가 있는데도 문제가 되는 흔한 케이스

조회했을 때 레코드가 나온다고 끝난 게 아닙니다. 실무에서 자주 보는 문제는 레코드는 존재하지만 실제로는 작동하지 않는 상태입니다.

가장 흔한 것은 _dmarc 레코드를 도메인당 두 개 이상 등록해 둔 경우입니다. SPF와 마찬가지로 DMARC도 레코드가 여러 개면 어떤 것을 기준으로 삼아야 할지 알 수 없어 전체가 무효 처리됩니다. 그다음은 rua 태그에 mailto: 접두사를 빠뜨리는 문법 오류, 그리고 등록은 했지만 몇 달째 p=none에 머물러 사실상 아무 정책도 집행되지 않는 경우입니다.

• _dmarc TXT 레코드가 중복 등록된 경우
• rua= 값에 mailto: 접두사 누락
• p=none 상태로 장기 방치되어 사실상 무정책
• 리포트 수신 메일함을 만들어 두고 실제로는 확인하지 않는 경우
• 서브도메인 발신이 있는데 sp= 태그를 지정하지 않아 정책이 불명확한 경우

p=none에서 reject까지, 정책 강화 절차

DMARC 도입 초기에는 p=none으로 시작해 리포트만 쌓는 것이 원칙입니다. 이 단계에서 rua로 지정한 주소에 하루 또는 며칠 단위로 집계 리포트(XML 형식)가 도착하는데, 여기에는 어떤 IP가 해당 도메인 이름으로 메일을 보냈는지, SPF와 DKIM을 통과했는지가 기록됩니다.

리포트를 2~4주 정도 확인해 정상 발신 경로(사내 메일 서버, CRM 발송 모듈, 워밍업용 계정 등)가 모두 통과하고 있다는 것이 확인되면 p=quarantine으로 올립니다. 이 단계는 실패한 메일을 곧바로 반송하지 않고 스팸함으로 보내는 정도라 리스크가 크지 않습니다. quarantine 상태에서도 문제가 없다는 것이 확인되면 마지막으로 p=reject로 전환해 인증 실패 메일을 아예 거부하도록 만듭니다.

이 단계를 건너뛰고 처음부터 reject로 걸면, 미처 SPF에 등록하지 못한 발신 경로가 있을 경우 정상 업무 메일까지 반송되는 사고로 이어질 수 있습니다.

• 1단계: p=none, 2~4주 리포트 수집
• 2단계: 정상 발신원 확인 후 p=quarantine 전환
• 3단계: 안정적 통과 확인 후 p=reject 전환
• 각 단계 전환 전 반드시 리포트로 발신 경로 누락 여부 재확인

정책 수준별 도메인 사칭 대응력 차이

정책 수준을 올릴수록 도메인을 사칭한 피싱·스푸핑 메일에 대한 실질적인 차단력이 올라갑니다. 다만 이 수치는 조직마다 발신 환경이 달라 절대적인 기준으로 받아들이기보다는 상대적인 방향성으로 참고하는 것이 맞습니다.

LDM이 DMARC 상태를 다루는 방식

LDM은 콜드메일 발송에 쓰이는 발신 도메인의 DMARC 레코드를 발송 전에 조회해 정책 수준과 리포트 수신 여부를 확인합니다. p=none 상태로 방치된 도메인이나 레코드 자체가 없는 도메인은 발송 전 인증 설정을 먼저 안내하고, 특정 소수 담당자에게 보내는 타겟형 발송이라 해도 인증되지 않은 도메인의 위험은 대량 발송과 다르지 않다는 원칙으로 접근합니다. 정책을 quarantine이나 reject로 이미 올려둔 도메인에 대해서는 워밍업 단계에서 리포트 상 실패 이력이 없는지 별도로 점검합니다.

자주 묻는 질문