문제

메일이 반송되는 게 아니라 — 정확히는 지연됩니다. 로그에는 452 4.2.2가 “mailbox full”, “over quota”, 또는 “Requested action not taken: insufficient system storage” 같은 문구와 함께 뜨고, 메시지는 곧장 실패하는 대신 큐에 앉아 있습니다. 본능적으로 이걸 거부처럼 다루며 SPF·DKIM·IP 평판을 감사하기 시작합니다. 그 본능이 틀렸습니다. 452는 ‘안 돼’가 아닙니다. ‘지금은 안 돼’이고, 앞자리 숫자가 그렇게 말해줍니다: 4xx는 일시적입니다. 수신 서버는 연결을 받았고 주소를 인식했으며, 그러고 나서 목적지 메일함에 메시지를 넣을 공간이 없음을 발견했습니다. 그건 상대 쪽 저장공간 문제이고, 대개 저절로 풀립니다.

증상

  • 응답에 452 4.2.2(때로 452-4.2.2로 표기)가 메일함이 꽉 찼다거나 할당량 초과라는 문구와 함께 실려 있다.
  • 메시지가 즉시 반송되지 않고 큐에 남아 재시도한다 — 메일 로그에 같은 수신자에게 반복 지연이 보인다.
  • 한 수신자 또는 몇 명에게만 영향을 주고, 같은 도메인의 나머지는 정상으로 받는다.
  • SPF·DKIM·DMARC가 모두 통과하고, 다른 발송자가 같은 주소로 보내도 똑같이 지연된다.
  • 당신 쪽 변경 없이 나중 재시도에서 그냥 성공하기도 한다 — 수신자가 메일함을 비웠기 때문이다.

452 4.2.2가 실제로 뜻하는 것

코드를 둘로 쪼갭시다. 기본 응답 452는 RFC 5321에서 “요청한 동작 미실행: 시스템 저장공간 부족”으로 정의되고, 4yz 코드이므로 §4.2.1이 이를 일시적 부정 완료로 분류합니다 — 명령은 실패했지만 “오류 조건이 일시적”이고 “동작을 다시 요청할 수 있다”는 뜻입니다. 확장 코드 4.2.2가 이를 좁힙니다: 2번 클래스가 메일함이고, X.2.2는 구체적으로 “메일함 꽉 참”입니다. 합치면 452 4.2.2는 이렇게 읽힙니다: 이 수신자의 메일함이 지금 할당량을 넘었으니 나중에 다시 시도하라.

이 중 어느 것도 당신에 관한 게 아닙니다. 완벽하게 인증된 메시지도 대상 메일함이 꽉 차면 똑같이 지연됩니다. 당신의 DNS나 SPF나 발송 IP 어디에도 꽉 찬 메일함이 메일을 받게 만들 것은 없습니다 — 오직 시간, 또는 수신자가 공간을 비우는 것만이 그렇게 합니다.

서버가 이걸 처리한다는 게 핵심인 이유

452가 552와 별개 코드로 존재하는 이유는 예의 바른 발송자가 포기하지 않게 하기 위해서입니다. 당신의 MTA가 452를 받으면 메시지를 큐에 넣고 백오프 스케줄로(RFC 5321 §4.5.4.1) 재시도해야 합니다 — 몇 분, 그다음 더 길게, 또 더 길게 — 하루 이상 동안, 실패를 영구로 취급하기 전까지. 이게 시스템이 제대로 도는 모습입니다: 수신 측의 일시적 문제는 자동으로 견뎌내지고, 대부분의 452는 발송자가 포기하기 전에 해소됩니다.

그래서 당신이 할 수 있는 최악의 두 가지는 둘 다 조급함의 형태입니다:

  • 손으로 다시 보내기는 공간이 비는 순간 한꺼번에 배달될 중복 사본을 만듭니다.
  • 재시도를 끄거나 짧게 줄이기는 스스로 낫는 소프트 바운스를 잃어버린 메시지로 바꿉니다.

큐를 그냥 두세요. 재시도 구간 안에 메일함이 비워지면 — 대부분 그렇습니다 — 배달이 완료되고 문제가 있었다는 걸 아무도 눈치채지 못합니다.

일시적이지 않게 되는 순간

452는 메일함이 여전히 꽉 찬 채로 발송자의 재시도 타임아웃이 다 되면 진짜 반송이 됩니다. 그 지점에서 일시적 452 4.2.2는 영구 552 5.2.2(또는 550 5.2.2)로 격상됩니다 — 같은 ‘용량 초과’ 뜻이지만 이제 발송자가 그만뒀고 메시지가 되돌아옵니다. 며칠째 지연 중인 메시지를 지켜보고 있다면, 그때가 다른 경로로 수신자에게 연락해 공간을 비우라고 알릴 순간입니다. 영구 실패 쪽은 552 5.2.2 메일함 꽉 참 가이드를 보세요. 그리고 지연 문구가 452가 아니라 451이라면, 아주 다른 방식으로 저절로 풀리는 그레이리스팅일 수 있습니다.

DechoNet으로 진단하기

  • 이메일 점검은 문제가 아닌 쪽을 확인해줍니다: 수신 도메인의 MX·SPF·DMARC를 읽어 당신 인증을 한 번에 배제하고, 당신과 무관한 반송을 쫓지 않게 해줍니다.
  • 역방향 DNS 점검은 지연이 예상 구간을 넘겨 계속될 때만 볼 가치가 있습니다 — 유효한 PTR이 없는 발송 IP는 잠깐이어야 할 452를 결코 풀리지 않는 정책 지연으로 바꿀 수 있습니다. 같은 코드를 뒤집어쓴 다른 실패인 셈이죠.

해결 체크리스트

  • 확장 코드가 4.2.2(수신자 메일함 꽉 참)인지, 4.3.1(수신 서버 디스크 부족)인지 확인 — 고칠 주체가 다르다.
  • 메시지가 반송이 아니라 큐에서 재시도 중인지 확인. 4xx는 여전히 메일 큐에 있어야 한다.
  • 손으로 다시 보내지 말 것 — 메일함이 비면 중복이 생긴다.
  • 수신자 한정인지 확인: 같은 도메인의 다른 주소로는 여전히 배달된다.
  • 스스로를 배제: SPF·DKIM·DMARC가 통과하므로 인증 문제가 아니다.
  • 약 24~72시간을 넘겨 계속되면 영구 552 5.2.2로의 격상을 예상하고, 다른 경로로 수신자에게 공간을 비우라고 알린다.

당신이 수신 서버를 운영한다면

자기 사용자들의 수신 메일이 452 4.2.2로 지연된다면, 할당량은 DNS가 아니라 메일 서버의 사서함별로 설정됩니다 — Dovecot의 quota 플러그인, Exchange의 ProhibitSendReceiveQuota, cPanel/Plesk의 계정별 이메일 할당량. 해당 사용자의 한도를 올리거나, 더 낫게는 하드 할당량 아래에 경고 임계값을 둬서 메일이 지연되기 전에 사람들에게 알리세요. 메일 스풀의 df도 거의 꽉 찼고 모든 사서함이 한꺼번에 지연된다면, 이건 4.3.1 모양의 디스크 문제이고 해결책은 사용자별 숫자가 아니라 저장공간입니다.

내 도메인에서 바로 확인

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