도메인 이메일 송수신 문제 해결 가이드

도메인을 구입하고 사서함을 만들었습니다. 웹메일에 로그인해 받은편지함도 확인했습니다. 이제 끝났다고 생각했을 것입니다.

그런데 휴대전화에서 테스트 메일을 보내도 아무 일도 일어나지 않습니다. 보낼편지함에서 계속 대기합니다. 개인 Gmail에서 새 주소로 보낸 메시지가 반송도 오류도 없이 사라지기도 합니다.

이것이 좀비 상태입니다. 불은 켜져 있지만 아무도 없는 상태입니다. 웹메일은 일반 웹사이트와 같은 HTTPS, 포트 443을 사용하므로 로그인은 됩니다. Outlook, Apple Mail 또는 CRM의 송수신은 SMTP와 IMAP을 사용합니다. 이들은 완전히 다른 문이며 아직 잠겨 있을 수 있습니다.

전체 설정을 진행 중이라면 도메인으로 이메일을 만드는 방법 안내서에서 단계별 절차를 확인하세요. 이 글은 그다음 상태, 즉 로그인은 되지만 메일 흐름이 작동하지 않는 상황을 다룹니다.

초기 진단에 60초를 배정하는 점검 예시부터 CLI 진단까지, 증거를 모아 장애 구간을 좁혀 가는 절차입니다. 이 시간 안에 해결된다는 뜻은 아닙니다.

단계 1: 변경하기 전에 증상부터 파악하기

어느 구간이 고장 났는지 알기 전에 DNS 레코드를 건드리지 마세요. "작동하지 않는다"는 진단이 아닙니다. 해당하는 상황을 고르세요.

상황 A: 유령 도시 (수신 불가)

Gmail에서 새 주소로 테스트 메시지를 보내도 도착하지 않고 발신자에게 반송 메일도 오지 않습니다. 로그인은 정상적으로 됩니다.

확인할 사항: 발신 서버의 대기열, 수신 측 스팸 폴더와 격리함, 대상 사서함, MX 경로를 확인하세요. 누락되거나 오래된 MX도 원인일 수 있지만 반송이 없다는 사실만으로 원인을 확정할 수는 없습니다.

상황 B: 발신 차단 (송신 불가)

Outlook이나 iPhone에서 보내기를 누르면 진행 표시가 멈춥니다. "Connection Timed Out" 또는 "Server Unreachable"처럼 연결 실패를 알리는 오류가 표시될 수 있습니다.

확인할 사항: DNS, 서버 상태, 방화벽, ISP의 포트 25 차단 여부, TLS 설정을 차례로 확인하세요. 연결 실패가 반드시 네트워크 차단을 뜻하는 것은 아닙니다.

상황 C: 신뢰받지 못하는 발신자 (스팸 또는 반송)

메일은 전송되지만 수신자의 스팸 폴더로 갑니다. 또는 550 5.7.1 Message rejected라는 반송 메시지가 즉시 도착합니다.

확인할 사항: 전체 오류 응답과 실제 메시지의 인증 결과를 확인하세요. SPF, DKIM, DMARC 설정 외에도 평판, 콘텐츠, 수신 정책이 거부나 스팸 분류에 영향을 줄 수 있습니다.

해결 점검표: 내 도메인에 이메일을 올바르게 설정하는 방법

아래 순서대로 진행하고 단계를 건너뛰지 마세요.

1. MX 레코드: 배송지 좌표

누군가 you@yourdomain.com으로 메일을 보내면 발신 서버는 DNS에서 수신 서버를 찾습니다. 잘못된 MX는 이전 제공업체로의 전달, 일시적 지연 또는 오류를 일으킬 수 있습니다. 실제 처리 결과는 서버 응답과 대기열에서 확인해야 합니다.

전달 가능성을 해치는 두 가지 실수:

이전 제공업체의 레코드가 남아 있음. GoDaddy 등 이전 제공업체의 MX가 현재 경로와 맞는지 확인하세요. 여러 제공업체를 사용하는 승인된 게이트웨이 또는 하이브리드 구성이 유효할 수도 있습니다. 우선순위와 장애 시 경로를 검토하고 담당자의 승인 아래 불필요해진 레코드만 제거하세요.
MX가 CNAME을 가리킴. MX 레코드는 A 또는 AAAA 레코드를 통해 IP로 직접 해석되는 호스트 이름을 가리켜야 합니다. CNAME을 가리키면 RFC 2181에 어긋나며 불규칙해 보이는 전달 장애를 일으킬 수 있습니다.

지금 MX 레코드를 확인하세요.

dig mx yourdomain.com +short

결과가 승인된 메일 경로와 일치해야 합니다. 여러 제공업체가 표시되면 무조건 삭제하지 말고 의도된 구성인지 확인하세요.

