인프라로서의 SMTP 릴레이

결과를 보고하는 SMTP 릴레이 서비스

호스트와 포트만 바꾸고 코드는 그대로 두세요. SMTP 릴레이 서비스를 거치는 모든 메시지마다 인증 검사, 워밍업, 재시도, 추적 정보를 받을 수 있습니다.

SMTP로 발송 시작하기 릴레이가 처리하는 항목 보기
모니터링 터미널 앞의 엔지니어, 어두운 서버 통로 끝에서 파란 상태 표시등이 빛나는 모습
릴레이가 처리하는 것

직접 하던 여섯 가지 작업을 덜어냅니다

SMTP 릴레이는 작업을 줄여줄 때만 쓸모가 있습니다. 아래는 보통 크론 작업과 런북으로 얽히게 되는 아웃바운드 메일의 부분들입니다.

드롭인 SMTP 엔드포인트

587 포트와 STARTTLS, 또는 465 포트와 암시적 TLS를 지원합니다. SMTP를 쓰는 프레임워크 메일러, CMS, 레거시 시스템은 호스트와 자격 증명만 바꾸면 됩니다.

인증을 먼저 검증

첫 운영 발송 전에 SPF, DKIM, DMARC 정렬을 확인합니다. 잘못된 DNS 레코드가 나머지 설정을 조용히 무너뜨리지 않습니다.

고정된 램프의 워밍업

새 도메인은 약 4주에 걸쳐 하루 50건에서 10만 건까지 올라갑니다. 이 곡선은 스프레드시트가 아니라 릴레이가 강제합니다.

백오프를 적용한 재시도

4xx 지연 응답은 지수 백오프로 재시도합니다. 5xx 거부는 즉시 중단하고 분류하므로, 죽은 사서함을 밤새 두드리지 않습니다.

발송별 추적

메시지마다 열람, 클릭, 반송, 스팸 신호를 SSE로 스트리밍합니다. 발송이 실패하면 원본 SMTP 응답이 함께 붙습니다.

내 스택으로 내보내기

같은 이벤트를 Datadog 또는 Grafana로 보내, 지연 시간이나 오류율에 알림을 걸듯 전달 상태에도 알림을 설정할 수 있습니다.

작동 방식

로컬 Postfix에서 릴레이 발송까지 다섯 단계

대부분의 이전 작업은 반나절이면 끝납니다. 오래 걸리는 부분은 램프 구간이며, 그 부분은 무인으로 진행됩니다.

  1. 1

    발송 도메인 추가

    서비스가 제공하는 SPF include와 DKIM 레코드를 게시하세요. 메일이 나가기 전에 정렬부터 검증됩니다.

  2. 2

    SMTP 자격 증명 생성

    애플리케이션마다 범위를 제한한 자격 증명을 만드세요. 비밀번호 하나가 유출되어도 메일을 보내는 모든 서비스가 노출되지는 않습니다.

  3. 3

    메일러를 릴레이로 향하게 설정

    호스트를 지정하고 587 포트와 STARTTLS를 사용해 테스트 메시지를 보내세요. Postfix에서는 main.cf의 relayhost 한 줄이면 됩니다.

  4. 4

    목표 발송량과 기간 설정

    어느 수준까지, 얼마나 긴 기간에 걸쳐 올릴지 정하세요. 콜드 도메인이라면 4주에 걸쳐 하루 10만 건까지 올리는 것이 흔한 출발점입니다.

  5. 5

    추적을 보고 전환

    먼저 일부만 라우팅하고 추적 정보를 읽으세요. 반송률과 불만률이 정상으로 보이면 나머지 발송량을 옮깁니다.

대상 독자

자체 운영 Postfix 서버를 퇴역시키는 팀을 위한 서비스

직접 운영하는 메일 서버는 문제가 생기기 전까지는 잘 동작합니다. IP가 차단 목록에 오르거나, 느린 수신자 뒤로 큐가 막히거나, 설정을 이해하던 한 사람이 떠나는 날이 옵니다. 릴레이가 전달, 평판, 재시도를 맡고, 애플리케이션은 지금과 같은 SMTP 엔드포인트로 계속 발송합니다. 메일 로그를 SSH로 뒤지는 대신, 어느 배치가 왜 반송되었는지 바로 볼 수 있습니다.

  • 앱이 이미 쓰는 SMTP 인터페이스를 그대로 유지
  • 관리해야 할 큐나 차단 목록이 없음
  • 상태 라벨뿐 아니라 추적 정보에 원본 SMTP 응답 포함
터미널 로그가 떠 있는 노트북 옆에 메일 서버들이 화살표로 연결된 노트 스케치
대상 독자

트랜잭션 발송량이 계단식으로 늘어나는 제품 팀을 위한 서비스

