내 도메인으로 무료 이메일 받기
Cloudflare 이메일 라우팅 + Gmail 완전 정리

서버도, 매달 나가는 유료 구독도 없이 hello@mcpy.kr 같은 브랜드 이메일을 쓴다. 수신은 Cloudflare가 공짜로 받아 넘기고, 발신은 늘 쓰던 Gmail이 대신한다.

대상: 도메인은 있는데 이메일은 개인 Gmail로 쓰는 1인 운영자·개발자  ·  형식: 따라 하는 how-to  ·  2026-07-06

매달 나가는 구독료 없이, 도메인 이메일을 갖는 법

도메인은 이미 하나 있다고 하자. 사이트도 붙였다. 그런데 명함이나 문의 페이지에 적을 이메일이 여전히 mybrand2025@gmail.com이면 어딘가 아마추어처럼 보이지 않나.

제대로 하려면 보통 Google Workspace 같은 유료 메일 서비스를 붙이는데, 사용자당 매달 요금이 나간다. 1인이 주소 하나 쓰자고 그 돈을 계속 내자니 아깝다.

그래서 많은 1인 운영자가 택하는 조합이 이것이다. 받는 건 Cloudflare Email Routing이 공짜로 받아서 내 Gmail로 던져 주고, 보내는 건 Gmail의 Send mail as 기능이 도메인 주소인 척 대신 보내 준다.

구조를 한 문장으로 줄이면, 도메인 주소는 간판이고 실제 일은 Gmail이 다 해 준다. 밖에서는 hello@mcpy.kr로 보이지만, 메일이 실제로 쌓이는 곳도 답장을 쓰는 손도 늘 쓰던 Gmail일 뿐이다.

이 글은 그 조합을 처음부터 끝까지 따라 하도록 정리했다. 공개 주소는 실제 값 hello@mcpy.kr로 예시를 들고, 실제 받을 Gmail만 you@gmail.com 자리표시자로 둔다. 그 자리엔 본인 Gmail을 넣으면 된다.

중요한 건 순서다. 네임서버 위임부터 수신을 완전히 켜 놓아야 뒤에서 발신 인증이 된다. 왜 그런지는 뒤에서 이유까지 짚는다. 지금은 "위임 먼저, 수신 그다음, 발신 마지막"만 기억하자.

먼저 이것부터: 3가지가 빠지면 반드시 막힌다

이 글에서 초보자가 가장 많이 놓치는 지점 셋을 먼저 못박아 둔다. 나머지는 순서대로 따라오면 되지만, 이 셋은 빠뜨리면 "분명히 다 했는데 안 된다"의 원인이 된다.

• 1. 네임서버 위임(0단계). 가비아 같은 등록기관에서 네임서버를 Cloudflare로 바꾸고 "Active"가 돼야, 뒤의 모든 DNS가 효력을 갖는다.
• 2. DMARC 레코드. SPF·DKIM만으로는 부족하다. _dmarc TXT 한 줄이 있어야 수신 서버가 내 도메인 메일을 신뢰하고 스팸으로 덜 본다.
• 3. Destination 인증 → Rule 생성 순서. 목적지 Gmail을 먼저 인증(Verified)한 다음에야 라우팅 규칙을 만들 수 있다. 순서가 거꾸로면 규칙이 안 걸린다.

그리고 준비물 둘. 도메인과 2단계 인증을 켠 Gmail 계정이다. 2단계 인증은 뒤에서 앱 비밀번호를 만들 때 전제 조건이라, 지금 안 켜져 있으면 그때 가서 막힌다.

0단계. 가비아에서 Cloudflare로 네임서버 위임하기

모든 것의 출발점이다. 네임서버(nameserver)는 "이 도메인의 DNS를 누가 관리하냐"를 가리키는 이정표라 보면 된다. 도메인을 가비아에서 샀어도, DNS 관리를 Cloudflare에 맡기려면 이 이정표를 Cloudflare 쪽으로 돌려놔야 하는 것이다.

순서는 이렇다. Cloudflare에 도메인 mcpy.kr을 추가하면, Cloudflare가 네임서버 2개(예: xxx.ns.cloudflare.com, yyy.ns.cloudflare.com)를 알려 준다. 이 두 값을 가비아 관리 콘솔의 네임서버 설정에 그대로 넣어 준다.

