문제

메일이 반송되거나 메일 서버 로그에 452 4.5.3 Too many recipients가 찍힙니다. 때로는 452 4.5.3 Your message has too many recipients라고 나옵니다. 뉴스레터 스크립트, 300명 목록에 “전체 답장”, 모든 고객을 참조로 넣는 크론 잡에서 흔합니다. 메일이 고장 났으니 재시도하면 풀리겠지 싶지만, 저절로는 안 풀립니다. 한 메일에 수신자를 너무 많이 넣었고, 경로 상의 어느 서버가 그 전부를 한 번에 받기를 거부한 겁니다.

증상

  • 반송문이나 로그 줄에 452 4.5.3과 “too many recipients” 문구가 붙습니다.
  • 작은 발송은 되는데, 수신자 목록이 큰 메일에서만 실패가 나타납니다.
  • 그 메일의 일부 수신자는 받았고, 넘친 나머지만 반송됐습니다.
  • 똑같은 메일을 다시 보내면 매번 정확히 같은 거부가 재현됩니다.
  • 손으로 두어 명 칠 때가 아니라 자동 경로 — 스크립트, 메일링 도구, 큰 그룹에 보내는 프린터/스캐너 — 에서 터집니다.

452 4.5.3이 실제로 뜻하는 것

코드를 두 조각으로 읽으세요. 452는 SMTP 응답(RFC 5321)으로 일시적 부정 — 클래스 4는 “명령은 성공 못 했지만 조건이 일시적이라 다시 시도해도 된다”(§4.2.1)는 뜻입니다. 4.5.3은 확장 상태 코드로, RFC 3463이 정확히 정의합니다: “Too many recipients — 그 메일에 대해 전달 가능한 것보다 많은 수신자가 지정됐다.” RFC 3463은 정의 안에 처방까지 넣었습니다: 메일을 나눠서 남은 수신자를 다음 시도에 전달하라.

여기엔 SMTP 역사가 한 조각 박혀 있습니다. 1982년 원조 규격인 RFC 821은 수신자 초과 오류를 응답 코드 552 아래에 넣었습니다. RFC 5321 §4.5.3.1.10이 이를 바로잡았습니다: “트랜잭션당 수신자 한도에 걸렸다”의 올바른 코드는 452이며, 이 코드를 받은 클라이언트는 이미 수락된 수신자에게 전달한 뒤 거부된 나머지를 새 트랜잭션으로 재시도해야 한다는 것입니다. 설계 의도가 이게 전부입니다 — 452 4.5.3은 “네 메일이 거부됐다”가 아니라 “더 작은 묶음으로 보내라”입니다.

애초에 하한이 있는 이유도 있습니다: RFC 5321 §4.5.3.1.8은 모든 SMTP 서버가 메일당 최소 100명의 수신자를 버퍼링하도록 요구합니다. RCPT가 100명 미만인 메일을 “너무 많다”고 거부하면 규격 위반입니다. 100명을 넘으면 서버가 한도를 둘 수 있고, 그럴 때 예의 바른 클라이언트는 100명 단위로 나눠 보내야 합니다.

주요 원인 3가지

  1. 하드한 메일당 한도를 넘었다. Gmail의 SMTP 경로(smtp.gmail.com, smtp-relay.gmail.com)는 한 트랜잭션에서 100명을 넘으면 바로 이 코드로 거부합니다. 단서: 같은 메일이 항상 같은 크기에서 실패하고, 받는 쪽이 대형 제공자입니다. 해법은 그쪽 설정이 아니라 내 쪽에서 나눠 보내는 것입니다.
  2. 받는 메일 서버의 설정이 한도를 걸었다. Postfix는 smtpd_recipient_limit(기본 1000)를 넘으면 452 4.5.3 Error: too many recipients로 거부합니다. 온프레미스 Exchange 수신 커넥터는 MaxRecipientsPerMessage 기본값이 200이고, 발신 서버가 부하를 나누게 하려고 일부러 452 4.5.3을 반환합니다. 단서: 받는 서버를 내가 통제하거나 물어볼 수 있고, 숫자가 딱 떨어집니다.
  3. 영구 한도를 일시적인 것으로 착각했다. 코드가 사실 550 5.5.3(또는 Exchange의 RESOLVER.ADR.RecipLimit)이라면 그건 영구 쌍둥이 — 커넥터 한도가 아니라 전송 전체나 사서함별 봉투 한도입니다. 재시도로는 절대 안 풀립니다. 단서: 4xx가 아니라 5xx입니다. 해법은 같지만(목록 분할), “기다리면 들어간다”는 없습니다.

DechoNet으로 진단

  • 이메일 확인 — 수신 도메인의 MX·SPF·DKIM·DMARC를 한 번에 가져옵니다. 수신자 수를 세지는 않지만, 받는 쪽이 그 외엔 정상인지 확인해 452 4.5.3이 순전히 수신자 수 문제이지 다른 얼굴을 한 인증 반송이 아님을 알 수 있습니다.
  • DNS 조회 — MX가 실제로 생각한 곳을 가리키는지 확인해, 엉뚱한 서버(낡았거나 split-MX인 대상)의 한도를 쫓지 않도록 합니다.

해결 체크리스트

  • 반송문을 읽고 정확한 코드를 확인하세요 — 452 4.5.3(일시적, 넘친 나머지 재시도)인지 550/552 5.5.3(영구, 나누기 전엔 어떤 재시도도 성공 못 함)인지.
  • 어느 서버가 냈는지 Received/거부 줄에서 파악하세요 — 내 발신 릴레이인지, 수신자의 MX인지. 그 서버가 한도의 주인입니다.
  • 수신자 목록을 그 서버의 한도 이하로 나누고(Gmail SMTP의 ≤100은 안전한 보편 하한) 각 묶음을 별개 트랜잭션으로 보내세요.
  • 받는 서버를 내가 운영하고 정상 내부 발신자에게 한도가 너무 낮다면, 가드레일을 통째로 없애지 말고 올바른 손잡이를 올리세요 — Postfix smtpd_recipient_limit, Exchange 커넥터 MaxRecipientsPerMessage.
  • 대량·목록 메일이라면 거대한 RCPT 목록을 직접 만들지 말고, 자동으로 묶고 속도를 조절하는 메일러나 ESP를 쓰세요.
  • 나눠 보낸 테스트를 다시 보내 452 4.5.3이 사라졌는지 확인하세요.

이럴 땐 넘겨야 한다

  • 메일당 수신자를 100명 아래로 나눴는데도 452 4.5.3이 계속 나오면, 메일 안의 수 자체가 진짜 방아쇠가 아닙니다 — 하루 수신자 한도나 속도 제한(흔히 421 4.7.x로 표출)을 찾으세요. 이건 메일당 문제가 아니라 볼륨·평판 문제입니다.
  • 내가 통제하지 않는 서버에서 550 5.5.3이 온다면, 수신자 관리자가 내 발송 크기보다 낮게 봉투 한도를 걸어 둔 겁니다. 클라이언트 쪽 재시도로는 안 풀립니다 — 더 작은 묶음 크기를 조율하거나 그쪽에 내 발신자용 한도 조정을 요청하세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.