SMTP 설정 완벽 가이드: 포트, 인증, 이메일 서버 구성

SMTP 설정은 메일 서버나 이메일 클라이언트를 올바르게 구성하여 Simple Mail Transfer Protocol을 통해 메시지를 전송하는 과정이에요. 제대로 설정하면 이메일이 받은편지함에 도착하고, 잘못되면 전송 실패, 인증 오류, 또는 스팸 폴더로 조용히 들어가는 상황을 맞게 돼요. 매번 꼭 맞춰야 할 세 가지는 올바른 포트, 올바른 암호화 방식, 그리고 작동하는 인증 정보예요.

SMTP가 실제로 하는 일

SMTP는 이메일 클라이언트나 애플리케이션이 발신 메시지를 메일 서버에 넘기기 위해 사용하는 프로토콜이에요. 메일 서버는 그 메시지를 받는 사람에게 라우팅해요. 발신만 담당하고, 수신은 별도의 프로토콜이 처리해요. IMAP은 동기화용, POP3는 다운로드용이에요.

"전송"을 누르면 클라이언트는 SMTP 서버로 TCP 연결을 열고, 인증한 후, 메시지를 넘기고, 연결을 끊어요. 그러면 서버는 같은 프로토콜을 사용해서 그 메시지를 받는 사람의 메일 서버로 전달하려고 시도해요. 이때 받는 사람의 MX(Mail Exchange) DNS 레코드를 조회해서 어디로 보낼지 찾아요.

SMTP는 RFC 5321 에 정의되어 있고, 원래의 RFC 2821을 대체했어요. 명세를 이해하면 원본 SMTP 대화를 디버깅하거나 서버를 처음부터 설정할 때 도움이 돼요.

SMTP 포트 설명: 25, 465, 587

SMTP 설정에서 만나게 될 포트는 세 가지예요. 각각 특정한 역할이 있고, 잘못된 포트를 사용하는 것은 이메일 전송 실패의 가장 흔한 원인 중 하나예요.

포트 25 vs 587: 어떤 것을 사용해야 할까요?

포트 25는 1982년으로 거슬러 올라가는 원래의 SMTP 포트예요. 메일 서버끼리 통신하도록 설계됐지, 최종 사용자가 메일을 제출하도록 만들어지지 않았어요. 대부분의 ISP와 클라우드 제공자는 스팸 방지를 위해 주거용이나 공유 호스팅 IP에서의 아웃바운드 포트 25를 차단해요. 애플리케이션이 이메일을 보내려고 포트 25를 사용하려 하면 거의 확실히 실패할 거예요.

포트 587은 클라이언트나 애플리케이션에서 이메일을 제출할 때 올바른 선택이에요. RFC 6409 에서 전용 "메시지 제출" 포트로 표준화됐어요. STARTTLS가 필수인데, 이는 연결이 암호화되지 않은 상태로 시작되었다가 인증 정보를 보내기 전에 TLS로 업그레이드된다는 뜻이에요. Gmail, Outlook, 그리고 거의 모든 현대적 이메일 제공자가 이것을 사용하도록 기대해요.

SMTP 포트 465: SSL 레거시 포트

포트 465는 특이한 역사를 가지고 있어요. 1997년에 SMTPS(SMTP over SSL)에 잠깐 할당되었다가 1998년에 포트 587의 STARTTLS가 선호되면서 그 할당이 취소됐어요. 공식적으로 폐기되었지만 많은 메일 서버가 계속 지원했고, 나중에 IANA에서 다른 목적으로 다시 등록됐어요.

실제로는 대부분의 제공자가 여전히 암묵적 SSL/TLS를 사용하는 포트 465의 연결을 수락해요. 이는 STARTTLS처럼 중간에 업그레이드하는 대신 첫 번째 바이트부터 TLS로 전체 연결을 감싼다는 뜻이에요. 특정 네트워크 프린터나 구형 CRM 같은 구형 애플리케이션과 하드웨어는 포트 465만 지원하므로 그런 경우에는 여전히 유용해요.

• 애플리케이션이나 기기가 암묵적 SSL을 특별히 요구하고 STARTTLS를 할 수 없으면 포트 465를 사용하세요.
• 다른 모든 경우에는 포트 587을 사용하세요. 현대의 표준이에요.
• 클라이언트 제출에는 포트 25를 완전히 피하세요.

SMTP 인증: 작동 방식

SMTP 인증(SMTP AUTH라고도 쓰임)은 RFC 4954 에 정의되어 있어요. 클라이언트가 서버에 신원을 증명해야 서버가 아웃바운드 메일을 수락해요. 없으면 서버에 도달할 수 있는 누구나 스팸을 보내는 데 사용할 수 있으므로 오픈 릴레이는 심각한 보안 문제로 취급돼요.

SMTP 설정에서 가장 흔히 보이는 인증 메커니즘은 다음과 같아요:

• PLAIN: 사용자 이름과 비밀번호를 base64로 인코딩해서 보내요. 암호화된 연결(TLS가 먼저 활성화되어야 함)에서만 안전해요.
• LOGIN: PLAIN과 비슷하지만 사용자 이름과 비밀번호를 별도의 교환으로 보내요. 역시 TLS가 필요해요.
• CRAM-MD5: 비밀번호를 직접 보내지 않는 챌린지-응답 메커니즘이에요. 현대 서버에서는 덜 흔해요.
• XOAUTH2: Gmail과 다른 Google Workspace 계정에서 사용돼요. 비밀번호 대신 OAuth 2.0 액세스 토큰을 제공해요. 이것은 "보안 수준이 낮은 앱 액세스"가 비활성화되었을 때 필요한 것이에요.

