이메일 인프라 2026 완벽 가이드 — Resend · Postmark · SendGrid · Mailgun · AWS SES · Loops · React Email · MJML 심층 분석

프롤로그 — "이메일은 죽었다고 했는데, 인프라는 왜 매년 더 복잡해지나"

매년 누군가는 "이메일은 죽었다"고 외친다. Slack이 사내 커뮤니케이션을 가져갔고, WhatsApp과 카카오톡이 개인 메시지를 가져갔고, Discord와 Notion이 커뮤니티를 가져갔다. 그런데 2026년 현재 SaaS 비즈니스의 절대 다수는 여전히 이메일로 회원가입 확인, 결제 영수증, 비밀번호 재설정, 마케팅 캠페인, 알림을 보낸다.

오히려 더 복잡해졌다. 2010년대에는 SendGrid나 Mailgun에 SMTP를 연결하면 끝났다. 2026년에는 다음과 같은 의사결정 트리가 생겼다.

1. 트랜잭셔널이냐 마케팅이냐 알림이냐 — 도구가 다르다.
2. SPF·DKIM·DMARC·BIMI 설정과 모니터링은 누가 책임지나.
3. 발신 도메인을 워밍업할 것인가, 매니지드 IP 풀을 빌릴 것인가.
4. Apple Mail Privacy Protection 이후 오픈율 추적이 망가졌는데, 어떤 지표로 대체할 것인가.
5. React Email로 컴포넌트 기반으로 빌드할 것인가, MJML로 마크업으로 짤 것인가, 비주얼 에디터(Stripo·Beefree)를 쓸 것인가.
6. 알림은 Knock·Courier·Novu 같은 오케스트레이터에 맡길 것인가, 직접 짤 것인가.

이 글은 2026년 5월 기준 이메일 인프라 전체 지도를 그린다. Resend·Postmark·SendGrid·Mailgun·AWS SES로 나뉜 트랜잭셔널, Loops·Customer.io·Mailchimp·Klaviyo·Kit·Beehiiv로 분화한 마케팅, Knock·Courier·Novu의 알림, React Email·MJML·Maizzle의 빌더, 그리고 deliverability·privacy·compliance까지 한꺼번에 정리한다.

1장 · 트랜잭셔널 vs 마케팅 vs 알림 — 세 영역을 섞지 마라

이메일을 시작하는 팀이 가장 먼저 저지르는 실수가 "하나의 도구로 다 보낸다"는 결정이다. 트랜잭셔널·마케팅·알림은 받는 사람의 기대치도 다르고, 발신 도메인의 평판 관리 방식도 다르다.

세 카테고리를 같은 도메인에서 같은 도구로 보내면 평판이 빠르게 망가진다. 마케팅에서 한 번 스팸 신고가 몰리면 영수증까지 스팸함으로 빠진다. 그래서 운영팀은 보통 발신 서브도메인을 분리한다.

핵심 원칙은 평판 분리. 한쪽이 깨져도 다른 쪽이 안전해야 한다.

2장 · Deliverability 기초 — SPF · DKIM · DMARC · BIMI

이메일이 인박스에 도달하느냐 스팸함에 빠지느냐를 결정하는 것은 콘텐츠가 아니라 인증 체계다. 2026년 기준 다음 네 가지는 선택이 아니라 필수다.

1. SPF (Sender Policy Framework) — 도메인의 TXT 레코드로 "이 IP에서 보내는 메일만 정당하다"를 선언. v=spf1 include:_spf.example.net ~all 형태.
2. DKIM (DomainKeys Identified Mail) — 메일 헤더에 서명. 수신자가 도메인의 공개키로 검증. 키 길이 2048비트 권장.
3. DMARC (Domain-based Message Authentication, Reporting, and Conformance) — SPF/DKIM 실패 시 정책(none / quarantine / reject)을 선언. 리포트로 위변조 시도 모니터링.
4. BIMI (Brand Indicators for Message Identification) — DMARC가 reject이고 VMC(Verified Mark Certificate)가 있으면 수신자 UI에 브랜드 로고가 뜬다. Gmail·Yahoo·Apple Mail이 지원.

