중소기업이 특정 서비스에 묶이지 않고 대량 메일을 설계하는 방법

「전용 뉴스레터 발송 서비스를 새로 늘리지 않고, 기존 도메인과 사이트로 수십~수백 건의 안내 메일을 보내고 싶다」. 이 상담에 대한 현실적인 답은 Bcc 일괄 발송이 아니라, 수신자별 개별 발송, 구독 관리, 구독 해지, SPF / DKIM / DMARC를 갖춘 작은 발송 기반으로 만드는 것입니다.

여기서 말하는 「특정 서비스를 쓰지 않는다」는 「아무것도 쓰지 않는다」가 아닙니다. SMTP라는 표준, 구독자 리스트, 템플릿, 구독 해지 동선을 자사 쪽에 두고, 발송 수단만 나중에 갈아끼울 수 있는 구성으로 한다는 뜻입니다.

또한 이 글에서는 기존 고객, 회원, 자료 청구자, 뉴스레터 구독자처럼 어떤 관계나 동의가 있는 상대에게 보내는 메일을 전제로 합니다. 공개 주소를 모아 무차별 발송하는 이야기가 아닙니다. 광고·홍보 메일에는 법적 전제가 있고, 발송 품질 면에서도 그 방식은 오래가지 않습니다.¹²

이하는 2026년 4월 시점에 확인할 수 있는 일본의 특정전자메일법 관련 공적 정보와, Google / Yahoo / Outlook의 발송자 가이드라인을 전제로 한 정리입니다.¹²³⁴⁵

이 글의 대상 독자와 전제

이 글에서 쓰는 약어

2장 이후에서 설명 없이 나오는 말을 먼저 정리합니다.

1. 먼저 결론

중소기업이 외부향 대량 메일에서 현실적으로 취해야 할 형태는 대체로 다음 4점입니다.

1. 수신자별로 개별 발송한다 Bcc에 모아 넣는 것이 아니라, 한 통씩 보낸다는 전제로 큐를 구성합니다.
2. 구독 상태를 자사에서 가진다 active, unsubscribed, bounced 같은 상태 관리를 자사 DB나 CSV에 분명히 둡니다.
3. 구독 해지를 자동으로 접수한다 「이제 보내지 마세요」를 수작업으로 처리하는 운영으로 두지 않습니다. 본문에 보이는 링크와, 가능하면 List-Unsubscribe를 넣습니다.³⁴⁵
4. 발송 도메인을 인증한다 SPF / DKIM / DMARC, reverse PTR, TLS를 갖춥니다. 보낼 수 있더라도, 이것이 없으면 도달하기 어려워집니다.³⁴⁵

요컨대 메일 소프트웨어 조작의 문제가 아니라, 발송 기반의 문제입니다.

「한꺼번에 보내고 싶다」는 요건을 To / Cc / Bcc에 잔뜩 늘어놓는 것으로 생각하면 무너집니다. 실제로 필요한 것은 이런 구조입니다.

• 누구에게 보내도 되는가
• 이제 보내서는 안 되는 상대는 누구인가
• 무슨 목적으로 동의를 받았는가
• 구독 해지를 어떻게 받을 것인가
• 발송원으로서 신뢰받는 설정이 되어 있는가

이 글의 지식 맵

중소기업이 특정 메일링 서비스에 의존하지 않고 대량 메일을 보내려면, Bcc 일괄 발송이 아니라 구독자 테이블·억제 테이블·발송 큐로 구성된 발송 기반을 자사 측에 두고 SMTP 릴레이라는 출구만 교체할 수 있는 구성으로 만드는 것이 현실적입니다. 억제 테이블은 발송 중지와 bounce를 구독자 테이블보다 우선시키고, 발송 큐는 거기서 SMTP 릴레이로 송신을 넘깁니다. 발신 도메인은 SPF·DKIM·DMARC로 인증하고, 역방향 PTR과 List-Unsubscribe를 갖춤으로써 Google이나 Yahoo가 요구하는 불만율 기준을 충족할 수 있습니다. 특정 전자메일법은 opt-in의 사전 동의와 발신자 표시 의무를 부과하며, listmonk와 같은 OSS는 이 구조를 그대로 셀프 호스트로 구현하고 있습니다.

