스팸함 안 가는 발신 도메인 설정: SPF·DKIM·DMARC부터 분리까지 (2027년)

🗣️ 발신 도메인, 용도별로 나눠야 할까요?

다큐라이즈 메일 구조를 정리하면서 저희가 실제로 했던 고민이에요. 로그인 링크, 결제 안내, 제품 업데이트 레터, 그리고 크리에이터가 구독자에게 보내는 메일까지 전부 한 시스템에서 나가고 있었거든요.

다큐라이즈는 비밀번호 없이 이메일 링크로 로그인해요. 로그인 메일이 스팸함에 들어가면 그분은 그날 서비스를 못 써요. 레터 한 통 때문에 이런 일이 생기면 안 되겠다 싶었어요.

막상 찾아보니 "도메인을 나누세요"라는 말은 많은데, 어떤 메일을 어떤 주소로 나눠야 하는지 알려주는 자료는 잘 없더라고요. 그래서 국내외 서비스 19곳의 실제 메일 원본을 하나씩 열어봤어요. 같은 고민을 하고 계실 분들께 도움이 될 것 같아, 저희가 찾은 것과 내린 결론을 그대로 정리했습니다.

결론부터 말하면, 발신 도메인은 용도별로 3개로 나누면 됩니다. 거래 메일(로그인·결제)은 루트 도메인, 팀 레터(제품 업데이트·뉴스레터)는 서브도메인 하나, 고객 대신 보내는 메일은 또 다른 서브도메인에 둡니다. 그리고 세 도메인 모두 SPF·DKIM·DMARC를 맞추고, 거래 메일만 쓰는 발송 계정을 따로 만듭니다.

다만 도메인만 나눈다고 끝나지는 않아요. 받는 사람에게 보이는 주소, 메일에 찍히는 서명 도메인, 실제로 메일을 내보내는 발송 계정이 각각 따로 움직이기 때문이에요. 아래에서 하나씩 짚어볼게요.

결론부터: 발신 주소는 3개, 발송 계정은 2개

먼저 저희가 정한 구조를 한 장으로 보여드릴게요.

🔺 보이는 주소는 3개로 나누고, 실제로 메일을 내보내는 계정은 거래 메일 전용과 대량 발송용 2개로 나눕니다

이 구조의 핵심은 하나예요. 안 가면 서비스가 멈추는 메일과, 안 가도 서비스는 돌아가는 메일을 섞지 않는 것.

거래 메일과 마케팅 메일, 도메인을 꼭 나눠야 하나요?

네, 나누는 게 맞습니다. 수신 서비스가 평판을 도메인과 IP 단위로 따로 기억하기 때문이에요.

구글은 공식 발송자 가이드라인에서 Gmail이 발송 한도와 피드백을 도메인과 IP 주소별로 추적한다고 밝히고 있습니다. 같은 가이드라인에서 같은 종류의 메일은 같은 From 주소로 보내고, 여러 IP를 쓴다면 메일 종류마다 IP를 나누라고 권해요.

이메일 발송 서비스들의 권장도 같은 방향입니다.

• Postmark: 거래 메일과 대량·홍보 메일을 서로 다른 서브도메인에 두고, 각각 DKIM과 Return-Path를 따로 설정하라고 안내합니다.
• Resend: 루트 도메인 대신 updates.example.com 같은 서브도메인에서 보내라고 권하고, 뉴스레터와 계정 메일을 서로 다른 서브도메인으로 나누는 예시를 듭니다.
• Customer.io: 거래 메일용 도메인을 마케팅 도메인과 분리하라고 권하면서, 마케팅 메일의 평판이 중요한 거래 메일에 번지는 걸 막기 위해서라고 설명해요.

반대 의견도 있어요. ActiveCampaign은 서브도메인이 나쁜 평판을 피해 가는 방패는 아니라고 분명히 말합니다. 서브도메인 평판은 루트 도메인에도 어느 정도 영향을 주고, 서브도메인끼리의 영향만 작다는 설명입니다.

그래서 서브도메인 분리는 사고가 번지는 범위를 줄이는 장치이지, 스팸을 보내도 괜찮게 만드는 장치가 아닙니다.

다른 회사들은 발신 주소를 어떻게 나누나요?

저희는 받은편지함에 있던 국내외 서비스 메일의 원본 헤더를 하나씩 열어봤습니다. 보이는 From 주소뿐 아니라 서명(DKIM) 도메인, 반송 주소(Return-Path), 발송 도구까지 확인했습니다. 아래 값은 모두 2026년 10월 기준입니다.

