554 5.7.1 Relay Access Denied 해결

문제

메일이 554 5.7.1과 Relay access denied 또는 Unable to relay라는 문구를 달고 영구 거부됩니다. 메시지가 통째로 거부된 것 — 서버가 전달을 거절했습니다. 스팸 판정도, 사서함 부재도 아닙니다. 권한 거부입니다: 서버가 이 특정 메시지를 이 특정 목적지로 운반할 권한이 없다고 판단하고 그렇게 말한 겁니다.

증상

• 바운스(NDR)에 554 5.7.1 Relay access denied, 554 5.7.1 <주소>: Relay access denied, 또는 Microsoft 시스템에선 550 5.7.1 Unable to relay가 뜹니다.
• 발신: 특정 서버·SMTP 호스트를 통해 외부 수신자에게 보내려는 순간 발송 메일이 튕깁니다.
• 수신: 사서함이 존재하고 같은 서버의 다른 도메인은 멀쩡한데도, 당신 도메인으로 오는 메일이 554 5.7.1로 튕깁니다.
• SMTP 릴레이로 보내던 스크립트·앱이 설정 변경·비밀번호 교체·새 호스트 이전 후 갑자기 실패합니다.
• 같은 메시지가 다른 제공자나 다른 네트워크에선 잘 나갑니다.

이 오류의 진짜 의미

“릴레이”는 SMTP 서버가 하는 일을 가리키는 옛 단어입니다: 자기가 호스팅하지 않는 사서함을 향해 메시지를 받아 전달하는 것. 초기 인터넷에선 모든 서버가 누구에게나 릴레이해 줬습니다 — 그렇게 메일이 흘렀죠. 그러다 스패머들이 오픈 릴레이가 정크 메일을 공짜로 익명 세탁하는 서비스임을 알아챘고, 생태계 전체가 문을 걸어 잠갔습니다. Sendmail 8.9가 1998년 릴레이를 기본 비활성화했고, 모든 현대 MTA가 뒤따랐습니다. 오늘날 서버는 신뢰하는 발신자에게만 릴레이하고, 나머지는 554 5.7.1로 거부합니다.

확장 상태는 RFC 3463의 X.7.1, ‘전달 미승인, 메시지 거부’입니다: 발신자가 이 서버를 통해 목적지로 보낼 권한이 없다. 기본 코드 554는 ‘Transaction failed’ — 단단한 영구 거부입니다. 같은 메시지를 재시도해도 아무것도 바뀌지 않습니다.

함정은 이 하나의 오류가 정반대 수정을 요구하는 두 거울상 상황을 덮는다는 점입니다:

• 발신 — 당신이 자신을 신뢰 발신자로 여기지 않는 서버를 통해 보내려 합니다. 인증을 건너뛰었거나, 서버가 릴레이해 주지 않는 IP에서 접속 중이죠. 서버는 제3자에게 배달을 요청하는 낯선 이를 보고 거부합니다.
• 수신 — 누군가 당신 도메인으로 보내는데, 당신 서버가 그 도메인을 책임진다는 걸 모릅니다. 서버 입장에서 권한 없는 수신자는 외부인에게 릴레이하라는 요청과 구분되지 않아, 똑같이 거부합니다.

같은 문구, 같은 코드, 완전히 다른 근본 원인. 무엇이든 손대기 전에 실패하는 메일이 어느 방향인지부터 가리세요.

가장 흔한 원인 3가지

1. 발신: SMTP 인증 없음(전형적 경우) — 메일 클라이언트·앱이 발송 서버에 접속해 로그인 없이 외부 수신자에게 배달을 시도합니다. 서버는 인증된 사용자에게만 릴레이하므로(Postfix permit_sasl_authenticated), 미인증 세션은 554 5.7.1을 받습니다. 흔한 방아쇠: 클라이언트에서 SMTP AUTH 꺼짐, 틀리거나 교체된 비밀번호, 제출 포트 587 대신 (서버 간 통신용인) 포트 25 사용, 만료된 서비스 계정 자격증명.
2. 발신: 서버가 릴레이해 주지 않는 IP에서 발송 — 서버는 고정된 신뢰 네트워크 집합(Postfix mynetworks)에만 릴레이하는데 당신 출발 IP가 거기 없습니다. 앱이 새 호스트로 옮기거나, NAT/이그레스 IP가 바뀌거나, 클라우드 인스턴스가 새 주소를 받거나, 사무실 IP 대역에 묶인 릴레이 밖으로 나갔을 때 물립니다. 메시지는 정상이고 발송 IP만 인식 안 되는 것.
3. 수신: 수신 도메인이 로컬로 설정 안 됨 — 받는 서버에 그 도메인을 책임지게 하는 항목이 없어 당신 도메인으로 오는 메일이 튕깁니다. Postfix에선 mydestination·virtual_mailbox_domains·relay_domains에서 빠졌고, Exchange에선 수락 도메인이 아니며, 이전 후 MX가 그 도메인을 모르는 호스트를 가리킵니다. 서버는 당신 수신자를 제3자로 취급해 릴레이를 거부합니다.