이메일 서버 설정 단계별 가이드

Thunderbird 같은 이메일 클라이언트, 거래 이메일을 보내는 웹 앱, 또는 자체 호스팅 메일 서버를 설정하든 프로세스는 같은 논리적 순서를 따라요.

이메일 클라이언트와 애플리케이션의 경우

1. 제공자로부터 SMTP 호스트명을 얻으세요. 예시: smtp.gmail.com , smtp.office365.com , mail.yourdomain.com .
2. 올바른 포트를 선택하세요. STARTTLS와 함께 포트 587을 기본값으로 사용하세요. 앱이 필요로 하면 SSL만으로 포트 465로 폴백하세요.
3. 인증 정보를 입력하세요. 보통 사용자 이름은 전체 이메일 주소이고 비밀번호나 앱 비밀번호를 사용해요.
4. 암호화 방식을 설정하세요. 포트와 일치시키세요: 587은 STARTTLS, 465는 SSL/TLS.
5. 연결을 테스트하세요. 대부분의 이메일 클라이언트는 "계정 설정 테스트" 또는 "확인" 버튼을 가지고 있어요. 저장하기 전에 사용하세요.

자체 호스팅 메일 서버의 경우 (Postfix 예시)

Postfix로 자신의 서버를 실행 중이면 핵심 SMTP 설정은 /etc/postfix/main.cf 에 있어요. 여기는 제3자 SMTP 제공자를 통해 릴레이하는 서버의 최소한의 작동 예시예요:

# /etc/postfix/main.cf - Basic relay configuration

relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_use_tls = yes

편집 후, /etc/postfix/sasl_passwd 를 자격 증명과 함께 만들고, postmap /etc/postfix/sasl_passwd 을 실행해서 해시한 다음, systemctl reload postfix 로 Postfix를 다시 로드하세요.

인기 제공자의 일반적인 SMTP 설정

SMTP 연결 문제 해결

대부분의 SMTP 실패는 적은 수의 범주로 나뉘어요. 로그를 파고들기 전에 포트가 실제로 서버나 네트워크에서 도달 가능한지 확인하세요. 방화벽이나 ISP 차단이 종종 원인이고 특별한 도구 없이도 빠르게 확인할 수 있어요.

무료 온라인 포트 체커를 사용해서 메일 서버의 SMTP 포트가 열려 있는지 확인할 수 있어요. 메일 서버의 호스트명이나 IP를 입력하고, 포트 25, 465, 또는 587을 선택하고 테스트를 실행하세요. 결과가 폐쇄됨 또는 시간 초과로 나오면 문제는 네트워크 수준(방화벽, ISP 차단, 또는 서비스가 실행 중이 아님)이지 앱 내부의 설정 오류가 아니에요.

일반적인 오류 메시지와 의미

• 연결 거부됨 / 연결 시간 초과: 포트가 차단되었거나 서비스가 수신 중이 아니에요. 방화벽 규칙을 확인하고 SMTP daemon이 실행 중인지 확인하세요.
• 535 인증 실패: 잘못된 사용자 이름이나 비밀번호예요. Gmail의 경우 계정 비밀번호가 아니라 앱 비밀번호가 필요한 것이 보통이에요.
• 550 5.7.1 릴레이 액세스 거부됨: 서버가 그 발신자 주소로 메일을 릴레이하도록 설정되지 않았거나 MAIL FROM 명령 전에 인증이 일어나지 않았어요.
• 421 연결이 너무 많음: 수신 서버가 속도를 제한하고 있어요. 전송 빈도를 줄이거나 지연이 있는 큐를 구현하세요.
• TLS 핸드셰이크 실패: 인증서 불일치 또는 구형 TLS 버전이에요. 서버의 SSL 인증서가 유효한지 확인하고 대부분의 제공자가 비활성화한 TLS 1.0이나 1.1을 사용하려고 하지 않는지 확인하세요.

빠른 진단 체크리스트

1. SMTP 포트가 열려 있고 발신 환경에서 도달 가능한지 확인하세요.
2. 호스트명이 올바르게 확인되는지 nslookup smtp.yourdomain.com 으로 확인하세요.
3. 발신 IP가 MXToolbox 블랙리스트 확인 같은 도구를 사용해서 블랙리스트에 없는지 확인하세요.
4. SPF, DKIM, DMARC DNS 레코드가 올바르게 발행되었는지 확인하세요. 누락되거나 손상된 레코드로 인해 정당한 메일이 거부되거나 스팸으로 분류돼요.
5. 메일 서버 로그를 검토하세요. Postfix의 경우 /var/log/mail.log 을 확인하세요. 로그의 실제 SMTP 응답 코드는 원격 서버가 무엇을 거부했고 왜 거부했는지 정확히 알려줘요.

SMTP 포트가 실제로 열려 있나요?

SMTP 설정을 탓하기 전에 문제가 차단된 포트가 아닌지 확인하세요. 무료 포트 체커로 메일 서버의 포트 25, 465, 또는 587을 즉시 테스트하면 방화벽 문제인지 설정 오류인지 알 수 있어요.

지금 SMTP 포트 확인하기 →