해외 서비스: 거래 메일은 루트, 레터는 서브도메인이 많아요

여기서 세 가지 패턴이 보여요.

1. Linear, Vercel, Stripe는 거래 메일을 루트 도메인에서 보냅니다. 대량·마케팅 메일만 서브도메인이나 다른 도구로 뺐습니다.
2. 제품 업데이트와 마케팅을 서로 다른 도메인으로 나눈 곳은 없었습니다. Linear는 체인지로그와 가격 변경 공지를 같은 updates.linear.app에서 보내요.
3. 보이는 주소는 루트로 두고 서명만 나누는 곳도 있어요. Supabase, PostHog, Mobbin이 그렇습니다.

우리 회사는 어느 쪽이 맞을까요?

🔺 Linear처럼 주소까지 나누는 방식(A)과 Supabase처럼 서명만 나누는 방식(B). 루트 도메인에 엄격한 DMARC를 걸어둔 회사는 A가 맞습니다

국내 서비스: 원티드는 3갈래, 플랫폼은 고객 메일을 따로 격리해요

🔺 국내에서 가장 깔끔하게 나눈 사례였던 원티드. 공지와 광고성 안내는 mail. 서브도메인, 뉴스레터는 newsletter. 서브도메인을 씁니다

국내 사례에서 저희가 가장 크게 배운 건 채널톡과 스티비예요. 고객사 대신 메일을 보내는 서비스는 자사 메일과 고객 메일을 처음부터 다른 도메인에 둡니다. 고객 한 곳의 문제가 자사 공지나 인증 메일에 번지지 않게 하려는 구조로 보입니다.

주소는 어떻게 지어야 하나요? noreply, hello, team, 그리고 서브도메인 이름

뉴스레터는 noreply로 보내도 되나요?

권하지 않습니다. Resend는 no-reply 주소가 일방향 소통이라는 신호를 줘서 신뢰를 떨어뜨린다고 설명해요. 스티비도 발신 전용 주소 사용을 권장하지 않는다고 안내합니다.

거래 메일은 noreply여도 괜찮아요. 받는 사람이 답장할 이유가 거의 없고, 이미 많은 서비스가 그렇게 씁니다. 하지만 사람이 읽고 답할 수 있는 레터라면 답장이 닿는 주소가 좋아요.

hello, team, product, marketing 중 뭐가 좋나요?

기술적인 차이는 없습니다. 실제로 쓰이는 주소를 보면 이래요.

받는 사람이 주소만 보고 어떤 메일인지 알 수 있나요? 그거면 충분해요.

그리고 하나만 지키면 됩니다. 구글 가이드라인처럼 같은 종류의 메일은 같은 주소로 계속 보내세요. 받는 사람의 주소록과 수신 서비스의 기억이 그 주소에 쌓여요.

send, mail, updates, news 중 어떤 서브도메인 이름이 좋나요?

서브도메인 이름이 스팸 판정에 영향을 준다는 근거는 찾지 못했어요. 그래서 팀이 보고 바로 용도를 알아보는 이름을 고르는 게 맞습니다.

• updates.: 제품 업데이트와 뉴스레터를 같이 담기 좋아요. Linear가 쓰고, Resend도 예시로 듭니다.
• news. / newsletter.: 정기 뉴스레터만 보낼 때 분명해요. 원티드가 newsletter.를 씁니다.
• mail. / email.: 회사마다 뜻이 달라요. Anthropic은 mail.을 영수증에, email.을 마케팅에 쓰고 Notion은 mail.에 거의 모든 메일을 담습니다. 팀 안에서 헷갈리기 쉽습니다.
• send.: Resend는 반송 주소(Return-Path) 기본값으로 send.를 씁니다. 보이는 주소로 쓰려면 반송 주소와 겹치지 않는지 먼저 확인하세요. 스티비처럼 고객 대신 발송하는 용도로 쓰는 곳도 있어요.

도메인을 나눠도 같이 멈추는 경우가 있나요?

있습니다. 저희가 가장 놓치기 쉽다고 본 부분이에요. 보이는 도메인을 나눠도, 같은 발송 계정으로 보내면 계정 단위로 함께 멈춥니다.

Amazon SES를 예로 들면, 반송률이 5% 이상이면 계정을 검토 상태로 두고 10% 이상이면 계정의 발송을 멈출 수 있어요. 스팸 신고율은 0.1%에서 검토, 0.5%에서 정지 가능입니다. 기준은 도메인이 아니라 계정 전체입니다.