DNS 변경 점검에 48시간을 잡을 수 있지만 보장된 완료 시한은 아닙니다. TTL, 리졸버 캐시와 권한 서버의 응답을 확인하세요. whatsmydns.net은 여러 지점의 조회 결과를 비교하는 데 유용하지만 전 세계의 모든 캐시를 확인하지는 않습니다.

2. 사서함 상태와 저장 공간

깊이 조사하기 전에 기본 사항부터 확인하세요.

사서함이 실제로 존재합니까? 철자를 확인하세요. support@를 만들었습니까, 아니면 suport@를 만들었습니까?
사서함이 할당량을 초과했습니까? Google Workspace와 M365의 사용자별 한도, 공유 저장 공간과 초과 시 처리는 제품 및 에디션에 따라 다릅니다. 실제 한도와 "Mailbox Full"을 포함한 전체 응답을 확인하세요.

TrekMail의 공유 저장 공간은 계정 차원의 용량 관리에 도움이 됩니다. 다만 적용되는 계정 및 사서함 한도는 남아 있으므로 실제 사용량과 현재 요금제의 제한을 확인하세요.

3. SMTP 구성: 90%라는 경험적 추정치를 해석할 때의 주의점

이 비율은 설명을 위한 대략적인 추정치이지 측정된 장애 빈도가 아닙니다. 웹메일 로그인은 브라우저의 웹 연결을 이용하므로 데스크톱 클라이언트의 SMTP 연결과 다릅니다. 웹메일 자체도 발송 과정에서 서버 측 SMTP를 사용할 수 있습니다. Outlook, Thunderbird 또는 CRM에는 제공업체가 지정한 설정을 적용하세요.

포트 25는 많은 가정 및 사무실용 ISP에서 차단합니다. Comcast, Verizon, AT&T 등은 스팸 봇을 막기 위해 발신 포트 25를 차단할 수 있습니다. 포트 25로 연결을 시도했다면 이것이 원인일 수 있습니다.

프로토콜	기능	포트	암호화
SMTP	송신	587	STARTTLS
SMTP	송신	465	암시적 SSL/TLS
IMAP	수신	993	SSL/TLS

포트 587에는 STARTTLS를, 포트 465에는 연결 시작부터 TLS를 적용합니다. 클라이언트의 SSL 표시는 오래된 설정 이름일 수 있으며 폐기된 SSL 프로토콜을 쓰라는 뜻은 아닙니다. 587에 암시적 TLS를 적용하거나 465에 STARTTLS를 적용하면 연결이 실패할 수 있습니다. 서버 이름과 인증서도 검증하세요.

TrekMail은 POP3를 지원하지 않습니다. 해당 프로토콜의 서버 측 삭제는 클라이언트가 삭제 명령을 보내는지와 보관 설정에 달려 있으며, 다운로드만으로 반드시 삭제되지는 않습니다. IMAP은 지원되는 기기 사이에서 상태를 동기화하지만 독립적인 백업을 대신하지는 않습니다.

4. 호스트 이름: 추측하지 말고 정확한 값을 사용

메일 클라이언트에는 제공업체가 제시한 호스트 이름이 필요합니다. 다음 예시는 구성과 인증서를 함께 확인해야 합니다.

mail.google.com (잘못된 제공업체)
smtp.yourdomain.com (적절한 주소 레코드나 제공업체가 지원하는 별칭, 일치하는 인증서가 있어야 하며 CNAME만이 유일한 방법은 아님)

환영 이메일이나 제공업체 대시보드에 나온 호스트 이름, 예를 들어 smtp.trekmail.net을 사용하세요. 정확한 값은 IMAP & SMTP 설정 참고 자료에서 확인할 수 있습니다.

5. SPF, DKIM, DMARC: 2025년의 핵심 설정

메일은 전송되지만 스팸으로 분류되거나 550 5.7.1 반송 메시지를 받는다면 DNS 인증 레코드가 누락되었을 수 있습니다. Google과 Yahoo는 특히 대량 발신자에게 인증 요건을 적용하며, 요건을 충족하지 않는 메일은 거부될 수 있습니다.

SPF는 SMTP 봉투 발신자 도메인에 대해 전송 IP를 허용하는 TXT 정책입니다. 화면에 표시되는 From 도메인을 직접 인증하지는 않습니다. 다음 예시는 실제 제공업체가 요구하는 값에 맞춰 적용하세요.

v=spf1 include:sendingprovider.net ~all

중요한 실수는 SPF 레코드를 하나보다 많이 만드는 것입니다. v=spf1로 시작하는 줄이 두 개면 평가 오류가 발생합니다. 하나의 레코드로 합치세요.

