이 글의 순서 11개 절

1. SPF, DKIM, DMARC가 각각 보는 도메인
2. 발송 서비스를 쓸 때
3. dig로 확인하기
4. 받은 메일에서 결과 보기
5. p=none에서 p=reject까지
6. rua 보고서 읽기
7. Gmail, Yahoo, Outlook.com 발신자 요건
8. Cloudflare DMARC Management로 보고서 받기
9. 메일을 쓰지 않는 도메인
10. 점검표
11. 참조

인증서 만료 경고를 메일로 받게 해 두었다. 발송 로그에는 상대 서버가 메일을 받았다는 250 응답이 찍혀 있다. 그런데 메일은 받은편지함이 아니라 스팸함에 있다. 만료 당일에야 그걸 찾는다.

SMTP의 250은 상대 서버가 메일을 넘겨받았다는 뜻일 뿐이다. 받은편지함에 넣을지 스팸함으로 보낼지는 받는 쪽이 여러 신호로 정한다. 그중 발신자가 손댈 수 있는 최소한이 도메인 인증이다. “이 메일이 정말 이 도메인에서 왔다”를 SPF와 DKIM으로 증명하고, DMARC로 사람이 보는 발신 주소와 묶는 일이다. Gmail과 Yahoo는 2024-02부터 이걸 발신자 요건으로 걸었다.

SPF, DKIM, DMARC가 각각 보는 도메인

메일에는 ’보낸 사람’이 세 군데 있다. 예시 도메인 example.com으로 구조만 보면 이렇다.

MAIL FROM:<bounce@bounce.example.com>          ← SMTP 봉투. SPF 가 본다. 받는 쪽에 Return-Path 로 남는다
From: 인증서 알림 <alerts@example.com>          ← 헤더. 사람이 보는 주소. DMARC 가 지키는 도메인
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...   ← DKIM 이 인증하는 도메인(d=)

SPF에서는 받는 서버가 MAIL FROM 도메인의 SPF 레코드를 보고, 접속한 IP가 허용 목록에 있는지 확인한다. SPF는 HELO 이름도 검사할 수 있지만 DMARC는 MAIL FROM 결과만 쓴다.

DKIM에서는 보내는 쪽이 헤더와 본문을 개인키로 서명해 DKIM-Signature를 붙인다. 받는 쪽은 s=(셀렉터)와 d=(도메인)로 s1._domainkey.example.com TXT의 공개키를 가져와 검증한다.

DMARC에서는 받는 쪽이 헤더 From의 도메인으로 _dmarc.example.com TXT를 찾는다. SPF가 pass이고 그 도메인이 From과 정렬되거나, DKIM이 pass이고 d=가 From과 정렬되면 DMARC pass다. 둘 중 하나면 된다.

세 표준은 따로 나왔다. DKIM은 RFC 6376(2011-09), SPF는 RFC 7208(2014-04)이다. DMARC는 2015-03에 RFC 7489로 나왔는데, IETF 작업반이 아닌 독립 제출이라 Informational 문서였다. 2026-05에 RFC 9989(DMARC, Standards Track), RFC 9990(집계 보고), RFC 9991(실패 보고)이 나와 RFC 7489를 대체했다.

정렬(alignment)

RFC 9989에 나오는 예다.

인증된 도메인	From 도메인	정렬
foo.example.com	news.example.com	relaxed: 조직 도메인(example.com)이 같다
news.example.com	news.example.com	strict: 완전히 같다
foo.example.net	news.example.com	정렬 안 됨

정렬이 안 되면 SPF와 DKIM이 pass여도 DMARC에는 소용이 없다. 누구나 자기 도메인에 SPF를 걸고 pass를 받을 수 있고, 어느 도메인으로든 DKIM 서명을 할 수 있기 때문이다.

기본값은 relaxed(adkim=r, aspf=r)다. RFC 9989는 거의 모든 도메인 소유자에게 relaxed로 충분했다고 적는다.

조직 도메인을 정하는 방법은 바뀌었다. RFC 7489는 Public Suffix List를 썼고, RFC 9989는 DNS 트리를 거슬러 올라가며 레코드를 찾는 ’DNS Tree Walk’로 바꿨다. 두 방식이 다른 답을 낼 수 있는데, RFC 9989는 strict 정렬과 From 도메인마다 DMARC 레코드를 두면 이 차이를 피한다고 적는다.

