이메일 발신 인프라 종합 분석

RINDA 발신 메일 — 현황 · 기능별 발신 · 이슈 · 근본원인

alpha/beta DB · SES · Cloudflare · 코드 · 221개 도메인 실측 배치테스트 종합

2026-07-13 221 도메인 전수 seed 테스트 gmail-watcher 5계정 판독 개인용 · noindex

1 현황 한눈에

221

SES 도메인(전부 verified)

governor 실사용 풀(전부 오염)

143

GOOD 신선 도메인(미활용)

94%

실사용 1만+ 도메인 스팸율

alpha=워밍업 fleet(221 데우는 중) / beta=프로덕션 발송(governor 13개 풀, alpha와 동일). 워밍업은 alpha 전용(beta 0).

2 기능별 발신 메일 (지금 실제로 나가는 것)

기능(활성)	실제 From	도메인 상태	배치
OTP·트랜잭셔널 인증·비번재설정·답장알림·DSAR·가입환영	`no-reply@fetch.rinda.ai`	실사용 오염	SPAM 🚨
마케팅 넛지 구독만료·결제완료·제품등록 (활성 5)	`hello@{entry·channel·web…}` 10개 순환	실사용 오염	10/10 SPAM
tx 넛지 계정탈퇴·일한도경고 (활성 2)	`hojin@channel.rinda.ai`	실사용 오염	SPAM
콜드 시퀀스 바이어 발굴 캠페인	고객 자기 계정 주소	고객 도메인	—
워밍업 peer 폐쇄루프(평판용)	`rinda@{221 도메인}`	신선 유지	—

넛지 정의 33종 중 실제 활성 7종(마케팅5+tx2). welcome 등 26종은 OFF.

3 핵심 이슈

P0 OTP가 스팸함으로 감

OTP primary fetch.rinda.ai 실측 스팸 → 인증코드·비밀번호 재설정이 스팸함 = 유저 로그인 장애. 반면 스필오버 herald·second는 INBOX.

P0 마케팅 넛지 100% 스팸

governor 마케팅 풀 10개 도메인 전부 스팸. 구독 만료·결제 완료 알림이 전부 스팸함행.

P1 콜드 ↔ 시스템 도메인 미분리

시스템 발송(OTP·마케팅)과 콜드가 도메인 평판을 공유. 콜드의 오염이 시스템으로 전이.

P1 GOOD 143개 미활용

깨끗한 신선 도메인 143개가 send_role=none으로 방치. 이미 SES/DNS 완비 상태인데 governor가 안 씀.

⚪ DMARC·콘텐츠는 이슈 아님 (검증 완료)

DMARC 강화(fetch p=reject)해도 스팸 유지. 동일 콘텐츠 221통이 도메인별로 갈림 → 둘 다 원인 아님.

4 근본원인 — "실유저 발송이 도메인을 태운다"

콘텐츠 100% 동일한 221통이 도메인 실사용량에 따라 8%~94%로 갈렸습니다. 용량-반응(dose-response) 관계가 명확합니다.

콜드 발송 누적	도메인	SPAM율
0통 (순수 워밍업)	155	8%
1-99통	4	0%
1만+ 통	17	94%

메커니즘

peer 워밍업(7통/일)은 도메인을 안 태운다 → 순수 워밍업 143개 INBOX 유지
실유저에게 보내는 순간(콜드든 OTP든 마케팅이든) 태워진다 → fetch(OTP 많이 씀) 스팸, herald(스필오버 적게 씀) INBOX
governor 풀은 콜드 발송 0인데도 스팸 = 시스템 발송 자체가 태움
한 번 태워지면 도메인 단위 고착 (Gmail "이전 메일 스팸 표시" 학습)

추가 요인: 수신자측 학습(admin 계정은 과거 대량수신으로 rinda.ai 전체를 스팸 처리 = 100%). 신선 계정은 16%.

5 최적 설계 방향

완벽한 도메인 찾기가 아니라, 소진을 분산하고 신선 재고를 계속 채우는 로테이션 파이프라인이 답입니다.

우선	조치	방법
P0	BURNED 13개 governor 강등	fetch·entry·channel 등 `send_role=NULL`
P0	OTP를 herald(primary)·second로	display_order 스왑
P0	마케팅을 GOOD 10개로	bay·beam·bell·bridge… `send_role='system_marketing'`
P1	콜드 ↔ 시스템 완전 격리	콜드는 태울 도메인, 시스템은 GOOD 전용
P1	저용량 cap + 로테이션	daily_cap 300/500→20~30, 143개 순환
P1	평판 소진 모니터	주간 seed 배치테스트 → 태워진 도메인 자동 강등

6 반영 위치

코드 전수분석 확정: 이 테이블이 발신 도메인 SSOT. Admin API 없음(SQL이 유일 경로). manual-migration은 CD 자동실행 안 됨(README stale, drizzle만 실행) → DB 직접 UPDATE가 정식 경로.

항목	반영처	비고
send_role·display_order·cap 재배정	alpha DB + beta DB 각각 직접 SQL	governor가 이 테이블에서 선택. 30초 캐시라 재시작 불필요. alpha-beta-sync가 이 테이블 커버 안 함 → 양쪽 각각 실행 필수
영속화(선택·권장)	새 manual-migration(012) 파일 병행	파일 생성 ≠ 자동적용. 감사/재현/신규환경용. 008 편집 금지(SHA 추적)
Infisical(env)	재배정엔 불필요	도메인은 DB 결정. env는 governor ON이면 override됨. 단 governor/role-sync on-off·fallback 주소 변경 시만 예외
SES / Cloudflare	불필요	143개 GOOD 전부 verified·DKIM·MAIL FROM·DNS 완비

⚠️ 덮어쓰기 위험 — role-sync 자동강등

SES_DOMAIN_ROLE_SYNC_ENABLED=true(현재 ON)면, 평판 악화 도메인의 send_role을 자동으로 NULL 강등 + cap 절반으로 덮어씀(강등만, 승격은 안 함). 재배정한 GOOD 승격은 유지되나, 승격 도메인이 태워지면 자동 강등됨 — 이는 의도된 안전장치. (008 재실행 위험은 수동이라 낮음)