Cloudflare 이메일 라우팅으로 도메인 메일 무료로 만들기｜SPF 레코드 충돌 해결까지

블로그를 운영하다 보면 문의 페이지에 적을 이메일 주소가 필요합니다. 애드센스 심사를 준비하면 더욱 그렇습니다. 저는 지금까지 개인 Gmail 주소를 그대로 적어 두었는데, 두 가지가 마음에 걸렸습니다.

개인 메일 주소가 인터넷에 그대로 노출됩니다. 메일 주소 아이디가 다른 서비스 아이디와 같다면 더 신경 쓰입니다.
contact@내도메인.com 같은 도메인 메일이 방문자에게 더 신뢰를 줍니다.

그렇다고 메일 서버를 직접 운영하거나 유료 기업용 메일을 쓰기에는 부담이 컸습니다. 그래서 이미 도메인과 NAS 연결에 쓰고 있던 Cloudflare의 이메일 라우팅(Email Routing)을 써 보기로 했습니다.

결론부터 정리하면 이렇습니다.

받는 메일은 무료입니다. contact@내도메인으로 온 메일을 내 Gmail로 전달해 줍니다.
설정은 10분이면 됩니다. 대상 주소 인증, 라우팅 규칙 만들기, DNS 레코드 추가 세 단계입니다.
보내는 기능은 없습니다. 답장은 전달받은 Gmail에서 보내게 됩니다.
도메인에 기존 SPF 레코드가 있으면 충돌합니다. 제 블로그 세 개 중 한 곳에서 실제로 충돌이 났고, 이 글에서 해결 과정을 자세히 다룹니다.

1. Cloudflare는 어떤 서비스인가

Cloudflare는 한마디로 내 도메인 앞에 서서 트래픽을 대신 받아 주는 서비스입니다. 방문자는 내 서버가 아니라 Cloudflare에 먼저 접속하고, Cloudflare가 그 요청을 확인한 뒤 실제 서버로 넘겨줍니다. 이 구조 덕분에 DNS, 캐시, HTTPS 인증서, 보안 차단을 한 곳에서 처리할 수 있고, 개인 블로그 수준에서는 무료 요금제로도 대부분을 쓸 수 있습니다.

제가 쓰는 기능만 정리하면 이렇습니다.

기능	하는 일	제가 쓰는 방식
DNS	도메인 이름을 서버 주소로 연결	블로그 도메인 3개의 DNS를 모두 Cloudflare에서 관리
프록시·캐시·HTTPS	방문자와 서버 사이에서 페이지를 전달하고 암호화	블로그 설정을 바꾼 뒤에는 캐시를 비워 바로 반영
규칙(리디렉션)	주소를 다른 주소로 자동 이동	`www.` 주소를 루트 도메인으로 301 리디렉션해 중복 색인을 막음
보안 이벤트	차단되거나 의심스러운 요청 기록	NAS의 자동화 스크립트가 내 블로그에서 403을 받았을 때 원인을 찾는 출발점으로 활용
Tunnel (Zero Trust)	서버에서 Cloudflare 방향으로 바깥 연결을 만들어 포트포워딩 없이 서비스 공개	집에 있는 시놀로지 NAS의 워드프레스 3개를 이 방식으로 운영
Email Routing	도메인으로 온 메일을 다른 메일함으로 전달	이번 글의 주제. 세 블로그의 `contact@` 주소를 블로그 전용 Gmail 하나로 모음

집 NAS의 블로그를 Tunnel로 공개하는 구조

제 블로그는 호스팅 업체가 아니라 집에 있는 시놀로지 NAS의 Docker 컨테이너에서 돌아갑니다. 방문자가 블로그 주소를 열면 요청은 이렇게 이동합니다.

방문자 → Cloudflare(DNS·HTTPS·보안) → Cloudflare Tunnel → NAS의 cloudflared 컨테이너 → 워드프레스 컨테이너

핵심은 공유기에 열려 있는 포트가 없다는 점입니다. NAS 안의 cloudflared가 Cloudflare 쪽으로 나가는 연결을 먼저 맺고, 외부 요청은 그 연결을 통해서만 들어옵니다. 예전에는 포트포워딩으로 공개했다가 Tunnel로 옮긴 과정은 [NAS 구축기 4부 — Cloudflare Tunnel을 직접 붙여보니 생각보다 쉽지 않았다]에 자세히 적었습니다.

이렇게 도메인의 DNS가 이미 Cloudflare에 있었기 때문에, 메일도 같은 대시보드에서 처리하는 것이 가장 간단했습니다. 이메일 라우팅은 Cloudflare DNS를 쓰는 도메인에서만 쓸 수 있습니다.