전달되면 SPF는 깨진다

메일이 다른 주소로 전달되면 다음 서버는 전달 서버의 IP에서 메일을 받는다. 전달 서버가 MAIL FROM을 바꾸지 않으면 SPF는 실패한다. DKIM 서명은 대개 살아남는다. 그래서 RFC 9989는 p=reject를 쓰는 도메인이 SPF만으로 DMARC pass를 받아서는 안 되고 DKIM 서명을 해야 한다(MUST)고 적는다. Google도 SPF와 DKIM 양쪽 정렬을 권하며, 둘 다 정렬하는 것이 나중에 요건이 될 가능성이 높다고 FAQ에 적었다.

발송 서비스를 쓸 때

먼저 그 서비스가 어떤 MAIL FROM과 d=로 보내는지 확인한다. 서비스 자신의 도메인을 쓰면 From과 정렬되지 않는다. Amazon SES 문서로 예를 든다.

SES는 기본으로 amazonses.com의 하위 도메인을 MAIL FROM으로 쓴다. SPF는 그 도메인으로 pass하지만 From(example.com)과 정렬되지 않는다.

사용자 지정 MAIL FROM을 쓰면 MAIL FROM이 bounce.example.com 같은 내 서브도메인이 되고, relaxed 정렬로 example.com과 정렬된다. 검증한 도메인의 하위 도메인이어야 하고, 메일을 보내거나 받는 데 쓰지 않는 이름이어야 한다. MX는 정확히 하나만 둔다.

Easy DKIM을 켜면 SES가 내 도메인(d=example.com)으로 서명한다. 기본 2048비트이고, 콘솔이 주는 CNAME 3개를 DNS에 넣는다.

; 반송용 MAIL FROM 서브도메인 — SPF 정렬
bounce.example.com.              MX     10 feedback-smtp.us-east-1.amazonses.com.
bounce.example.com.              TXT    "v=spf1 include:amazonses.com ~all"
; Easy DKIM — 콘솔의 'Publish DNS records' 값 그대로 (토큰·호스팅 존은 리전·계정마다 다르다)
<토큰1>._domainkey.example.com.  CNAME  <토큰1>.<콘솔에 표시된 호스팅 존>.
; (같은 형식으로 2개 더)
; DMARC — 처음엔 감시만
_dmarc.example.com.              TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

이 구성에서는 example.com의 SPF에 include:amazonses.com이 필요 없다. SPF는 MAIL FROM 도메인(bounce.example.com)의 레코드를 보기 때문이다. apex SPF에 서비스마다 include를 쌓으면 뒤에 나올 10회 한도에 가까워진다.

SES의 ’MX 실패 시 동작’이 ’기본 MAIL FROM 사용’이면 MX 레코드가 사라져도 메일은 계속 나가지만, MAIL FROM이 amazonses.com으로 돌아가 SPF 정렬이 조용히 깨진다. 이때 DMARC가 버티려면 DKIM이 정렬돼 있어야 한다. SPF와 DKIM을 둘 다 맞춰 두는 이유다.

DKIM 키를 CNAME으로 서비스에 맡기는 방식은 다른 곳에서도 쓴다. Microsoft 365는 selector1과 selector2 두 CNAME을 걸어 두고, 하나로 서명하다가 키를 교체하면 다른 쪽으로 넘어간다(Microsoft Learn). 2026-10-15의 microsoft.com이 그 모양이다.

dig +noall +answer TXT selector2._domainkey.microsoft.com

selector2._domainkey.microsoft.com. 3600 IN CNAME selector2-microsoft-com._domainkey.microsoft.onmicrosoft.com.
selector2-microsoft-com._domainkey.microsoft.onmicrosoft.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCPkb8bu8RGWeJGk3h…"

selector1 쪽 CNAME 대상에는 이날 TXT가 없었다. 지금은 쓰지 않는 쪽 셀렉터로 보인다.

dig로 확인하기

DMARC

dig +short TXT _dmarc.example.com

"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

example.com은 메일을 쓰지 않는 도메인의 구성이다. strict 정렬에 reject다. 보고서를 받는 도메인이라면 rua가 보인다.

dig +short TXT _dmarc.cloudflare.com

