| Config Set | 용도(현) | Tracking | IP Pool | Reputation |
|---|---|---|---|---|
rinda-marketing | 마케팅 | link.rinda.ai | shared | ON |
rinda-transactional | 트랜잭셔널 | link.rinda.ai ⚠️ | shared | ON |
rfq-prod | RFQ | 없음 | shared | ON |
rinda-notrack | 무트래킹 | 없음 | shared | ON |
+ rinda-marketing-alpha, rinda-transactional-alpha (스테이징). VDM(Virtual Deliverability Manager) ENABLED. 최근 바운스·컴플레인 0. | ||||
⚠️ 발견: 모든 config set이 SendingPool=null(shared IP 공유). 즉 OTP·마케팅·콜드 아웃리치가 같은 IP 평판을 공유. 트랜잭셔널에 마케팅 트래킹 도메인이 붙어 있음.
일 22K는 AWS가 dedicated IP를 권하던 기준(과거 공식 권장 일 175,000통 평균, 현재는 강제 폐지했으나 여전히 "대량·규칙적 발송"이 조건)에 못 미칩니다. Dedicated IP 1개는 45일 워밍업·SPOF·관리부담이 있고, 무엇보다 발송량이 적으면 수신 서버가 그 IP를 신뢰할지 판단할 트래픽이 부족해 오히려 배달성이 나빠집니다(AWS·업계 공통 경고). 소량엔 Amazon의 거대·고평판 shared 풀이 유리.
진짜 문제는 IP 종류가 아니라 트래픽 유형이 안 나뉜 것.
| 상황 | 권장 | 이유 |
|---|---|---|
| 현재 (일 22K, 혼합) | Shared 유지 | 임계 미달 · shared 평판이 더 안정 |
| OTP/트랜잭셔널 일 5만+ 꾸준 | Dedicated pool 도입 | 배달성을 직접 통제 · 콜드 오염 차단 |
| 콜드 아웃리치 대량 | 별도 Dedicated로 격리 | 메인 도메인/IP 평판 보호 |
| 관리 최소화하며 전용 원함 | Managed Dedicated IP | AWS 자동 워밍업·스케일 |
핵심: IP를 나누기 전에 "발신 도메인 + config set"부터 나눠라. 그게 배달성의 90%. Dedicated IP는 그 다음 단계.
가장 중요한 원칙: OTP는 콜드와 절대 같은 도메인·IP를 쓰면 안 된다. 콜드의 낮은 평판이 OTP 배달을 죽입니다. 유형을 완전히 분리하세요.
| 발신 도메인 | verify.rinda.ai 또는 notify.rinda.ai (전용, 최고 평판 유지) |
| Config Set | rinda-transactional — 단, 트래킹 제거 (OTP에 픽셀·링크추적 = 불필요+스팸신호) |
| List-Unsubscribe | 넣지 않음 (트랜잭셔널은 구독취소 대상 아님) |
| 내용 | 짧고 명확, 이미지 최소, 코드/링크 1개, 만료시간 명시 |
| IP | shared → 볼륨 커지면 dedicated pool 최우선 후보 |
| SPF/DKIM/DMARC | DKIM 정렬 필수 · DMARC p=quarantine+ 지향 |
| 발신 도메인 | mail.rinda.ai 등 (트랜잭셔널과 반드시 분리) |
| Config Set | rinda-marketing (tracking link.rinda.ai ON — open/click 측정) |
| List-Unsubscribe | 필수 — One-Click(RFC 8058) 헤더 + 본문 링크. Gmail/Yahoo 대량발신자(일 5,000+ 발송) 의무 · 마케팅만 해당(트랜잭셔널 제외) |
| 스팸 신고율 | Postmaster Tools 기준 <0.3% 유지 (초과 시 2024.6~ 완화 불가 · 2025.11~ reject 강화) |
| 리스트 위생 | bounce/complaint suppression 준수 · 비참여자 정리 · 빈도 캡 |
| 내용 | text:image 균형, 명확한 CTA, 물리주소 표기(CAN-SPAM) |
| IP | shared 충분 |
| 발신 도메인 | 전용 워밍업 풀(현 *.rinda.ai 200개) — 메인/OTP와 완전 격리 |
| Config Set | 전용 (예: rinda-notrack 계열) · 초기 트래킹 픽셀 끄기 |
| 워밍업 | 실측 배치(seed 계정)로 검증 후 투입 · peer 지표만 믿지 말 것 |
| 발송 주소 | 워밍업한 주소 = 실발송 주소 일치 (현재 불일치가 문제) |
| IP | 대량 시 별도 dedicated로 격리해 메인 보호 |
rinda-transactional에서 open/click 추적 해제. OTP에 추적 픽셀·링크래핑은 스팸 신호이자 불필요. 전용 verify.rinda.ai 서브도메인 분리.
p=none. 모니터링 데이터 확인 후 p=quarantine(pct 점진↑) → reject. OTP 도메인부터.
전용 IP는 지금 필요 없다. 진짜 지렛대는 OTP · 마케팅 · 콜드를 서로 다른 도메인/config set으로 격리하고, OTP에서 트래킹을 빼 최고 평판을 지키며, 마케팅에 One-Click 구독취소를 붙이는 것. Dedicated IP는 트랜잭셔널 볼륨이 커진 뒤의 다음 수순.
| Dedicated vs Shared IP | AWS 공식: 저볼륨은 shared 권장. 과거 dedicated 권장 임계 일 175K. 소량 dedicated는 신뢰 트래픽 부족으로 배달성 악화. docs.aws.amazon.com/ses, Managed Dedicated IP |
| Gmail/Yahoo 2024 요건 | 일 5,000+ 발송 시 SPF+DKIM+DMARC(≥p=none), One-Click 구독취소(마케팅), 스팸율 <0.3%. 2025.11~ enforcement 강화. Gmail 발신자 가이드, Yahoo Sender Hub, Mailgun |
| 트랜잭셔널↔마케팅 분리 | 서브도메인 분리가 베스트프랙티스. 마케팅의 높은 complaint가 OTP 배달성을 오염. Suped, Mailgun, Litmus |
| OTP 딜리버러빌리티 | 전용 서브도메인 · 트래킹 픽셀은 보안 게이트웨이 트리거(금융/보안 특히) → 제거 또는 custom tracking domain. Autodesk OTP 가이드, Mailtrap |