발신 도메인 18-way 분산 교체 — 타당성 & 위험 분석

✓판정: 계획은 타당하다 (조건부)

1. 가장 큰 위험이 실증으로 해소 — 18개 워밍업 도메인은 이미 각 102~176건 답장을 수신 중(6/5~6/15). MX/SES Receipt Rule이 작동한다는 직접 증거 = "수신 인프라 누락으로 답장 유실" 위험 없음.
2. "랜덤"이 아니라 더 안전한 sticky 해시 — 코드는 SHA256(리드 이메일) % 풀크기로 분배. 같은 바이어는 항상 같은 도메인, 1·2·3차 후속도 같은 주소. 한 바이어가 18개 도메인에서 받는 혼란은 구조적으로 발생 안 함.
3. 스레드/시퀀스 매칭은 발신 도메인과 완전 무관 — SES 발신의 message_id가 @amazonses.com 고정이라 도메인을 바꿔도 In-Reply-To 매칭 키 불변.
4. 진행중 enrollment는 자동으로 안 바뀜 — 발신계정이 sticky 고정. reallocate-sender-pool.ts --commit 실행이 세트로 필요(미발송분만 재분산, 발송완료분은 보존).
5. 옛 3개 도메인 즉시 폐기 금지 — in-flight 시퀀스 답장이 그리로 옴. is_active=false로 발송만 끊고 수신은 grace 유지.

★핵심 증거: 18개 도메인 수신 실증

코드상 가장 치명적 위험은 "발송은 되는데 그 도메인 MX/Receipt Rule이 없어 답장이 시스템에 진입조차 못 하고 로그도 없이 완전 유실"이다(코드에 수신 도메인 검증·계측 부재). 그러나 실데이터가 18개 전부 수신 작동을 증명한다.

1발송 코드 — from 결정 & 분산

2답장·웹훅 수신 코드

수신 진입점 3개

매칭 & 귀속

3수신 누락 시나리오 전수

4위험 매트릭스

5실행 체크리스트 (순서 중요)

1. 일반 ws용 18개 도메인 계정 발급 — 현재 18개 도메인은 2개 슈퍼 ws(50a26184·b3e2c3bf) 전용. 분산 대상 ws마다 prefix@각도메인 계정을 user_email_accounts에 생성(귀속 키 확보).
2. 평판 나쁜 3계정을 sequence_email_accounts에서 제거 + 18계정 추가 — 신규 enrollment가 18-way로 자동 분산 시작.
3. 진행중 캠페인 재할당 — reallocate-sender-pool.ts --commit(또는 pause→resume). 미발송분만 18개로 재분산, 발송완료분 보존.
4. 각 계정 daily_limit 설정 — SES cap 면제이므로 워밍업 단계에 맞춰 보수적으로. 점진 ramp.
5. 옛 3개 도메인 발송 차단 — rinda_managed_sending_domains.is_active=false(chat은 이미 infinite 전용). MX·계정 row는 유지. ⚠️ user_email_accounts row를 절대 DELETE하지 말 것 — status='inactive'로만(옛 주소 수신 영구 보존, §6 참조).
6. 계측 추가 — 도메인별 발송 대비 답장 회수율 모니터링(현재 유실 시 로그조차 없음). 누락 조기 감지.

⚑옛 주소로 오는 메일 — 무엇이 유실을 부르나

질문: "평판 나쁜 도메인을 전부 교체하면, 바이어가 옛 주소로 직접 보내는 메일을 웹훅이 못 잡지 않나?" — 코드 직답

귀속 쿼리 원문 (webhook.service.ts:269-290)

옛 계정 정리 방식별 영향

왜 중요한가 — 옛 주소는 아직 활발히 수신 중

in-flight enrollment(특히 mail.rinda 24.7만)이 앞으로도 계속 발송→답장 유입. 옛 주소 수신 보존은 선택이 아니라 필수.

헤더 있는 답장 vs 직접 발신 — 둘 다 같은 게이트

스레드 매칭(message_id)이 성공해도 계정 귀속(to_email)이 단일 상위 게이트다. 귀속 0건이면 fallback에 도달조차 못 하고 return. 헤더 없는 직접발신도 to_email 귀속을 먼저 거친 뒤에야 addr/subject fallback을 탄다. 결국 옛 주소 row만 살아있으면 답장·직접발신 모두 잡힌다.

!코드의 구조적 빈틈 (별도 개선 권고)

• 발송 SSOT와 수신 인프라 drift 가능 — rinda_managed_sending_domains에 도메인 INSERT하면 발송은 즉시 시작되나, 그 도메인 MX/Receipt Rule 존재를 코드가 검증하지 않음. 풀 추가 전 수신 사전검증 게이트 부재.
• 유실 무계측 — 수신 인프라 누락 시나리오(a)는 로그·DB·격리(failed/) 어디에도 흔적 없음. CLAUDE.md preflight ⑦(오작동 감지) 위반 소지.
• reply_classification 99.5% null의 근본 — 도메인 문제가 아니라 스레드 매칭 실패로 email_replies row가 안 생기는 것. 수신 누락이 누적되면 분류율도 동반 하락.