2024년 2월 Gmail과 Yahoo가 "월 5,000건 이상 발신자는 DMARC 의무"로 정책을 강화했다. 2026년에는 사실상 모든 비즈니스 발신자가 DMARC quarantine 이상을 걸어야 한다.

; SPF
example.com.  TXT  "v=spf1 include:_spf.resend.com include:_spf.mailgun.org ~all"

; DKIM (Resend가 제공한 셀렉터)
resend._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIB..."

; DMARC
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; aspf=s; adkim=s"

; BIMI (VMC 인증서 보유 시)
default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

여기에 더해 reverse DNS (PTR) 가 정방향 도메인과 일치해야 하고, IP 평판(reputation) 이 깨끗해야 한다. 자체 IP가 아니라 매니지드 IP 풀을 빌릴 때는 풀 안에 누가 같이 들어 있는지가 중요하다.

3장 · Resend — 2023 Y Combinator, 개발자 우선 트랜잭셔널

Resend는 2023년 Y Combinator W23 배치로 시작했다. 한 줄 표어는 "developer-first email API"였고, 실제 API 표면이 단순해서 빠르게 점유율을 끌어올렸다.

핵심 특성

• API 표면이 작다 — POST /emails 한 엔드포인트로 시작 가능.
• React Email과 1급 통합 — Resend가 만든 오픈소스. JSX 컴포넌트로 메일을 짜고 그대로 보낸다.
• 도메인 인증 흐름이 깔끔하다 — 콘솔에서 SPF·DKIM·DMARC 레코드를 한 번에 제시.
• 가격 — 무료 100/일, Pro $20/월 50,000건부터.
• 다중 리전(US·EU)으로 데이터 거버넌스 옵션 제공.

약점

• 마케팅(브로드캐스트) 기능은 상대적으로 늦게 추가됐다. 본격 캠페인은 Loops/Customer.io 조합이 더 강하다.
• 매우 큰 발신량(월 천만 건 이상)에서는 AWS SES 직접 운용 대비 비용 우위가 줄어든다.

// Resend SDK (Node.js) 사용 예
import { Resend } from 'resend'
import { WelcomeEmail } from './emails/Welcome'

const resend = new Resend(process.env.RESEND_API_KEY)

await resend.emails.send({
  from: 'YJ Blog <noreply@tx.example.com>',
  to: ['user@example.com'],
  subject: '가입을 환영합니다',
  react: WelcomeEmail({ name: 'Youngju' }),
})

4장 · Postmark — ActiveCampaign 인수, deliverability 1등

Postmark는 2025년 ActiveCampaign에 인수됐지만 브랜드는 그대로 유지된다. 시장에서의 포지션은 일관됐다 — "트랜잭셔널 전용, deliverability 절대 1등".

핵심 특성

• 마케팅 발송을 정책적으로 거부한다. Stream을 transactional / broadcast로 명시 분리.
• 평균 인박스 도달 시간이 수 초 단위로 일관적 — 영수증·코드 발송에 강하다.
• Postmark DMARC Digest — DMARC 리포트를 시각화하는 무료 서비스. 도메인 위변조 모니터링을 그냥 켤 수 있다.
• Templates와 변수 치환이 강력 — Mustache 스타일.

약점

• 가격이 비싸다 — 트랜잭셔널 100K가 약 $50/월. 대량에서는 SES와 차이가 크다.
• 마케팅 캠페인을 하려면 다른 도구가 필요하다.

curl -X POST "https://api.postmarkapp.com/email" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Postmark-Server-Token: YOUR_TOKEN" \
  -d '{
    "From": "noreply@tx.example.com",
    "To": "user@example.com",
    "Subject": "Welcome",
    "HtmlBody": "<h1>Hello</h1>",
    "MessageStream": "outbound"
  }'

5장 · SendGrid — Twilio 산하, 트랜잭셔널과 마케팅 모두

SendGrid는 2019년 Twilio에 인수된 이후로 트랜잭셔널과 마케팅 양쪽을 모두 보유한 종합 플랫폼이다. 점유율로 보면 여전히 시장 1위.

핵심 특성