그다음이 초보자가 성급해지는 지점이다. 네임서버 변경은 즉시 반영되지 않는데, Cloudflare 대시보드에서 해당 도메인 상태가 Active로 바뀔 때까지 기다려야 한다는 뜻이다. 보통 몇 분에서 길게는 몇 시간이 걸린다.

왜 이게 0단계냐면, Active가 안 된 상태에서 아무리 MX·SPF·DKIM을 넣어도 바깥세상은 그 레코드를 못 보기 때문이다. 뒤에서 "다 넣었는데 메일이 반송된다"의 십중팔구 원인이 바로 이 위임 미완료다. 여기서 확실히 Active를 확인하고 넘어가는 게, 나중에 원인 찾느라 반나절 태우는 것보다 낫지 않겠나.

값을 넣고 저장했으면, 이제 공을 Cloudflare로 넘긴 것이다. 변경이 실제로 반영됐는지는 등록기관이 아니라 Cloudflare 쪽 상태로 판단한다.

1단계. Cloudflare에서 이메일 라우팅 켜기 (MX·SPF·DKIM 자동 생성)

도메인이 Active가 됐으면, Cloudflare 대시보드에서 Email → Email Routing으로 들어가 Enable Email Routing을 눌러 준다. 그러면 Cloudflare가 수신에 필요한 DNS 레코드를 자동으로 제안한다. 제안된 레코드를 그대로 적용하면 그만이다.

여기서 Cloudflare가 만드는 건 세 종류다. 공식 문서 기준으로 정리하면 이렇다.

• MX 레코드: "이 도메인으로 오는 메일은 Cloudflare 서버로 보내라"는 이정표. 여러 개(보통 3개)를 우선순위와 함께 만든다.
• SPF (TXT 레코드): "Cloudflare가 이 도메인 메일을 대신 처리해도 된다"는 허가장. 스팸 필터가 메일을 신뢰하게 한다.
• DKIM (TXT 레코드): 전달되는 메일에 위조 방지 서명을 붙이는 인증키.

세 레코드가 왜 필요한지 한 줄씩만 더 파 두면 좋다. 뒤에서 문제가 생기면 결국 이 셋(+다음 단계의 DMARC) 중 하나다.

MX(Mail Exchanger)는 도메인으로 오는 메일을 받을 서버 주소다. 이게 없거나 틀리면, 세상 어떤 메일 서버도 내 도메인 메일을 어디로 보낼지 몰라 그냥 반송해 버린다. Cloudflare는 이 MX를 *.mx.cloudflare.net 형태의 호스트로 채워 준다.

여기서 하나 짚자. 오래된 가이드들은 MX 값으로 route1.mx.cloudflare.net, route2, route3를 박아 두는데, Cloudflare는 계정·도메인마다 다른 호스트명을 배정한다. 내 대시보드가 실제로 만들어 준 3개 값을 그대로 쓰는 게 정답이고, 남의 가이드에 적힌 호스트명을 손으로 베껴 넣으면 안 된다. 우선순위 숫자도 대시보드가 정해 주는 값을 따른다.

SPF는 발신자 위조를 막는 장치다. Cloudflare가 넣는 값은 공식 postmaster 문서에 나온 대로 v=spf1 include:_spf.mx.cloudflare.net ~all 형태다. 받는 쪽 스팸 필터가 "이 도메인 메일을 Cloudflare가 다뤄도 정상"이라고 판단하는 근거가 된다.

DKIM은 메일 본문에 전자 서명을 붙여, 중간에 내용이 바뀌지 않았음을 증명한다. Cloudflare Email Routing의 DKIM 셀렉터는 cf2024-1._domainkey를 쓴다. SPF와 DKIM이 없으면 전달된 메일이 스팸함으로 빠지거나 아예 거부될 수 있다.

2단계. DMARC 한 줄 더하기 (가장 많이 빠뜨리는 레코드)