트랜잭션 메일은 계단처럼 늘어납니다. 새 온보딩 흐름이 출시되거나 기능이 정식 공개되면 하루 발송량이 밤사이 두 배가 되기도 합니다. 새 발송량을 뒤에서 램프 업하면 비밀번호 재설정과 영수증이 받은편지함에 계속 도착하고, 무언가 어긋나면 추측하는 대신 어떤 신호가 문제인지 알림으로 알려줍니다.

  • 꾸준한 성장뿐 아니라 계단식 증가도 처리
  • 램프 업 중에도 기존 트랜잭션 발송은 영향을 받지 않음
  • 반송률이나 스팸률이 임계값을 넘으면 자동 일시 중지
노란 케이블과 파란 상태 표시등이 있는 서버 랙 패치 패널
비교

자체 운영과 API 사이에서 SMTP 릴레이의 위치

순위가 아닙니다. 이미 무엇을 운영하고 있는지, 전달을 얼마나 직접 소유하고 싶은지에 따라 선택이 달라집니다.

기준자체 운영 MTASMTP 릴레이 서비스HTTP 이메일 API 전용
기존 SMTP 코드와 호환예예아니요, 연동 필요
IP 및 도메인 평판직접 관리워밍업 포함 관리형워밍업 포함 관리형
재시도 및 반송 처리직접 설정내장, 분류 포함내장, 분류 포함
발송별 추적박스 내 메일 로그추적과 SSE 이벤트추적과 SSE 이벤트
멱등성 키사용 불가API와 SDK를 통해 제공기본 제공
운영 부담높음낮음낮음

자주 묻는 질문

SMTP 릴레이 서비스란 무엇인가요?
애플리케이션에서 SMTP로 메일을 받아 인증한 뒤, 수신자의 메일 서버로 대신 전달하는 관리형 서버입니다. 기존 코드나 프레임워크 메일러는 그대로 두고 호스트, 포트, 자격 증명만 바꾸면 됩니다.
SMTP 릴레이에는 어떤 포트를 써야 하나요?
대부분의 애플리케이션에는 STARTTLS를 쓰는 587 포트, 또는 암시적 TLS를 쓰는 465 포트를 권장합니다. 25번 포트는 서버 간 통신용이고 많은 클라우드 공급자가 아웃바운드를 차단하므로, 릴레이를 통해 발송하는 앱에는 보통 맞지 않습니다.
SMTP 릴레이와 이메일 API는 무엇이 다른가요?
둘 다 같은 전달 파이프라인으로 들어갑니다. SMTP는 호환성 경로입니다. SMTP를 말할 수 있는 프레임워크, CMS, 레거시 시스템은 아무 변경 없이 동작합니다. HTTP API와 Node, Python, Go SDK는 새 코드를 위해 멱등성 키와 구조화된 오류를 추가로 제공합니다.
릴레이를 써도 SPF, DKIM, DMARC가 필요한가요?
네. 릴레이가 서명하고 발송하지만, 도메인이 릴레이의 발송을 승인해야 합니다. 서비스는 첫 운영 발송 전에 SPF와 DKIM 정렬을 확인합니다. 레코드가 빠진 것이 이전 후 메일이 스팸함으로 가는 가장 흔한 원인이기 때문입니다.
다운타임 없이 자체 Postfix 서버에서 옮길 수 있나요?
네. Postfix의 스마트호스트를 587 포트의 릴레이로 지정하고, 발송량의 일부를 먼저 보내며 추적 정보를 확인하세요. 반송률과 불만률이 정상으로 보이면 나머지 트래픽을 옮기고 직접 전달 경로를 퇴역시킵니다.
발송이 실패하거나 수신 서버가 바쁘면 어떻게 되나요?
4xx 지연 같은 일시적 실패는 지수 백오프로 재시도합니다. 550 사서함 없음 같은 영구적 실패는 하드 반송으로 분류되어 재시도를 멈추고, 원본 SMTP 응답과 함께 발송별 추적에 나타납니다.
새 도메인은 첫날부터 받은편지함에 도착하나요?
확실하지 않습니다. 콜드 도메인에는 평판이 없으므로 발송량을 점진적으로 늘려야 합니다. 워밍업은 하루 50건에서 10만 건까지 약 4주가 걸리며, 반송률이나 스팸률이 임계값을 넘으면 발송이 자동으로 멈춥니다.
월 수천 건의 메일이라도 릴레이를 쓸 가치가 있나요?
발송량이 적어도 보통 그렇습니다. 피하는 비용이 운영 비용이기 때문입니다. IP 평판 관리, 큐 모니터링, 반송 처리가 여기에 해당합니다. 신규 온보딩 흐름이나 정식 출시처럼 발송량이 계단식으로 늘 때 가장 설득력이 있습니다.

호스트 하나만 바꾸고 나머지 스택은 그대로 두세요

메일러를 릴레이로 향하게 하고, 도메인을 램프 업하고, 모든 발송의 추적을 읽으세요. 워밍업과 자동 일시 중지가 기본으로 켜져 있습니다.

무료로 시작하기 롤아웃 방식 보기
Last updated · 1 change
Changelog · 1
  • comparison_fields_edited Comparison structure updated
notificationharbor
무료로 시작하기