문제

메일이 552 5.2.2와 “The email account that you tried to reach is over quota” 또는 그냥 “Mailbox full” 같은 문구와 함께 반송됩니다. 반사적으로 SPF·DKIM을 뒤지러 가게 되는데 — 그게 틀린 반사입니다. 이 코드는 당신이 누구인지, 인증됐는지와 무관합니다. 수신자에게 남은 공간이 없다는 뜻입니다. 받는 서버는 당신의 연결을 받아들이고, 주소를 인식하고, 자격증명을 확인한 다음, 메일을 넣어야 할 그 메일함이 저장 한도에 도달했다는 걸 발견한 겁니다. 이건 회선 반대편의 문제이지 당신 쪽 문제가 아닙니다.

증상

  • 반송에 552 5.2.2(때로 550 5.2.2 또는 일시 코드 452 4.2.2)가 메일함 가득/용량 초과 문구와 함께 붙습니다.
  • 같은 도메인의 다른 사람들은 멀쩡히 받는데 특정 수신자 한 명이나 소수에게만 걸립니다.
  • 내 SPF·DKIM·DMARC는 모두 통과 — 그리고 그 주소로는 다른 발신자의 메일도 반송됩니다.
  • Gmail 수신자면 정확한 문구는 552-5.2.2 The email account that you tried to reach is over quota입니다.
  • 당신 쪽 변화 없이 그 주소가 다시 메일을 받기 시작하기도 합니다 — 수신자가 공간을 비웠기 때문입니다.

552 5.2.2가 실제로 뜻하는 것

두 개의 별개 주장으로 읽으세요. 552는 SMTP 응답 코드이고, RFC 5321 §4.2.3은 이를 “Requested mail action aborted: exceeded storage allocation”(저장 할당량 초과로 작업 중단)으로 정의합니다. 5.2.2는 RFC 3463의 enhanced status code로, X.2.2는 정확히 **“Mailbox full”**로 정의됩니다: “사용자가 메일함별 관리 할당량 또는 물리적 용량을 초과해 메일함이 가득 참”, 그리고 수신자가 메시지를 지워 공간을 만들 수 있다는 주석이 달립니다.

알아둘 만한 표준의 작은 특이점이 하나 있는데, 왜 같은 상황에 코드가 둘 보이는지 설명해 줍니다. RFC 3463은 원래 X.2.2를 persistent transient(지속되는 일시적) 실패로 기술했습니다 — 즉 RFC상 올바른 짝은 class-4 응답 452 4.2.2(“지금은 꽉 참, 나중에 시도”)입니다. 하지만 대부분의 큰 수신 서버는 재시도가 소용없어지면 같은 5.2.2 세부코드를 영구 5xx 응답과 짝지어 보냅니다. 그래서 점 뒤 숫자는 원인(메일함 가득)을, 점 앞 숫자는 서버가 아직 재시도할 의향이 있는지를 알려줍니다:

  • 452 4.2.2 — 일시. 메일함이 지금 꽉 찼음. 발신 서버는 메일을 큐에 두고 재시도해야 합니다. 당황하지 마세요.
  • 552 5.2.2(또는 550 5.2.2) — 영구. 서버가 포기했습니다. 메일은 죽었고 재시도되지 않습니다. 수신자가 공간을 확보한 뒤 다시 보내야 합니다.

어느 쪽이든 해결은 그 메일함을 통제하는 사람의 몫입니다. 이건 “당신이 할 수 있는 게 없다”가 기술적으로 맞는 답인 드문 반송입니다 — 아래 두 가지 단서만 빼고.

내 쪽에서 확인할 두 가지