flowchart LR
    accTitle: 대량 메일 발송 기반의 지식 맵
    accDescr: Bcc 일괄 발송의 한계, 구독자 테이블·억제 테이블·발송 큐로 구성된 자체 설계 발송 기반, SMTP 릴레이의 출구 선택, SPF·DKIM·DMARC에 의한 발신 도메인 인증, opt-in이나 표시 의무 등의 법령 요건이 어떻게 관계하는지를 보여주는 그림
    bulk_email_infrastructure["자체 설계 발송 기반(구독자 테이블·억제 테이블·발송 큐)"]
    individual_send["수신자별 개별 발송"]
    subscriber_table["구독자 테이블"]
    suppression_table["억제 테이블"]
    delivery_queue["배달 큐"]
    bcc_mass_send["Bcc 일괄 전송"]
    smtp_relay["SMTP 릴레이"]
    m365_smtp_methods["Microsoft 365의 SMTP 송신 방식(4가지)"]
    spf["SPF(Sender Policy Framework)"]
    dmarc["DMARC"]
    dkim["DKIM(DomainKeys Identified Mail)"]
    reverse_dns_ptr["역방향 PTR"]
    list_unsubscribe_header["List-Unsubscribe 헤더/원클릭 수신 거부"]
    tokutei_email_law["특정 전자메일법"]
    opt_in_consent["opt-in(사전 동의)"]
    sender_display_obligation["발신자 표시 의무"]
    spam_rate["스팸 신고율(spam rate)"]
    listmonk_oss["listmonk"]
    bulk_email_infrastructure -->|"이용한다"| subscriber_table
    bulk_email_infrastructure -->|"이용한다"| suppression_table
    bulk_email_infrastructure -->|"이용한다"| delivery_queue
    bcc_mass_send -->|"사용은 비권장"| bulk_email_infrastructure
    individual_send -->|"권장되는 대응"| bulk_email_infrastructure
    delivery_queue -->|"전제로 한다"| subscriber_table
    delivery_queue -->|"전제로 한다"| suppression_table
    delivery_queue -->|"이용한다"| smtp_relay
    smtp_relay -.->|"에서 구성할 수 있다"| m365_smtp_methods
    smtp_relay -.->|"전제로 한다"| spf
    dmarc -.->|"전제로 한다"| spf
    dmarc -.->|"전제로 한다"| dkim
    smtp_relay -.->|"전제로 한다"| reverse_dns_ptr
    list_unsubscribe_header -->|"권장되는 대응"| bulk_email_infrastructure
    tokutei_email_law -.->|"전제로 한다"| opt_in_consent
    tokutei_email_law -->|"전제로 한다"| sender_display_obligation
    suppression_table -.->|"완화한다"| spam_rate
    list_unsubscribe_header -.->|"완화한다"| spam_rate
    listmonk_oss -->|"구현을 담당한다"| bulk_email_infrastructure
    individual_send -->|"전제로 한다"| subscriber_table
    bcc_mass_send -.->|"양립하지 않는다"| suppression_table
    opt_in_consent -->|"권장되는 대응"| bulk_email_infrastructure

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 왜 Bcc 일괄 발송으로는 부족한가

외부향 일괄 발송에서 Bcc가 힘든 이유는, 겉보기는 쉬운데 운영의 본체를 하나도 갖지 못하기 때문입니다.

특히 위험한 것은 「보내는 것」은 되므로, 구조로서 성립한 것처럼 보이는 점입니다. 하지만 실제로는 발송 정지, bounce 억제, 동의 기록, 발송 로그가 없는 상태이므로, 인원이 조금 늘어난 순간에 수작업 운영이 무너집니다.

Bcc가 완전히 나쁜 것은 아닙니다. 사내 연락, 비공개 회원에 대한 극소규모 안내, 단발 관계자 연락이라면 가능한 경우도 있습니다. 다만 외부 고객이나 잠재 고객에게 계속 보내는 구조의 토대로는 약하다는 이야기입니다.

3. 「특정 서비스를 쓰지 않는다」의 현실적인 의미

여기서 오해하기 쉬운 점은, 「특정 서비스를 쓰지 않는다」=「전부 손으로 한다」가 아니라는 것입니다.

실무에서는 다음 3가지를 자사 쪽에 두고 있으면, vendor lock-in을 꽤 피할 수 있습니다.

