DMARC 레코드 설정·확인 방법

DMARC 레코드가 실제로 하는 일

DMARC 레코드는 DNS 텍스트 한 줄입니다. 그 얄팍한 단순함이 바로 수많은 레코드가 아무 일도 안 하는 이유입니다. TXT 레코드를 넣고, 도구가 초록불이 뜨고, 스푸핑이 해결됐다고 믿습니다. 대개는 아닙니다 — 정책이 관찰 전용으로 설정돼 있는데 아무도 리포트를 안 읽고 있거나, 애초에 통과하도록 설정된 적 없는 메일에 정책을 시행하고 있거나 둘 중 하나입니다. 두 실패 모두 조용합니다. DNS를 건드리기 전에 이해해둘 함정입니다.

먼저 새겨야 할 것: DMARC는 자기 의견이 없습니다. 메일 내용을 검사하지 않고, 블록리스트를 돌리지 않고, “스팸처럼 보이는지” 판단하지 않습니다. DMARC가 하는 일은 딱 하나의 좁은 질문입니다 — SPF 또는 DKIM이 통과했는가, 그리고 통과한 그 도메인이 사람이 From: 헤더에서 보는 도메인과 일치하는가? — 그리고 답이 ‘아니오’일 때 수신 서버에게 어떻게 하라고 알려줍니다. 이 정렬 검사가 핵심의 전부입니다. 어떤 메일이 어느 마케팅 업체의 도메인으로는 SPF를 통과하면서도 내 도메인으로는 DMARC에 실패할 수 있습니다. 업체의 도메인은 내 도메인이 아니니까요.

그래서 DMARC 레코드는 두 가지 일을 합니다. 정책을 공표하고(실패한 메일을 수신 서버가 어떻게 처리할지), 리포팅을 켭니다(그 수신 서버들이 나를 사칭해 보낸 발신자 목록을 매일 XML로 보내주도록). 리포팅은 사람들이 가장 덜 쓰는 부분이자, DMARC를 안전하게 배포할 수 있게 만드는 바로 그 부분입니다.

올바른 시작 레코드

시행부터 하지 마세요. 자기 메일을 망치는 가장 흔한 방법이 첫날부터 p=reject를 발행하는 것입니다 — 어떤 정상 서비스가 내 이름으로 메일을 보내는지 알기도 전에요. 여기서 시작하세요:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

완결된, 유효한 레코드입니다. 하나씩 보면:

• v=DMARC1 — 필수, 그리고 맨 앞이어야 합니다. 없으면 수신 서버가 이걸 DMARC 레코드로 인식하지 못하고 전체를 무시합니다.
• p=none — 정책. none은 “지켜보되 행동하지 않음”입니다: 수신 서버는 리포트는 보내주되 실패한 메일도 정상 전달합니다. 모니터링 모드이고, 모든 배포가 여기서 시작해야 합니다.
• rua=mailto:[email protected] — 집계 리포트를 받을 곳. 이 작업 전체를 할 가치가 있게 만드는 부분입니다. 실제로 읽을 메일함(또는 리포트 파싱 서비스)을 가리키세요.

그다음 정직한 롤아웃은 이렇습니다: p=none을 발행하고, 몇 주간 집계 리포트를 읽어 모든 정상 발신원을 파악하고 정렬을 확인한 뒤, 정책을 quarantine으로, 다시 reject로 올립니다. 그 단계별 진행과 언제 올려도 안전한지는 별도 주제입니다 — DMARC none·quarantine·reject 가이드를 보세요.

자주 보게 될, 알아둘 선택 태그 몇 가지:

• sp= 는 서브도메인용 별도 정책을 지정합니다. 생략하면 서브도메인은 p를 상속합니다.
• adkim= / aspf= 는 정렬 엄격도를 조절합니다: r(relaxed, 기본값)은 조직 도메인이 일치하면 허용, s(strict)는 정확히 일치해야 합니다. 특별한 이유가 없으면 relaxed로 두세요.
• np= (2026년 신설)는 존재하지 않는 서브도메인 — A/MX 레코드가 아예 없어 공격자가 즐겨 사칭하는 것들 — 의 정책을 지정합니다. 예전엔 와일드카드 없이는 막을 수 없던 구멍입니다.

2026년에 바뀐 것 (그리고 왜 예전 조언이 틀렸는지)

2026년 5월, DMARC가 드디어 정보성(Informational) 문서에서 표준 트랙 프로토콜로 승격했습니다: RFC 9989가 2015년의 원조 RFC 7489를 폐기했습니다(집계·실패 리포트 형식은 RFC 9990·9991). 기존 v=DMARC1 레코드는 그대로 동작합니다 — 하위 호환입니다 — 하지만 아직 떠도는 복붙 조언 상당수가 이제 표준이 삭제한 것들을 가르치고 있습니다.