남의 받은편지함에 저장 공간을 더해줄 수는 없지만, 올바른 에러를 진단하고 있는지는 확인할 수 있습니다:

  1. 5.2.2가 아니라 5.3.4일 수 있습니다. 552 5.3.4(“메시지가 고정 최대 크기를 초과”)는 앞의 552는 같지만 완전히 다른 문제입니다 — 당신 메시지가 수신자의 크기 상한을 넘은 것이고, 첨부를 줄이거나 링크로 바꾸면 해결됩니다. enhanced 코드가 5.3.4면 여기서 멈추세요. 이건 당신 쪽입니다. 오직 5.2.2만 용량 문제입니다.
  2. 진짜 용량 반송인지, 용량 문구를 빌린 필터인지 확인하세요. 일부 수신 서버·스팸 필터는 완곡한 거절을 용량 형태로 돌려줍니다. 도메인 전체가 갑자기 5.2.2로 반송된다면 — 한 명의 헤비 유저가 아니라 — 의심하고, 모두의 받은편지함이 동시에 찼다고 가정하기 전에 당신의 인증과 평판부터 검증하세요.

DechoNet으로 진단하기

  • 이메일 점검은 도메인의 SPF·DKIM·DMARC·MTA-STS를 한 번에 가져옵니다. 수신자의 용량은 못 봅니다 — 바깥에서 볼 수 있는 건 아무것도 없습니다 — 하지만 발신 쪽이 깨끗함을 증명해, 이 반송이 당신 설정이 아니라 상대 저장 공간 문제임을 자신 있게 알릴 수 있습니다.
  • 역방향 DNS 조회는 발신 IP의 PTR/FCrDNS가 건강한지 확인해, 사람들이 메일함 가득과 자주 혼동하는 다른 5.7.x 거부 계열을 배제합니다.

해결 체크리스트

  • 552만 보지 말고 enhanced 코드를 읽으세요. 5.2.2 = 수신자 메일함 가득. 5.3.4 = 메시지 너무 큼(당신 해결). 5.7.x = 인증/정책(완전히 다른 가이드).
  • 452 4.2.2(일시 — 큐에 두면 배달될 수도)인지 552/550 5.2.2(영구 — 나중에 재전송)인지 확인하세요.
  • 수신자 한 명이면: 공간을 비우라고 알리세요(휴지통 비우기, 큰 메일/파일 삭제, 용량 추가). 발신자 쪽 해결책은 없습니다.
  • 이메일 점검으로 SPF·DKIM·DMARC 통과를 확인해, 수신자와의 대화가 당신 도메인이 아니라 상대 저장 공간에 머물게 하세요.
  • 도메인 전체가 한꺼번에 걸리면 대규모 용량 초과로 단정하지 말고 — 인증과 IP 평판부터 확인하세요. 필터가 용량 코드를 빌려 쓰고 있을 수 있습니다.
  • 반송되는 사용자가 당신 서버에 있다면, 메일함별 할당량(Dovecot/Exchange/cPanel/Zimbra)을 올리고 메일 스풀의 디스크 공간을 확인하세요.

에스컬레이션 시점

  • 수신자가 당신이 통제하지 못하는 메일 플랫폼에 있고 메일함이 안 찼다고 우기면, 전체 계정 저장 용량을 확인하라고 하세요 — Gmail과 Microsoft 365는 할당량을 메일·드라이브·포토가 공유하므로, 드라이브가 꽉 차면 메일이 조용히 막힙니다.
  • 당신 도메인의 메일함이 전반적으로 5.2.2로 반송되면 메일 서버 운영자에게 넘기세요: 대개 스풀 디스크 가득이거나 전역 할당량이 너무 낮게 잡힌 것이고, 개별 사용자 조정이 아니라 저장 공간 해결이 필요합니다.
  • 인증이 깨끗하고 수신자가 여유 공간을 확인했는데도 5.2.2가 계속 뜨면, 헤더가 포함된 전체 반송을 캡처해 받는 쪽 postmaster에게 가져가세요 — 그 시점엔 상대 쪽 용량 계산이 깨진 것이고, 그건 그들만 볼 수 있습니다.

내 도메인에서 바로 확인

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