3.1 자사가 가져야 할 것

• 구독자 데이터
  • 메일 주소
  • 동의 시각
  • 동의 취득 경로
  • 발송 카테고리
  • 구독 해지 상태
• 발송 규칙
  • 무엇을 누구에게 보낼지
  • 어느 속도로 보낼지
  • bounce나 구독 해지를 어떻게 반영할지
• 발송자 identity
  • 발송 도메인
  • SPF / DKIM / DMARC
  • 회신을 받을 메일 주소
  • 구독 해지 URL

3.2 갈아끼워도 되는 것

• 실제로 보낼 SMTP 릴레이
• 관리 화면의 구현 방식
• 발송 큐의 구현 장소
• 로그 보관처

즉 「서비스를 쓰지 않는다」의 본질은 발송 규칙과 상태를 상대 쪽에 전부 맡기지 않는 것입니다.

• 수신자 리스트는 자사 DB에 있다
• 구독 해지 URL은 자사 도메인 아래에 있다
• 제목과 본문 템플릿은 자사에서 가진다
• SMTP 출구만 나중에 갈아끼울 수 있다

이 형태라면 처음에는 기존 메일 기반을 쓰고, 나중에 다른 발송 수단으로 옮길 수도 있습니다.

4. 중소기업에 현실적인 구성

4.1 최소한의 부품

수십~수백 건/회 정도라면, 처음부터 거창한 구조는 필요 없습니다. 다만 최소한 이 정도는 나눠 두는 편이 안정됩니다.

1. 구독자 테이블
2. suppression 테이블
   • 구독 해지
   • hard bounce
   • complaint
3. 발송 템플릿
   • 제목
   • 본문(HTML / text)
   • 발송 카테고리
4. 발송 큐
   • 수신자별 상태
   • 발송 결과
   • 재시도 횟수
5. SMTP 릴레이
   • 기존 메일 기반을 쓸지
   • 자체 서버를 쓸지
6. 로그
   • 언제 누구에게 보냈는지
   • 성공 / 실패
   • 해지 / bounce 반영

오픈율이나 클릭률의 고도 계측은 처음부터 필수가 아닙니다. 먼저 필요한 것은 안전하게 보내고, 멈출 수 있고, 설명할 수 있는 것입니다.

4.2 발송 대상 테이블에서 가질 항목

최소한의 항목은 이 정도입니다.

처음 마스터가 Excel이나 기존 고객 명부라도, 여기까지는 나눠 두는 편이 좋습니다. 특히 중요한 것은 suppression 정보가 항상 우선되는 것입니다.

예를 들어 영업 명부에 그 사람의 주소가 남아 있어도, suppression 테이블에서 unsubscribed이면 보내지 않습니다. 이 규칙이 없으면 구독 해지 후에 다른 경로로 다시 섞여 들어와 사고가 납니다.

4.3 구성도

flowchart LR
    A[홈페이지 / 구독 폼] --> B[구독자 테이블]
    A2[기존 고객 명부 / 회원 명부] --> B

    C[발송 템플릿<br/>제목 / HTML / text] --> D[발송 큐]
    B --> D
    E[suppression 테이블<br/>구독 해지 / bounce / complaint] --> D

    D --> F[SMTP 릴레이<br/>기존 메일 기반 or 자체 릴레이]
    F --> G[수신자]

    G --> H[구독 해지 URL]
    G --> I[회신]
    G --> J[bounce / complaint]

    H --> E
    J --> E
    I --> K[운영 창구]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

그림이 보이지 않는 환경을 위해, 같은 내용을 글로도 적습니다.

• 입구: 홈페이지의 구독 폼과, 기존 고객 명부·회원 명부. 둘 다 구독자 테이블로 모읍니다.
• 중심: 발송 큐에 구독자 테이블(누구에게 보낼지), suppression 테이블(보내서는 안 되는 상대), 발송 템플릿(제목·HTML·text) 세 가지가 들어갑니다.
• 출구: 발송 큐에서 SMTP 릴레이(기존 메일 기반 또는 자체 릴레이)로 넘기고, 거기서 수신자에게 도달합니다. SMTP 릴레이에는 SPF / DKIM / DMARC / PTR / TLS 설정이 연결됩니다.
• 되돌아오는 경로: 수신자로부터 3방향의 반응이 돌아옵니다. 구독 해지 URL과 bounce·complaint는 suppression 테이블로 되돌리고, 회신은 운영 창구 담당자가 받습니다.