참고: 웹사이트 접속(Tunnel)과 메일 수신(이메일 라우팅)은 서로 다른 레코드를 씁니다. 메일 설정을 바꿔도 블로그 접속에는 영향이 없습니다. 이 부분은 뒤의 자주 묻는 질문에서 제 실제 경험과 함께 다시 다룹니다.

2. 이메일 라우팅으로 할 수 있는 것과 없는 것

이메일 라우팅은 메일함을 만들어 주는 서비스가 아닙니다. 내 도메인으로 온 메일을 이미 쓰고 있는 메일함으로 전달하는 우체국에 가깝습니다.

보낸 사람 → [email protected] → Cloudflare(라우팅 규칙 확인) → 블로그용 Gmail 받은편지함

구분	내용
요금	받는 메일 전달은 무료 요금제에서도 무료이고 수신 횟수 제한이 없습니다
만들 수 있는 주소	도메인당 라우팅 규칙 200개까지 (`contact@`, `admin@`, `ads@`처럼 용도별로)
전달받을 메일함	계정당 200개까지. 한 번 인증한 메일함은 다른 도메인에서도 그대로 씁니다
메일 크기	한 통에 25MiB까지. 더 큰 메일은 거부됩니다
보내기	기본 설정으로는 불가능. 답장은 전달받은 메일함의 주소로 나갑니다

한 가지 꼭 알고 시작해야 할 점이 있습니다. 답장을 하면 전달받은 메일 주소가 상대방에게 보입니다. 개인 Gmail로 전달받으면 답장하는 순간 개인 주소가 드러나는 것이죠. 그래서 저는 블로그 전용 Gmail을 새로 만들어 전달 대상으로 썼습니다. 문의 답장도 그 계정에서 합니다.

Cloudflare에는 내 도메인 이름으로 메일을 보내는 별도 기능(Email Sending)도 있지만, 아무에게나 보내려면 Workers 유료 요금제가 필요합니다. 블로그 문의에 답하는 정도라면 필요 없습니다.

준비물

Cloudflare에 등록되어 있고 Cloudflare DNS를 쓰는 도메인
전달받을 메일 주소 (블로그 전용 Gmail 권장)
테스트용으로 메일을 보낼 다른 메일 계정 하나
그 도메인에서 이미 다른 메일 서비스(네이버웍스, 구글 워크스페이스 등)를 쓰고 있지 않은지 확인. 쓰고 있다면 메일 수신 경로가 바뀌니 이 글대로 하면 안 됩니다

3. 설정 따라하기

Cloudflare 대시보드에서 도메인을 고른 뒤 왼쪽 메뉴의 이메일 → 이메일 라우팅으로 들어갑니다. 화면 위쪽에 개요, 활동 로그, 라우팅 규칙, 대상 주소, 목적지 Workers, 설정 탭이 보입니다. 메뉴 이름은 Cloudflare 화면 업데이트에 따라 조금씩 바뀝니다.

중간에 “Email Workers 생성” 화면이 나오면 취소하면 됩니다. 받은 메일을 코드로 처리하는 고급 기능이라 단순 전달에는 필요 없습니다. 저도 처음에 이 화면으로 잘못 들어갔습니다.

1단계: 대상 주소 등록과 인증

메일을 전달받을 메일함을 먼저 등록합니다.

대상 주소 탭 → 대상 주소 추가
블로그 전용 Gmail 주소를 입력하고 저장
그 Gmail로 온 Cloudflare 메일에서 Verify email address를 누릅니다
대상 주소 탭에서 상태가 확인됨(Verified)으로 바뀐 것을 확인합니다

인증을 하지 않으면 규칙을 만들어도 메일이 전달되지 않습니다. 한 번 인증한 주소는 같은 계정의 다른 도메인에서도 다시 인증할 필요 없이 쓸 수 있습니다. 저는 블로그 세 개에 같은 Gmail을 썼습니다.

2단계: 라우팅 규칙 만들기

이제 contact@내도메인 주소를 만들고 전달할 곳을 정합니다.

라우팅 규칙 탭 → 사용자 지정 주소 만들기
칸을 이렇게 채웁니다.
- 사용자 지정 주소: contact (뒤에 @내도메인이 자동으로 붙습니다)
- 작업: 이메일로 보내기(Send to an email)
- 대상: 1단계에서 인증한 Gmail
저장합니다

규칙 목록에 전체 수신(Catch-all) 항목도 보입니다. 정해 두지 않은 아무 주소(abc@, test@ 등)로 온 메일까지 받는 규칙인데, 켜면 스팸도 함께 들어옵니다. 블로그 문의용이라면 꺼 두는 것을 권합니다.