SPF·DKIM까지 하고 끝냈다가 "왜 자꾸 스팸함으로 가지" 하는 경우가 흔하다. 빠진 게 DMARC다. Cloudflare가 자동으로 안 넣어 주는 경우가 있어서, 손으로 하나 추가해 두는 게 안전하지 않을까.

Cloudflare 공식 설명대로, DMARC는 SPF와 DKIM을 하나로 묶어 "인증이 실패하면 받는 서버가 어떻게 처리할지"를 알려 주는 정책이다. 이 정책이 있어야 수신 측(특히 대형 메일 서비스)이 내 도메인 메일을 더 신뢰한다.

Cloudflare DNS → Records에서 이 TXT 레코드를 추가해 준다.

값을 뜯어보면 이렇다. p=none은 "실패해도 일단 막지는 말고 지켜만 봐라"는 감시 모드다. 처음 세팅할 땐 이 none으로 시작해 메일이 정상인지 관찰하고, 나중에 필요하면 quarantine이나 reject로 조이면 된다. rua=mailto:hello@mcpy.kr는 "인증 결과 리포트를 이 주소로 보내 달라"는 뜻이라, 어떤 메일이 인증에 걸리는지 눈으로 볼 수 있다.

정리하면 SPF·DKIM·DMARC는 삼형제다. SPF가 "이 서버가 보내도 된다", DKIM이 "내용이 안 바뀌었다", DMARC가 "둘 중 하나라도 어긋나면 이렇게 처리하고 나한테 알려 달라"를 맡는다. 셋이 다 있어야 수신함에 안정적으로 꽂히는 구조다.

3단계. DNS에 레코드가 진짜 박혔는지 확인하기

레코드를 넣었다고 끝난 게 아니다. 외부 DNS에서 그 MX가 실제로 조회돼야 진짜 켜진 것이다. 확인은 두 군데서 한다. Cloudflare 안에서는 DNS → Records에 MX 3개·SPF·DKIM·DMARC가 보이는지 보고, 바깥에서는 터미널로 직접 조회하는 게 가장 확실하다.

dig MX mcpy.kr +short
# 정상이면 우선순위 숫자와 함께 *.mx.cloudflare.net 3줄이 뜬다

여기서 아무것도 안 나오거나 예전 메일 서비스 MX가 나오면, 아직 반영이 안 된 것이다. 원인은 대개 둘이다. 하나는 0단계 네임서버 위임 미완료(가장 흔하다), 다른 하나는 단순 지연이다. 네임서버가 확실히 Cloudflare Active면, 조금 기다렸다 다시 조회한다.

기존에 다른 메일 서비스를 쓰던 도메인이면 함정이 하나 더 있다. 옛 MX 레코드가 남아 Cloudflare MX와 섞이면 메일이 어디로 갈지 꼬인다. 예전 서비스용 MX가 보이면 지우고 Cloudflare MX만 남긴다.

4단계. 목적지 Gmail 등록하고 인증하기 (Verified)

메일 받을 준비(MX)는 됐으니, 이제 Cloudflare에게 "받은 메일을 어느 Gmail로 던져라"를 알려 줄 차례다. Cloudflare는 아무 주소로나 함부로 전달하지 않는다. 목적지 주소를 먼저 등록하고 소유를 증명해야 한다.

Email Routing → Destination Addresses에서 you@gmail.com(본인 Gmail)을 추가한다. 그러면 Cloudflare가 그 Gmail로 확인 메일을 보내고, 메일 안의 Verify email address를 누르면 검증이 끝난다. 이 절차는 공식 문서에도 명시돼 있다.

이건 상식적인 안전장치이기도 하지 않나. 소유 증명 없이 전달을 허용하면, 남의 주소로 메일 폭탄을 던지는 통로가 되어 버리니까. 그래서 목적지 상태가 Verified가 아니면 다음 라우팅 규칙의 전달 대상으로 쓸 수 없다. 이 인증을 먼저 끝내는 게 순서의 핵심이라 하겠다.

이 확인 메일은 Cloudflare가 Gmail로 직접 보내는 것이라, 아직 도메인 라우팅이 완성 안 됐어도 도착한다. 안 오면 스팸함까지 뒤진다.

5단계. 라우팅 규칙 만들기 (hello@mcpy.kr → 내 Gmail)

