450 4.2.1 메일 수신 지연 (지메일)

Problem

당신 메일 서버가 지메일로부터 450 4.2.1 응답을 기록합니다 — 흔히 “The user you are trying to contact is receiving mail too quickly. Please resend your message at a later time.” 문구와 함께요. 메일이 반송된 게 아니라 지연(deferred)된 것입니다.

Symptoms

• 하드 반송이 아니라 450 4.2.1이 메일 로그나 배달 지연 알림에 나타난다.
• 영향받는 메일이 전체가 아니라 지메일 수신자 한두 명에게 몰린다.
• 서버가 재시도한 뒤 메일이 결국 도착한다 — 또는 배달 경고에 해당 항목이 아직 큐에 남아 있다.
• Google Workspace SMTP 릴레이로 보낸다면, 같은 코드가 “peak SMTP relay limit” 문구와 함께 한 수신자가 아니라 전반적인 발송에 영향을 준다.

450 4.2.1이 실제로 뜻하는 것

그 문자열에는 두 가지가 담겨 있고, 중요한 건 맨 앞 숫자입니다. SMTP에서 4로 시작하는 응답은 일시 실패입니다 — RFC 3463은 4.x.x 등급을 “persistent transient failure(지속적 일시 실패)“라 부릅니다. ‘지금 말고 나중에’라는 뜻이고, 제대로 설정된 발송 서버는 자동으로 정확히 그렇게 합니다: 메시지를 큐에 두고 평소 일정대로 재시도하죠. 같은 향상된 코드의 영구 버전인 5.2.1(RFC 3463의 X.2.1 = “mailbox disabled, not accepting messages”)과 비교하면 이건 진짜 반송입니다. ‘기다려’와 ‘죽었다’의 차이가 숫자 하나입니다.

향상된 코드 4.2.1은 당신 도메인·인증·메시지 내용이 아니라 사서함을 가리킵니다. 지메일의 평이한 문구가 그대로 말해 줍니다: 수신자가 지메일이 사서함에 허용하는 속도보다 빠르게 메일을 받고 있다고요. 그건 그쪽 받은편지함의 속도 제한입니다. 흔한 이유는 수신자 측에 있습니다 — 메일을 그 계정으로 쏟아붓는 포워딩 루프, 대량 메일링 리스트로 인한 갑작스러운 적체, 실제 메일 폭탄 — 어느 것도 당신 발송 서버에서 닿을 수 없습니다. 그래서 일반적인 경우의 정직한 답은 불편하지만 단순합니다: 고칠 게 없습니다. 큐가 재시도하게 두면, 수신자 받은편지함이 비워질 때 메일이 도착합니다.

한 가지 변형은 따로 갈라야 합니다. Google Workspace로 릴레이하는데 문구에 “peak SMTP relay limit”이 있다면, 같은 450 4.2.1이 수신자 받은편지함이 아니라 당신의 릴레이가 처리량 허용치를 넘긴 것을 뜻합니다. 여전히 일시적이고 재시도로 풀리지만, 이번엔 근본 해법이 당신 쪽에 있습니다: 발송 속도가 튀지 않게 하세요.

Top 3 Causes

1. 수신자 사서함이 넘쳐나고 있다. 포워딩 루프, 리스트 트래픽 폭주, 메일 폭탄 때문에 그 받은편지함이 도착 속도보다 느리게 메일을 받아들인다. 신호: 지메일 주소 한두 개에 “receiving mail too quickly” 문구의 450 4.2.1이 뜨고, 재시도 후 저절로 풀린다. 당신이 고칠 문제가 아니다.
2. 당신이 그 폭주다. 앱 버그, 폭주하는 cron, 재시도 폭풍이 같은 수신자를 당신 쪽에서 두들기고, 지메일이 당신을 스로틀링한다. 신호: 반복 발송하는 단일 목적지에 450이 몰리고, 루프를 고치면 멈춘다.
3. Google Workspace 릴레이 피크 제한. Workspace SMTP 릴레이를 통한 발송이 허용 피크 속도를 넘겨 튄다. 신호: 문구에 “peak SMTP relay limit exceeded”가 있고, 한 수신자가 아니라 발송 전반에 영향을 준다.

Diagnose with DechoNet

• 이메일 점검은 발송 도메인의 SPF·DKIM·DMARC가 깨끗한지 확인합니다. 일시적 4.2.1은 인증 실패가 아니지만, 이것들이 망가져 있으면 곧 진짜 거부와 씨름하게 됩니다 — 미리 배제해 두면 이 450이 순수한 속도 문제이지 더 세게 스로틀링당할 도메인의 징후가 아님을 알 수 있습니다.
• 역방향 DNS 조회는 발송 IP에 유효한 PTR이 있는지 확인합니다. 좋은 역방향 DNS가 수신자 측 4.2.1을 풀어 주지는 않지만, 물량을 릴레이하며 지메일이 처리량을 신뢰하게 하려면 정방향 확인되는 PTR은 기본기입니다.

Resolution Checklist

• 코드만 보지 말고 응답 전체를 읽는다: “receiving mail too quickly”(수신자 받은편지함)인가 “peak SMTP relay limit”(내 릴레이)인가?
• 서버가 4xx를 영구 실패로 취급하지 않고 실제로 재시도하는지 확인한다 — 재시도 없는 단발 450은 지메일 문제가 아니라 잘못 설정된 큐다.
• 수신자 폭주 경우: 큐가 재시도하도록 두는 것 외엔 아무것도 안 한다. 전체 재시도 기간을 넘겨 메시지가 결국 타임아웃(배달 실패로 전환)될 때만 escalate한다.
• 자주 보내는 한 주소에 450이 몰리면, 당신 쪽 루프를 점검한다 — 버그 있는 재시도, 반복 실행되는 cron, 중복 발송.
• Workspace 릴레이 피크 제한이라면 발송 속도를 고른다: 폭주 대신 배치·페이싱으로 내보내고, 릴레이의 문서화된 처리량을 검토한다.
• 이메일 점검을 돌려 실제 SPF/DKIM/DMARC 문제를 배제하고, 이 450이 속도 제한 그 이상이 아님을 확실히 한다.

When to Escalate

• 특정 지메일 수신자에 대해 4.2.1이 서버의 전체 재시도 기간을 넘겨 계속 반복되어 영구 배달 실패로 전환될 때만 escalate하세요 — 그 시점엔 수신자 받은편지함이 막힌 것이고, 수신자(또는 그 관리자)가 풀어야 합니다.
• 페이싱으로도 안 풀리는 지속적 Workspace 릴레이 피크 제한 4.2.1이라면, 발송 물량과 정확한 응답 문구를 들고 Google Workspace 지원에 문의하세요.