가이드

작성자 Matt Connor 2026-08-18 · 업데이트됨 2026-08-21

VPS에 Mailpit으로 일회용 이메일 서버 구축하기

Q: How do I stop the inbox filling the disk?

Keep MP_MAX_MESSAGES at a real number and add MP_MAX_AGE. The default cap is 500 messages, and setting it to 0 disables deletion entirely, which is how a catch-all with attachments grows quietly. MP_MAX_AGE accepts hours or days, such as 36h or 14d. Clear the store in CI teardown with curl -X DELETE http://127.0.0.1:8025/api/v1/messages. Inbucket does the same job with INBUCKET_STORAGE_RETENTIONPERIOD (72h) and INBUCKET_STORAGE_MAILBOXMSGCAP (300).

Docker Compose와 Mailpit을 사용하여 스테이징 환경의 메일 발송을 격리하는 방법을 설명합니다. 실제 고객에게 메일이 발송되는 사고를 방지하고 웹 UI에서 테스트 메일을 확인하는 최적의 구성법을 안내합니다.

일회용 이메일 수신함이란 무엇인가

일회용 이메일 수신함은 모든 주소로 오는 메일을 수신하되 실제로는 아무 곳으로도 전달하지 않는 소규모 SMTP(Simple Mail Transfer Protocol) 서버입니다. 스테이징 애플리케이션은 실제 메일 제공업체 대신 이 서버로 메일을 보내며, 모든 메시지는 이곳에 머무릅니다. 웹 인터페이스를 통해 도착한 메일을 확인할 수 있으므로, 수신자 목록이 잘못되었거나 템플릿이 깨져 있더라도 메일이 외부로 나가지 않아 아무런 문제가 발생하지 않습니다.

이 가이드에서는 Docker Compose를 사용하여 단일 VPS에 이를 구축합니다. Mailpit은 모든 메일을 받아내는 싱크(sink) 역할을 합니다. Mailpit의 SMTP 리스너는 애플리케이션만 접근할 수 있는 곳에 바인딩하고, 웹 인터페이스는 TLS(Transport Layer Security)와 비밀번호가 적용된 nginx 뒤에 배치하며, 보관 제한을 설정하여 메일함이 디스크를 가득 채우지 않도록 합니다. Compose 사용이 처음이라면 VPS를 위한 Compose 기초에서 이 가이드가 가정하는 파일 구조를 확인할 수 있습니다.

이 결과물은 테스트 도구일 뿐 메일 서버가 아닙니다. 계정 기능, 메일 전달 기능, 스팸 필터링 기능이 없습니다. 실제 사용자를 위한 메일함은 Mailcow와 같은 완전한 메일 서버가 필요하며, 이는 훨씬 더 큰 규모의 작업입니다.

Mailpit 대 Inbucket 대 MailHog: 어떤 싱크를 실행할 것인가

이 작업을 수행하는 도구는 세 가지가 있습니다. 이 도구들을 구분 짓는 요소는 유지보수 상태, 수신 대기 포트, 그리고 메시지 수신 후 처리 능력입니다. 아래 버전은 2026년 8월 기준으로 확인되었습니다.

MailHog(mailhog/mailhog)는 SMTP를 위해 1025 포트에서 대기하며 8025 포트로 인터페이스를 제공합니다. 여전히 작동은 합니다. 기본 브랜치는 2022년 8월 이후 커밋이 없으며, 이슈 트래커에는 250개가 넘는 미해결 이슈가 쌓여 있습니다. 따라서 이를 사용하면 테스트 경로에서 패치되지 않은 의존성을 실행하게 됩니다. 새로운 작업에 이 도구를 사용하지 마십시오.

Inbucket(inbucket/inbucket)은 SMTP를 위해 2500 포트, 웹 인터페이스를 위해 9000 포트, POP3(Post Office Protocol version 3)를 위해 1100 포트에서 대기합니다. 2025년 12월에 버전 3.1.1이 출시되었습니다. 메시지를 /storage 아래에 파일로 저장하며 자체적으로 삭제합니다. 이미지는 INBUCKET_STORAGE_RETENTIONPERIOD=72h 및 INBUCKET_STORAGE_MAILBOXMSGCAP=300를 설정합니다. 테스트 시 HTTP 호출 대신 POP3 클라이언트 라이브러리로 메일을 수집해야 할 때 이 도구를 선택하십시오.