목적지가 Verified가 됐으면, 마지막 연결 고리를 건다. "hello@mcpy.kr로 온 메일은 you@gmail.com으로 보내라"는 라우팅 규칙(Routing rule)이다.

Email Routing의 규칙 화면에서 이렇게 잡아 준다.

이 규칙이 켜지면 hello@mcpy.kr로 온 메일이 you@gmail.com으로 흘러 들어가 준다. 처음엔 대표 주소 하나만 두길 권한다. 나중에 support@, team@ 같은 역할별 주소를 규칙만 추가해 얼마든지 늘릴 수 있다.

여기까지가 수신 쪽 이야기 전부다. 이 시점에 외부에서 hello@mcpy.kr로 메일을 보내 보면, 내 Gmail 받은편지함에 도착해야 한다. 도착하면 수신은 초록불이고, 이게 켜져야 다음 발신 인증이 돌아간다.

6단계. Gmail에서 도메인 주소로 보내게 만들기

Cloudflare Email Routing은 수신 전용이라 받기만 한다. 그래서 hello@mcpy.kr로 답장을 보내려면 Gmail 쪽에서 따로 설정해야 한다. 안 하면 받은 메일에 답할 때 발신자가 개인 Gmail로 찍혀, 상대가 헷갈리게 된다.

Gmail의 다른 주소에서 메일 보내기(Send mail as)를 쓰면 된다. 공식 도움말 기준 경로는 이렇다.

• Gmail → 설정(톱니) → 모든 설정 보기 → 계정 및 가져오기 탭
• 다른 주소에서 메일 보내기 → 다른 이메일 주소 추가
• 이름(브랜드 표시명)과 hello@mcpy.kr을 입력, "별칭으로 처리" 체크

이름은 상대의 받은편지함에 뜨는 발신자 표시명을 말한다. "별칭으로 처리"는 이 주소를 같은 사람의 다른 얼굴로 볼지 결정하는데, 개인이 자기 도메인 주소를 얹는 지금 상황에선 보통 체크해 둔다. 여기서 다음을 누르면 Gmail이 SMTP 정보를 물어보는데, 이게 바로 다음 단계다.

7단계. SMTP와 앱 비밀번호 넣기 (2단계 인증이 전제)

Gmail은 외부 주소를 발신 주소로 등록할 때, "이 계정으로 실제 메일을 내보낼 권한이 있냐"를 SMTP 인증으로 확인한다. Gmail SMTP로 보낼 때 값은 이렇게 넣어 준다.

포트 587에 TLS는 오늘날 표준 발신 조합이다. 그런데 여기서 초보자가 거의 다 한 번씩 밟는 지뢰가 하나 숨어 있다. 비밀번호 칸에 평소 Gmail 로그인 암호를 넣으면 실패한다. 실제로 뜨는 오류는 534-5.7.9 Application-specific password required, "앱 전용 비밀번호가 필요하다"는 말이다.

여기서 순서가 중요하다. 앱 비밀번호는 2단계 인증을 먼저 켜야만 만들 수 있다. 2단계 인증(2FA)이 꺼져 있으면 앱 비밀번호 메뉴 자체가 안 보인다. 그래서 준비물에 "2단계 인증 켠 Gmail"이 있었던 것이다. Google도 앱 비밀번호는 2단계 인증이 켜진 계정에서만 발급된다고 명시한다.

앱 비밀번호는 이렇게 만든다. Google 계정 → 보안 → 2단계 인증이 켜진 상태에서 앱 비밀번호로 들어가, 이름(예: domain-mail)을 붙여 생성한다. 그러면 16자리 문자열이 뜬다. 이게 열쇠다.

여기 경고 하나. 이 16자리는 딱 한 번만 표시되니 주의하자. 창을 닫으면 다시 못 본다. 그러니 그 자리에서 바로 SMTP 비밀번호 칸에 넣거나 안전한 곳에 복사해 둔다. 놓치면 재발급밖에 답이 없으니까.

8단계. 발신 주소 인증 (수신이 켜져야 이 고리가 닫힌다)