가장 중요한 것: pct가 사라졌습니다. 10년간 pct=10은 시행을 단계적으로 도입하는 권장 방법이었습니다 — 실패 메일의 10%에만 정책을 적용하고 점점 올리는 식으로요. 수신 서버마다 구현이 제각각이고 종종 무시돼서, DMARCbis가 삭제했습니다(거의 안 쓰이던 rf·ri 태그와 함께). 단계적 롤아웃의 대체재는 t 태그입니다: t=y는 레코드를 테스트 중으로 표시하고, t=n(기본값)은 실제로 시행하라는 뜻입니다. 생성기나 블로그 글이 pct=가 든 레코드를 건네준다면, 그건 더 이상 존재하지 않는 버전의 DMARC로 쓰인 것입니다.

또 하나의 조용한 변화는 내부에 있습니다: 수신 서버가 이제 외부에서 관리되는 Public Suffix List를 참조해 조직 도메인을 알아내지 않습니다. DNS 트리를 거슬러 올라가며 각 상위 라벨에 DMARC 레코드가 있는지 확인합니다. 이걸 위해 다르게 발행할 건 없지만 — 그래서 서브도메인 정책이 이제 더 예측 가능하게 동작하고, 새 np 태그가 존재하는 것입니다.

DMARC가 “아무 일도 안 하는” 3대 원인

1. 레코드는 있는데 SPF/DKIM이 정렬 안 됨. DMARC는 SPF·DKIM 위에 얹히는 판정입니다. 정상 메일이 발송 플랫폼의 도메인으로는 SPF를 통과하지만 내 도메인으로는 아니면 정렬에 실패합니다 — 그리고 p=none에선 실패 메일도 전달되니 영원히 눈치채지 못합니다. 시행 전에 리포트를 읽어야 하는 이유가 바로 이것입니다.
2. 영원히 p=none. 모니터링 모드는 아무도 보호하지 않습니다. 진입로일 뿐 목적지가 아닙니다. 1년째 p=none에 머문 레코드는 세상의 수신 서버들에게 “내 도메인을 위조한 메일에 아무것도 하지 마”라고 말해온 레코드입니다. 가치는 결국 quarantine이나 reject에 도달하는 데 있습니다.
3. rua가 없어 깜깜이. 정책은 있는데 리포팅 주소가 없는 레코드는 검증할 수 없는 정책을 줍니다. 시행 전에 어떤 발신원이 영향받을지 볼 방법이 없으니 정책을 올리는 게 도박이 됩니다. rua는 항상 넣으세요.

DechoNet으로 진단하기

• 이메일 점검 — 내 도메인에 돌리면 SPF·DKIM·DMARC를 함께 파싱·검증해 보여줍니다. DMARC 레코드 누락이나 형식 오류, 아직 none에 머문 정책, 그리고 도구가 볼 수 있는 발신원의 정렬 문제를 표시합니다 — 내 레코드가 내가 생각한 대로 말하는지 가장 빠르게 확인하는 길입니다.
• DNS 조회 — _dmarc.내도메인의 원시 TXT 레코드를 직접 확인하세요. 레코드가 정확히 하나인지, v=DMARC1으로 시작하는지, 둘 다 무효화하는 두 번째 DMARC 레코드가 없는지 확인합니다. 어떤 DMARC 체커든 그 밑에 깔린 실측 진실입니다.

설정·검증 체크리스트

• 먼저 모든 정상 발신자에 대해 SPF·DKIM이 설정·정렬돼 있는지 확인한다. 이게 없는 DMARC는 그냥 전부 실패시킨다.
• _dmarc.내도메인에 v=DMARC1; p=none;으로 시작하는 TXT 레코드 하나를 발행한다.
• 실제로 모니터링할 rua=mailto: 주소를 넣는다. 언젠가 시행할 생각이라면 선택이 아니다.
• 조회되는지 확인한다: DNS 조회 결과 v=DMARC1 문자열이 정확히 하나여야 한다. 두 개면 정책이 없는 것이다.
• 집계 리포트가 도착할 때까지(하루 이틀) 기다린 뒤, 모든 발송원을 알아볼 수 있을 때까지 읽는다.
• 그제서야 정책을 올린다: none → quarantine → reject, 각 단계마다 리포트를 지켜보며.
• 옛 가이드에서 복사한 레코드의 pct= 태그는 뺀다. 테스트 신호가 필요하면 t=y를 쓴다.

언제 에스컬레이션할까

• 정상 발신원이 계속 정렬에 실패하는데 고칠 수 없다면(예: 내 도메인에 DKIM 설정을 허용하지 않는 SaaS 플랫폼), 그건 발신 측 설정 문제입니다 — 시행하기 전에 그 업체로 가져가세요. 안 그러면 시행이 진짜 메일을 튕겨냅니다.
• 공개 서픽스 도메인(레지스트리, 독립 당사자들이 서브도메인을 보유하는 대형 멀티테넌트 플랫폼)을 운영한다면 psd 태그와 조직 도메인 규칙이 상당히 복잡해집니다 — 일반적인 안내에 기대지 말고 RFC 9989를 직접 읽으세요.