🔺 고객 한 명의 대량 발송이 반송·신고 기준을 넘기면, 계정을 같이 쓰는 로그인·결제 메일까지 멈춥니다

고객 대신 메일을 보내는 플랫폼이라면 이 위험이 더 큽니다. 고객이 오래된 리스트나 오타 주소에 한 번 보내기만 해도 반송률이 튈 수 있기 때문이에요.

SPF·DKIM·DMARC는 각각 어떻게 설정하나요?

세 가지는 역할이 다릅니다.

• SPF: 이 도메인 이름으로 메일을 보내도 되는 서버 목록입니다. DNS의 TXT 레코드로 등록해요.
• DKIM: 메일에 찍는 전자 서명이에요. 발송 서비스가 주는 CNAME이나 TXT 값을 등록합니다.
• DMARC: SPF나 DKIM이 From 주소의 도메인과 맞지 않을 때 어떻게 처리할지 정하는 정책이에요. p=none(모니터링만), p=quarantine(스팸함), p=reject(거부) 중에서 고릅니다.

🔺 서브도메인 하나를 새로 만들 때 필요한 레코드 예시. 값은 발송 서비스 대시보드에서 발급한 그대로 넣으세요

설정할 때 자주 틀리는 부분이 세 가지 있어요.

1. 루트 SPF에 업무용 메일을 빼먹는 경우. Google Workspace로 대표 메일을 보내는데 SPF에 include:_spf.google.com이 없으면, 대표 메일이 SPF 검사에서 떨어집니다. DKIM이 살아 있을 때는 통과되지만, 전달 과정에서 서명이 깨지면 DMARC 정책에 따라 거부될 수 있어요.
2. 엄격한 DKIM 정렬(adkim=s)을 모르고 서명만 서브도메인으로 하는 경우. 루트 DMARC에 adkim=s가 있으면 From이 루트일 때 서명도 정확히 루트여야 해요. 이럴 땐 보이는 주소까지 서브도메인으로 옮기는 게 깔끔합니다.
3. 새 서브도메인에 바로 대량 발송하는 경우. Postmark는 새 서브도메인은 반응 좋은 사용자에게 먼저 보내면서 물량을 천천히 늘리라고 권해요.

Gmail·Outlook 발송자 규정은 2024~2026년에 어떻게 바뀌었나요?

큰 메일 서비스들이 인증을 사실상 의무로 바꿨습니다.

Gmail은 2025년 11월부터 요구사항을 못 지킨 메일을 일시·영구 거부하는 식으로 집행을 강화한다고 밝혔어요.

Outlook.com은 2025년 5월 5일부터 인증을 통과하지 못한 대량 발송 메일을 550 5.7.515 오류로 거부한다고 공지했습니다.

네이버 메일은 어떨까요? 국내에서는 스티비가 G메일과 네이버 메일 정책에 따라 외부 서비스에서 gmail.com, naver.com 주소로는 보낼 수 없다고 안내해요. 그래서 개인 메일 주소를 발신자로 넣으면 send.stibee.com 주소로 자동으로 바뀝니다.

광고성 뉴스레터는 법적으로 뭘 지켜야 하나요?

국내 수신자에게 광고성 이메일을 보낸다면 정보통신망법 제50조를 지켜야 합니다. 한국인터넷진흥원과 방송미디어통신위원회의 불법스팸 방지 안내서에 나온 이메일 기준은 이렇습니다.

• 수신자의 명시적인 사전 동의를 받아야 해요. 같은 종류의 재화를 거래한 고객에게는 거래 종료 후 6개월까지 예외가 있습니다.
• 제목이 시작되는 부분에 (광고) 를 붙여요.
• 본문에 전송자 명칭과 연락처, 그리고 수신거부 방법을 한글과 영문으로 적어야 해요.
• 수신거부는 로그인 없이 바로 처리되도록 기술적 조치를 해야 합니다.
• 오후 9시~오전 8시 광고 전송 제한에서 이메일은 제외예요.

제품 업데이트 레터라도 할인, 이벤트 초대, 유료 플랜 권유가 들어가면 광고성 정보로 볼 여지가 커요. 애매하면 광고로 취급하고 동의한 사람에게만 보내는 쪽이 안전합니다.

📋 상황별 추천 구조 정리

🔺 물량보다 "그 메일이 안 가면 무슨 일이 생기는지"를 기준으로 고르세요