SMTP 정보까지 넣으면, Gmail이 hello@mcpy.kr로 확인 메일을 보내 준다. 그 안의 링크를 눌러야 발신 주소 인증이 끝난다. 그런데 이 확인 메일이 어디로 갈지 생각해 보자. 여기에 이 글 전체의 핵심 구조가 숨어 있다.

인증 루프는 이렇게 돈다. Gmail이 hello@mcpy.kr로 인증 메일을 발송한다. 그 메일은 도메인 MX를 타고 Cloudflare로 들어온다. Cloudflare 라우팅이 그걸 내 Gmail(you@gmail.com)로 전달한다. 나는 바로 그 받은편지함에서 링크를 클릭하는 셈이다. 즉, 인증 메일이 한 바퀴 돌아 나에게 돌아오는 셈이다.

그래서 수신이 정상 작동해야만 발신 인증 메일을 받을 수 있다. 이 순환 의존을 모르고 발신부터 손대면, 확인 메일이 반송되거나 영영 안 와서 "왜 인증이 안 되지" 하며 발신 설정만 붙잡고 헤맨다. 정작 문제는 뒤쪽 수신이 아직 안 켜진 것인데 말이다.

그래서 이 글은 계속 "위임 먼저, 수신 그다음, 발신 마지막"을 반복했다. 앞 단계에서 hello@mcpy.kr 수신 테스트가 초록불이었다면, 이 확인 메일도 같은 길로 무사히 Gmail에 도착한다. 링크를 누르면 그걸로 인증 완료다.

9단계. 수신과 발신 양쪽을 실제로 테스트하기

설정이 끝났다고 믿지 말고, 두 방향을 실제로 돌려 보자. 눈으로 도착을 확인해야 비로소 "완료"라 부를 수 있지 않을까.

수신 테스트는 다른 이메일(개인 계정 아무거나)에서 hello@mcpy.kr로 메일을 한 통 보내는 것이다. you@gmail.com 받은편지함에 제목·본문 손상 없이 도착하면 수신은 정상이다.

발신 테스트는 반대로 한다. Gmail에서 새 메일을 쓰고, From을 hello@mcpy.kr로 바꿔 외부 주소로 보낸다. 받은 쪽에서 발신자가 개인 Gmail이 아니라 hello@mcpy.kr로 보이면 발신도 정상이라는 뜻이다.

둘 다 통과하면 도메인 이메일이 완성된 것이다. Gmail 설정의 Send mail as 목록에서 hello@mcpy.kr을 기본 발신 주소로 지정해 두면, 새 메일을 쓸 때마다 자동으로 이 주소로 나가 준다.

10단계. Gmail 스팸 필터 잡기 (안 하면 수신이 스팸함으로)

마지막 한 걸음이 의외로 자주 빠진다. Cloudflare가 전달한 메일은 "원래 발신자 대신 내 도메인을 거쳐 온" 모양새라, Gmail이 이따금 스팸으로 오인해 스팸함에 넣는다. 앞서 DMARC를 넣은 것도 이걸 줄이기 위함이지만, 확실히 하려면 Gmail 필터로 못박아 두자.

경로는 이렇다. Gmail 설정 → 필터 및 차단된 주소 → 새 필터 만들기에서 조건에 from:(hello@mcpy.kr)를 넣고, 다음 화면에서 "스팸으로 보내지 않기"를 체크한다. 이렇게 하면 내 도메인으로 들어오는 메일이 스팸함으로 새지 않고 받은편지함에 꽂혀 준다.

왜 중요하냐면, 여기까지 완벽히 세팅해도 정작 고객 문의가 스팸함에 처박혀 있으면 그걸 놓친다. 수신의 마지막 안전장치인 셈이다.

안 될 때 어디부터 보나

문제는 대개 정해진 몇 곳에서 생긴다. 증상별로 어디를 먼저 보는지만 알아도 시간이 크게 줄어든다는 게 다행이다.

확인 메일이 반송된다 / no relevant answers가 뜬다. 거의 항상 수신 쪽 문제다. 대표 에러는 DNS type 'mx' lookup of mcpy.kr had no relevant answers인데, "MX를 못 찾았다"는 뜻이다. 순서대로 본다. 가비아 네임서버가 진짜 Cloudflare Active인가(가장 흔한 원인), Cloudflare DNS에 MX 3개가 있나, Destination이 Verified인가, hello 라우팅 규칙이 Enabled인가. 네임서버 미위임이면 아무리 레코드를 넣어도 바깥세상은 못 본다.