DechoNet으로 진단하기

• 이메일 진단을 수신 도메인에 돌리면 MX 레코드가 실제로 어디를 가리키는지 보입니다. 수신 케이스에선, 당신 도메인 메일이 그 도메인을 호스팅한다고 주장이라도 하는 서버에 떨어지는지를 드러냅니다 — 이전 후 남은 MX는 자기 도메인이 554 5.7.1로 튕기는 전형적 원인입니다.
• 이메일 헤더 분석은 바운스를 읽어 어느 호스트가 어느 방향에서 거부했는지 알려 줍니다. 코드가 5.7.1 릴레이 거부(사서함 부재 5.1.1도, 인증/DMARC 차단 5.7.x도 아님)인지 확인하고 보고 서버를 식별하세요 — 이게 수정이 당신 몫인지 수신자 몫인지를 가릅니다.
• DNS 진단은 도메인 MX 우선순위와 최근 변경을 보여 줍니다. 강등·중복·오래된 MX가 어느 호스트도 수락하도록 설정되지 않은 도메인의 메일을 조용히 받아 챙기면, 멀쩡한 주소가 수신 554 5.7.1을 냅니다.

해결 체크리스트

• 먼저 방향을 정하세요. 실패하는 메일이 발신(당신이 밖으로 보냄)인가요, 수신(누군가 당신 도메인으로 보냄)인가요? 바운스의 보고 호스트가 알려 줍니다. 아래 전부가 여기서 갈립니다.
• 발신: 클라이언트·앱에서 SMTP 인증을 켜고, 포트 25가 아니라 제출 포트 587(STARTTLS) 또는 465(암시적 TLS)를 쓰세요. 사용자명·비밀번호가 최신인지 확인.
• 발신: 로그인 없이 서버·스크립트로 보낸다면 출발 IP가 릴레이의 허용 네트워크 목록에 있는지 확인하세요. 호스트 이전·새 클라우드 IP·바뀐 이그레스 주소가 흔한 파열점입니다.
• 수신: 받는 서버에서 그 도메인이 메일을 수락하는 도메인으로 설정됐는지 확인하세요 — Postfix mydestination/virtual_mailbox_domains, Exchange 수락 도메인. 없으면 추가하고 리로드.
• 수신: MX 레코드가 그 도메인을 실제로 수락하도록 설정된 호스트를 가리키는지 확인하세요. 이전이 남긴 오래된 MX 항목을 정리하세요.
• 변경할 때마다 재전송하세요. 554는 영구라, 근본 권한이 고쳐지기 전까진 아무것도 풀리지 않습니다.

에스컬레이션 시점

• 실패 메일이 제공자 릴레이를 통한 발신이고 자격증명·포트가 맞다면 그 제공자에게 올리세요 — 당신 계정에 릴레이 권한이 없거나 IP가 그쪽에서 차단됐을 수 있습니다.
• 실패 메일이 당신이 관리하지 않는 도메인으로의 수신이라면, 정확한 바운스를 그 수신 도메인의 postmaster에게 전달하세요. 554 5.7.1과 보고 호스트 이름이 그들 서버가 그 도메인 메일을 수락하도록 설정되지 않았음을 정확히 짚어 줍니다 — 그들만 고칠 수 있는 문제입니다.
• 받는 서버를 당신이 소유하고, 도메인이 수락 목록에 있는데도 멀쩡한 수신자가 여전히 554 5.7.1로 튕긴다면, MTA 벤더에게 SMTP 트랜스크립트를 넘기세요. 올바로 설정된 로컬 도메인을 서버가 여전히 외부로 취급한다면 그쪽의 설정 로드·라우팅 결함을 가리킵니다.