이미 루트 도메인으로 거래 메일을 오래 보내왔다면, 거래 메일을 새 서브도메인으로 옮기지 않는 게 좋아요. 쌓인 발송 기록을 버리고 평판 0부터 다시 시작하는 셈이기 때문입니다.

다큐라이즈는 이렇게 정했습니다

다큐라이즈는 크리에이터가 자료를 공유하면 리드를 모으고, 결제 전환과 후속 이메일·알림톡까지 이어주는 서비스예요. 크리에이터가 구독자에게 보내는 후속 이메일을 저희가 대신 보내기 때문에, 위에서 말한 "고객 대신 발송"에 해당합니다.

그래서 저희는 이렇게 정했어요.

팀 레터를 team@으로 고른 데는 이유가 있어요. 그동안 저희 레터가 team@ 주소로 나갔기 때문에, 앞부분은 그대로 두고 도메인만 바꾸는 게 받는 분들께 덜 낯설다고 판단했습니다. 답장은 대표 메일함으로 오도록 Reply-To를 따로 지정해요.

크리에이터분들이 쓰는 이메일 발송 한도와 플랜별 차이는 다큐라이즈 요금제에서 확인할 수 있어요.

자주 묻는 질문

발신 도메인을 나누면 스팸함에 안 가나요?

보장되지는 않아요. 도메인 분리는 한 종류의 메일에서 생긴 문제가 다른 종류로 번지지 않게 막는 장치입니다. 스팸함에 가는지는 결국 수신 동의, 반송률, 스팸 신고율, 내용이 결정해요.

하루 5,000통이 안 되면 DMARC는 안 해도 되나요?

Gmail의 DMARC 의무는 하루 5,000통 이상 보내는 발송자 기준이에요. 그래도 구글은 모든 도메인에 SPF·DKIM·DMARC를 설정하라고 권하고, 물량은 생각보다 금방 늘어나요. 처음부터 p=none으로라도 걸어두는 게 낫습니다.

스팸률은 어디서 확인하나요?

Gmail로 가는 메일은 구글 Postmaster Tools에서 도메인별 스팸률을 볼 수 있어요. 도메인을 나눠두면 거래 메일과 레터의 스팸률을 따로 확인할 수 있다는 장점도 생깁니다.

완전히 다른 도메인(예: example-mail.com)을 사는 건 어떤가요?

권하지 않아요. Postmark는 두 도메인을 완전히 다르게 가져가면 피싱이나 스푸핑처럼 보일 수 있다고 설명합니다. 같은 루트 아래 서브도메인이 받는 사람에게도 더 믿음직해요.

DMARC 정책은 none, quarantine, reject 중 뭘 써야 하나요?

처음에는 p=none으로 시작하세요. 구글도 대량 발송자의 DMARC 정책은 none이어도 된다고 안내해요. none 상태에서 DMARC 리포트(rua)를 받아 보고, 내 발송 경로가 전부 SPF·DKIM을 통과하는 게 확인되면 quarantine, 그다음 reject로 올리는 순서가 안전합니다. none은 위조 메일을 막아주지는 못하니, 확인이 끝나면 quarantine 이상으로 올리는 게 좋아요.

마무리하며

이 글의 사례는 저희 받은편지함에 있던 메일과 공개 DNS로 확인한 2026년 10월 시점의 값이에요. 회사들은 발송 구조를 자주 바꾸기 때문에, 지금 이 순간의 구조와는 다를 수 있습니다.

• 서브도메인 이름(updates, news, send)이 스팸 판정에 영향을 준다는 근거는 찾지 못했어요. 이름은 사람을 위한 선택입니다.
• 물량이 작을 때 도메인을 너무 잘게 쪼개면, 어느 쪽도 평판이 쌓일 만큼 발송량이 안 나와요.
• 분리는 사고의 범위를 줄일 뿐이에요. 동의 없는 발송이나 오래된 리스트는 어떤 구조에서도 평판을 깎습니다.

그래도 하나만 남긴다면 이거예요.

"이 메일이 안 가면 서비스가 멈추는가?" 이 질문에 "네"라고 답하는 메일만 따로 떼어내세요.

그게 로그인 링크든 결제 안내든, 그 메일은 다른 어떤 메일과도 같은 주소, 같은 계정을 쓰지 않는 게 맞습니다.

관련 글 읽기

이메일 자동화, 다큐라이즈에서 5분만에 세팅하기

무료 자료를 받아간 사람에게, 다음엔 뭘 보내야 할까요?

CRM 마케팅이 필요한 이유, 열심히 모은 리드를 매출로 연결하는 법