포트 25가 막혔으면 수신자에게 587로 보내면 되지 않나요?

안 됩니다. 가장 흔한 오해입니다. 포트 587과 465는 제출(submission) 포트로, '내' 발신 메일 서버(또는 제공업체 스마트호스트)에 속하며 보내기 전에 인증을 요구합니다. 수신자 메일 서버 — 내 도메인 MX가 가리키는 그곳 — 은 들어오는 메일을 포트 25에서만 받습니다. 수신 쪽에는 587로 배달할 곳이 없습니다. 그래서 아웃바운드 25가 막히면, 해법은 같은 목적지로 가는 다른 포트가 아니라, 587/465에서 인증된 릴레이에 메일을 넘겨 그 릴레이가 허용된 망에서 25로 최종 배달하게 하는 것입니다.

ISP와 클라우드는 왜 포트 25를 막나요?

포트 25는 인증 없는 서버 간 릴레이로 설계됐고, 오랫동안 감염된 가정용 PC와 임대 VM이 완벽한 스팸 대포였기 때문입니다. 봇넷 머신은 전 세계 어떤 메일 서버로든 포트 25를 열어 메일을 직접 주입할 수 있었죠. 소비자·클라우드 IP 대역에서 아웃바운드 25를 막으면 그 악용을 근원에서 끊습니다. AWS는 EC2와 Lambda에서 기본 차단하고 요청 시에만 풀어 주며, Google Cloud는 외부 목적지로의 아웃바운드 25를 아예 막고 해제 절차조차 없습니다. 오설정이 아니라 정책입니다.

내 아웃바운드 연결 문제인지, 내 수신 서버 문제인지 어떻게 구분하나요?

둘은 해법이 다른 별개 문제입니다. 아웃바운드: 내가 '보내려는데' 원격 포트 25 연결이 타임아웃 — `telnet smtp.gmail.com 25`로 테스트해 멈추는데 587은 연결되면 내 망이 아웃바운드 25를 막은 것입니다. 인바운드: 다른 서버가 '나에게 배달'을 못 하는 것으로, 내 메일 서버의 25가 방화벽에 막혔거나 MX가 틀린 것입니다 — 발신 세계는 25로만 도달할 줄 알기에 인바운드를 587로 옮길 수 없습니다. 무엇을 바꾸기 전에 어느 방향이 실패하는지부터 가리세요.

조회수: 19

SMTP 포트 25 차단: 원인과 해결

SMTP 포트 25 차단은 보통 ISP나 클라우드가 아웃바운드 메일을 막은 것. 경우를 가려 587/465로 옮기는 법을 4단계로. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

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

문제

메일이 안 나갑니다. 애플리케이션이나 서버가 보내려 하는데 원격 메일 서버의 포트 25 연결이 그냥 멈췄다 타임아웃되고, 모든 정황이 한 곳을 가리킵니다: 포트 25 차단. 문제는 누가 막았는지, 그리고 어느 포트 25인지 — 내 것인지 상대 것인지입니다.

증상

원격 서버로의 아웃바운드 SMTP가 포트 25에서 타임아웃되는데, DNS와 웹은 멀쩡합니다.
telnet smtp.gmail.com 25는 배너 없이 멈추고, 같은 테스트를 포트 587에 하면 즉시 연결됩니다.
앱 로그에 MX 호스트 도달 시 “connection refused”가 아니라 “connection timed out”이 찍힙니다.
워크로드를 클라우드 VM(AWS, GCP)이나 가정·사무실 ISP로 옮겼을 때 시작됐습니다.

”포트 25 차단”의 실체

포트 25는 원래의 SMTP 포트이며 서버 간 릴레이 — 한 메일 서버가 다음 서버에 메시지를 넘기는 용도 — 입니다. SMTP 원설계에서는 인증이 필요 없었고, 그래서 스팸이 가장 좋아하는 문이 됐습니다: 감염된 머신이 지구상 아무 메일 서버로든 포트 25를 열어 메일을 직접 주입할 수 있었죠. 그래서 메일 서버를 돌릴 일이 없는 망 — 가정용 ISP 대역, 클라우드 컴퓨트 — 은 그 악용을 끊으려 아웃바운드 포트 25를 기본 차단합니다.

