직접 호스팅하면 Listmonk는 이미 비용을 내고 있는 VPS에서 실행됩니다. 발송 비용은 SMTP 릴레이가 1,000통당 청구하는 금액만큼만 듭니다. 구독자 수가 늘어도 두 비용 모두 달라지지 않습니다. 관리형 무료 플랜의 한계를 넘어서는 순간, 설정에 드는 시간을 감수할 만큼 직접 호스팅이 가치 있어지는 구조적 변화가 바로 이것입니다.
Listmonk는 Go로 작성된 오픈소스 뉴스레터 관리 도구입니다. VPS와 SMTP 릴레이 계정 비용만으로 구독자, 리스트, 캠페인을 무제한 사용할 수 있습니다. 명령어를 입력하기 전에 한 가지를 분명히 해 두어야 합니다. Listmonk는 실제 발송을 제외한 모든 것을 처리합니다. 이메일이 받은편지함에 도착할지 스팸함으로 갈지는 여러분이 설정하는 SMTP 릴레이와 발송 도메인에 등록하는 DNS 레코드가 결정합니다.
이 가이드에서 다루는 내용
- HTTPS를 적용한 Nginx(또는 Caddy) 리버스 프록시 뒤에서 Docker Compose로 Listmonk와 PostgreSQL 배포하기
- 발송량과 예산에 맞는 SMTP 릴레이 고르기(Amazon SES, Postmark, Brevo 등)
- 발송 도메인에 SPF, DKIM, DMARC 설정하기
- 명확한 오류 없이 발생하는 경우가 많은 네 가지 운영 장애 모드 피하기
- 예상 소요 시간: VPS와 도메인이 준비되어 있다면 30분
- 다루지 않는 내용: 드립 자동화, 트랜잭션 이메일, 다중 인스턴스 구성(FAQ 참고)
Listmonk가 적합하지 않은 경우
Listmonk는 특정 상황에 딱 맞는 답입니다. 상황이 다르다면 더 나은 답이 있습니다.
월 발송량이 약 10K 미만인 경우. 이 규모에서는 Brevo나 Mailchimp의 관리형 무료 플랜이 VPS와 SMTP 릴레이를 합친 비용보다 전체적으로 더 저렴할 수 있습니다. 직접 호스팅은 그 구간을 넘어서야 비로소 이득이 되기 시작합니다. 배포하기 전에 실제 구독자 수와 발송 빈도를 기준으로 숫자를 따져 보세요.
비기술 팀. Mailchimp와 Brevo는 터미널을 다루지 않는 사람들을 위해 정말로 더 나은 UI를 제공합니다. Listmonk는 팀 내 누군가가 서버에 SSH로 접속하고, Docker 로그를 읽고, DNS 전파를 해석할 수 있다고 전제합니다. 그런 사람이 없다면 관리형 서비스가 올바른 선택입니다.
자동화 워크플로가 필요한 경우. Listmonk는 캠페인을 발송합니다. 드립 시퀀스, 행동 기반 트리거 이메일, 시각적 워크플로 빌더는 지원하지 않습니다. 그런 기능이 필요하다면 Mautic 를 실행하거나 Listmonk를 n8n에 연결해 자동화 계층을 구성하세요.
GDPR이 민감한 구독자 리스트. 구독자가 주로 EU에 있거나 리스트가 GDPR 데이터 거주지 규칙의 적용을 받는다면 Listmonk를 유럽 데이터센터에서 실행하세요. Cloudzy는 EU 거주지 요건을 충족하는 프랑크푸르트와 런던 지역을 제공합니다.
시작하기 전에 필요한 것
Listmonk와 PostgreSQL, 그리고 적당한 큐 작업 부하를 합치면 최소 2 GB RAM이 필요합니다. 4 GB가 안정적인 운영 목표치입니다.
하드웨어. 월 50K 미만의 개인용 리스트라면 vCPU 2개, 4 GB RAM, 120 GB NVMe 저장소를 갖춘 VPS면 충분합니다. 월 200K 이상으로 늘어나는 리스트는 vCPU 4개와 8 GB RAM이 필요합니다. 저희는 이 Compose 구성을 프랑크푸르트의 4 GB VPS에서 운영합니다. 가능하면 구독자와 가까운 지역을 고르세요. 발송 지연은 크게 중요하지 않지만, 관리 패널의 반응 속도는 중요합니다.
도메인. A 레코드로 VPS를 가리키는 도메인. 관리자 인터페이스용으로는 서브도메인을 사용하세요. 예를 들면 mail.example.com입니다. 발송 도메인과 관리자 서브도메인은 같은 루트 도메인을 써도 됩니다.
SMTP 릴레이 계정. 아직 만들지 마세요. 릴레이 선택은 이 가이드에서 가장 중요한 결정이며 발송량에 따라 달라집니다. 아래 "SMTP 릴레이 선택하기" 섹션으로 건너뛰어 제공업체를 고른 다음, SMTP 호스트, 포트, 사용자 이름, 비밀번호를 손에 들고 여기로 돌아오세요.
VPS에 설치할 소프트웨어. Ubuntu 22.04 LTS 또는 24.04 LTS. Docker Compose 플러그인을 포함한 Docker Engine 24.0 이상. 포트 22, 80, 443이 열린 UFW 또는 동등한 방화벽. root가 아닌 sudo 사용자로 SSH 접속.
Docker Compose로 Listmonk 배포하기
배포용 디렉터리를 만든 다음, 두 개의 서비스를 담은 docker-compose.yml 파일을 작성합니다. 데이터베이스용 postgres와 애플리케이션용 listmonk입니다. 둘 다 실패 시 재시작합니다. Listmonk는 127.0.0.1 에 바인딩되므로 리버스 프록시만이 접근할 수 있습니다.
Docker Compose 파일
주어진 문장이 완전하지 않습니다. 번역할 전체 텍스트를 제공해주세요. docker-compose.yml. 정확한 이미지 태그와 환경 변수 이름은 공식 Listmonk 설치 문서와 대조해 확인하세요. 릴리스마다 바뀝니다.
# docker-compose.yml
services:
postgres:
image: postgres:16-alpine
container_name: listmonk-postgres
restart: unless-stopped
environment:
POSTGRES_USER: listmonk
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: listmonk
volumes:
- listmonk-postgres:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U listmonk"]
interval: 10s
timeout: 5s
retries: 6
app:
image: listmonk/listmonk:latest
container_name: listmonk-app
restart: unless-stopped
# Bind to loopback only. The reverse proxy is the public entrypoint.
ports:
- "127.0.0.1:9000:9000"
depends_on:
postgres:
condition: service_healthy
environment:
LISTMONK_app__address: "0.0.0.0:9000"
LISTMONK_db__host: postgres
LISTMONK_db__port: 5432
LISTMONK_db__user: listmonk
LISTMONK_db__password: ${POSTGRES_PASSWORD}
LISTMONK_db__database: listmonk
volumes:
listmonk-postgres:
만들기 .env 파일이 포함된 POSTGRES_PASSWORD= 를 길고 무작위인 문자열로 설정합니다. 그런 다음 스택을 시작하고 1회성 데이터베이스 설치를 실행합니다:
# Pull images and start the database first
docker compose up -d postgres
# Run the install step (creates schema and the first admin user)
docker compose run --rm app ./listmonk --install --idempotent --yes
# Start the application
docker compose up -d
현재 --install 명령은 관리자 이메일과 비밀번호를 묻습니다. 저장해 두세요. 두 컨테이너가 모두 실행 중인지 확인합니다:
docker compose ps
예상 출력: 두 개의 서비스가 표시되고 둘 다 Up 상태입니다. postgres 행에는 (healthy)가 표시되어야 합니다.
현재 127.0.0.1:9000 바인딩은 의도적입니다. Listmonk에는 내장된 인증 속도 제한기도, IP 허용 목록 기능도 없습니다. 포트 9000을 공개 인터넷에 노출하면 전 세계 누구나 여러분의 관리자 로그인에 접근할 수 있다는 뜻입니다. 리버스 프록시는 그 로그인을 HTTPS로만 접근 가능하게 만드는 역할을 합니다.
Nginx 리버스 프록시와 SSL
Ubuntu 저장소에서 Nginx와 Certbot을 설치합니다. Listmonk가 올바른 캠페인 링크를 생성하는 데 필요한 프록시 헤더와 함께 /etc/nginx/sites-available/listmonk 에 사이트 설정을 만듭니다:
# /etc/nginx/sites-available/listmonk
server {
listen 80;
server_name mail.example.com;
location / {
proxy_pass http://127.0.0.1:9000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Listmonk streams campaign progress over WebSocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
sites-enabled로 심볼릭 링크를 걸고, 설정을 테스트하고, Nginx를 리로드한 다음, 인증서를 발급받습니다:
sudo ln -s /etc/nginx/sites-available/listmonk /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d mail.example.com
Certbot은 server 블록을 443에서 새 인증서로 수신하도록 다시 작성하고 HTTP에서 HTTPS로의 리다이렉트를 추가합니다. 확인하세요:
curl -I https://mail.example.com
예상 출력: 유효한 strict-transport-security 헤더가 포함된 HTTP/2 200. 리다이렉트 루프가 발생한다면 위 Nginx 설정에서 X-Forwarded-Proto 헤더가 설정되어 있는지 확인하세요. 열에 아홉은 그 헤더가 원인인 루프입니다.
이 VPS에 Listmonk만 운영한다면 Caddy를 대신 사용하세요. Caddyfile은 세 줄이면 되고, cron 작업 없이 인증서 갱신을 처리합니다:
mail.example.com {
reverse_proxy 127.0.0.1:9000
}
Message-ID 헤더 수정하기
기본적으로 Listmonk는 발신 Message-ID 헤더에 시스템 호스트명을 사용합니다. VPS 호스트명이 localhost이거나 유효한 FQDN이 아닌 것이라면 Listmonk는 이런 값을 보냅니다: Message-ID: <[email protected]>. Gmail과 Outlook의 스팸 필터가 이를 즉시 표시합니다. 이 내용은 다음에 기록되어 있습니다: Cloudron 포럼 스레드 15410.
해결책은 Listmonk의 다음 파일에서 한 줄입니다: config.toml. 새로 설치한 경우, 다음 명령으로 파일을 생성하세요: docker compose run --rm app ./listmonk --new-config. 그런 다음 설정합니다:
[app]
hostname = "mail.example.com"
편집 후 앱 컨테이너를 재시작합니다:
docker compose restart app
캠페인을 한 통이라도 보내기 전에 이 작업을 하세요. 다음 값으로 오염된 리스트는 localhost.localdomain Message-ID로 오염된 리스트는 처음부터 깨끗하게 시작한 리스트보다 복구하기가 더 어렵습니다.
전문가 팁
Compose 설정을 건너뛰고 싶다면 원클릭 Listmonk VPS 를 확인해 단 몇 분 만에 클릭 한 번으로 Listmonk를 배포하세요. 인스턴스에는 PostgreSQL이 사전 구성되어 있습니다. 여전히 SMTP 릴레이를 설정하고 DNS 레코드를 추가해야 합니다. 어떤 방식으로 배포하든 그 단계들은 선택 사항이 아닙니다.
SMTP 릴레이 선택하기
모든 발송은 여러분이 설정하는 릴레이를 통해 이루어집니다. 릴레이의 IP 평판, 속도 제한, 반송 처리 방식이 이메일이 받은편지함에 도착할지 스팸함으로 갈지를 결정합니다.
기능 비교는 다음과 같습니다. 가격과 무료 플랜 한도는 바뀝니다. 결정하기 전에 각 제공업체의 공식 가격 페이지에서 확인하세요.
| 제공업체 | 비용 구조 | 반송 웹훅 | 적합한 용도 |
|---|---|---|---|
| Amazon SES | 이메일당 과금, 대량일 때 매우 저렴 | 예, SNS를 통해 | 대량 발송 시 비용 절감; 이미 AWS 사용 중 |
| Postmark | 월 기본료에 이메일당 과금 추가 | 예, 기본 제공 | 도달성 우선; 트랜잭션 평판 |
| Brevo | 소량은 무료 플랜, 그 이상은 유료 플랜 | 지원 | 업그레이드 경로가 있는 소량 발송 |
| Mailgun | 이메일당 과금 | 기본 웹훅 엔드포인트 없음; 필요하면 범용 반송 API 사용. | 개발자에게 익숙함 |
지금까지는 각 SMTP 릴레이를 간단히 살펴본 것입니다. 이제 각각을 자세히 다루겠습니다.
Amazon SES(권장 시작 지점)
SES는 대량 발송 시 가장 저렴한 선택지이며 Listmonk 커뮤니티에서 가장 많이 논의됩니다. 설정 단계는 Postmark나 Brevo보다 많지만, 이메일당 비용 차이가 어느 정도 실질적인 발송량에서든 그 작업을 정당화할 만큼 큽니다.
세 단계로 설정합니다. 첫째, AmazonSESFullAccess 정책(또는 ses:SendRawEmail 및 ses:GetSendQuota만 허용하는 더 엄격한 사용자 지정 정책)으로 IAM 사용자를 만듭니다. 둘째, SES 콘솔에서 발송 도메인을 인증합니다. SES가 추가할 DKIM CNAME을 안내해 줍니다. 셋째, SES SMTP 설정 패널에서 SMTP 자격 증명을 생성합니다. 이것은 AWS 액세스 키가 아닙니다. "Create SMTP credentials"를 클릭하면 SES가 SMTP 전용 사용자 이름과 비밀번호를 별도로 생성합니다.
Listmonk 관리자의 Settings → SMTP에서 다음과 같이 새 서버를 추가합니다:
- 호스트:
email-smtp.<region>.amazonaws.com(도메인을 인증한 SES 지역을 사용하세요) - 포트: 587
- 인증 프로토콜: LOGIN
- TLS: STARTTLS
- 사용자 이름과 비밀번호: SES가 생성한 SMTP 자격 증명
SES는 포트 587에서 STARTTLS를 요구합니다. TLS를 none으로 두거나 포트 465를 선택하면, Listmonk는 연결되고, SES는 530 Must issue a STARTTLS command first를 반환하며, 관리 패널의 SMTP 자격 증명 테스트는 그래도 성공으로 표시될 수 있습니다. 캠페인을 실행하기 전에 직접 관리하는 개인 받은편지함으로 실제 테스트 이메일을 보내세요.
새 SES 계정은 샌드박스 모드로 시작합니다. 샌드박스에서는 인증된 이메일 주소로만 발송할 수 있는데, 이는 구독자 리스트에는 쓸모가 없습니다. SES 콘솔에서 지원 티켓을 열어 프로덕션 액세스를 요청하세요. 승인은 보통 영업일 기준 하루가 걸립니다.
Postmark(도달성 우선 대안)
Postmark는 SES보다 이메일당 비용이 더 들지만 기본 반송 웹훅을 지원하고, 엄격한 발신자 정책으로 높은 받은편지함 도달률이라는 평판을 갖고 있습니다. 뉴스레터가 사업에 필수적이거나 SES의 샌드박스에서 프로덕션으로 넘어가는 승인을 관리하고 싶지 않다면 그만한 값을 합니다.
Listmonk 설정 형태는 SES와 같습니다. 호스트, 포트 587, STARTTLS, 그리고 Postmark 서버의 API 토큰 패널에서 받은 자격 증명입니다. Postmark의 서명 설정에서 발송 도메인을 인증하고, Postmark가 생성하는 DKIM 레코드를 추가하면 발송 준비가 끝납니다.
이메일당 비용보다 도달성이 더 중요하면 Postmark를 고르세요. 발송량이 부가적인 지원보다 더 중요하면 SES를 고르세요.
SMTP 자격 증명 테스트에 대한 경고. Listmonk 관리자의 연결 테스트는 자격 증명이 유효하지 않아도 항상 성공으로 보고합니다. 이는 몇몇 GitHub 이슈에 기록되어 있습니다. 그것을 믿지 마세요. 어떤 릴레이든 설정한 뒤에는 단일 테스트 구독자에게 캠페인을 보내고 전체 리스트로 발송하기 전에 대상 받은편지함에서 수신을 확인하세요.
대량 캠페인 발송에는 Mailersend를 피하세요. 연결당 이메일 5통 제한이 421 Service not available 오류를 일으키는데, Listmonk는 전송이 실패했는데도 이를 발송됨으로 기록합니다. 캠페인은 Listmonk에서 성공한 것처럼 보이지만 경고 없이 대부분의 메시지를 누락합니다.
이메일을 실제로 도착하게 만들기: SPF, DKIM, DMARC
이것들은 발송 도메인에 등록하는 세 개의 DNS 레코드로, 여러분의 도메인이 이 릴레이가 대신 발송하도록 승인했음을 수신 메일 서버에 알립니다. 이 중 하나라도 빠뜨리면 릴레이나 본문이 아무리 깨끗해도 발송량이 많아질수록 상당한 비율이 스팸함에 도착합니다. 첫 캠페인을 보내기 전에 DNS 제공업체에서 이것들을 추가하세요.
SPF 레코드
SPF는 여러분의 도메인을 위해 이메일을 발송할 수 있는 특정 IP나 발송 서비스를 승인합니다. 발송 도메인의 루트에 릴레이용 include를 담은 TXT 레코드 하나를 추가하세요. SES의 경우 레코드는 다음과 같습니다:
v=spf1 include:amazonses.com ~all
Postmark의 경우 include를 include:spf.mtasv.net로 바꾸세요. 정확한 include 값은 항상 릴레이의 공식 SPF 문서에서 확인하세요. 제공업체마다, 때로는 지역마다 달라집니다.
도메인에는 SPF 레코드가 하나만 있을 수 있습니다. 다른 서비스(Google Workspace, Microsoft 365)를 위한 SPF 레코드가 이미 있다면, 두 번째 레코드를 추가하지 말고 기존 레코드에 include를 병합하세요.
DKIM
DKIM은 발신 이메일에 암호화 서명을 첨부하고, 수신 서버는 이를 여러분의 DNS에 있는 공개 키로 검증합니다. 키 쌍은 릴레이가 생성합니다. 여러분은 공개 키를 선택자 서브도메인(예: sel1._domainkey.example.com)에 TXT 레코드로, 릴레이가 알려준 정확한 값으로 추가합니다.
Listmonk는 DKIM 서명을 처리하지 않습니다. 릴레이가 처리합니다. Listmonk 고유의 DKIM 설정은 없습니다. 릴레이의 DKIM 설정 마법사를 따라 알려주는 레코드를 추가하고 DNS 전파를 기다리세요(보통 30분 이내, 때로는 몇 시간).
DMARC
DMARC는 SPF나 DKIM 검사에 실패한 이메일을 어떻게 처리할지 수신 서버에 알려줍니다. 먼저 다음 값으로 p=none 모니터링 모드에서 시작해, 설정 오류를 바로잡는 동안 도달성에 영향을 주지 않으면서 집계 보고서에서 실패를 확인할 수 있게 하세요. 다음 위치에 TXT 레코드를 추가합니다: _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:[email protected]
2~3주 동안 보고서가 깨끗하면 정책을 다음으로 강화하세요: p=quarantine or p=reject. 모니터링 단계를 건너뛰지 마세요. SPF include의 오타가 첫날부터 다음과 p=reject 결합되면, 무언가 잘못되었다는 신호 하나 없이 여러분 자신의 정상적인 이메일이 모두 차단됩니다.
List-Unsubscribe 헤더(RFC 8058)는 Listmonk가 자동으로 생성합니다. Settings → General에서 활성화되어 있는지 확인하세요. Gmail과 Apple Mail은 이 헤더를 원클릭 구독 취소 옵션으로 표시하며, 이는 발신자 평판을 보호합니다.
실제 운영에서 무엇이 문제가 되는가
첫 실제 캠페인을 보내기 전까지는 드러나지 않는 네 가지 장애 모드입니다. 구독자보다 먼저 잡아내세요.
문제 1: 반송률이 릴레이의 수치와 일치하지 않는다. Listmonk는 지정된 반송 이메일 주소를 POP3로 읽고 읽은 모든 메시지를 삭제하는 방식으로 반송을 처리합니다. 여기에는 휴가 자동 응답, 수신 확인, 부재중 알림까지 포함되어 모두 반송으로 분류됩니다. 릴레이는 수신자 메일 서버가 반환한 실제 전송 실패만 집계합니다. SES가 0.6%로 보고하는데 Listmonk가 4%로 보고한다면, 바로 이 차이입니다. 해결책은 POP3 대신 반송 웹훅 콜백을 설정하는 것입니다. SES는 SNS를 사용해 반송 알림을 Listmonk의 웹훅 엔드포인트로 전달하세요. Postmark는 기본 웹훅을 같은 엔드포인트로 향하게 하세요. 웹훅 반송은 정확하고, POP3 반송은 부풀려집니다.
문제 2: SMTP 자격 증명 테스트가 잘못되었는데도 성공이라고 한다. 릴레이 섹션에서 언급했듯, 연결 테스트는 자격 증명 유효성과 무관하게 항상 성공으로 보고합니다. 그것을 믿지 마세요. 어떤 SMTP 설정이든 구성하거나 변경한 뒤에는 항상 실제 테스트 이메일을 보내세요.
문제 3: 캠페인이 오류 없이 발송 중에 멈춘다. Listmonk는 구독자의 60%만 이메일을 받았어도 캠페인을 Finished로 표시합니다. 나머지 발송은 릴레이가 거부했거나 VPS 네트워크 계층에서 스로틀링된 것인데, Listmonk는 그 어느 것도 캠페인 수준의 오류로 드러내지 않습니다(Cloudron 포럼 스레드 13165). 캠페인이 구독자보다 적은 발송 건수를 표시하면, 해당 발송 시간대의 릴레이 대시보드를 열어 릴레이의 수락 건수와 Listmonk의 건수를 비교하세요. 진실은 릴레이에 있습니다.
문제 4: 아무도 PostgreSQL을 백업하지 않는다. Compose 볼륨은 재시작 사이에 데이터를 유지합니다. 호스트 장애, 실수로 인한 docker volume rm, 손상된 업그레이드로부터는 보호해 주지 않습니다. 매일 실행되는 pg_dump를 추가하세요:
0 2 * * * docker exec listmonk-postgres pg_dump -U listmonk listmonk > /backups/listmonk-$(date +\%Y\%m\%d).sql
먼저 이 줄을 직접 한 번 실행하세요. cron 항목을 신뢰하기 전에 출력 파일이 비어 있지 않은지 확인하세요. 오류를 일으키지 않으면서 0바이트 파일을 쓰는 백업 스크립트는 아예 백업이 없는 것보다 더 나쁩니다. 백업에 대해 더는 신경 쓰지 않게 되기 때문입니다.
이 모든 것을 운영 환경에서 신뢰하기 전에, 구독자 한 명에게 테스트 캠페인을 보내고 대상 받은편지함에서 수신을 확인하세요. 그 한 통의 이메일이 깔끔하게 도착하면, 다음 1만 통도 그럴 것입니다.
자주 묻는 질문
Listmonk 반송률이 Amazon SES 보고치보다 높은 이유는 무엇인가요?
Listmonk의 POP3 반송 처리는 부재중 응답과 휴가 자동 응답을 반송으로 읽어 들여 집계를 부풀립니다. 정확한 집계를 위해 SES SNS 웹훅 콜백을 설정하세요.
Listmonk는 트랜잭션 이메일을 지원하나요?
Listmonk는 뉴스레터와 브로드캐스트 캠페인 도구입니다. 트랜잭션 이메일(비밀번호 재설정, 주문 확인, 일대일 트리거 이메일)을 기본으로 처리하지는 않습니다. 같은 발송 도메인에서 트랜잭션 이메일을 보내려면, 릴레이의 트랜잭션 엔드포인트를 별도로 설정하거나 Postal 또는 Postmark의 트랜잭션 API 같은 전용 도구를 Listmonk와 함께 사용하세요.
Mailchimp 구독자를 Listmonk로 가져오려면 어떻게 하나요?
Audience → Export Audience에서 Mailchimp 리스트를 CSV로 내보내세요. Listmonk에서 Subscribers → Import로 이동해 CSV를 업로드합니다. 안내가 나오면 이메일과 이름 열을 매핑하세요. Listmonk는 Mailchimp, ConvertKit을 비롯한 대부분의 뉴스레터 플랫폼의 표준 CSV 내보내기를 형식 변환 없이 받아들입니다.
누군가 Listmonk 캠페인 구독을 취소하면 어떻게 되나요?
Listmonk는 기본적으로 모든 캠페인 이메일에 구독 취소 링크를 추가합니다. 구독자가 이를 클릭하면 차단 목록에 추가되고 이후 모든 캠페인에서 제외됩니다. List-Unsubscribe 헤더(RFC 8058)가 자동으로 포함되므로, 원클릭 구독 취소를 지원하는 메일 클라이언트(Gmail, Apple Mail)는 이를 기본으로 표시합니다. 구독자 기록은 감사 목적으로 데이터베이스에 남지만 이후 캠페인은 발송되지 않습니다.