"v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100; rua=mailto:a1c47f179bc04efd8ee4dcd4d85dfc65@dmarc-reports.cloudflare.net,mailto:rua@cloudflare.com"

보고서를 두 곳으로 받는다. 앞의 주소는 Cloudflare의 dmarc-reports.cloudflare.net 도메인이다. pct=100은 RFC 7489의 태그로, RFC 9989에서는 빠졌다.

• v=DMARC1이 맨 앞이어야 한다. 아니면 레코드 전체가 무시된다
• _dmarc에 DMARC 레코드가 두 개면 둘 다 버려진다(RFC 9989 §4.10). 서비스를 붙이면서 새 레코드를 만들지 말고 기존 레코드를 고친다
• From이 alerts.example.com인데 그 이름에 레코드가 없으면 수신자는 상위로 올라가 _dmarc.example.com을 쓴다. 이때 하위 도메인에는 sp=(없으면 p=)가, DNS에 존재하지 않는 이름에는 np=가 적용된다
• +short는 응답 코드를 숨긴다. NXDOMAIN이나 SERVFAIL은 +short를 빼고 status:로 본다

SPF

dig +short TXT example.com

"v=spf1 -all"
"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

TXT는 여러 개여도 되지만 v=spf1로 시작하는 것은 하나여야 한다. 둘 이상이면 permerror다(RFC 7208 §4.5). 두 번째 줄은 다른 용도의 TXT다.

include, a, mx, ptr, exists, redirect는 평가할 때 DNS 조회를 일으키고, include 안의 것까지 합쳐 10회를 넘으면 permerror다(RFC 7208 §4.6.4). 조회 결과가 비는 ’void lookup’은 2회로 제한하라고 권한다. 세어 보는 스크립트다.

#!/bin/bash
# spf-count.sh — SPF 평가에 DNS 조회가 드는 항목 수를 센다 (RFC 7208 한도 10)
# 사용법: ./spf-count.sh example.com
count() {
  local rec t n=0
  # 255자를 넘는 TXT 는 여러 문자열로 나뉘어 온다 — 공백 없이 이어 붙인다
  rec=$(dig +short TXT "$1" | sed 's/" "//g; s/"//g' | grep -i '^v=spf1 ')
  for t in $rec; do
    case "${t#[-+~?]}" in
      include:*)  n=$((n + 1 + $(count "${t#*:}"))) ;;
      redirect=*) n=$((n + 1 + $(count "${t#*=}"))) ;;
      a|a:*|a/*|mx|mx:*|mx/*|ptr|ptr:*|exists:*) n=$((n + 1)) ;;
    esac
  done
  echo "$n"
}
echo "$1: $(count "$1")"

$ ./spf-count.sh cloudflare.com
cloudflare.com: 7
$ ./spf-count.sh example.com
example.com: 0

cloudflare.com은 include 6개와, 그중 한 include 안의 exists 1개로 7회다. 한도까지 3회 남았다. mx에는 별도 한도도 있다. 가리키는 메일 호스트들의 주소(A·AAAA) 조회가 10개를 넘으면 그 mx는 permerror다.

DKIM

셀렉터 이름은 받은 메일의 DKIM-Signature 헤더 s=에 있다. Google Workspace의 기본 셀렉터는 google이다.

dig +short TXT selector1._domainkey.example.com

"v=DKIM1; p="

example.com은 *._domainkey.example.com에 와일드카드로 이 레코드를 둔다. 어느 셀렉터를 물어도 같다. RFC 6376에서 빈 p=는 폐기된 키라는 뜻이라, 이 도메인 이름으로 된 DKIM 서명은 모두 실패한다.

키 길이는 이렇게 확인한다. 앞의 microsoft.com 셀렉터다.

dig +short TXT selector2._domainkey.microsoft.com | sed 's/" "//g; s/"//g' | tail -1 \
  | sed 's/.*p=//; s/;.*//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1

Public-Key: (1024 bit)

RFC 8301(2018-01)은 DKIM 서명에 rsa-sha1을 금지하고, 서명자가 RSA 1024비트 이상을 써야 하며(MUST) 2048비트 이상을 권한다(SHOULD). 새로 만든다면 2048비트로 한다. 2048비트 공개키는 base64로 392자라 TXT 한 문자열(255자)에 들어가지 않는다. 여러 문자열로 나눠 넣고, 검증하는 쪽은 공백 없이 이어 붙인다(RFC 6376 §3.6.2.2).