이 그림의 핵심은 발송 수단이 중심이 아니라는 것입니다. 중심은 구독자 테이블과 suppression 테이블과 발송 큐입니다.

SMTP 릴레이는 출구에 지나지 않습니다. 여기가 나뉘어 있으면, 나중에 발송 수단을 바꿔도 과거의 구독 해지나 동의 이력을 잃지 않습니다.

4.4 출구와 발송 엔진을 고르는 방법

「자사에서 가질 것」과 「갈아끼워도 되는 것」을 나눈 뒤, 실제로 손을 움직이는 단계가 되면 다음에 볼 것은 이 두 가지입니다.

1. 출구(SMTP 릴레이)를 무엇으로 할지

이미 쓰는 메일 기반을 그대로 출구로 쓸 수 있는 경우가 많습니다. 예를 들어 Microsoft 365라면, 메일박스가 없는 장치나 앱에서 보내기 위한 방식이 공식으로 정리되어 있고, 인증이 있는 Client SMTP submission, 커넥터를 쓰는 SMTP relay, 인증 없는 Direct Send, 사내 대상 대량 발송용 High Volume Email 네 가지가 발송 한도와 필요한 TLS·포트와 함께 비교되어 있습니다.¹⁰ 온프레미스 메일 서버(Exchange Server 등)가 있는 경우에는, 그쪽에서 릴레이를 받는 편이 구성하기 쉽다고도 안내되어 있습니다.¹⁰

고를 때 보는 것은 대체로 이 4점입니다.

2. 발송 엔진을 만들지, 기존 OSS에 올릴지

구독자 테이블, suppression 테이블, 발송 큐, 구독 해지 페이지를 전부 자체 제작하는 것은 생각보다 손이 갑니다. 같은 구조를 가진 셀프호스트형 OSS가 있으므로, 먼저 그것으로 충분한지 보는 것이 지름길입니다. 예를 들어 listmonk는 AGPLv3의 셀프호스트형 뉴스레터 발송 소프트웨어로, 싱글 / 더블 opt-in의 구독자 리스트 관리, 캠페인 발송 실적과 bounce 집계, 여러 SMTP를 쓰는 큐를 갖추고 있습니다.¹¹

판단의 기준은 이렇게 됩니다.

어느 경우든 구독자 데이터·suppression 데이터·구독 해지 URL을 자사 쪽에 남긴다는 원칙은 바뀌지 않습니다. 여기만 지키면 출구도 발송 엔진도 나중에 바꿀 수 있습니다.

5. 규모별로 어디까지 만들까

5.1 월 1회·수십 건

이 규모라면 최소 구성으로 충분한 경우가 많습니다.

• 발송 전용 치환 템플릿
• 수신자별 개별 발송
• 구독 해지 URL
• 발송 로그 보존
• SPF / DKIM / DMARC 정비

여기서의 핵심은 인원이 적어도 Bcc로 돌아가지 않는 것입니다. 50건 이하여도, 외부향 지속 발송이라면 이미 개별 발송 + 상태 관리 형태로 두는 편이 나중에 편합니다.

5.2 월 수회·수백 건

이 단계에 왔다면, 몇 가지를 더하는 편이 안정됩니다.

• 발송 큐
• 발송 속도 제어
• bounce 반영
• 구독 해지의 즉시 반영
• 발송 전용 서브도메인
• 승인 플로
  • 테스트 발송
  • 실제 발송
  • 결과 확인

또한 일상의 사람 메일과 판촉·안내 메일을 나누는 것이 중요합니다. Google은 메시지 종류마다 From 주소나 IP를 나누는 관점을 보이고 있고, Yahoo도 bulk / marketing과 transactional / alerts를 같은 IP나 DKIM 도메인에 섞지 말라고 안내합니다.³⁴

예를 들어 용도마다 주소를 나누는 것만으로도 운영이 꽤 정리됩니다.³⁴⁵

• 수주 확인·청구계: billing@example.com
• 장애 알림·유지보수 정보: notice@example.com
• 뉴스레터·안내: news@example.com

