554 5.4.14 Hop count exceeded: 메일 루프 해결

문제

메시지가 554 5.4.14 Hop count exceeded - possible mail loop ATTR34로 바운스되고 수신자에게 끝내 도착하지 못합니다. 본능적으로 발신자 평판이나 인증 문제로 보고 SPF·DKIM부터 확인하게 되죠. 헛다리입니다. 이 코드는 누가 보낼 수 있느냐와 아무 상관이 없습니다. 메시지가 루프에 갇혔다는 뜻입니다 — 서버를 떠나, 곧장 되돌려 보내는 곳에 도착하기를, 홉 한도를 넘을 때까지 반복하다가 Exchange Online이 죽인 겁니다. 해법은 당신의 메일 라우팅에 있고, 루프를 끊기 전까지 모든 재시도는 똑같은 한 바퀴를 돕니다.

증상

• 발신자가 554 5.4.14 Hop count exceeded - possible mail loop ATTR34(때로는 ATTR1)이라 적힌 배달 실패 보고(NDR)를 받음.
• 모두가 아니라 특정 도메인이나 수신자에게 영향 — 대개 최근 DNS·커넥터·전달 변경과 얽힌 대상.
• 메시지 헤더에 같은 호스트나 홉이 여러 번 반복되어 나타남.
• 온프레미스 Exchange가 루프에 얽히면 관련 코드 554 5.4.6이 대신 뜸.
• 재시도·재발송·대기해도 아무것도 안 바뀜 — 매번 다시 루프를 돕니다.

이 오류가 실제로 뜻하는 것

SMTP는 처음부터 자기 발자국을 세어 왔습니다. RFC 5321 §6.3은 Received: 헤더 필드를 세어 루프를 감지하도록 정의합니다 — 메시지를 다루는 서버마다 하나씩 붙이니, 계속 도는 메시지는 그걸 쌓아 갑니다. 명세 자체의 조언은 임계값을 크게(“보통 최소 100개 Received 항목”) 잡으라는 것인데, 정당하게 긴 경로가 루프로 오인되지 않게 하려는 겁니다. 이게 모든 “홉 너무 많음” 바운스 밑에 깔린 보편 메커니즘입니다.

Exchange Online은 그 위에 더 날카로운 걸 얹습니다. 날것의 Received: 줄만 세는 게 아니라, 자기 어트리뷰션 카운터 — 바운스의 ATTR 값 — 를 찍어 Exchange Online Protection이 한 테넌트 안에서 메시지를 몇 번 처리했는지 기록합니다. Microsoft는 현재 총 7홉, 또는 단일 테넌트 환경 내부에서는 3홉을 허용합니다. 전체 총합을 넘기면 ATTR1, 테넌트 내부 한도를 넘기면 ATTR34가 뜹니다. 확장 상태 코드 5.4.14는 Exchange Online의 “라우팅 루프 감지”이고, 그 형제 5.4.6은 온프레미스 Exchange가 루프에 끼었을 때의 같은 판정입니다.

핵심은 이겁니다: 이건 불안정한 실패가 아니라 결정론적인 설정 실패입니다. 메시지는 형식이 온전하고 흔히 완벽하게 인증돼 있습니다. 깨진 건 경로입니다 — 끝나는 사서함이 없어서, 카운터가 상한에 닿을 때까지 같은 홉을 다시 방문합니다. 그래서 “그냥 재발송”은 결코 통하지 않고, 진단은 언제나 “메시지를 계속 주고받는 두(또는 세) 곳을 찾아라”입니다.

주요 원인 3가지

1. Microsoft 365의 미검증 도메인. Microsoft가 가장 자주 지목하는 원인이고, 설계상 그렇게 됩니다: 당신 테넌트가 다루는 도메인으로 메일이 오는데 그게 허용 도메인으로 추가·검증되지 않았으면, Exchange Online이 실제 사서함에 귀속시키지 못해 홉 한도가 걸릴 때까지 계속 재처리합니다. 해법은 지루하고 정확합니다 — 도메인을 추가하고 검증을 마치세요.
2. 엉뚱한 방향을 가리키는 하이브리드 커넥터. 하이브리드 온프레미스/클라우드 구성에서, 온프레미스 송신 커넥터가 메시지를 Exchange Online으로 보내고, 도메인 라우팅 설정 때문에 그게 다시 온프레미스로 돌아오고, 다시 올라갑니다. 양쪽 다 상대가 사서함을 소유했다고 여깁니다. 전형적인 5.4.6/5.4.14 짝이고, 해법은 커넥터와 허용 도메인 유형이 누가 배달하는지에 합의하게 만드는 겁니다.
3. 순환 전달 또는 리다이렉트 규칙. 사서함 A가 B로 전달하는데 B가 다시 A로 전달하거나; 전송 규칙이 다시 같은 시스템으로 라우팅되는 주소로 리다이렉트하거나; 서드파티 필터가 Microsoft 365로 전달하는데 MX(또는 오래된 규칙)가 그걸 필터로 되돌립니다. 서로를 가리키는 전달 둘이면 충분합니다.

