도입
SPF를 설정했고, DKIM도 활성화했습니다.
그런데 여전히 누군가가 우리 회사 도메인으로 피싱 메일을 보내고 있습니다.
왜일까요?
SPF와 DKIM은 이메일을 검증하는 기술이지만, 검증에 실패했을 때 "어떻게 처리할지"를 결정하는 권한은 없습니다.
수신 서버가 알아서 판단하게 내버려두는 셈입니다.
이 빈틈을 채우는 것이 바로 DMARC(Domain-based Message Authentication, Reporting & Conformance)입니다.
DMARC란? — 한 줄 정의
DMARC란, SPF와 DKIM 인증 결과를 기반으로 인증 실패 이메일의 처리 방법(허용/격리/거부)을 도메인 소유자가 직접 지정하고, 인증 결과 리포트를 받을 수 있게 하는 이메일 인증 정책 프레임워크입니다.
SPF와 DKIM 위에 얹는 "정책 레이어"입니다
도메인 소유자가 "내 이름을 사칭한 메일은 이렇게 처리해줘"라고 수신 서버에 지시
인증 결과에 대한 리포트(Report)를 받아 모니터링할 수 있습니다
SPF, DKIM과 함께 이메일 인증의 3대 표준을 구성합니다
왜 DMARC가 필요한가요?
SPF와 DKIM만으로는 두 가지 핵심 문제가 해결되지 않습니다.
문제 1: 정책 부재
SPF나 DKIM 검증에 실패한 이메일을 어떻게 처리할지는 수신 서버의 재량입니다. 도메인 소유자가 "거부해줘"라고 말할 수 있는 방법이 없습니다.
문제 2: 정렬(Alignment) 미검증
SPF는 Return-Path 도메인을, DKIM은 서명 도메인(d= 태그)을 각각 검증합니다. 하지만 사용자가 실제로 보는 "보낸 사람(From)" 주소와 이 도메인들이 일치하는지는 확인하지 않습니다. DMARC는 이 "정렬(Alignment)"을 검증합니다.
DMARC가 있을 때 | DMARC가 없을 때 |
|---|---|
인증 실패 이메일의 처리 방법을 도메인 소유자가 결정 | 수신 서버가 임의로 판단 — 통과시킬 수도 있음 |
From 주소와 인증 도메인의 정렬(Alignment) 검증 | From 주소 위조를 감지하지 못함 |
인증 결과 리포트를 받아 사칭 시도를 모니터링 | 누가 우리 도메인을 사칭하는지 알 수 없음 |
점진적 정책 강화 가능 (none → quarantine → reject) | 정책 적용 자체가 불가능 |
BIMI(브랜드 로고 표시) 같은 고급 기능 활용 가능 | BIMI 적용 불가 |
2024년부터 Google, Yahoo, Microsoft 등 주요 메일 서비스는 대량 발송자에게 DMARC를 필수로 요구합니다. DMARC가 없으면 이메일이 거부되거나 스팸으로 분류될 수 있습니다.
DMARC는 어떻게 작동하나요?
DMARC의 작동 과정을 단계별로 살펴보겠습니다.
1단계: 도메인 소유자가 DMARC 레코드 게시
도메인의 DNS에 DMARC 정책을 TXT 레코드로 게시합니다
레코드 위치:
_dmarc.yourdomain.com예:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
2단계: 수신 서버가 이메일을 받음
수신 메일 서버가 이메일을 받으면, 발신 도메인의 DMARC 레코드를 DNS에서 조회
3단계: SPF와 DKIM 인증 수행
수신 서버가 SPF 검증(발신 서버가 허용 목록에 있는가?)과 DKIM 검증(디지털 서명이 유효한가?)을 수행
4단계: 정렬(Alignment) 확인
SPF 또는 DKIM이 통과한 도메인이 이메일의 "From" 주소 도메인과 일치하는지 확인
이것이 DMARC만의 핵심 기능인 "정렬(Alignment)"입니다
SPF/DKIM이 통과해도 From 주소와 정렬되지 않으면 DMARC는 실패합니다
5단계: 정책에 따라 처리
DMARC 인증에 실패한 이메일은 DMARC 레코드의 정책(p= 태그)에 따라 처리됩니다
p=none: 아무 조치 없이 정상 전달 (모니터링 모드)
p=quarantine: 스팸/정크 폴더로 격리
p=reject: 이메일 거부 (가장 강력한 보호)
6단계: 리포트 발송
수신 서버가 인증 결과 리포트를 도메인 소유자에게 발송
집계 리포트(Aggregate Report, rua): XML 형식, 일별 발송, 전체 인증 통계
포렌식 리포트(Forensic Report, ruf): 개별 실패 건에 대한 상세 정보
DMARC 레코드 구성 요소
DMARC 레코드는 여러 태그로 구성됩니다. 핵심 태그를 살펴보겠습니다.
태그 | 필수 여부 | 의미 | 예시 |
|---|---|---|---|
v | 필수 | DMARC 버전 (항상 DMARC1) | v=DMARC1 |
p | 필수 | 정책 (none / quarantine / reject) | p=reject |
rua | 권장 | 집계 리포트 수신 이메일 주소 | rua=mailto:dmarc@example.com |
ruf | 선택 | 포렌식 리포트 수신 이메일 주소 | ruf=mailto:forensic@example.com |
pct | 선택 | 정책 적용 비율 (기본값 100%) | pct=50 |
sp | 선택 | 서브도메인 정책 | sp=reject |
adkim | 선택 | DKIM 정렬 모드 (r=relaxed / s=strict) | adkim=s |
aspf | 선택 | SPF 정렬 모드 (r=relaxed / s=strict) | aspf=r |
DMARC 정책 3단계 — none → quarantine → reject
DMARC는 점진적으로 강화하는 것이 핵심입니다. 처음부터 reject로 시작하면 정상 이메일도 거부될 수 있습니다.
1단계: p=none (모니터링)
이메일 처리에 영향 없이 리포트만 수집
우리 도메인으로 누가, 어디서 이메일을 보내는지 파악
정상 발송 서비스가 SPF/DKIM 인증을 제대로 통과하는지 확인
기간: 보통 2~4주, 충분한 데이터가 모일 때까지
2단계: p=quarantine (격리)
인증 실패 이메일을 스팸 폴더로 격리
pct 태그로 적용 비율을 점진적으로 늘림 (예: 25% → 50% → 100%)
리포트를 계속 모니터링하면서 정상 이메일에 영향 없는지 확인
3단계: p=reject (거부)
인증 실패 이메일을 완전히 거부 — 가장 강력한 보호
사칭 이메일이 수신자에게 도달하지 않음
BIMI(브랜드 로고 표시) 적용을 위한 필수 조건
주의: p=reject를 너무 서둘러 적용하면, 아직 SPF/DKIM 설정이 안 된 정상 발송 서비스(마케팅 도구, CRM, 고객지원 등)의 이메일까지 거부됩니다. 반드시 none → quarantine → reject 순서로 단계적으로 강화하세요.
SPF · DKIM · DMARC — 세 가지가 함께 작동하는 방식
세 프로토콜은 이메일 인증의 서로 다른 질문에 답합니다.
프로토콜 | 핵심 질문 | 비유 |
|---|---|---|
SPF | "이 서버가 이 도메인 대신 메일을 보낼 권한이 있는가?" | 방문자 명단 — 허용된 서버 목록 |
"이메일이 변조되지 않았고 진짜 이 도메인에서 보낸 것인가?" | 위조 방지 도장 — 디지털 서명 | |
DMARC | "인증 실패 시 어떻게 처리하고, 결과를 어디로 보고하는가?" | 경비 지침 — 정책 + 보고 체계 |
작동 순서:
이메일 도착 → 수신 서버가 SPF 확인 (발신 서버 IP 검증)
DKIM 확인 (디지털 서명 검증)
DMARC 확인 (SPF/DKIM 결과 + From 주소 정렬 + 정책 적용)
정책에 따라 전달 / 격리 / 거부
도메인 소유자에게 리포트 발송
DMARC 설정하는 법
1. SPF와 DKIM이 정상 작동하는지 확인
DMARC는 SPF 또는 DKIM 중 최소 하나가 통과 + 정렬되어야 작동합니다
먼저 SPF와 DKIM을 설정하고 테스트하세요
2. DMARC 레코드 생성
모니터링 모드부터 시작:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDNS에 TXT 레코드로 추가:
_dmarc.yourdomain.com
3. 리포트 모니터링
2~4주간 집계 리포트를 분석하여 모든 정상 발송 서비스가 인증을 통과하는지 확인
DMARC 리포트 분석 도구(Valimail, Postmark 등)를 활용하면 XML 리포트를 읽기 쉽게 변환
4. 정책 점진적 강화
정상 발송 확인 후 quarantine → reject 순서로 강화
pct 태그를 활용하여 적용 비율을 점진적으로 늘림
DMARC 설정 시 주의사항
❌ 하지 마세요 | ✅ 이렇게 하세요 |
|---|---|
처음부터 p=reject로 시작 | p=none으로 시작하고 리포트 분석 후 점진적 강화 |
리포트 수신 주소(rua)를 설정하지 않음 | 반드시 rua를 설정하여 인증 결과를 모니터링 |
서드파티 서비스의 SPF/DKIM 설정을 빠뜨림 | 우리 도메인으로 메일 보내는 모든 서비스를 점검 |
DMARC만 설정하고 SPF/DKIM은 미설정 | 세 가지를 모두 설정 — DMARC는 SPF/DKIM 위에서 작동 |
설정 후 리포트를 방치 | 정기적으로 리포트를 확인하고 새로운 발송 서비스 추가 시 즉시 반영 |
서브도메인 정책(sp)을 고려하지 않음 | 서브도메인도 사칭 대상 — sp 태그로 별도 정책 설정 |
DMARC 리포트 읽는 법
DMARC의 가장 강력한 기능 중 하나가 리포트입니다.
집계 리포트 (Aggregate Report, rua)
형식: XML (보통 일 1회 수신)
내용: 어떤 IP에서 우리 도메인으로 이메일을 보냈는지, SPF/DKIM/DMARC 통과 여부
활용: 사칭 발송 시도 탐지, 정상 서비스의 인증 실패 발견
포렌식 리포트 (Forensic Report, ruf)
형식: 개별 실패 건마다 발송
내용: 인증 실패한 이메일의 상세 헤더 정보
주의: 모든 수신 서버가 지원하지는 않으며, 개인정보 이슈로 제한적
XML 리포트를 직접 읽기 어렵다면, DMARC 리포트 분석 도구를 활용하세요. 무료 도구(Postmark DMARC, MXToolbox 등)부터 유료 서비스(Valimail, Agari 등)까지 다양한 선택지가 있습니다.
DMARC가 B2B 비즈니스에 미치는 영향
이메일 전달률: DMARC 정책이 적용된 도메인은 메일 서비스 제공자에게 신뢰할 수 있는 발신자로 인식됩니다
브랜드 보호: 사칭 이메일을 원천 차단하여 고객 피싱 피해를 방지
가시성: 리포트를 통해 우리 도메인이 어떻게 사용되고 있는지 파악 가능
규정 준수: 금융, 의료 등 규제 산업에서 이메일 인증은 컴플라이언스 요건
BIMI 활용: p=quarantine 이상의 DMARC 정책을 적용하면 수신자의 받은 편지함에 브랜드 로고를 표시할 수 있습니다
핵심 요약
항목 | 내용 |
|---|---|
DMARC란 | SPF/DKIM 결과에 기반해 인증 실패 이메일의 처리 정책을 지정하는 프레임워크 |
핵심 기능 | 정책 적용(none/quarantine/reject) + 정렬(Alignment) 검증 + 리포트 |
SPF/DKIM과의 관계 | SPF/DKIM이 "검증", DMARC가 "정책 + 보고"를 담당 |
도입 순서 | SPF → DKIM → DMARC (none) → quarantine → reject |
레코드 위치 | DNS TXT: _dmarc.yourdomain.com |
필수인 이유 | Google/Yahoo 필수 요건, 브랜드 보호, 전달률 향상, BIMI 전제 조건 |