5.3 하루 수천 건에 가까워진다면

여기까지 오면 「특정 서비스를 쓰지 않는 것」 자체가 목적이 되기 쉽습니다.

Google은 Gmail 대상으로 하루 5,000통 초과 발송자에게 SPF / DKIM / DMARC, From 도메인 alignment, 원클릭 구독 해지 등의 요건을 명시하고 있습니다. Outlook도 하루 5,000통 초과 도메인에 SPF / DKIM / DMARC를 요구하고, 요건을 충족하지 않는 메시지는 스팸함으로 보내지거나 거부 대상이 될 수 있다고 안내합니다.³⁵

이 규모가 되면 운영의 주제도 바뀝니다.

• IP 평판
• 신고율
• bounce율
• 구독 해지 처리
• 볼륨을 늘리는 방법
• 감시

이 단계라면 전용 서비스를 쓰는 편이 저렴한 경우도 많습니다.

즉 이 글의 결론은 「어느 규모여도 전부 자체로 해야 한다」가 아니라, 수십~수백 건 규모라면, 상태와 규칙을 자사에서 가진 작은 발송 기반이 알맞다는 것입니다.

6. 법무와 발송 품질에서 최소한 빼놓을 수 없는 것

6.1 동의

광고·홍보 메일은 원칙적으로 사전 동의가 필요합니다. 스팸메일상담센터의 정리에서도, 사전 승낙 없이 광고 홍보 메일을 보내는 것은 원칙적으로 불가라고 되어 있습니다.²

또한 Google도 Yahoo도 수신자가 명시적으로 원한 메일만 보낼 것, 구매 리스트를 쓰지 말 것, 자동 체크된 opt-in을 피할 것을 요구합니다.³⁴

실무에서 최소한 남기고 싶은 것은 이 정도입니다.

• 동의 시각
• 동의 취득 경로
• 어떤 발송인지
• 설명 문구
• 동의를 받은 화면 또는 문구

덧붙여 법률상으로는, 홈페이지에 공개된 사업용 주소로의 발송에 예외 규정이 있습니다. 다만 그 예외에 의존해 발송 기반을 만드는 것은 권하지 않습니다. 클레임, 도달률, 평판, 실제 반응률 중 무엇을 보더라도 오래가기 어렵기 때문입니다.²

6.2 표시 의무와 구독 해지

동의가 있는 상대에게 보내는 경우에도, 발송자에게는 표시 의무가 있습니다. 스팸메일상담센터의 정리에서는 적어도 다음 정보가 필요합니다.²

• 발송자 등의 성명 또는 명칭
• 수신 거부 통지를 받을 메일 주소 또는 URL
• 수신 거부할 수 있다는 취지
• 발송자 등의 주소
• 불만·문의처

즉 푸터에 최소한 이것이 필요합니다.

발송자: 주식회사 ○○
구독 해지: https://example.com/unsubscribe/xxxxx
수신 정지를 원하시면 위 URL에서 절차를 진행해 주세요.
주소: 도쿄도...
문의: support@example.com

또한 주요 수신 측은 구독 해지의 쉬움을 꽤 중시합니다.

• Google: 대량 발송자에게는 원클릭 unsubscribe를 요구³
• Yahoo: List-Unsubscribe와 본문 링크, 2일 이내 반영을 요구 / 권장⁴
• Outlook: 찾기 쉽고 동작하는 unsubscribe를 권장⁵

그래서 최소한 본문에 보이는 링크, 가능하면 다음 헤더를 넣는 것이 자연스럽습니다.³⁴

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 인증과 도달률

주요 수신 측은 이미 「보낼 수 있는 것」이 아니라 「인증되어 있는 것」을 전제로 합니다.

Google의 공개 가이드라인에서는 다음이 요구됩니다.³

• 모든 발송자: SPF 또는 DKIM, PTR(forward / reverse 일치), TLS
• 대량 발송자: SPF + DKIM + DMARC, From 도메인 alignment
• 낮은 spam rate
• 대량 발송자에서는 one-click unsubscribe

Yahoo의 요건은 이렇습니다.⁴

• SPF / DKIM / DMARC
• DMARC alignment
• valid forward / reverse DNS
• unsubscribe
• spam rate 0.3% 미만
• opt-in
• bulk와 transactional의 분리