• API와 SMTP 둘 다 지원 — 레거시 호환성에 강하다.
• Marketing Campaigns 모듈 — 세분화·자동화·A/B 테스트 가능.
• Twilio SendGrid Email Validation API — 발송 전 유효성 검증.
• 글로벌 인프라 — 미국·유럽·일본 리전.
• IP 워밍업 자동화 — 신규 IP를 며칠에 걸쳐 점진적으로 데우는 옵션.

약점

• 콘솔 UX가 종합 플랫폼답게 복잡하다.
• 발송 정책이 빡빡해서 신규 계정의 cold start가 까다롭다.
• 가격 — 무료 100/일, 이후 Essentials $19.95/월부터.

# SendGrid Python SDK
from sendgrid import SendGridAPIClient
from sendgrid.helpers.mail import Mail

message = Mail(
    from_email='noreply@tx.example.com',
    to_emails='user@example.com',
    subject='Welcome',
    html_content='<h1>Hello</h1>')

sg = SendGridAPIClient(os.environ.get('SENDGRID_API_KEY'))
response = sg.send(message)

6장 · Mailgun — Sinch 산하, 개발자 친화 API

Mailgun은 2021년 Sinch에 합류해 글로벌 커뮤니케이션 그룹의 일원이 됐다. 포지션은 "SendGrid보다 가볍고 API가 깔끔한 개발자 도구".

핵심 특성

• HTTP API와 SMTP 둘 다. 라우팅 룰(받은 메일을 처리하는 인바운드)도 강력.
• MJML2HTML 컴파일러를 오픈소스로 유지(Mailgun이 후원).
• Deliverability 도구 — Inbox Placement Testing, Send Time Optimization.
• 멀티 리전(US·EU)으로 데이터 주권 옵션.
• 가격 — Foundation $35/월 50K건부터.

약점

• UI는 SendGrid보다 더 빈약하다. 콘솔보다 API로 운영하는 팀에 맞다.
• 마케팅 캠페인 도구는 SendGrid/Mailchimp 대비 약하다.

curl -s --user 'api:YOUR_API_KEY' \
  https://api.mailgun.net/v3/mail.example.com/messages \
  -F from='Y. Kim <noreply@mail.example.com>' \
  -F to=user@example.com \
  -F subject='Welcome' \
  -F html='<h1>Hello</h1>'

7장 · AWS SES — 대규모에서 가장 저렴

Amazon Simple Email Service는 발송 가격이 1,000건당 0.10달러로, 대규모에서 비교 대상이 없다. 단, 평판 관리·바운스/컴플레인 처리·UI 같은 모든 부속을 직접 짜야 한다.

핵심 특성

• 가격 — 발송 1,000건당 0.10달러. EC2에서 보내면 매월 62,000건까지 무료(retiring 정책 확인).
• SNS/SQS로 바운스·컴플레인·전송 이벤트를 실시간 수신.
• Configuration Set으로 발신 도메인·이벤트 분리.
• 멀티 리전 — us-east-1, eu-west-1, ap-northeast-1 등.
• Dedicated IP, IP Pool, BYOIP(자체 IP 가져오기) 지원.

약점

• 신규 계정은 샌드박스 모드(확인된 수신자에게만 발송)로 시작. production 승격 신청 필요.
• 평판·바운스·UI를 전부 직접 다뤄야 한다 — SaaS 대비 운영 부담.
• 콘솔이 AWS의 평균적인 복잡도를 그대로 가진다.

대량을 보내는 팀의 표준 패턴은 "AWS SES + 자체 큐(SQS) + 자체 워커 + Resend/Postmark는 부분적 백업".

# boto3 ses send_email
import boto3

ses = boto3.client('ses', region_name='ap-northeast-1')

ses.send_email(
    Source='noreply@tx.example.com',
    Destination={'ToAddresses': ['user@example.com']},
    Message={
        'Subject': {'Data': 'Welcome'},
        'Body': {'Html': {'Data': '<h1>Hello</h1>'}},
    },
    ConfigurationSetName='tx-config',
)

8장 · 셀프호스팅 — Postal · Listmonk · Plunk · Maileroo

자체 인프라로 가는 옵션도 살아 있다. 매니지드를 못 쓰는 규제 환경이나 비용이 클 때 검토한다.