DKIM은 서명이 적용된 메시지 부분을 암호학적으로 검증하는 방식입니다. DNS 공개 키뿐 아니라 실제 발신 메시지의 서명과 검증 결과도 확인해야 합니다. 모든 메시지에 자동으로 유효한 서명이 붙는다고 가정하지 마세요.

DMARC는 SPF 또는 DKIM 중 하나 이상이 성공하고 표시된 From 도메인과 정렬되면 통과합니다. 어느 쪽도 이 조건을 충족하지 못할 때 요청하는 처리를 정책으로 지정합니다. 아래 모니터링 정책은 DMARC에 따른 격리나 거부를 요청하지 않지만 다른 수신 필터를 해제하지는 않습니다. 보고서 수신 설정과 지원 여부도 확인하세요.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

보고서를 검토하고 적법한 메일이 검사를 통과하는지 확인한 뒤에만 p=quarantine 또는 p=reject로 이동하세요. 전체 절차는 필수 DNS 레코드 안내서에서 확인할 수 있습니다.

심층 진단: 점검표로 해결되지 않을 때

위의 모든 항목을 확인했는데도 작동하지 않는다면 더 깊이 조사할 차례입니다.

스플릿 브레인 DNS

대표적인 증상은 휴대전화의 셀룰러 연결에서는 메일이 작동하지만 사무실 Wi-Fi나 VPN에서는 실패하는 것입니다.

내부 DNS 서버 (Active Directory, Pi-hole, 사내 리졸버)의 권한 영역과 전달 정책을 확인하세요. mail.yourdomain.com의 내부 및 외부 응답을 비교하고 담당자가 승인한 경로에 맞춰 수정합니다. mail.yourdomain.com은 구성에 따라 공개 서버나 내부 서버를 가리킬 수 있습니다. 192.168.x.x 같은 사설 주소도 의도된 하이브리드 구성에서는 유효하므로 무조건 공개 IP로 바꾸지 마세요.

MTU 불일치

증상은 짧은 텍스트 메일은 정상적으로 전송되지만 PDF를 첨부하면 연결이 멈추는 것입니다.

VPN (WireGuard, IPsec)이나 DSL/PPPoE 경로에서는 사용 가능한 MTU가 일반적인 1500바이트보다 작을 수 있습니다. 담당자의 승인 아래 원래 값을 기록하고 제한된 범위에서 MTU 1300을 시험한 뒤 복원하세요. 증상이 달라지면 경로 MTU 문제를 더 조사할 근거가 되지만 조각화된 패킷의 폐기를 단독으로 입증하지는 않습니다.

백신 프로그램의 SSL 검사

서버 인증서가 유효한 것을 알면서도 메일 클라이언트에 인증서 오류가 표시됩니다.

Avast, Bitdefender 등의 "Mail Shield" 또는 "SSL Scanning" 기능은 연결 검사 과정에서 자체 인증서를 제시할 수 있습니다. 보안 담당자와 인증서 체인 및 신뢰 설정을 확인하세요. 필요한 진단은 승인된 범위에서 일시적으로 수행하고 원래 설정으로 복원합니다. 인증서 검증을 끄거나 광범위한 검사 해제와 영구 예외를 적용하지 마세요.

2FA를 사용 중일 때의 앱 비밀번호

이중 인증을 활성화하자 Outlook이 작동을 멈추고 올바른 비밀번호도 계속 거부합니다.

일부 레거시 IMAP/SMTP 클라이언트는 대화형 2FA 인증을 처리하지 못하지만 호환되는 제공업체와 클라이언트는 OAuth를 사용할 수 있습니다. 앱 비밀번호가 필요한지는 실제 계정 정책과 제공업체 지원 여부에 따라 다릅니다. 지원되는 경우에만 해당 기기에 발급하고 안전하게 보관하며 필요 없어지면 폐기하세요. 일반 2FA를 해제하지 마세요.

내 도메인에 이메일 설정하기: 지원팀에 문의하기 전에 준비할 정보

"이메일이 중단됐다"는 내용만으로 티켓을 열면 질문과 답변이 오래 오갈 수 있습니다. 다음 네 가지를 제공하면 첫 답변에서 해결될 가능성을 높일 수 있습니다.

정확한 오류 코드. 다음 코드는 각각 의미가 다릅니다.

550 User Unknown: 서버가 수신자를 알 수 없다고 응답함. 주소와 수신자 설정 확인
421 Connection Refused: 일시적 SMTP 거부 응답. 운영체제의 TCP 연결 거부 오류와 구분하고 전체 서버 응답 확인
535 Authentication Failed: 인증 실패. 인증 정보, 방식과 계정 정책 확인
5.7.1 Relay Access Denied: 릴레이 권한 거부. 인증, 경로와 서버 정책 확인