Outlook도 고볼륨 발송자용 요건을 내놓고 있습니다.⁵

• SPF pass
• DKIM pass
• DMARC(적어도 p=none, SPF 또는 DKIM과 alignment)
• 실제로 존재하는 From / Reply-To
• unsubscribe
• list hygiene

최소한의 운영 점검을 표로 하면 이렇게 됩니다.

Google은 발송량을 늘릴 때 낮은 볼륨부터, 반응이 좋은 상대에게, 일정한 페이스로 시작할 것을 권합니다. 갑작스러운 스파이크나 한 번에 배증하는 발송은 제한이나 reputation 저하의 원인이 되기 쉽습니다.³

7. 구현을 진행하는 방법

최소로 시작한다면, 순서는 이 정도가 현실적입니다.

1. 보내는 메일 종류를 나눈다
   • 알림 메일
   • 뉴스레터
   • 세미나 안내
   • 기존 고객용 안내
2. 구독 폼이나 동의 취득 플로를 만든다 홈페이지에서 설명문과 함께 받을 수 있게 합니다. 「무엇이, 어느 빈도로 도착하는지」가 보이는 문구로 하는 것이 중요합니다.⁴
3. 구독자 테이블과 suppression 테이블을 나눈다 여기를 먼저 나눠 두면, 나중에 무엇으로 갈아타도 운영이 무너지지 않습니다.
4. 발송 전용 도메인 / 서브도메인을 정한다 예를 들어 news.example.com이나 mail.example.com입니다. 적어도 일상의 수발주나 개인 메일박스와 책임을 섞지 않는 것입니다.³⁴
5. SPF / DKIM / DMARC / PTR / TLS를 갖춘다 자체 발송이라면 여기가 최우선입니다. reverse lookup이 되지 않는 환경을 발송 기반으로 두지 않는 것입니다.³⁴
6. 관리 화면은 작아도 되니 만든다 필요한 것은 화려한 UI가 아니라 다음 기능입니다.
   • 제목 편집
   • 본문 편집
   • 테스트 발송
   • 실제 발송
   • 발송 대상 미리보기
   • 배치 크기 설정
   • 결과 확인
7. 처음은 소량부터 보낸다 기존 고객이나 반응이 좋은 구독자로 좁혀, 일정한 페이스로 냅니다. 문제가 없으면 대상을 넓힙니다.³
8. 구독 해지와 bounce를 최우선으로 반영한다 오픈율보다 앞에서, 여기가 움직이는지를 확인합니다.

이 순서라면 「일단 보낼 수 있다」가 아니라 「사고 없이 계속할 수 있다」는 형태로 가져갈 수 있습니다.

7.1 다음에 찾아볼 키워드

사내에서 조사하거나 업체에 상담할 때, 그대로 검색어로 쓸 수 있는 말을 단계별로 늘어놓습니다.

이 가운데 먼저 손댈 것은 인증 설정입니다. 여기가 끝나지 않으면, 이후 작업을 아무리 정성스럽게 해도 도달하지 않습니다.

구독 폼, 동의 문구, 구독 해지 페이지 설계까지 포함해 다시 본다면, 홈페이지 제작과 함께 정리하면 진행하기 쉽습니다. 한편 기존 고객 명부나 사내 시스템, Windows 도구와 잇는 전제라면, 기술 상담·설계 리뷰에서 책임 분할부터 파고드는 편이 안전합니다.

8. 흔한 실패

흔한 실패는 대체로 이 근처입니다.

• 사람의 일상 메일과 판촉·안내 메일을 같은 발송원으로 돌린다
• 동의를 free text 메모만으로 관리한다
• 구독 해지를 메일 회신 수작업으로 한다
• 오래된 명함 리스트를 모아 흘려 넣는다
• 갑자기 과거 최대 볼륨으로 보내기 시작한다
• 알림 메일에 판촉 문구를 섞는다
• 발송 결과를 「발송 API가 성공했다」에서 멈춘다
• 기존 고객 명부보다 suppression 테이블이 약하다

특히 마지막은 정말 사고가 나기 쉽습니다.

영업 쪽 Excel에 주소가 남아 있다. 하지만 그 사람은 뉴스레터를 이미 해지했다. 이때 해지 정보가 항상 이긴다는 규칙으로 두지 않으면, 다른 경로에서 몇 번이고 재발송됩니다.

