메일이 안 오는데 웹사이트는 잘 열립니다. 왜 그런가요?

웹과 메일은 서로 다른 레코드를 씁니다. 웹사이트는 A 레코드로, 메일은 MX 레코드로 목적지가 정해집니다. MX 가 비어 있거나 잘못된 호스트를 가리키면 사이트는 정상인데 메일만 들어오지 않습니다. dig MX 로 값을 먼저 확인하세요.

상대는 보냈다고 하는데 제 메일함에 없습니다.

먼저 스팸함과 전체 메일 검색으로 확인하고, 보낸 쪽에 반송 메일을 받았는지 물어보세요. 반송이 없고 메일함에도 없다면 수신 서버까지 도착한 뒤 필터나 전달 규칙이 다른 폴더로 옮긴 경우가 많습니다. 메일 서비스의 수신 로그나 감사 로그에서 해당 메시지 ID 를 추적하는 것이 가장 확실합니다.

보낸 메일이 특정 회사에만 안 들어갑니다.

그 회사의 수신 정책이 엄격하거나 발신 IP 평판이 낮은 경우입니다. SPF, DKIM, DMARC 가 모두 통과하는지 먼저 확인하고, 바운스 메시지에 차단 사유나 조회용 링크가 있으면 그 안내를 따릅니다. 평판 문제라면 해제 요청 절차를 거쳐야 하므로 시간이 걸립니다.

메일 용량이 꽉 차면 어떤 증상이 나오나요?

보낸 쪽에 용량 초과를 뜻하는 영구 오류가 반송되거나, 서비스에 따라 일시 오류로 재시도 후 반송됩니다. 메일함이나 계정 전체 할당량이 원인이므로 오래된 첨부를 비우거나 할당량을 늘려야 합니다. 웹 호스팅 플랜을 쓴다면 대시보드 호스팅 상세에서 이메일 계정의 할당량을 확인할 수 있습니다.

MX 를 바꿨는데 옛 서버로 메일이 계속 들어옵니다.

이전 MX 값의 TTL 이 남아 있어 발신 서버들이 캐시된 값을 그대로 쓰는 것입니다. 옛 메일 서버를 바로 끄면 그동안 도착한 메일이 반송되므로, 전환 뒤 최소 며칠은 양쪽을 모두 살려 두는 것이 안전합니다.

회사 메일이 오지 않을 때

회사 메일 문제는 가장 먼저 방향을 갈라야 합니다. 받는 메일이 안 오는 것과 보낸 메일이 상대에게 안 가는 것은 원인도 확인 방법도 전혀 다릅니다. 받는 쪽 문제라면 dig MX example.co.kr +short 로 목적지가 제대로 적혀 있는지 보는 것이 가장 빠르고, 보내는 쪽 문제라면 반송(바운스) 메일의 응답 코드를 읽는 것이 가장 빠릅니다.

양쪽이 동시에 안 된다면 도메인 자체나 DNS 위임 문제일 가능성이 큽니다. 그 경우에는 사이트가 열리지 않을 때의 1번, 2번 단계를 먼저 확인하세요.

어느 방향의 문제인지 먼저 정합니다

증상	방향	가장 먼저 볼 것
외부에서 보낸 메일이 안 들어온다	수신	MX 레코드, 스팸함, 용량
사내끼리는 되는데 외부 메일만 안 들어온다	수신	MX 레코드와 방화벽
우리가 보낸 메일이 상대 스팸함에 있다	발신	SPF, DKIM, DMARC
우리가 보낸 메일이 반송된다	발신	바운스 메시지의 응답 코드
특정 회사에만 안 들어간다	발신	발신 IP 평판과 그 회사 정책
수신도 발신도 모두 안 된다	공통	도메인 상태와 네임서버 위임

받는 메일이 안 오는 경우

