451 4.7.1 메일 지연·그레이리스팅 해결

Problem

메일이 안 나가고 로그에 451 4.7.1 Please try again later 또는 451 4.7.1 Service unavailable - try again later 같은 게 찍힙니다. 거절처럼 읽혀서 다시 보내거나 반송인가 싶어 당황하게 됩니다. 둘 다 틀렸습니다. 451은 SMTP식 “5분 뒤에 다시 오세요”이고 — 새 발신자의 첫 메일이라면 열에 아홉은 그레이리스팅이 설계된 대로 정확히 작동하는 것입니다.

Symptoms

• 메일이 반송이 아니라 지연됩니다 — 영구 실패가 아니라 451 상태로 발신 큐에 남아 있습니다.
• 수신자에게 보내는 첫 메일에서(또는 새로 구축한 발신 서버에서) 발생하고, 그다음엔 멈춥니다.
• 잠시 후 같은 메일이 아무 조치 없이도 배달됩니다.
• 4.7.1이 구체적으로 보이고, 때로 “greylisted”, “try again later”, “temporarily deferred”로 표현됩니다.

4xx는 5xx가 아니다 (여기서 왜 중요한가)

SMTP는 모든 실패를 두 통에 나눠 담는데, 이 둘을 헷갈리는 게 451 공포의 뿌리입니다.

5xx 응답은 영구적입니다. 550은 서버가 최종 결정을 내린 것입니다: 이 메일은 받지 않으니 그만 시도하라. 그게 반송이고, 발신자는 배달 불가 보고서를 받습니다.

4xx 응답은 일시적입니다. 451은 서버가 지금은 메일을 받을 수 없거나 받지 않겠다는 뜻이지만 다시 시도하라고 권합니다. RFC 5321은 이를 transient negative completion이라 부르고, 규격을 따르는 모든 발신 MTA는 똑같이 처리합니다: 메일을 큐에 두고 타이머에 맞춰 재시도합니다. 손으로 다시 보낼 필요 없습니다 — 메일 서버가 이미 처리하고 있습니다.

확장 코드 4.7.1(RFC 3463 상태 레지스트리)은 이것이 자원 문제가 아니라 정책 결정임을 표시합니다. 그레이리스팅이 바로 정책이고, 그래서 정확히 이 코드에 걸립니다.

그레이리스팅이 실제로 하는 일

그레이리스팅(RFC 6647에 정리됨, 2000년대 초부터 쓰이던 관행)은 무례할 정도로 단순하고, 그래서 통합니다.

메일이 도착하면 수신자는 트리플릿을 기록합니다: 발신 IP 주소, 봉투 발신자(envelope sender), 수신자. 이 트리플릿을 처음 본다면 451로 응답하고 일단은 메일을 거부합니다. 그리고 기다립니다. 규칙을 따르는 정상 메일 서버는 자기 지연 간격 뒤 그 메일을 재시도합니다. 설정된 최소 대기 시간이 지난 뒤 재시도가 도착하면, 수신자는 트리플릿을 알아보고 메일을 받아들이며, 대개 그 발신자를 기억해 이후 메일은 대기를 건너뛰게 합니다.

핵심은 무엇을 걸러내느냐입니다. 스팸의 상당수는 재시도 로직을 아예 구현하지 않은 fire-and-forget 소프트웨어가 보냅니다 — 한 번 쏘고 넘어갑니다. 그런 발신자는 451을 맞고 다시 돌아오지 않으므로 그 메일은 영영 배달되지 않습니다. 그레이리스팅은 첫 정상 메일을 몇 분 늦추는 대가로 상당량의 쓰레기를 버립니다. 값싼 방어, 실질적 이득.

Top 3 Causes

1. 첫 접촉에서의 전형적 그레이리스팅. 누군가에게(또는 새 서버에서) 처음 메일을 보내는데 트리플릿이 미지라 수신자가 한 번 미룹니다. 신호: 첫 메일이고, 몇 분에서 1시간 안에 재시도로 풀리며, 같은 수신자에게 가는 이후 메일은 곧장 지나갑니다.
2. 발신 소스 IP가 순환하는 구성. 메일이 서로 다른 IP를 가진 서버 풀을 통해 나가면, 트리플릿이 바뀌므로 새 IP마다 그레이리스팅이 다시 걸릴 수 있습니다. 신호: 완전히 안정되지 않는 간헐적 451이 어느 서버가 보냈는지와 상관관계를 보입니다.
3. 같은 코드를 뒤집어쓴 평판 지연. 몇 시간 내내 지속되는 451 4.7.1은 그레이리스팅이 아닙니다 — 수신자가 발신 IP 평판 때문에 메일을 붙잡는 것입니다: PTR 없음/불일치, SPF/DKIM 실패, 발신 이력 없음, 블록리스트 등재. 신호: 재시도로 절대 풀리지 않고, 첫 접촉 이상으로 영향을 미칩니다.

Diagnose with DechoNet

• Email Check는 발신 도메인의 SPF, DKIM, DMARC 정렬을 점검합니다 — 수신자가 당신을 미룰지 결정할 때 가늠하는 인증 신호입니다. 그레이리스팅이 안 풀린다면 평판 문제가 여기서 드러납니다.
• Reverse DNS Check는 발신 IP가 정방향 호스트명과 일치하는 유효한 PTR 레코드를 갖는지(FCrDNS) 확인합니다. PTR이 없거나 불일치하는 것은 수신자가 ‘잠깐 그레이리스트’에서 ‘지속적 4.7.1 지연’으로 넘어가는 가장 흔한 이유 중 하나입니다.

Resolution Checklist

• 먼저 반송이 아니라 지연인지 확인합니다: 451(4xx)은 자동으로 큐에 담겨 재시도됩니다 — 550(5xx)이 진짜 반송입니다. 첫 메일에서의 451이라면 올바른 행동은 대개 기다리기입니다.
• 시간을 주세요. 전형적 그레이리스팅은 MTA가 최소 대기 시간 뒤 재시도하면 풀립니다 — 보통 몇 분에서 약 1시간. 손으로 다시 보내면 도움이 안 되고 큐 순번만 초기화될 수 있습니다.
• 451이 몇 시간 지속되면 그레이리스팅으로 취급하지 마세요. Email Check를 실행해 발신 도메인의 SPF/DKIM/DMARC 정렬을 고칩니다.
• 발신 IP에 Reverse DNS Check를 실행하고 PTR이 없으면 일치하는 레코드를 설정합니다 — 수신자는 정방향 확인 역방향 DNS가 없는 IP의 메일을 흔히 미룹니다.
• 순환 IP 뒤에서 대량 발송을 통제한다면, 각 소스 IP가 처음부터 다시 그레이리스팅되지 않도록 모든 소스 IP를 워밍업하고 인증하세요.

When to Escalate

• 인증이 깨끗하고 PTR도 맞는데 특정 수신자가 여전히 메일을 451로 무기한 붙잡는다면, 블록리스트에 올랐거나 수동 평판 페널티일 가능성이 큽니다 — 이건 수신 제공업체와의 도달성(deliverability) 에스컬레이션이지 내 쪽에서만 고칠 수 있는 설정이 아닙니다.
• 그레이리스팅 지연이 시간에 민감한 흐름(비밀번호 재설정, 일회용 코드)을 깨뜨린다면, 해법은 수신자의 그레이리스팅을 무력화하는 게 아닙니다 — 그런 메일은 수신자가 이미 신뢰하는, 충분히 자리 잡은 인증된 IP에서 보내 첫 접촉 지연이 애초에 적용되지 않게 하는 것입니다.