SMTP 인증이 실패한다. 534-5.7.9 Application-specific password required가 떴다면, 로그인 암호를 넣은 것이다. 2단계 인증을 확인하고, 앱 비밀번호를 새로 발급해 다시 넣는다. 서버 smtp.gmail.com, 포트 587, TLS 조합도 재확인한다.

Gmail이 계속 "확인되지 않음"이다. 확인 메일을 못 받았거나 링크를 안 누른 경우가 대부분이다. 몇 분 기다렸다 확인 메일을 재전송하고, 받은편지함과 스팸함을 모두 뒤진다. Cloudflare의 Activity Log에서 그 메일이 실제로 라우팅됐는지도 볼 수 있다.

메일은 오는데 자꾸 스팸함으로 간다. DMARC(_dmarc TXT)가 빠졌거나, 10단계의 Gmail 필터를 안 건 것이다. 둘 다 확인한다.

혼자 쓰다 팀이 생기면

이 구조의 한계는 솔직하게 말해 두는 게 낫다. 실제 메일함이 Gmail 한 계정에 몰려 있다는 점이다. 혼자 쓸 땐 더없이 편하지만, 사람이 늘면 권한 분리나 공용 보관함 같은 협업 기능이 슬슬 아쉬워지기 시작하지 않겠나.

그래도 급하게 갈아엎을 필요는 없다. 가장 가벼운 건 지금 구조를 그대로 두고 주소만 추가하는 방법이다. Cloudflare 라우팅에 support@mcpy.kr은 담당자 Gmail로, biz@mcpy.kr은 다른 Gmail로 규칙을 하나씩 더 얹는다. 빠르고 여전히 공짜지만, 권한 분리나 감사 기록 같은 건 못 챙긴다.

사람이 둘 이상으로 늘고 각자 독립된 @mcpy.kr 메일함이 필요해지면, 그때 Google Workspace 같은 유료 팀 메일로 전환을 검토한다. 사용자별 메일함, 조직 계정, 퇴사 시 권한 회수 같은 걸 그때 얻으면 된다. 대표 주소만 지금 구조로 두고 핵심 팀만 유료 계정을 쓰는 절충도 가능하다. 요점은 순서다. 무료로 시작해 필요가 생길 때 갈아타면 되지, 처음부터 팀 요금을 낼 이유가 있을까.

정리: 이 순서대로만 하면 막히지 않는다

개념 설명은 여기까지다. 실제로 앉아서 할 때는 아래 순서와 점검 질문만 챙기면 된다. 하나라도 건너뛰면 뒤에서 반드시 돌아온다.

그래도 하나만 챙긴다면, 이것이다.

위임 먼저, 수신 그다음, 발신 마지막. 인증 메일조차 그 길로 들어온다.

근거·출처

• Cloudflare가 만드는 MX·SPF·DKIM과 목적지 검증: Cloudflare Docs, Enable Email Routing
• SPF 값·DKIM 셀렉터(cf2024-1) 등 정확한 레코드: Cloudflare Docs, Email Routing Postmaster
• DMARC가 SPF·DKIM을 묶어 실패 시 처리를 정함: Cloudflare Docs, DMARC Management
• Gmail 다른 주소에서 메일 보내기·SMTP 설정: Google Support, Send emails from a different address
• 앱 비밀번호가 2단계 인증을 요구하고 16자리로 한 번만 표시됨: Google Support, Sign in with app passwords

공개 브랜드 값(mcpy.kr, hello@mcpy.kr)은 실제 예시로 썼고, 수신 Gmail은 자리표시자(you@gmail.com)이니 본인 주소로 바꾼다. 앱 비밀번호 실값은 넣지 않는다. MX 호스트명·우선순위·네임서버 2개 값은 Cloudflare가 도메인마다 다르게 배정하므로, 실제 설정 시 자기 대시보드가 만들어 준 값을 그대로 쓴다.