DechoNet으로 진단

• 이메일 진단은 당신 인프라 바깥에서 도메인의 MX 레코드와 메일 라우팅을 읽어 인바운드 메일이 실제로 어디로 향하는지 보여줍니다. 루프는 거의 언제나 메일이 되돌려 보내는 곳으로 넘겨지는 데서 비롯됩니다 — 그러니 MX가 최종 권한 호스트(Microsoft 365라면 *.mail.protection.outlook.com 엔드포인트)를 가리키는지, 클라우드로 튕겼다 되돌아올 중간 필터나 옛 서버가 아닌지 확인하세요. MX가 진짜 사서함 호스트가 아닌 곳을 가리킨다면 루프의 한 다리를 찾은 겁니다.
• DNS 진단은 날것의 MX 우선순위와 충돌하거나 남아 있는 레코드를 보여줍니다. 마이그레이션에서 남은 중복·오래된 MX는 메시지가 옛 메일 호스트와 새 메일 호스트 사이를 핑퐁하게 만드는 흔한 방식입니다.

해결 체크리스트

• 바운스의 Received 헤더를 읽어라. NDR은 메시지의 경로를 담고 있습니다. 루프는 같은 호스트가 반복되는 걸로 드러납니다 — 그 반복이 메시지가 도는 곳의 지도입니다. 거기서 시작하세요.
• ATTR 값을 확인하라. ATTR34는 루프가 한 테넌트 내부라는 뜻 — 당신의 허용 도메인·커넥터·메일 흐름 규칙을 보세요. ATTR1은 전체 홉 총합이 터진 것 — 더 긴 외부 경로가 자기 위로 접히고 있는 겁니다.
• Microsoft 365의 모든 도메인을 검증하라. 당신 테넌트가 다루는 도메인은 허용 도메인으로 추가·검증됐는지 확인하세요. 미검증 도메인은 Microsoft가 가장 흔히 꼽는 원인이고 설계상 루프를 돕니다.
• 하이브리드 커넥터를 감사하라. 온프레미스/클라우드 구성에서 송·수신 커넥터와 허용 도메인 유형(authoritative vs. internal relay)이 누가 사서함을 소유하는지에 합의하게 만들어, 어느 쪽도 상대에게 메일을 되돌리지 않게 하세요.
• 순환 전달을 색출하라. 사서함 전달, 전송/메일 흐름 규칙, 그리고 앞단 서드파티 필터에서 A→B→A 패턴을 확인하세요. 뒤를 가리키는 것을 제거하세요.
• 외부 진단으로 MX를 확인하라. 이메일 진단을 돌려 인바운드 메일이 되돌릴 중간 지점이 아니라 진짜 최종 사서함 호스트로 향하는지 검증하세요. 메시지를 그냥 재시도하지 마세요 — 설정이 바뀌기 전까지 루프는 다시 돕니다.

언제 에스컬레이션

• 도메인이 검증됐고, 커넥터도 올바르고, 어떤 전달 규칙으로도 설명이 안 된다면, 메일 플랫폼을 관리하는 쪽(Microsoft 365 / Exchange 관리자)에게 바운스된 메시지의 전체 Received 헤더 추적과 함께 에스컬레이션하세요 — 반복되는 홉이 어느 두 시스템이 메시지를 주고받는지 정확히 말해줍니다.
• 루프가 Microsoft 365 앞단의 서드파티 게이트웨이나 필터와 얽혀 있다면 그 벤더와 조율하세요: 해법은 대개 그들의 전달 대상과 당신의 MX를 맞춰 메일이 원을 그리지 않고 사서함 호스트에 한 번에 도착하게 하는 겁니다.