Mailpit(axllent/mailpit)은 MailHog와 동일한 1025 및 8025 포트를 사용하므로 애플리케이션 설정을 변경하지 않고도 MailHog를 대체할 수 있습니다. 2026년 8월 8일에 버전 1.30.7이 출시되었습니다. 이 도구는 본 가이드에서 필요한 기능을 바이너리 내부에 포함하고 있습니다. 웹 인터페이스 및 API(Application Programming Interface)를 위한 비밀번호 파일, 메시지 개수 제한, 보관 기간 제한, 수신자 필터 기능이 이에 해당합니다. 이 가이드의 나머지 부분은 Mailpit을 기준으로 진행합니다.

Catch-all의 작동 방식과 DNS가 관여하지 않는 이유

애플리케이션은 여기서 메시지를 어디로 전달할지 조회하지 않습니다. 호스트와 포트를 지정하면 애플리케이션은 TCP 연결을 열고 RCPT TO:<anyone@example.test>을 알립니다. Mailpit은 수신자가 누구든 상관없이 이를 수락하여 메시지를 저장하며, 아무것도 전달하지 않습니다. 도메인 이름은 해석되지 않으므로, .test이 도메인 이름 시스템(DNS)상 어디에도 존재하지 않는 예약된 이름이라 할지라도 example.test은 정상적으로 작동합니다.

이것이 전체 메커니즘이며, 기본적으로 받은 편지함이 안전한 이유입니다. MX(mail exchanger) 레코드는 관여하지 않으며, 전달 시도도 이루어지지 않으므로 실제 사용자에게 메시지가 도달할 수 없습니다.

스테이징 애플리케이션을 싱크(sink)로 지정

애플리케이션이 동일한 Compose 프로젝트 내에서 컨테이너로 실행될 때는 SMTP 호스트를 mailpit로 설정하고, 호스트에서 직접 실행될 때는 127.0.0.1으로 설정합니다. 포트는 1025로 설정하고, TLS는 끄며, 사용자 이름과 비밀번호는 비워 둡니다. Mailpit은 익명 메일을 허용합니다.

일부 프레임워크는 자격 증명 없이는 메일 발송을 거부합니다. MP_SMTP_AUTH_ACCEPT_ANY=1을 사용하면 Mailpit이 모든 사용자 이름과 비밀번호를 수락하며, MP_SMTP_AUTH_ALLOW_INSECURE=1는 암호화되지 않은 연결에서 PLAIN 및 LOGIN 메커니즘을 허용합니다. 이 두 설정은 리스너가 인터넷에서 접근할 수 없는 환경에서만 안전하며, 아래의 배포 설정이 이를 강제합니다.

MP_SMTP_ALLOWED_RECIPIENTS은 초기부터 설정하는 것이 좋습니다. 이 설정은 정규 표현식을 사용하여 일치하지 않는 모든 수신자를 거부합니다. 테스트 도메인을 지정하면, 실제 고객 주소가 포함된 스테이징 데이터베이스를 사용하더라도 메일이 싱크에 조용히 쌓이는 대신 애플리케이션 로그에 명확한 실패 기록이 남게 됩니다.

Docker Compose 파일

먼저 웹 인터페이스를 위한 디렉터리와 비밀번호 파일을 생성합니다. htpasswd -B는 bcrypt 해시를 기록하며, Mailpit은 일반 텍스트와 bcrypt를 모두 읽을 수 있습니다.

mkdir -p ~/mailpit/data
cd ~/mailpit
sudo apt update && sudo apt install -y apache2-utils
htpasswd -B -c data/ui-auth qa

compose.yaml를 작성합니다:

services:
  mailpit:
    image: axllent/mailpit:v1.30
    container_name: mailpit
    restart: unless-stopped
    ports:
      - "127.0.0.1:8025:8025"
      - "127.0.0.1:1025:1025"
    volumes:
      - ./data:/data
    environment:
      MP_DATABASE: /data/mailpit.db
      MP_MAX_MESSAGES: 2000
      MP_MAX_AGE: 14d
      MP_UI_AUTH_FILE: /data/ui-auth
      MP_SMTP_AUTH_ACCEPT_ANY: 1
      MP_SMTP_AUTH_ALLOW_INSECURE: 1
      MP_SMTP_ALLOWED_RECIPIENTS: '@example\.test$$'

달러 기호를 두 번 쓴 것은 오타가 아닙니다. Compose는 단일 $을 변수 확장의 시작으로 읽기 때문에, $$을 사용해야 리터럴 달러 기호 하나를 컨테이너로 전달할 수 있습니다. 정규 표현식은 @example\.test$로 Mailpit에 전달됩니다.

서비스를 시작하고 상태를 확인합니다:

docker compose up -d
docker compose ps

STATUS 열은 Up ... (healthy)으로 표시되어야 합니다. 이미지 자체에 15초마다 /mailpit readyz을 실행하는 헬스체크가 포함되어 있으므로, 컨테이너가 starting 상태로 유지되거나 unhealthy으로 바뀐다면 컨테이너 내부의 8025 포트에서 서비스가 정상적으로 동작하지 않는 것입니다. 다른 설정을 변경하기 전에 docker compose logs mailpit를 읽어보십시오.

공개된 두 포트 모두 주소를 포함하며, 이 주소가 보안 제어의 핵심입니다. 컨테이너 내부에서 Mailpit은 0.0.0.0에서 수신 대기하는데, 컨테이너는 고유한 네트워크 네임스페이스를 가지므로 이는 문제가 되지 않습니다. 매핑의 왼쪽 부분은 외부에서 누가 접근할 수 있는지를 결정합니다. 8025:8025으로 작성하면 Docker는 공용 주소를 포함하여 호스트의 모든 주소에 바인딩합니다.

스테이징 앱이 동일한 파일 내의 서비스라면 1025 매핑을 완전히 삭제하고, 앱에서 호스트 이름 mailpit의 1025 포트를 가리키도록 설정하십시오. 공유 Compose 네트워크에 있는 컨테이너들은 서로 직접 통신할 수 있으므로, SMTP 포트를 호스트에 노출할 필요가 전혀 없습니다. Compose 네트워크가 서비스 이름을 확인하는 방법에서 해당 내용을 다룹니다.

메시지를 하나 발송하고 수신 여부 확인

python3 - <<'EOF'
import smtplib
from email.message import EmailMessage

m = EmailMessage()
m["From"] = "staging@example.test"
m["To"] = "anyone@example.test"
m["Subject"] = "Mailpit smoke test"
m.set_content("If this appears in the web interface, the sink works.")
with smtplib.SMTP("127.0.0.1", 1025) as s:
    s.send_message(m)
EOF

스크립트가 성공하면 아무것도 출력하지 않습니다. API를 통해 메시지가 저장되었는지 확인하십시오:

curl -s -u qa:yourpassword http://127.0.0.1:8025/api/v1/messages

그러면 저장된 메시지 목록이 JSON 형식으로 반환됩니다. -u 플래그를 제거하면 동일한 요청이 거부되는데, 이는 MP_UI_AUTH_FILE이 API와 웹 인터페이스를 모두 보호하기 때문입니다. 받은 편지함을 읽는 모든 테스트는 해당 자격 증명을 함께 전송해야 합니다.

Python 스크립트에서 ConnectionRefusedError이 발생한다면 127.0.0.1:1025에서 수신 대기 중인 서비스가 없다는 뜻입니다. SMTP 매핑을 제거했다면 이는 예상된 결과이며, 이 경우 동일한 Compose 네트워크 내의 컨테이너에서 확인 작업을 수행해야 합니다.

nginx를 통해 비밀번호로 웹 인터페이스 게시하기

현재 인터페이스는 루프백 주소에서만 응답합니다. nginx가 TLS를 종료하고, 요청이 도달하기 전에 비밀번호를 요구하도록 설정합니다.