9. 정리

중소기업이 특정 서비스를 쓰지 않고 꽤 많은 인원에게 메일을 보내고 싶다면, 생각할 것은 「어느 버튼을 누를까」가 아닙니다.

정말 필요한 것은 다음 5점입니다.

• Bcc 일괄 발송이 아니라 수신자별 개별 발송
• 구독자 테이블과 suppression 테이블
• 구독 해지를 자동으로 받는 동선
• SPF / DKIM / DMARC / PTR / TLS
• 알림계와 판촉계를 나누는 운영

결국 발송 수단을 갖는 것보다, 발송 규칙을 갖는 것이 먼저입니다.

수십~수백 건/회 정도라면 전용 서비스 없이도 충분히 돌릴 수 있습니다. 다만 그 경우에도 「메일 소프트웨어로 한꺼번에 보낸다」가 아니라 작은 발송 기반으로 설계하는 것이 지름길입니다.

관련 기사

• 문의가 오지 않는 사이트에서 먼저 고쳐야 할 세 곳
• 글과 서비스 페이지를 어떻게 잇는가 - 내부 링크 설계의 기본

참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

안내 메일을 Bcc로 모아 한꺼번에 보내면 안 되나요?

외부 고객이나 잠재 고객에게 계속 보내는 구조의 토대로는 약합니다. Bcc는 보내는 것 자체는 되지만, 구독 해지를 따라갈 수 없고, bounce 관리가 없으며, 동의 기록이 없고, 발송 속도를 제어할 수 없으며, 담당자 의존이 되는 등 운영의 본체를 하나도 갖지 못합니다. 인원이 조금 늘어난 순간에 수작업 운영이 무너집니다. 사내 연락이나 단발 관계자 연락이라면 성립할 때도 있지만, 외부향 지속 발송이라면 수신자별 개별 발송과 상태 관리 형태로 가야 합니다.

광고·안내 메일을 보내는 데 동의가 필요한가요?

광고·홍보 메일은 원칙적으로 사전 동의가 필요합니다. 스팸메일상담센터의 정리에서도, 사전 승낙 없이 광고 홍보 메일을 보내는 것은 원칙적으로 불가라고 되어 있습니다. Google도 Yahoo도, 수신자가 명시적으로 원한 메일만 보낼 것, 구매 리스트를 쓰지 말 것을 요구합니다. 실무에서는 동의 시각, 동의 취득 경로, 어떤 발송인지, 설명 문구를 기록으로 남겨야 합니다. 홈페이지에 공개된 사업용 주소에 대한 예외 규정은 있지만, 그에 의존한 발송 기반은 권하지 않습니다.

메일이 스팸으로 판정되지 않으려면 최소한 무엇이 필요한가요?

발송 도메인 인증입니다. 구체적으로는 SPF/DKIM/DMARC 설정, reverse PTR을 조회할 수 있는 발송 환경, TLS, 실제로 존재하고 회신을 받을 수 있는 From/Reply-To, 본문의 구독 해지 링크와 List-Unsubscribe 헤더, opt-in만의 리스트 품질입니다. Google은 Gmail 대상으로 하루 5,000통을 넘는 발송자에게 SPF+DKIM+DMARC와 원클릭 구독 해지를 요구하고, Yahoo는 spam rate 0.3% 미만 등을 요구합니다. 또한 발송량을 늘릴 때는 낮은 볼륨부터 일정한 페이스로 시작해야 합니다.

뉴스레터 발송 서비스를 쓰지 않고 자체적으로 발송 기반을 만들 수 있나요?

수십~수백 건/회 규모라면 충분히 가능합니다. 핵심은 구독자 데이터, 발송 규칙, 발송자 identity(도메인·인증·구독 해지 URL)를 자사 쪽에 두고, SMTP 릴레이라는 출구만 나중에 갈아끼울 수 있는 구성으로 하는 것입니다. 중심은 SMTP가 아니라 구독자 테이블·suppression 테이블·발송 큐입니다. 다만 하루 수천 건에 가까워지면 IP 평판과 신고율 관리가 주제가 되므로, 전용 서비스를 쓰는 편이 저렴한 경우도 많아집니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.