셀프호스팅의 본질적 한계는 IP 평판. 신규 IP는 빅테크 메일 서비스가 자동으로 의심한다. 자체 호스팅으로 시작하더라도 외부 트랜잭셔널 서비스로 평판이 쌓인 IP를 빌리는 것이 일반적이다.

9장 · 마케팅 — Mailchimp · Loops · Customer.io

마케팅(브로드캐스트) 시장은 트랜잭셔널과 완전히 다른 도구 군이 차지한다.

2026년의 흐름은 두 가지다. 하나는 "코드로 캠페인을 정의" — Loops·Customer.io처럼 API와 트리거로 자동화를 코드 베이스에 묶는 것. 다른 하나는 "크리에이터 경제" — Beehiiv·Substack·Kit이 가져간 영역.

// Loops API — 이벤트 트리거 캠페인 예
await fetch('https://app.loops.so/api/v1/events/send', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer ' + process.env.LOOPS_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    email: 'user@example.com',
    eventName: 'signup_completed',
    eventProperties: { plan: 'pro' },
  }),
})

10장 · 알림 오케스트레이션 — Knock · Courier · Novu

알림(notification)은 단순한 메일과 다르다. 사용자별 채널 선택(이메일·SMS·푸시·인앱), 빈도 조절, 다이제스트, 시간대 처리가 필요하다. 이걸 직접 짜기 시작하면 별도의 마이크로서비스가 된다.

전형적 사용 패턴은 "백엔드에서 이벤트 발송 → Knock 워크플로우 → 사용자 선호도에 따라 이메일은 Resend로, 푸시는 FCM으로, SMS는 Twilio로 분기". 알림 빈도 제어와 다이제스트(여러 이벤트를 한 통의 메일로 묶는 것)가 핵심 가치.

// Knock 워크플로우 트리거
await knock.workflows.trigger('new-comment', {
  recipients: ['user_123'],
  data: {
    comment: 'Great post!',
    author: 'Alice',
    post_title: 'Email Infra 2026',
  },
})

11장 · 이메일 빌더 — React Email · MJML · Maizzle

이메일 HTML은 2026년에도 1996년의 Outlook 호환성 짐을 그대로 짊어진다. 이 짐을 추상화하는 빌더 세 가족이 자리 잡았다.

React Email (Resend 후원)

• React 컴포넌트로 메일을 작성.
• @react-email/components 패키지에 Button, Hr, Img, Container 등.
• Resend SDK와 1급 통합 — react: <Welcome /> 옵션으로 그대로 보낸다.
• 미리보기 서버 내장 — pnpm dev로 로컬 미리보기.

MJML (Mailjet 후원)

• XML 같은 마크업 → 호환 HTML로 컴파일.
• 반응형이 기본 — Outlook 2007/2010까지 자동 대응.
• 비주얼 에디터(Stripo·Topol)들이 내부에서 MJML을 쓰는 경우가 많다.

Maizzle

• Tailwind CSS로 메일 스타일링.
• 빌드 타임에 인라인 CSS로 변환.
• 컴포넌트 슬롯과 환경별 빌드 옵션.

비주얼 에디터

• Stripo, Beefree, Topol, Postcards — 드래그앤드롭으로 만들고 HTML/MJML로 내보낸다.

// React Email 컴포넌트 예시
import { Html, Body, Container, Heading, Text, Button } from '@react-email/components'

export function WelcomeEmail({ name }: { name: string }) {
  return (
    <Html>
      <Body style={{ fontFamily: 'Inter, sans-serif' }}>
        <Container>
          <Heading>안녕하세요, {name}님</Heading>
          <Text>YJ Blog에 가입해 주셔서 감사합니다.</Text>
          <Button href="https://example.com/onboard">시작하기</Button>
        </Container>
      </Body>
    </Html>
  )
}

<!-- MJML 마크업 예시 -->
<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text font-size="20px">안녕하세요</mj-text>
        <mj-button href="https://example.com">시작하기</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

12장 · 렌더링 검증 — Outlook의 악몽과 Litmus · Email on Acid

