이메일 안 쓰는 도메인도 SPF/DMARC가 필요한 이유

도메인을 등록하고 이메일은 쓸 일이 없어서 그냥 놔뒀어요. 그런데 MXToolbox로 도메인 상태를 점검하다가 이런 경고를 발견했어요. 처음엔 "이메일 안 쓰는데 뭐가 문제야"싶어서 넘겼는데, 경고 내용을 읽고 나서 바로 설정하러 갔어요.

"SPF record not found. Anyone can send email as your domain."

이 글은 Cloudflare에서 관리하는 이메일 미사용 도메인 기준이에요. 왜 설정이 필요한지와 DNS 레코드 2개로 차단하는 방법을 정리했어요.

이메일 안 써도 사칭은 가능해요

SPF(Sender Policy Framework) 레코드가 없으면 SPF를 검증하는 수신 서버는 내 도메인 발신 메일을 그냥 통과시켜요.

공격자가 noreply@potatolog.dev를 발신자 주소로 설정하고 피싱 메일을 보내요. 수신자는 도메인을 보고 "이 사람 블로그 운영자네"라고 신뢰하죠. 실제로 저는 그 메일을 보낸 적이 없고, 저 자신도 그 사실을 모를 수 있어요.

SPF가 없으면 생기는 일

SPF 레코드가 없는 도메인은 발신자 주소를 위조할 수 있습니다. 이메일을 사용하지 않아도 사칭 피해를 입을 수 있습니다.

이 글을 읽고 나면 DNS 레코드 2개로 이런 사칭을 차단할 수 있어요.

이메일 인증의 3요소: SPF, DKIM, DMARC

이메일 인증은 세 가지 레코드가 함께 작동하는 구조예요.

SPF — 누가 이 도메인으로 메일을 보낼 수 있는가

SPF는 "이 도메인으로 메일을 보낼 수 있는 서버 목록"을 DNS에 선언하는 방식이에요. 수신 서버는 메일을 받으면 발신 서버 IP가 SPF 레코드에 있는지 확인해요.

이메일 미사용 도메인은 "허가된 발신 서버가 아무것도 없다"고 선언하면 돼요. 그게 v=spf1 -all이에요.

DKIM — 메일 내용의 위변조 방지

DKIM(DomainKeys Identified Mail)은 이메일에 디지털 서명을 추가해서 내용이 중간에 변경되지 않았음을 증명해요. 메일 서버에서 서명 키를 생성해야 해서 실제로 이메일을 발송하는 환경이 없으면 설정할 수 없어요.

이메일 미사용 도메인은 DKIM을 생략해도 괜찮아요.

DMARC — SPF/DKIM 실패 시 처리 정책

DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 SPF나 DKIM 검사가 실패했을 때 수신 서버가 어떻게 처리할지를 정해요. "거부", "스팸함으로 보내기", "아무 것도 하지 않고 리포트만 받기" 세 가지 정책 중 하나를 선택할 수 있어요.

처음에 p=none부터 시작하라는 가이드도 봤는데, 이메일을 아예 안 쓰니까 p=reject로 바로 가는 게 맞다고 판단했어요. 현황 파악이 필요한 건 실제로 이메일을 운영하는 도메인 얘기죠.

세 레코드의 관계

수신 서버가 메일을 받으면
│
├─ SPF 확인 → 발신 서버 IP가 허가 목록에 있는가?
│
├─ DKIM 확인 → 서명이 유효한가? (이메일 미사용 시 생략)
│
└─ DMARC 정책 적용
      ├─ p=none     → 그냥 통과, 리포트만 수집
      ├─ p=quarantine → 스팸함으로 분류
      └─ p=reject   → 완전 거부 ✅

이메일 미사용 도메인은 SPF로 모든 발송을 차단하고, DMARC로 그 정책을 강제하는 구조면 충분해요.

Cloudflare에서 설정하기

Cloudflare DNS에 레코드 2개를 추가하면 끝이에요.

SPF 레코드 추가

Cloudflare 대시보드에서 DNS > Records > Add record를 눌러요.

필드	값
Type	TXT
Name	@
Value	`v=spf1 -all`

v=spf1 -all은 "이 도메인으로 메일을 보낼 수 있는 서버가 없다"는 선언이에요. SPF를 검증하는 수신 서버는 이 레코드를 보고 발신을 거부해요.

-all vs ~all

-all은 Hard Fail로 수신 서버에 "무조건 거부하라"고 지시합니다. ~all은 Soft Fail로 "의심스럽지만 일단 받아라"고 지시합니다. 이메일 미사용 도메인에는 -all을 사용하는 것이 적합합니다.

DMARC 레코드 추가

SPF만으로는 부족해요. DMARC 레코드가 없으면 SPF 실패 시 수신 서버가 자체 판단으로 처리하기 때문에 거부가 보장되지 않아요. DMARC를 추가해서 "SPF 실패 시 반드시 거부"를 강제해야 해요.

필드	값
Type	TXT
Name	`_dmarc`
Value	`v=DMARC1; p=reject`

p=reject는 SPF/DKIM 검사를 통과하지 못한 메일을 완전히 거부하도록 지시해요.

DMARC p= 값 비교

p=none: 정책 없이 리포트만 수집. 처음 이메일을 도입할 때 현황 파악용으로 쓰입니다.
p=quarantine: 실패한 메일을 스팸함으로 분류합니다.
p=reject: 실패한 메일을 완전히 거부합니다. 이메일 미사용 도메인에는 이게 적합합니다.

설정 확인하기

레코드를 추가한 후 제대로 반영됐는지 확인해요. DNS 전파에 최대 수 분이 걸릴 수 있어요.

dig 명령어로 확인

터미널에서 아래 명령어를 실행하면 현재 적용된 레코드를 바로 확인할 수 있어요.

# SPF 레코드 확인
dig TXT potatolog.dev +short

# DMARC 레코드 확인
dig TXT _dmarc.potatolog.dev +short

정상적으로 적용됐다면 아래와 같은 결과가 나와야 해요.

"v=spf1 -all"
"v=DMARC1; p=reject"

온라인 도구로 확인

터미널이 불편하다면 브라우저에서 확인할 수 있어요.

MXToolbox — 도메인을 입력하면 SPF, DMARC 레코드를 분석하고 문제를 알려줘요.
Google Admin Toolbox — Google의 이메일 관련 DNS 검사 도구예요. DMARC 정책이 올바른지 상세하게 확인할 수 있어요.

마무리하며

TL;DR

이메일 미사용 도메인도 SPF + DMARC 레코드 2개를 설정해야 도메인 사칭을 차단할 수 있습니다.

SPF: v=spf1 -all (TXT, Name: @)
DMARC: v=DMARC1; p=reject (TXT, Name: _dmarc)

나중에 이메일을 도입하게 된다면 SPF의 -all 앞에 발신 서버를 추가하고(v=spf1 include:_spf.google.com ~all), DKIM을 생성한 뒤, DMARC를 p=reject에서 p=none으로 낮춰 현황을 파악하는 순서로 진행하면 돼요.

설정 후 MXToolbox에서 도메인을 검색해보면 처음에 떴던 경고가 사라진 걸 확인할 수 있어요.