MX와 PTR

dig +short MX example.com

0 .

우선순위 0에 이름이 .인 MX는 ‘null MX’(RFC 7505)다. 이 도메인은 메일을 받지 않는다는 표시다.

직접 운영하는 서버에서 보낸다면 PTR(역방향 DNS)을 본다. Gmail과 Yahoo는 모든 발신자에게 발송 IP의 정방향·역방향 DNS가 유효할 것을 요구한다. 역방향 이름을 다시 정방향으로 찾으면 같은 IP가 나와야 한다.

dig -x 209.85.220.41 +short
dig +short A mail-sor-f41.google.com

mail-sor-f41.google.com.
209.85.220.41

바꾼 직후에는

레코드를 바꾼 직후라면 리졸버마다 옛 값이 TTL 동안 남는다. certdesk DNS 전파 확인의 _dmarc TXT 빠른 입력은 입력란의 이름 앞에 _dmarc.를 붙여 TXT로 조회하고, 권한 네임서버와 국내 통신 3사, 공용 DNS의 응답을 나란히 보여 준다. MX와 셀렉터._domainkey TXT도 같은 화면에서 본다. 전파 지연 자체는 DNS 전파 확인에 따로 적었다.

받은 메일에서 결과 보기

DNS가 맞아도 실제 메일이 통과하는지는 받은 메일로 확인한다. Gmail 웹에서는 메일을 열고 답장 옆 더보기(⋮) → 원본 보기(Show original)를 누르면 전체 헤더가 열린다. 수신 서버가 인증 결과를 기록하는 표준 헤더는 Authentication-Results(RFC 8601)다. 형식은 이렇다(값은 예시).

Authentication-Results: mx.receiver.example;
       dkim=pass header.d=example.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dmarc=pass header.from=example.com

dkim=의 header.d가 서명 도메인이다. header.from과 정렬되는지 본다. spf=의 smtp.mailfrom은 MAIL FROM 도메인이다. 여기에 서비스 도메인이 보이면 SPF 정렬은 안 된 것이다. 최종 판정은 dmarc=다.

p=none에서 p=reject까지

RFC 9989 5.1절은 도메인 소유자가 밟을 순서를 이렇게 적는다.

1. SPF와 DKIM을 From과 정렬되게 맞춘다
2. 집계 보고서를 받을 주소를 만든다
3. p=none과 rua로 DMARC 레코드를 공개한다. 이 상태를 감시 모드(Monitoring Mode)라고 부른다
4. 보고서로 모든 발송원을 확인한다. 정렬이 안 된 정상 메일은 강제 단계(quarantine, reject)로 가기 전에 고쳐야 한다(MUST)
5. 강제 단계로 갈지 정한다. RFC는 메일을 보내는 주기에 따라 확신하기까지 여러 달이 걸릴 수 있다고 적는다

RFC 9989에서 바뀐 태그

태그	뜻	기본값·비고
v	DMARC1, 맨 앞	필수
p	none·quarantine·reject	없으면 none으로 본다
sp	존재하는 하위 도메인의 정책	없으면 p
np	존재하지 않는 하위 도메인의 정책	신규. 없으면 sp, 그것도 없으면 p
adkim·aspf	DKIM·SPF 정렬 r(relaxed)·s(strict)	r
rua	집계 보고서 받을 주소	없으면 보고서를 보내지 않는다
ruf·fo	메일 단위 실패 보고서와 그 조건
t	y면 정책을 한 단계 낮춰 적용(시험)	신규, pct 대체. 기본 n
psd	공용 접미사 도메인 여부	신규, 기본 u
pct·rf·ri	RFC 7489의 비율·보고 형식·보고 주기	RFC 9989에서 삭제(historic)

pct가 빠진 이유도 RFC에 있다. 0과 100이 아닌 값은 구현마다 제각각 적용됐고, 실제로 쓸모가 있던 것은 pct=0이었다. 그래서 그 역할만 t=y로 남겼다.

단계별 레코드

단계	레코드	확인할 것
감시	v=DMARC1; p=none; rua=mailto:dmarc@example.com	보고서에 나온 모든 발송원이 정렬되는지
시험	v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc@example.com	실제 처리는 none. 메일링 리스트 등 중계를 거치는 흐름을 보고서로 파악(RFC 9989 부록 A.6)
격리	v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com	스팸함으로 간 정상 메일이 없는지
거부	v=DMARC1; p=reject; rua=mailto:dmarc@example.com