웹 브라우저보다 메일 클라이언트의 호환성 변동폭이 훨씬 크다. Gmail, Apple Mail, Outlook(특히 Windows Outlook 2007/2010/2013/2016/2019), Yahoo Mail, ProtonMail, 모바일 Gmail, 모바일 Outlook이 같은 HTML을 다 다르게 그린다.

Outlook(Windows 데스크탑)은 Word 렌더 엔진을 쓰기 때문에 CSS Flexbox·Grid·position 등이 무용지물이다. 이메일 HTML이 표 기반(table)으로 짜이는 이유. MJML과 React Email은 이런 표 기반 구조를 자동 생성한다.

13장 · DMARC 모니터링 — Postmark Digest · DMARCian · EasyDMARC

DMARC 정책을 quarantine 또는 reject로 걸면, 위반 시도 리포트가 매일 도착한다. 이걸 사람이 XML로 읽으면 안 된다. 시각화 도구를 쓴다.

핵심 운영 원칙은 단계적 강화 — 처음에는 p=none으로 30일간 리포트만 수집, 도메인 위반이 없으면 p=quarantine으로 올리고, 안정되면 p=reject로 마무리.

14장 · Apple Mail Privacy Protection — 오픈율 사망

2021년 Apple Mail Privacy Protection이 등장하면서 추적 픽셀이 사실상 무력해졌다. Apple Mail 사용자가 메일을 받는 즉시 백그라운드에서 자동 프리페치하기 때문에, 오픈율이 100%로 보이거나 의미를 잃는다. 2026년 기준 Apple Mail 점유율은 글로벌 약 50%.

대안 지표는 다음과 같다.

마케팅 도구들도 옵션을 추가했다 — "오픈율 보정(Apple Mail은 제외하고 계산)". Customer.io·Loops·Mailchimp 모두 지원한다.

15장 · 규제 — CAN-SPAM · GDPR · CASL · K-PIPA · APPI

이메일은 글로벌 발송이 기본이므로 각국 규제를 동시에 만족해야 한다.

가장 빡빡한 K-PIPA를 기준으로 운영하면 다른 지역도 대부분 통과한다. 광고성 정보의 제목에는 "(광고)" 표기, 본문에 발신자 정보·수신거부 방법·야간 발송 동의 여부를 명시.

16장 · 워밍업 — 신규 도메인과 IP의 첫 30일

새 도메인이나 새 IP로 발송을 시작하면 빅테크 메일 서비스는 자동으로 의심한다. 처음 며칠은 발송량을 점진적으로 늘리는 워밍업이 필요하다.

워밍업 도구:

• Mailwarm — 자동 발송·자동 응답으로 평판 누적.
• Lemwarm — Lemlist 계열.
• Mailflow — 가성비 옵션.
• SendGrid·Mailgun의 IP 워밍업 자동화.

전형적 30일 스케줄:

• Day 1-3: 50통/일.
• Day 4-7: 200통/일.
• Day 8-14: 1,000통/일.
• Day 15-30: 5,000~50,000통/일.

워밍업 중에는 가장 참여도 높은 사용자(최근 30일 클릭자)부터 보낸다. 콜드 리스트로 워밍업하면 평판이 더 망가진다.

17장 · 한국 시장 — KakaoTalk Biz Message · Naver Works

한국에서는 이메일만으로는 안 된다. 알림은 카카오톡, 인증은 SMS, 마케팅은 이메일 + 알림톡의 조합이 표준이다.

알림톡은 인증코드, 결제 알림 같은 정보성에 매우 강하다. 하지만 사전 등록된 템플릿만 가능하고, 광고성으로 분류되면 친구톡으로 강등된다.

18장 · 일본 시장 — SendGrid Japan · Sakura · Mailgun JP

일본은 이메일 자체의 점유율이 한국보다 훨씬 높게 유지된다. 거래처 커뮤니케이션, 회사 공지, BtoB 영업이 메일 중심.

일본 시장의 특수성: 휴대폰 캐리어(docomo, KDDI, SoftBank)가 운영하는 메일 서비스가 여전히 살아 있고, 이들이 자체 스팸 필터를 운영한다. 일본 도메인 발송 시 docomo·au·SoftBank 도착률을 별도로 모니터링하는 것이 표준이다.