3단계: DNS 레코드 추가

메일이 Cloudflare로 들어오게 하려면 DNS에 레코드 세 종류가 필요합니다. 설정 과정에서 Cloudflare가 추가를 제안하므로 버튼만 누르면 됩니다.

레코드	역할
MX	“이 도메인의 메일은 Cloudflare 메일 서버로 보내라”고 알려 줌
TXT (SPF)	Cloudflare 메일 서버가 이 도메인의 메일을 다루는 것을 허용. 값은 `v=spf1 include:_spf.mx.cloudflare.net ~all`
TXT (DKIM)	전달되는 메일에 서명을 붙여 위조를 막음. 호스트 이름이 `cf2024-1._domainkey`로 시작합니다

레코드가 모두 들어가면 개요 화면의 “DNS 레코드”가 잠김으로 표시됩니다. Cloudflare가 관리하는 레코드라 실수로 고치지 못하게 잠걼다는 뜻이라 정상입니다. “라우팅 상태”는 잠시 동기화 중으로 나오다가 보통 5~15분 안에 활성으로 바뀝니다.

문제는 다음 도메인이었습니다.

4. SPF 레코드 충돌 해결: “v=spf1 -all”이 막고 있었다

두 번째 도메인인 moneyiswater.net에서는 DNS 레코드 화면이 이렇게 나왔습니다.

레코드	값	상태
TXT (DKIM)	`cf2024-1._domainkey` …	잠김 (정상)
TXT (SPF, Cloudflare 요구)	`v=spf1 include:_spf.mx.cloudflare.net ~all`	누락
TXT (SPF, 기존)	`v=spf1 -all`	충돌

[스크린샷] 누락과 충돌이 표시된 DNS 레코드 화면

왜 충돌이 났을까

SPF(Sender Policy Framework)는 “이 도메인 이름으로 메일을 다룰 수 있는 서버는 여기뿐이다”라고 공개적으로 선언하는 TXT 레코드입니다. 메일을 받는 쪽은 이 값을 보고 사칭 메일인지 판단합니다.

기존에 있던 v=spf1 -all은 허용 목록 없이 -all만 있는 형태입니다. 뜻은 “이 도메인은 메일을 전혀 쓰지 않는다. 이 이름으로 온 메일은 전부 가짜다”입니다. 메일을 쓰지 않는 도메인을 스팸 발송자가 사칭하지 못하게 막는 좋은 설정이고, 제 도메인에도 그 목적으로 들어가 있었습니다.

문제는 SPF 레코드를 도메인당 하나만 둘 수 있다는 점입니다. 표준(RFC 7208)에 따르면 SPF 레코드가 두 개 이상이면 검사 결과가 오류(PermError)가 됩니다. 그래서 Cloudflare는 새 SPF를 추가하지 않고 “누락”과 “충돌”로 표시한 것입니다.

해결 방법

충돌로 표시된 v=spf1 -all 오른쪽의 삭제를 누릅니다.
아래 누락된 레코드 추가를 누릅니다.
몇 분 뒤 모든 항목이 잠김으로 바뀌면 끝입니다.

기존 레코드를 지워도 보호가 사라지는 것은 아닙니다. 새 레코드도 Cloudflare 메일 서버만 허용하고 나머지는 의심(~all)으로 처리하라는 뜻이라, 아무 서버나 내 도메인을 사칭하는 것은 여전히 막힙니다.

비슷한 충돌이 나는 다른 경우

MX 레코드가 0 .인 경우: “메일을 받지 않는 도메인”이라는 선언(Null MX)입니다. v=spf1 -all과 함께 들어가 있는 경우가 많으니 충돌로 표시되면 같은 방법으로 지웁니다.
다른 서비스로 메일을 보내고 있는 경우: 뉴스레터 발송 서비스 등이 SPF에 들어가 있다면 지우지 말고 하나로 합쳐야 합니다. 예) v=spf1 include:기존서비스 include:_spf.mx.cloudflare.net ~all
다른 메일 서비스로 메일을 받고 있는 경우: MX를 바꾸면 기존 메일함으로 메일이 가지 않습니다. 이때는 이메일 라우팅을 쓰지 않는 편이 맞습니다.

5. 테스트와 운영 팁

테스트는 다른 계정에서