시험 단계에 t=y와 pct=0을 함께 적은 데는 이유가 있다. RFC 7489만 구현한 수신자는 t를 모르는 태그로 무시하고(7489도 모르는 태그는 무시하게 한다), RFC 9989에는 pct를 처리하는 규칙이 없다(레지스트리에서 historic). 둘 다 “한 단계 낮춰 적용”이라는 같은 뜻이다. 7489의 pct=0은 quarantine을 일반 분류로, reject를 quarantine으로 낮춘다. 두 종류의 수신자가 섞인 지금은 함께 적어야 뜻이 고르게 전달된다. pct=10 같은 중간 값은 쓰지 않는다.

reject 전에 (RFC 9989 7.4절)

• 사람이 쓰는 메일 도메인, 특히 사용자가 인터넷 메일링 리스트에 글을 쓰는 도메인은 p=reject를 쓰지 않는 것이 좋다(SHOULD NOT). 그래도 쓰려면 p=none을 최소 한 달, 이어서 p=quarantine을 같은 기간 두고 결과를 비교하라고 적는다
• p=reject 도메인은 DKIM 서명이 필수다(앞의 전달 문제)
• 받는 쪽도 p=reject만 보고 거부해서는 안 되고, 다른 판단 근거가 없으면 quarantine처럼 다뤄야 한다(MUST NOT). reject가 곧 ’반드시 반송’은 아니다

알림이나 운영 메일은 전용 서브도메인으로 나누면 이 문제를 쉽게 피한다. alerts.example.com을 From으로 쓰고 _dmarc.alerts.example.com에 따로 레코드를 두면, 사람이 메일링 리스트에 쓸 일이 없고 발송원이 정해져 있어 보고서 확인이 짧다. 주 도메인은 제 속도로 단계를 올린다. 다만 Gmail의 대량 발신자 계산은 주 도메인 단위로 합산하므로, 나눈다고 5,000통 기준을 피하지는 못한다.

rua 보고서 읽기

수신자는 하루 단위(또는 더 자주)로 집계 보고서를 rua 주소에 보낸다(RFC 9990). 형식은 이렇다.

• XML 파일을 gzip으로 압축해(권장) 첨부한다. 파일 이름은 수신자!정책도메인!시작!끝.xml.gz(시각은 유닉스 초)
• 제목은 Report Domain: example.com Submitter: 수신자도메인 모양이다
• 보고서 메일 자체도 DMARC를 통과해야 한다

RFC 9990 부록 B의 예시 보고서를 줄였다.

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
    <discovery_method>treewalk</discovery_method>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

요소	읽는 법
row/source_ip·count	이 IP에서 온 메일 수. 한 record가 발송원 하나의 묶음이다
policy_evaluated/dkim·spf	정렬까지 따진 DMARC 결과
auth_results	SPF·DKIM 자체 결과와 그 도메인·셀렉터
disposition	수신자가 실제로 한 처리
identifiers	From 도메인과 봉투 발신자 도메인

예시는 SPF가 실패했지만 DKIM이 정렬된 채 통과해 DMARC는 통과한 경우다. 반대로 auth_results의 SPF가 pass인데 도메인이 amazonses.com처럼 남의 것이면 policy_evaluated의 spf는 fail이다. 앞에서 본 ’통과했지만 정렬 안 됨’이다.

읽는 순서는 단순하다. source_ip를 모아 우리 발송원 목록(메일 서버, 발송 서비스, 업무 도구)과 대조한다. 우리 것인데 실패하면 정렬을 고치고, 모르는 IP가 SPF와 DKIM 모두 실패하면 위조이거나 잊고 있던 발송원이다. 받는 쪽 구현에 따라 RFC 7489 시절 형식(네임스페이스 없음, pct 등)이 올 수도 있다. RFC 9989도 사람이 읽기보다 기계로 처리하라고 권한다.

다른 도메인의 주소로 보고서를 받으려면 확인 레코드가 있어야 한다. rua 주소의 조직 도메인이 다르면 수신자는 example.com._report._dmarc.<보고서 받는 도메인> TXT에 v=DMARC1이 있는지 확인하고, 없으면 보내지 않는다(RFC 9990 4절). 보고서를 대신 받는 쪽이 이 레코드를 자기 도메인에 둬야 한다.