19장 · 콜드 이메일 — Apollo · Instantly · Smartlead · lemlist

세일즈 콜드 이메일은 발신 전략이 트랜잭셔널·마케팅과 다르다. 매우 적은 양을 매우 개인화해서 보낸다. 도구도 분리된다.

콜드 이메일은 옵트인이 없으므로 GDPR/CASL/K-PIPA 영역과 정면 충돌한다. EU/한국/캐나다 발송에 콜드 이메일을 쓰는 건 위험하고, 도메인 자체의 평판도 빠르게 깎인다. 그래서 콜드용 발신 도메인은 메인 도메인과 반드시 분리한다.

20장 · 아키텍처 패턴 — API → Queue → Worker → 게이트웨이

대량 발송 시스템의 표준 패턴은 다음과 같다.

[애플리케이션 API]
   │  send_email(to, template, vars)
   ▼
[메시지 큐 (SQS / Kafka / RabbitMQ)]
   │  배압 조절, 재시도, 우선순위
   ▼
[이메일 워커 (worker pool)]
   │  렌더링, 변수 치환, 발송 한도 적용
   ▼
[게이트웨이 (SES / Resend / SendGrid)]
   │
   ├── 성공 → [이벤트 로그 / 분석]
   ├── 바운스 → [SNS / 웹훅 → 처리]
   └── 컴플레인 → [블록리스트 추가 / DLQ]

핵심 디자인 원칙:

1. 큐 분리 — 트랜잭셔널·마케팅·알림 큐를 분리. 한쪽이 막혀도 다른 쪽이 흐른다.
2. 블록리스트 — 바운스·컴플레인 사용자는 자동으로 제거. 같은 주소로 재발송하면 평판이 깨진다.
3. DLQ(Dead Letter Queue) — 발송 실패 메시지는 별도 큐로 보내 분석.
4. 레이트 리미트 — 게이트웨이별·도메인별 시간당 발송 한도를 워커에서 적용.
5. 멀티 게이트웨이 페일오버 — 주 게이트웨이가 죽으면 보조로 전환. Resend ↔ SES 같은 조합.
6. 이벤트 로그 — 모든 발송·열람·클릭·바운스 이벤트는 분석 DB에 적재.

21장 · 우리 팀은 무엇을 골라야 하나

워크로드별 추천을 한 번 더 압축하면 다음과 같다.

결국 도구를 한 개로 통일하려는 시도는 거의 다 실패한다. 트랜잭셔널·마케팅·알림을 분리하고, 각각에 맞는 도구를 골라서 조합하는 것이 2026년의 정답이다.

참고 / References

• Resend Docs — https://resend.com/docs
• Postmark Docs — https://postmarkapp.com/developer
• SendGrid Docs — https://docs.sendgrid.com/
• Mailgun Docs — https://documentation.mailgun.com/
• AWS SES Developer Guide — https://docs.aws.amazon.com/ses/
• Loops Docs — https://loops.so/docs
• Customer.io Docs — https://customer.io/docs/
• Knock Docs — https://docs.knock.app/
• Courier Docs — https://www.courier.com/docs/
• Novu Docs — https://docs.novu.co/
• React Email — https://react.email/
• MJML — https://mjml.io/
• Maizzle — https://maizzle.com/
• DMARC.org — https://dmarc.org/
• BIMI Group — https://bimigroup.org/
• Postmark DMARC Digest — https://dmarc.postmarkapp.com/
• DMARCian — https://dmarcian.com/
• EasyDMARC — https://easydmarc.com/
• Apple Mail Privacy Protection — https://support.apple.com/en-us/HT212614
• Gmail Sender Guidelines 2024 — https://support.google.com/mail/answer/81126
• Litmus — https://www.litmus.com/
• Email on Acid — https://www.emailonacid.com/
• KISA K-PIPA Guidelines — https://www.kisa.or.kr/
• Beehiiv — https://www.beehiiv.com/
• Substack — https://substack.com/
• Kit (구 ConvertKit) — https://kit.com/
• Klaviyo — https://www.klaviyo.com/