여기서 사람들이 막힙니다. 아웃바운드 25가 막혔을 때의 해법은 수신자에게 587로 가는 것이 아닙니다. 제출 포트 — 587(RFC 6409, SMTP AUTH 필수)과 465(implicit TLS, 2018년 RFC 8314로 부활) — 은 인증을 곁들여 내 발신 서버나 제공업체 스마트호스트와 대화하는 용도입니다. 수신자 서버, 즉 내 MX 레코드가 광고하는 그곳은 들어오는 메일을 25에서만 받습니다. 그래서 587/465로 릴레이에 인증해 넘기면, 허용된 망에서 도는 그 릴레이가 25로 최종 배달을 합니다.

주요 원인 3가지

클라우드 제공업체의 기본 아웃바운드 25 차단 — AWS는 허용목록에 없는 계정의 EC2·Lambda에서 포트 25를 막고, 요청 양식으로만 해제합니다. Google Cloud는 외부 목적지로의 아웃바운드 25를 막고 해제 절차가 없습니다 — 안내는 파트너 릴레이(SendGrid, Mailgun 등)를 쓰라는 것입니다. VM을 띄운 뒤 직접 발송이 멈췄다면 거의 이것입니다.
가정·사무실 ISP의 아웃바운드 25 차단 — 소비자 ISP는 감염 머신의 스팸을 막으려 20년간 아웃바운드 25를 차단해 왔습니다. 메일 클라이언트는 쓸 수 있어도 그 회선에서 메일을 직접 배달할 수는 없습니다. 해법은 같습니다: 스마트호스트를 통한 인증 제출.
내 서버의 인바운드 25가 방화벽에 막힘 — 정반대 경우입니다. 받으려는데 호스트 방화벽·보안그룹·상단 필터가 인바운드 25를 떨궈 발신 세계가 나에게 못 닿습니다. 이건 아웃바운드 차단과 다른 문제이고, 587로 옮겨 우회할 수 없습니다 — 들어오는 메일은 25로만 도착합니다.

DechoNet으로 진단

포트 진단은 특정 호스트에서 포트 25(및 587, 465)가 외부에서 도달 가능한지 망 바깥에서 테스트합니다. 내 메일 서버를 향해 돌려 인바운드 25가 열렸는지 확인하면, 로컬 방화벽과 무관하게 수신 쪽 상태를 알 수 있습니다.
이메일 진단은 MX 레코드와 메일 설정을 읽어, 엉뚱한 포트를 쫓기 전에 메일이 어디로 배달돼야 하는지 확인해 줍니다.
DNS 진단은 MX 레코드 자체를 검증합니다 — 없거나 틀린 MX는 배달 실패처럼 보이지만 포트 25와는 무관합니다.

해결 체크리스트

방향부터 확정: 보내기(아웃바운드)가 실패하는지 받기(인바운드)가 실패하는지. 해법이 다릅니다.
아웃바운드: telnet smtp.gmail.com 25와 587을 비교 테스트. 25는 멈추고 587은 연결되면 내 망이 아웃바운드 25를 막은 것 — 25를 고치려 들지 마세요.
발송을 인증 제출로 전환: 앱이나 서버가 SMTP AUTH 자격증명으로 587(STARTTLS) 또는 465(implicit TLS) 스마트호스트를 통해 릴레이하도록 설정.
클라우드 VM이면 포트 25 차단 해제를 요청(AWS)하거나 모든 발신 메일을 릴레이 서비스로 우회(GCP는 옵트아웃 없음).
인바운드: 포트 25가 외부에서 메일 서버에 열려 있는지, MX 레코드가 올바른 호스트를 가리키는지 확인. 들어오는 메일은 25를 벗어날 수 없습니다.

에스컬레이션 시점

인증 제출로 옮겼는데도 클라우드 VM에서 메일이 안 나간다면 제공업체에 에스컬레이션하세요 — 특히 GCP에서 직접 포트 25 송신은 망 차원 정책이라 우회 불가, 릴레이가 유일한 길입니다.
인바운드 25가 열려 있고 MX도 맞는데 메일이 여전히 반송된다면, 문제는 연결성을 넘어 인증·평판(SPF, DKIM, PTR, 블랙리스트)으로 옮겨간 것 — 별개의 진단입니다.