실패 보고서(ruf)에는 메일 단위로 내용 일부가 담길 수 있다. RFC 9989는 개인정보 문제로 대부분의 수신자가 실패 보고서를 보내지 않는다고 적는다. 기대는 rua에 둔다.

Gmail, Yahoo, Outlook.com 발신자 요건

요건	Gmail 모든 발신자	Gmail 하루 5,000통 이상	Yahoo 대량 발신자	Outlook.com 하루 5,000통 초과
SPF·DKIM	둘 중 하나	둘 다	둘 다	둘 다 통과
DMARC	-	레코드 필요(p=none 가능)	p=none 이상, DMARC 통과	p=none 이상
From 정렬	-	SPF 또는 DKIM과	SPF 또는 DKIM과(relaxed 가능)	SPF 또는 DKIM과(둘 다 권장)
정·역방향 DNS	필요	필요	필요	-
TLS	필요	필요	-	-
스팸 신고율	0.3% 미만(Postmaster Tools)	0.3% 미만	0.3% 미만	-
수신 거부	-	마케팅·구독 메일에 원클릭	원클릭(RFC 8058 POST 권장), 2일 안에 처리	쉬운 수신 거부(권장 사항)

Gmail의 대량 발신자는 24시간에 개인 Gmail 계정으로 5,000통 가까이 이상 보내는 발신자다. 같은 주 도메인에서 보낸 메일을 합산하고, 한 번 해당되면 영구히 대량 발신자로 본다. 요건은 개인 Gmail 계정으로 보내는 메일에 적용되고, Google Workspace 계정으로 보내는 메일에는 적용되지 않는다.

Gmail은 2024-02에 요건 시행을 시작했다. 수신 거부 링크를 이미 넣던 발신자는 원클릭 수신 거부를 2024-06-01까지 갖춰야 했다. 2025-11부터는 요건을 못 채운 메일의 임시 거부(4.7.x)와 영구 거부(5.7.x)를 늘리고 있다. 반송 코드가 원인을 가리킨다. FAQ의 예로 4.7.32는 From이 SPF·DKIM 어느 쪽과도 정렬되지 않은 경우, 4.7.23과 5.7.25는 PTR이 없거나 정방향과 맞지 않는 경우다.

Yahoo도 2024-02에 시행했다. 모든 발신자에게도 SPF 또는 DKIM, 정·역방향 DNS, 스팸률 0.3% 미만, RFC 5321·5322 준수가 필요하다.

Outlook.com(hotmail.com, live.com, outlook.com 소비자 서비스)은 2025-05-05에 하루 5,000통 넘게 보내는 도메인을 대상으로 시행했다. 2025-04-29에 갱신된 공지는 미충족 메일을 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.로 거부한다고 적는다. 같은 글에 정크함으로 보낸다는 이전 문단도 남아 있다.

알림 메일이 5,000통 기준에 못 미치더라도 표의 ‘모든 발신자’ 열은 적용된다. 직접 보내는 서버라면 SPF 또는 DKIM, PTR, TLS부터 확인한다.

Cloudflare DMARC Management로 보고서 받기

XML 보고서를 직접 모아 읽기 번거롭다면 대행 서비스를 쓴다. 도메인의 DNS가 Cloudflare에 있다면 Cloudflare DMARC Management가 있다. 다만 문서에 적힌 조건이 있다.

• Cloudflare DNS를 쓰는 apex 도메인(example.com)만 된다. blog.example.com 같은 하위 도메인이나 서브도메인 설정(subdomain setup) 존은 안 된다
• 모든 요금제에서 쓸 수 있고, 문서에는 베타로 표시돼 있다

켜는 순서다.

1. Cloudflare 대시보드에서 계정과 도메인을 고른다
2. Email > DMARC Management로 간다
3. Enable DMARC Management를 누른다
4. DMARC 레코드가 없으면 추가를 제안한다(Add). 있으면 기존 레코드에 Cloudflare 주소의 rua를 하나 더한다(Next)
5. 첫 보고서가 화면에 나오기까지 최대 24시간 걸린다

화면에서는 이런 것을 본다.