sudo htpasswd -B -c /etc/nginx/mailpit.htpasswd qa

server {
    listen 443 ssl;
    server_name mail-test.example.com;

    ssl_certificate     /etc/letsencrypt/live/mail-test.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail-test.example.com/privkey.pem;

    auth_basic           "mailpit";
    auth_basic_user_file /etc/nginx/mailpit.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:8025;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo nginx -t && sudo systemctl reload nginx으로 구문 검사를 수행한 뒤 설정을 다시 불러옵니다. 프록시 설정이 처음이라면 리버스 프록시 블록의 각 지시어가 하는 일을 한 번 읽어보는 것이 좋습니다.

nginx 파일과 data/ui-auth에 동일한 사용자 이름과 비밀번호를 사용하십시오. nginx는 브라우저의 Authorization 헤더를 업스트림으로 전달하므로, 자격 증명을 일치시키면 한 번의 입력으로 두 검사를 모두 통과할 수 있습니다. 자격 증명이 다르면 브라우저는 첫 번째 세트를 유지하게 되고, 두 번째 검사에서 거부됩니다.

Upgrade 및 Connection 헤더는 장식이 아닙니다. Mailpit은 WebSocket을 통해 열려 있는 페이지로 새 메일을 푸시하는데, 해당 헤더 없이 HTTP/1.1로 실행되는 프록시는 연결을 업그레이드할 수 없습니다. 이 경우 페이지는 정상적으로 로드되지만 내용이 갱신되지 않습니다. 즉, 메일이 도착하고 API가 이를 확인하더라도 페이지를 새로 고치기 전까지 목록은 그대로 유지됩니다.

두 가지 잠금 장치를 모두 유지하십시오. nginx 비밀번호는 공용 주소를 보호하며, MP_UI_AUTH_FILE은 8025 포트 자체를 보호합니다. 스테이징 앱에서 생성된 모든 비밀번호 재설정 링크를 해당 인터페이스에서 읽을 수 있으므로 이는 매우 중요합니다.

싱크가 오픈 릴레이가 되지 않도록 방지하십시오

오픈 릴레이는 누구에게서나 메시지를 받아 임의의 목적지로 전달하는 SMTP 서버를 의미합니다. 스패머들은 끊임없이 오픈 릴레이를 탐색하며, 귀하의 주소에서 이를 발견할 경우 남용 보고서가 접수되고 계정이 정지될 수 있습니다.

Mailpit은 기본적으로 메시지를 전달하지 않으므로 오픈 릴레이로 동작하지 않습니다. MP_SMTP_RELAY_CONFIG를 릴레이 설정 파일로 지정하기 전까지는 릴레이 기능이 꺼져 있으며, 인터페이스의 릴레이 동작도 설정 전까지는 아무런 기능을 수행하지 않습니다. 해당 설정을 비워두는 것은 의도적인 선택입니다.

이러한 안전성을 잃는 방법은 두 가지입니다. 릴레이를 설정하여 릴레이 버튼이 작동하게 만든 뒤 SMTP 포트를 인터넷에 노출하면, 즉시 오픈 릴레이가 구축됩니다. 릴레이 설정 없이 포트만 노출할 경우 외부인이 메일을 발송할 수는 없지만, 저장 공간을 가득 채우거나 팀이 신뢰하는 인터페이스에 콘텐츠를 주입할 수 있습니다.

Docker 호스트에서 발생하는 함정은 방화벽입니다. 포트를 게시(publish)하면 Docker가 nat 테이블에 자체 규칙을 작성하며, 컨테이너로 향하는 트래픽은 ufw(uncomplicated firewall) 규칙이 적용되기 전에 해당 테이블에서 먼저 처리됩니다. sudo ufw deny 1025/tcp은 성공을 보고하지만 실제로는 아무것도 변경하지 않습니다. Docker가 ufw를 우회하여 포트를 게시하는 이유에서 체인 순서에 대한 상세 내용을 확인할 수 있습니다.

해결책은 방화벽 규칙이 아니라 매핑 주소에 있습니다. 실제로 어떤 주소에 바인딩되어 있는지 확인하십시오:

sudo ss -ltnp | grep -E ':(1025|8025)'

정상적인 출력은 127.0.0.1:1025 및 127.0.0.1:8025를 보여줍니다. 0.0.0.0:1025으로 표시되는 줄이 있다면 매핑 주소가 누락되어 싱크가 인터넷을 향해 리스닝하고 있다는 의미입니다. 다른 머신에서 nc -vz mail-test.example.com 1025를 실행했을 때 타임아웃이 발생하거나 거부되어야 합니다.

애플리케이션이 다른 서버에 있는 경우, 두 서버를 연결하기 위해 1025 포트를 개방하지 마십시오. 두 머신을 사설 네트워크나 VPN 터널에 배치하고, 해당 인터페이스 주소에 매핑을 바인딩하십시오.

실제 인바운드 메일을 수신하려면 MX 레코드만 게시하십시오

MX(mail exchanger) 레코드는 도메인으로 들어오는 메일을 수신할 호스트를 다른 메일 서버에 알립니다. 일회용 도메인에 MX 레코드가 없으면 인터넷에서 오는 메일을 받을 수 없습니다. 메일을 보내는 서버가 메일을 전달할 목적지를 찾지 못하기 때문입니다. 받은 편지함에는 테스트용 메일함의 목적에 맞게 애플리케이션이 직접 제출한 메일만 남게 됩니다.

실제 메일을 수신한다는 것은 MX 레코드가 해당 서버를 가리키고, Mailpit이 MP_SMTP_BIND_ADDR=0.0.0.0:25 포트에서 대기 중이며, 해당 포트가 개방되어 있다는 의미입니다. 이 순간부터 귀하는 해당 도메인의 모든 주소에 대해 공개적인 catch-all 서버를 운영하게 됩니다. 다음 사항을 명확히 인지하십시오.

DNS를 수집하는 봇들이 레코드를 읽기 때문에, 레코드를 게시한 지 며칠 지나지 않아 스팸이 시작됩니다. 사전 공격(dictionary attack)은 흔한 이름들을 대입하며 모든 시도에 대해 메시지를 저장합니다.
낯선 사람이 보낸 첨부 파일이 디스크에 저장되어 그대로 남습니다. 이를 필터링하는 장치가 없으므로, 알 수 없는 발신자가 보낸 아카이브가 귀하의 테스트 메일과 함께 쌓입니다.
도메인을 알아낸 사람은 누구나 해당 도메인의 주소로 타사 서비스에 가입할 수 있으며, 확인 메일이 귀하의 서버로 전달됩니다. 비밀번호 보안이 허술해지면 해당 계정은 받은 편지함을 읽는 사람의 소유가 됩니다.
메일 보관 기간 제한은 단순한 정리 작업이 아니라 시스템 부하를 결정짓는 요소가 됩니다. 수신되는 메일의 양을 귀하가 통제할 수 없기 때문입니다.

전달 가능성(deliverability) 확인을 위해 실제 인바운드 메일이 필요하다면 전용 서브도메인을 할당하고, MP_MAX_AGE을 짧게 유지하며, 그 안의 모든 데이터를 공개 정보로 취급하십시오. 사람들이 실제로 의존할 수 있는 메일함이 필요하다면 필터링과 백업 기능을 갖춘 정식 메일 서버를 운영하십시오.

Retention: how an unbounded catch-all fills the disk

Mailpit keeps 500 messages by default and periodically deletes the oldest beyond that. MP_MAX_MESSAGES: 0 turns automatic deletion off completely, and that one change is how a catch-all fills a disk with nobody noticing. MP_MAX_AGE adds a time limit and takes hours or days, written as 36h or 14d.

MP_DATABASE decides whether any of this survives. Without it, Mailpit writes to a temporary file that is deleted when the process exits, so every restart empties the inbox. With it, the mail survives restarts and the file grows.

Attachments are what consume the space. A nightly job that mails a 2 MB PDF report to 300 test addresses is 600 MB per night, and a message count cap alone will not react in time. Budget that growth against whatever else shares the volume, because a media heavy neighbour such as PhotoPrism or Immich will already have claimed most of a small VPS disk.

du -h ~/mailpit/data/mailpit.db
df -h /

Empty the store between CI runs rather than waiting for a cap to trigger:

curl -s -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messages

Inbucket handles the same problem with INBUCKET_STORAGE_RETENTIONPERIOD (72h in the image) and INBUCKET_STORAGE_MAILBOXMSGCAP (300). Whichever you run, pick the limit before the first test suite points at it.

테스트 스위트에서 받은 편지함 읽기

GET /api/v1/messages는 저장된 항목을 나열하고, GET /api/v1/message/{ID}는 메시지 하나를 그 구성 요소 및 헤더와 함께 반환하며, GET /api/v1/search은 필터링을 수행하고, DELETE /api/v1/messages은 저장소를 비웁니다. 현재 실행 중인 버전에 대한 대화형 문서는 http://127.0.0.1:8025/api/v1/에서 제공됩니다.

유용한 테스트는 메시지를 전송하고, 메시지가 나타날 때까지 폴링(polling)한 뒤, 제목과 내부 링크를 확인하고 모든 항목을 삭제하는 과정을 거칩니다. 단일 요청보다는 짧은 재시도 루프를 사용하여 폴링하십시오. 백그라운드 워커에서 메일을 대기열에 넣는 애플리케이션은 Mailpit이 메시지를 수신하기 전에 전송 호출을 완료하기 때문입니다. 동일한 패턴이 자체 호스팅 API 테스트 및 모킹 도구에서도 나타나며, 이는 일반적으로 프로덕션 환경에 영향을 주지 않는 스테이징 환경의 나머지 절반을 구성합니다.

FAQ

Is a self-hosted disposable email inbox an open relay?

Not while relaying stays off. Mailpit stores messages and never forwards them until you point MP_SMTP_RELAY_CONFIG at a relay configuration, so a stranger who reaches port 1025 cannot send mail through your server. They can still fill your storage, so bind the SMTP port to an address only your application can reach. Publishing it as 1025:1025 in Compose binds every host address, and sudo ufw deny 1025/tcp will not close it, because Docker's own nat rules are matched first.

Do I need an MX record for my test domain?

Only if you want mail from the internet to arrive. Without an MX record, sending servers have nowhere to deliver, so the inbox holds only what your own applications submit over SMTP. Publish the record and open port 25, and you are running a public catch-all: spam within days, dictionary attacks that store a message per attempt, and attachments from strangers on your disk with no filtering.

Why does the message list only update when I reload the page?

Mailpit pushes new mail to an open page over a WebSocket. An nginx location block missing proxy_http_version 1.1 and the Upgrade and Connection headers cannot upgrade that connection, so the page loads normally and then freezes. Mail still arrives and the API still returns it, which is why the inbox looks stale rather than broken. Add those lines, reload nginx, then reload the page.

How do I stop the inbox filling the disk?

Keep MP_MAX_MESSAGES at a real number and add MP_MAX_AGE. The default cap is 500 messages, and setting it to 0 disables deletion entirely, which is how a catch-all with attachments grows quietly. MP_MAX_AGE accepts hours or days, such as 36h or 14d. Clear the store in CI teardown with curl -X DELETE http://127.0.0.1:8025/api/v1/messages. Inbucket does the same job with INBUCKET_STORAGE_RETENTIONPERIOD (72h) and INBUCKET_STORAGE_MAILBOXMSGCAP (300).

Should I run Mailpit, Inbucket or MailHog?

Mailpit for new work, as of August 2026. MailHog still runs, but its default branch has had no commit since August 2022, so it ships unpatched dependencies. Inbucket is actively maintained (3.1.1, December 2025) and is the better pick when a test needs POP3, since Mailpit's POP3 server only starts once you give it a password file. Mailpit uses the same ports as MailHog, 1025 and 8025, so replacing MailHog costs one image name in your Compose file.

#email #testing#mailpit#inbucket#docker #self-hosting