연결 로그. Outlook 또는 Thunderbird에서 문제 해결 로그를 활성화하세요. 기록된 통신은 실패한 연결 단계를 좁히는 데 도움이 되지만 모든 관련 이벤트가 남는 것은 아닙니다.

CLIENT: EHLO mycomputer
SERVER: 250-Hello
CLIENT: AUTH LOGIN
SERVER: 334 VXNlcm5hbWU6

AUTH LOGIN 뒤의 예시 응답은 사용자 이름을 요청하는 인증 단계이며 잘못된 비밀번호를 입증하지 않습니다. EHLO 전의 중단은 DNS, TCP 연결, TLS 또는 서버 상태를 확인할 단서입니다. 로그를 공유할 때 인증 정보와 개인정보는 가리세요.

CLI 검증. 티켓을 열기 전에 다음 명령을 실행하세요.

# Check MX records
dig mx yourdomain.com +short

# Check SPF record
dig txt yourdomain.com +short

# Test if port 587 is reachable
telnet smtp.trekmail.net 587

telnet 명령에서 220 배너가 표시되면 SMTP 서버까지 TCP 연결이 이루어진 것입니다. TLS, 인증 또는 실제 배달이 검증된 것은 아닙니다. "Connecting..."에서 멈추면 DNS, 서버 상태와 네트워크 경로를 함께 확인하세요. 암호화되지 않은 연결에 비밀번호를 입력하지 마세요.

보다 구체적인 도움말은 메일을 보낼 수 없을 때의 FAQ와 발송 오류 문제 해결 안내서를 참조하세요.

문제가 반복되는 이유: 기존 이메일 호스팅의 근본적인 문제

이 점검표를 여러 번 사용해 문제를 해결했다면 실력보다 인프라가 원인일 수 있습니다.

Google Workspace와 Microsoft 365는 대규모 협업 제품군입니다. 전문 이메일만 필요한 사용자에게는 기능과 관리가 복잡할 수 있습니다. 청구 포털, 도움말 문서, 지원 대기열이 나뉘어 있어 문제가 발생하면 직접 진단해야 하는 경우도 있습니다.

사용자당 가격 모델이 부담을 키울 수도 있습니다. 월 $6-$20는 과거 가격 비교 예시이며 실제 계약과 라이선스 조건을 확인해야 합니다. 일주일에 두 번 사용하는 직원도 별도 사용자 라이선스가 필요할 수 있지만 별칭이나 공유 사서함에는 다른 규칙이 적용될 수 있습니다. 30GB는 저장 공간의 예시로, 실제 공유 및 사용자별 한도와 증설 방법은 에디션에 따라 다릅니다.

TrekMail은 계정 단위 요금과 공유 저장 공간을 사용하는 모델입니다. 과거 Pro 예시의 50GB를 조직이 함께 사용하는 50GB 용량으로 이해하되 현재 요금제와 사서함 제한을 확인하세요. 유료 요금제의 관리형 발송은 실제 이용 권한과 클라이언트 설정에 따르며, 여기서 설명한 Nano 모델은 모든 발신과 답장에 본인의 외부 SMTP가 필요합니다. 서비스가 발송 인프라를 관리해도 사용자의 발송 관행은 평판에 영향을 줍니다. SharePoint, Teams 또는 "Viva"가 필요한지는 업무 요구와 함께 비교하세요.

사용자당 가격이 규모가 커질 때 실제로 얼마가 드는지 자세히 비교하려면 중소기업용 비즈니스 이메일 비용 분석을 참조하세요.

고객, 브랜드 또는 포트폴리오를 위해 여러 도메인을 관리한다면 제어 방식의 차이가 더욱 두드러집니다. 고객 이메일 관리 글에서 전체 프로비저닝 흐름을 설명합니다.

요약

로그인은 되지만 메일이 작동하지 않는다면 다음 다섯 영역부터 점검하세요. MX 경로, ISP의 포트 25 차단 여부, 클라이언트 호스트 이름, SPF/DKIM/DMARC와 실제 인증 결과, 로컬 네트워크입니다. 모든 장애 원인이 이 목록에 포함되는 것은 아닙니다.

위 점검표를 순서대로 실행하세요. 다음 계층을 수정하기 전에 dig와 telnet로 각 계층을 검증합니다. 지원팀에 문의하기 전에 오류 코드와 연결 로그를 수집하세요.

계정 단위 호스팅과 DNS 설정 안내를 비교하려면 TrekMail의 14일 체험을 확인해 보세요. 현재 체험 대상, 카드 등록 및 암호화폐 제한 조건을 확인하세요. 오 분은 간단한 설정의 예시일 뿐이며 실제 사용 준비에는 DNS, 클라이언트와 송수신 검증이 필요합니다.