라우팅 상태가 활성으로 바뀌면 다른 메일 계정에서 contact@내도메인으로 메일을 보내 봅니다. 전달받는 Gmail 자신에서 보내면 일부 메일 서비스가 자기가 보낸 메일로 보고 버리는 경우가 있어, 도착하지 않은 것처럼 보일 수 있습니다. 처음 몇 통은 스팸함으로 갈 수 있으니 같이 확인합니다.

메일이 오지 않으면 활동 로그 탭을 봅니다. 메일이 Cloudflare까지 도착했는지, 전달되었는지, 거부되었는지가 기록됩니다.

블로그가 여러 개라면 Gmail 필터로 나누기

저는 세 블로그의 contact@을 모두 같은 Gmail로 받습니다. Gmail에서 받는사람(to:[email protected])을 기준으로 필터를 만들어 블로그별 라벨을 붙이면 어느 블로그로 온 문의인지 바로 보입니다.

문의 페이지에 주소를 적을 때

스팸 봇 대비: 페이지에 메일 주소를 글자 그대로 적으면 수집 봇이 가져갑니다. Cloudflare의 이메일 주소 난독화(Scrape Shield)가 켜져 있으면 페이지 소스에서 주소가 암호화되고, 방문자 화면에는 정상으로 보입니다. 제 블로그도 이 기능으로 주소가 [email protected]처럼 가려져 있습니다.
개인정보 처리방침도 같이 바꾸기: 문의 페이지만 바꾸고 개인정보 처리방침의 연락처는 놓치기 쉽습니다. 저는 블로그 페이지를 복사해 만들다가 한 블로그의 개인정보 처리방침에 다른 블로그의 주소가 들어가 있는 것을 나중에 발견했습니다. 복사해서 만든 페이지는 주소를 한 번씩 더 확인하세요.
용도별 주소: 애드센스나 협업 제안을 따로 받고 싶다면 ads@, review@처럼 규칙을 하나 더 만들면 됩니다. 도메인당 200개까지 만들 수 있습니다.

자주 묻는 질문

Q. 정말 무료인가요?

받는 메일을 전달하는 기능은 무료 요금제에서도 무료이고, 수신 횟수 제한도 없습니다. 내 도메인 이름으로 아무에게나 메일을 보내는 기능은 Workers 유료 요금제가 필요하고, 월 3,000통이 포함되며 그 뒤로는 1,000통당 $0.35입니다(2026년 10월 기준).

Q. Gmail에서 contact@ 주소로 답장할 수는 없나요?

이메일 라우팅만으로는 안 됩니다. Gmail의 “다른 주소에서 메일 보내기”는 보내는 메일 서버(SMTP)가 필요한데, 이메일 라우팅은 받는 기능만 있습니다. Cloudflare의 유료 발송 기능이 SMTP를 제공하지만 저는 직접 써 보지 않았습니다. 블로그 문의 정도라면 블로그 전용 Gmail에서 답장하는 것으로 충분합니다.

Q. SPF 레코드를 지우면 웹사이트에 영향이 있나요?

없습니다. SPF는 메일에만 쓰이는 레코드입니다. 사실 저는 SPF를 지운 직후에 블로그가 Error 1033(Cloudflare Tunnel error)을 띄우면서 멈춰 깜짝 놀랐습니다. 확인해 보니 원인은 메일과 전혀 상관없는 다른 데 있었습니다. 같은 시간에 NAS의 컨테이너 자동 업데이트가 cloudflared를 새 버전으로 바꾸면서 터널이 1~2분 끊긴 것이었습니다. 이 이야기는 NAS 구축기 다음 편에서 따로 정리하겠습니다.

Q. 설정하고 바로 메일을 받을 수 있나요?

Cloudflare DNS를 쓰면 보통 5~15분이면 반영됩니다. 늦으면 24시간까지 걸릴 수 있습니다. 개요 화면의 라우팅 상태가 “활성”이 된 뒤 테스트하세요.

마무리

이미 Cloudflare로 도메인을 관리하고 있다면, 도메인 메일을 만드는 데 추가 비용도 서버도 필요 없습니다. 대상 주소를 인증하고, 규칙을 만들고, DNS 레코드를 추가하면 끝입니다. 다만 도메인에 예전에 넣어 둔 SPF나 MX가 있으면 충돌이 나니, “누락”과 “충돌” 표시가 보이면 이 글의 4번 항목대로 정리하면 됩니다.

도메인과 NAS 보안을 함께 점검하고 싶다면 [개인 NAS·홈서버 보안 체크리스트 10가지]도 함께 참고하세요.

참고 자료

이 글은 2026년 10월 Cloudflare 화면을 기준으로 작성했습니다. 메뉴 이름과 요금은 바뀔 수 있으니 적용 전에 공식 문서를 확인해 주세요.