금요일에 메일 서버를 가동하세요. 토요일 아침까지 인터넷에 10,000개의 메시지를 보내세요. 일요일이 되면 지구상의 모든 사서함 제공업체들은 당신이 봇넷이라고 확신합니다. 당신의 이메일은 스팸으로 전송됩니다. 당신의 IP는 차단 목록(blocklist)에 오릅니다. 당신의 팀은 비상 호출을 받습니다. 일요일은 망칩니다.

우리는 이것을 했습니다. 실제로 발생했던 일입니다.

새로운 IP가 위험한 이유 (Why New IPs Are Radioactive)

Gmail은 203.0.113.42가 누구인지 모릅니다. Microsoft도 모릅니다. Yahoo도 모릅니다. 그들에게 이 IP는 어디선가 나타나, 대량으로 메일을 쏟아내기 시작했고, 패턴 기록이 전혀 없습니다.

새로운 서버가 대량의 메일을 보내는 것은 이러한 시스템들에게 손상된 호스트(compromised host)와 구별할 수 없을 정도로 똑같습니다. 그들은 당신의 DKIM이나 SPF 서명에는 (아직) 신경 쓰지 않습니다. 그들이 보는 것은 다음과 같습니다:

• 이전에 접한 적 없는 IP
• 지금 대량으로 메시지를 전송하는 행위
• 장기적인 행동 패턴 부재
• => 이 인프라는 도난당했을 확률이 높음

Gmail의 대응: 이 IP에 속도 제한(rate limit)을 겁니다. 아무것도 못하게 제동을 걸 겁니다.
Microsoft의 대응: 이 IP에 속도 제한(rate limit)을 겁니다. 아무것도 못하게 제동을 걸 겁니다.
모든 제공업체들이 독립적으로 판단합니다: 이건 안 좋아 보인다.

당신의 메일은 대기열에 쌓입니다. 당신은 네트워크가 느리다고 생각하고 더 강하게 밀어붙입니다. 더 많이 보냅니다. 시스템들은 알려지지 않은 IP로부터 더 많은 양을 감지합니다. 그들은 그것을 차단 목록에 추가합니다.

월요일이 되면, 당신은 오프라인 상태가 됩니다. 문서에는 복구 계획이 없습니다. 왜냐하면 아무도 첫날부터 이런 일이 발생할 것이라고 예상하지 못하기 때문입니다.

실제 해결책: 느린 속도가 유일하게 통하는 속도 (Slow Is The Only Speed That Works)

더 좋은 코드로 고칠 수 없습니다. 인증(authentication)으로 고칠 수 없습니다. 돈을 주고 빠져나갈 수도 없습니다.

효과적인 방법은 **IP 워밍업 스케줄(IP warmup schedule)**입니다. 볼륨을 천천히 늘려가야 합니다.

Days 1-2:    50 messages/IP/day
Days 3-4:   100 messages/IP/day
Days 5-6:   200 messages/IP/day
...

0개의 반송(bounce)과 0개의 불만 접수(complaints)를 가정할 때, 4주가 지나면 프로덕션 볼륨에 도달합니다.

왜 느려야 할까요? 수신자들은 볼륨 증가 속도를 신호로 사용합니다. 그들에게는 두 가지 패턴이 있습니다:

*패턴 1 *(봇넷): 나타남 → 범람(flood) → 사라짐
*패턴 2 *(실제 서비스): 나타남 → 점진적 증가 → 일관성 유지

점진적으로 늘리면(ramp) 그들은 당신을 믿습니다. 급증하면(spike) 그들은 당신을 차단합니다.

냉혹한 진실은 이렇습니다: 이 타임라인을 압축할 수는 없습니다. 평판(Reputation)은 좋은 도메인을 가졌다고 해서 생기는 것이 아닙니다. SPF/DKIM 덕분에 생기는 것도 아닙니다 (그것들은 기본 요건(table stakes)일 뿐입니다). 평판은 시간 + 깨끗한 전달 지표(delivery metrics) + 증가하는 볼륨으로 정기적으로 나타나는 것에서 비롯됩니다.

지름길은 없습니다. 이를 더 빠르게 해제할 수 있는 API도 없습니다. 지구상의 모든 메일 제공업체는 동일한 방식으로 이를 처리합니다.

진짜 해결책: 풀 아키텍처 (Pool Architecture) (편법이 아닌 필수 사항)

하나의 IP + 하나의 워밍업(warmup) 일정 = 당신은 영원히 한계에 갇히게 됩니다.

확장할 수 있는 유일한 방법은 다음과 같습니다: 여러 개의 IP를 사용하고, 각 IP를 독립적으로 워밍업하며, 각 제공업체별로 각각 별도로 추적하는 것입니다.

Gmail은 203.0.113.40을 확인 → 하루 50건 확인 → 평판: 구축 중
Microsoft는 203.0.113.41을 확인 → 하루 50건 확인 → 평판: 구축 중
Yahoo는 203.0.113.42을 확인 → 하루 50건 확인 → 평판: 구축 중

각 제공업체는 자신만의 판단 기준을 가지고 있습니다. Gmail이 보는 1번 IP에 대한 관점은 Microsoft가 동일한 IP에 대해 갖는 관점과 아무런 관련이 없습니다.

이것이 중요한 이유는 다음과 같습니다: **Gmail의 속도 제한(rate-limiting)**이 .40 IP에 적용되어도 Outlook 전달 속도는 느려지지 않기 때문입니다. 별도의 풀(pool)이 없다면, Gmail이 당신을 제한(throttle)하는 순간 다른 모든 곳에서도 동일한 속도 저하를 겪게 됩니다. 당신의

점수 산정 방식은 다음과 같습니다:

사용자로부터의 스팸 신고 1건           → 0.65를 곱함
                                          (계정 강제 정지)
바운스(Bounce) 1건 (영구적, 잘못된 주소) → 0.5를 곱함
...

해석하자면: 평판(Reputation)을 쌓는 데는 수개월이 걸리지만(느린 가산적 이득), 당신을 스팸으로 표시한 사용자로부터의 신고 단 한 건만으로도 계정은 즉시 폐쇄됩니다.

이러한 비대칭성은 의도된 것입니다. 이는 스팸 발송을 경제적으로 어리석게 만듭니다. 깨끗한 평판을 육성하는 비용은 실제 시간과 깨끗한 지표(metrics)입니다. 이를 망쳤을 때의 대가는 계정의 완전한 상실입니다.

실제로 우리를 괴롭혔던 함정들

모든 IP가 동시에 속도 제한(Rate-Limit)에 걸릴 때

그런 일이 발생합니다. 4개의 IP가 모두 Gmail의 제한에 걸립니다. 4개 모두 Outlook의 제한에 걸립니다. 모든 것이 0으로 제한(throttle)됩니다.

이때 당신은 어떻게 하시겠습니까?

• 영원히 큐(Queue)에 쌓아둔다 (사용자는 기다려야 하며, 일부 메일은 타임아웃 발생)
• 제한을 무시하고 그냥 보낸다 (워밍업(warmup) 일정을 깨뜨리며, 아마도 평판 측면에서 원점으로 돌아가게 될 것임)

우리는 다음과 같은 선택을 했습니다: 제한을 무시하고, 전송하며, 무슨 일이 일어났는지 기록한다.

논리는 이렇습니다: 메일을 조용히 누락시키는 것이 워밍업 일정을 약간 위반하는 것보다 더 나쁩니다. 하지만 모든 것을 기록하기 때문에, 용량 한계에 도달하기 직전이 언제인지 알 수 있습니다.

역방향 DNS 체크포인트 (아무도 언급하지 않는 관문)

Gmail이나 Outlook이 당신의 DKIM 또는 SPF를 고려하기도 전에, 그들은 역방향 DNS(reverse DNS)를 확인합니다.

dig -x 203.0.113.40
# 반환값: mail-out-001.atomicmail.com

...

이것이 FCrDNS (Forward-Confirmed Reverse DNS)입니다. 이 확인을 통과하지 못하면, 수신 측은 단 하나의 서명(signature)을 확인하기도 전에 당신의 연결을 거부합니다.

mail-out-5.ec2.compute.internal?와 같은 일반적인 AWS rDNS는? 끝입니다. 수신 측은 이를 보고 연결 단계에서 거부하며, DKIM 검증조차 실행하지 않습니다.

우리의 각 아웃바운드(outbound) IP는 전용 호스트네임(hostname)을 가집니다:

203.0.113.40 → mail-out-001.atomicmail.com
203.0.113.41 → mail-out-002.atomicmail.com
203.0.113.42 → mail-out-003.atomicmail.com

각 호스트는 자신의 호스트네임으로 HELO를 수행합니다. 각 PTR 레코드는 자기 자신을 가리킵니다.

SPF가 당신의 풀(pool)을 노출시킨다

만약 당신의 SPF 규칙에 모든 IP가 나열되어 있다면:

v=spf1 ip4:203.0.113.40 ip4:203.0.113.41 ip4:203.0.113.42 ... -all

스패머(Spammers)는 당신의 SPF를 읽습니다. 그들은 당신의 전체 IP 풀(pool)을 확인합니다. 어떤 IP들이 존재하는지 알게 됩니다. 그들은 반쯤 예열된 (half-warm) IP를 탐색하여 그곳에서 스팸을 보낼 수 있습니다.

더 나은 관행: 최소한의 SPF (주요 IP만 포함). 보조 풀(secondary pools)을 공개해야 하는 경우 서브도메인(subdomains)에 대해 include 지시문을 사용하세요. 전체 명단을 숨기십시오.

비용 vs. 보상

지불하는 비용:

• 4-10개의 전용 IP (dedicated IPs): 월 $20-200
• 전용 역방향 DNS (reverse DNS): IP와 함께 제공됨
• 인적 시간: 3-6주간의 예열 (warmup) (전속도로 발송하는 것이 아님)

얻는 보상:

• 95% 이상의 받은 편지함(inbox) 도달률 (대량으로 투입된 콜드 IP(cold IPs)의 50-70% 도달률 대비)
• 남용 방지 팀(abuse teams)으로부터의 항의 전화 없음
• 블랙리스트(blocklisted)에 오르지 않고 확장할 수 있는 능력

우리가 틀렸던 한 가지 (그리고 수정한 것)

우리는 가입 시에 보편적인 작업 증명(proof-of-work) 난이도를 적용하려 했습니다. 모두에게 동일한 하나의 난이도 값을 적용한 것입니다.

자본력이 있는 사람들이 계정을 대량 생성(farm)하기에는 너무 쉬웠습니다. 반면, 정당하게 가입하려는 구형 휴대폰 사용자들에게는 너무 어려웠습니다.

수정 사항: 평판에 따른 난이도 조절 (reputation-scaled difficulty). 깨끗한 IP가 가입한다면? 난이도 4. 알려진 악성 IP라면? 난이도 8. 이것은 별개의 문제이지만, 핵심은 같습니다. 모든 상황에 들어맞는 단 하나의 숫자는 없습니다.

예열(warmup)도 마찬가지입니다. 치트 코드는 없습니다. 그것은 시간 + 모니터링 + 규율의 조합입니다. Gmail의 알고리즘과는 협상할 수 없습니다.