MX 레코드가 실제로 무엇을 가리키는지 확인합니다
```
# 공개 리졸버가 답하는 MX
dig MX example.co.kr +short

# 권한 네임서버에 직접 질의 (전파 문제와 구분)
dig @ns1.example-dns.com MX example.co.kr +noall +answer

# MX 가 가리키는 호스트가 실제 IP 를 갖는지
dig A mail.example.co.kr +short
```
값이 비어 있으면 발신 서버는 도메인의 A 레코드로 메일을 보내려 시도하고, 그 IP가 웹 서버라면 메일은 반송됩니다. 값이 있는데 가리키는 호스트가 CNAME이면 규격 위반이라 일부 발신 서버가 거부합니다. 우선순위 숫자의 의미와 올바른 값 형태는 MX 레코드 이해하기에 정리했습니다.
메일 서버가 실제로 접속을 받는지 확인합니다
MX가 맞아도 서버가 25번 포트를 닫고 있으면 메일은 들어오지 않습니다.
```
# SMTP 접속과 인사 확인
openssl s_client -connect mail.example.co.kr:25 -starttls smtp -crlf

# 포트만 빠르게 확인
nc -vz mail.example.co.kr 25
```
접속 직후 220 으로 시작하는 인사 줄이 보이면 서버는 살아 있습니다. 응답이 없으면 메일 서비스 장애이거나 방화벽 문제이므로 메일 서비스의 상태 페이지를 확인하세요.
스팸 필터와 전달 규칙을 확인합니다
메일이 서버까지는 도착했는데 받은 메일함에 없는 경우가 의외로 많습니다. 스팸함, 휴지통, 보관함을 전체 검색으로 확인하고, 메일 서비스 관리 화면에서 차단 목록과 자동 전달 또는 분류 규칙이 걸려 있는지 봅니다. 담당자가 퇴사하면서 남겨 둔 전달 규칙이 원인인 사례도 흔합니다.
메일함 용량과 계정 상태를 확인합니다
메일함이 꽉 차면 보낸 쪽에 용량 초과 오류가 반송됩니다. 계정이 정지되었거나 삭제된 경우에도 같은 증상이 나옵니다. 웹 호스팅 플랜을 쓰고 있다면 https://app.leto.kr 의 호스팅 관리 에서 해당 호스팅 상세를 열면 이메일 계정 카드에서 계정 목록과 할당량 을 볼 수 있습니다. 계정을 새로 만들거나 비밀번호를 바꾸는 작업은 상세 화면의 Plesk 로그인 으로 제어판에 들어가서 합니다.
최근에 DNS 를 바꿨다면 전파 상태를 확인합니다
MX나 네임서버를 바꾼 직후라면 일부 발신 서버가 아직 옛 값을 쓰고 있을 수 있습니다. 권한 서버와 공개 리졸버의 답이 다른지 비교하고, 다르다면 DNS 변경이 반영되지 않을 때를 보세요. 전환 중에는 옛 메일 서버를 끄지 말고 그대로 둡니다.

보낸 메일이 상대에게 안 가는 경우

반송 메일이 왔는지부터 확인합니다
반송 메일이 있으면 원인이 적혀 있습니다. 없다면 상대 쪽 스팸함 또는 조용한 폐기(silent drop)이므로 인증 설정을 의심합니다.

바운스 메시지의 응답 코드를 읽습니다

첫 숫자가 5 면 영구 오류라서 다시 보내도 같은 결과이고, 4 면 일시 오류라 재시도로 해결될 수 있습니다.

550 5.1.1 User unknown            수신 주소가 없음. 주소 오타 확인
550 5.7.1 Message rejected        정책 차단. 인증 실패나 내용 필터
550 5.7.26 Unauthenticated        SPF/DKIM 미설정 또는 실패
552 5.2.2 Mailbox full            상대 메일함 용량 초과
421 4.7.0 Try again later         속도 제한. 잠시 뒤 재시도
451 4.7.1 Greylisted              그레이리스팅. 보통 자동 재시도로 해결

5.7.x 계열은 거의 모두 인증이나 평판 문제입니다. 메시지 본문에 차단 사유 안내 링크가 붙어 있으면 그 안내를 먼저 따르세요.

보낸 메일의 헤더에서 인증 결과를 확인합니다
외부 계정으로 테스트 메일을 보낸 뒤 원본 보기에서 Authentication-Results 헤더를 읽습니다.
```
Authentication-Results: mx.example.com;
       dkim=pass header.i=@example.co.kr header.s=default;
       spf=pass smtp.mailfrom=example.co.kr;
       dmarc=pass header.from=example.co.kr
```
세 항목이 모두 pass 여야 합니다. 레코드 자체가 있는지는 바로 확인할 수 있습니다.
```
dig +short TXT example.co.kr              # SPF
dig +short TXT default._domainkey.example.co.kr   # DKIM 공개키
dig +short TXT _dmarc.example.co.kr       # DMARC 정책
```
설정 방법과 흔한 실수는 SPF, DKIM, DMARC 설정에 정리되어 있습니다.
발신 IP 의 평판을 확인합니다
인증이 모두 통과하는데도 특정 수신처에서만 막히면 발신 IP 평판 문제입니다. 공유 IP를 쓰는 서비스라면 같은 IP의 다른 사용자 때문에 영향을 받기도 합니다. 역방향 조회가 제대로 설정되어 있는지도 확인합니다.
```
# 발신 IP 의 역방향 조회 (PTR)
dig -x 203.0.113.10 +short
```
PTR이 없거나 발신 도메인과 무관한 이름이면 감점 요인입니다. 평판 회복과 발송량 관리는 메일 도달률 관리를 참고하세요.

그래도 해결되지 않으면

메일 문제는 근거 자료가 있으면 진단이 훨씬 빠릅니다. 아래 내용을 모아 문의로 보내 주세요.

수신 문제인지 발신 문제인지, 언제부터인지
dig MX 출력과 dig TXT 로 확인한 SPF, DKIM, DMARC 값
반송 메일 전문 (응답 코드와 진단 문구 포함)
문제가 된 메일의 헤더 전문 (Received 와 Authentication-Results 포함)
특정 상대에게만 문제인지, 모든 상대에게 문제인지
최근에 바꾼 DNS 레코드나 메일 서비스 설정