• 최대 30일의 메일량 그래프, 날짜별 보고서(View reports)
• 상위 10개 발송원(Top 10 sources)과 전체 발송원 목록(View all → 항목의 Details). 발송원마다 SPF, DKIM, DMARC 결과가 나온다
• Email record overview의 View records에서 SPF, DKIM, DMARC 레코드를 보고 만든다. SPF를 편집하면 DNS 조회 10회 초과를 검사해 경고한다

문서는 더해지는 주소를 ’Cloudflare 이메일 주소’라고만 적는다. 앞의 _dmarc.cloudflare.com에 있던 …@dmarc-reports.cloudflare.net이 그런 주소로 보인다. 켠 뒤에는 자기 존의 _dmarc 레코드에서 실제 값을 확인한다. dmarc-reports.cloudflare.net은 다른 도메인의 보고서를 받겠다는 확인 레코드도 두고 있다.

dig +short TXT example.com._report._dmarc.dmarc-reports.cloudflare.net

"v=DMARC1;"

임의의 이름으로 물어도 같은 답이 온다. RFC 9990이 설명하는 와일드카드 방식으로 모든 도메인의 보고서를 받겠다고 밝혀 둔 것이다. 주의할 점이 하나 있다. 존 안에 외부 도메인을 가리키는 CNAME이 있으면 DMARC Management는 SPF 수정을 지원하지 않는다. 그때 SPF는 그 외부 도메인의 DNS에서 고친다.

메일을 쓰지 않는 도메인

웹 전용 도메인이나 보유만 하는 도메인도 위조 발신에 쓰일 수 있다. example.com의 실제 레코드가 그런 구성이다(2026-10-15 조회).

example.com.               MX    0 .
example.com.               TXT   "v=spf1 -all"
*._domainkey.example.com.  TXT   "v=DKIM1; p="
_dmarc.example.com.        TXT   "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

메일을 받지 않고(null MX), 어떤 IP에서도 보내지 않으며, 모든 DKIM 키가 폐기됐고, 실패하면 거부해 달라는 뜻이다. 웹에도 쓰지 않는 도메인이라면 CAA의 0 issue ";"로 인증서 발급까지 막는다.

점검표

점검	정상 상태
_dmarc 레코드	하나, v=DMARC1이 맨 앞, rua 있음
SPF	v=spf1 레코드 하나, DNS 조회 10회 이내, 끝이 -all 또는 ~all
MAIL FROM	발송 서비스도 내 서브도메인(SPF 정렬)
DKIM	d=가 내 도메인, RSA 2048비트, 쓰지 않는 셀렉터는 정리
받은 메일	Authentication-Results에 dmarc=pass
직접 보내는 서버	PTR과 정방향 일치, TLS로 전송
보고서	매일 들어오고, 모르는 source_ip를 확인함
정책	감시 → 시험 → quarantine → reject 순서, pct 중간 값 안 씀
알림 메일	전용 서브도메인, 발송원 고정
메일 안 쓰는 도메인	null MX, v=spf1 -all, p=reject

인증을 다 맞춰도 받은편지함을 보장하지는 않는다. 놓치면 안 되는 알림이라면 받는 길을 하나 더 둔다. 인증서와 도메인 만료 경고를 받는 만료 감시 구독은 메일과 함께 Slack, Discord, Telegram 채널로도 보낼 수 있다. 슬랙으로 직접 받는 구성은 인증서 만료 알림 체계 직접 만들기에 있다.

참조

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: DMARC (구판)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990: DMARC Aggregate Reporting
• RFC 9991: DMARC Failure Reporting
• IETF Datatracker: draft-ietf-dmarc-dmarcbis
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7505: A “Null MX” No Service Resource Record
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Google: Email sender guidelines FAQ
• Google: Trace an email with its full headers
• Google Workspace: Set up DKIM
• Yahoo: Sender Best Practices
• Microsoft: Outlook’s New Requirements for High-Volume Senders
• Microsoft Learn: How to use DKIM for email in your custom domain
• Amazon SES: Using a custom MAIL FROM domain
• Amazon SES: Easy DKIM
• Amazon SES: Creating and verifying identities
• Cloudflare: DMARC Management
• Cloudflare: Enable DMARC Management
• Cloudflare DMARC Management: Statistics and details
• Cloudflare DMARC Management: DNS lookup limit