MX 레코드 없음: 메일이 안 들어올 때

Problem

도메인으로 보낸 메일이 “no MX record” / “recipient domain has no mail server” / “DNS error: no mail exchanger”로 바운스되거나, 조용히 영영 도착하지 않습니다. 같은 도메인의 웹사이트는 멀쩡한데 — 그래서 헷갈립니다. DNS는 살아 있고 도메인도 풀리는데, 메일을 어디로 배달할지 알려주는 DNS 부분이 없거나, 틀렸거나, 아무 데도 안 가리킵니다.

Symptoms

• 바운스 메시지에 550 5.1.2, “Domain not found”, “no MX record”, “Recipient address rejected: undeliverable address”.
• 어떤 발신자는 닿고 어떤 발신자는 안 닿는데, 뚜렷한 패턴이 없음.
• dig MX example.com의 응답 섹션이 비어 있음.
• 어제는 됐는데 DNS 마이그레이션이나 레지스트라 변경이 적용된 직후 깨짐.
• 웹사이트는 열리는데(A 레코드 정상) 수신 메일이 안 들어옴.

MX 레코드가 실제로 하는 일

MX(Mail eXchanger) 레코드는 발신 메일 서버의 단 하나의 진짜 질문에 답하는 DNS 조각입니다: 이 도메인의 메일을 어디로 넘기지? 두 부분으로 돼 있습니다 — 우선순위 숫자와 호스트명. 우선순위는 낮을수록 이깁니다: MX 10 mail1.example.com이 MX 20 mail2.example.com보다 먼저 시도되므로, 작은 숫자가 주(primary)이고 큰 숫자가 백업입니다. 그 호스트명은 다시 A나 AAAA 레코드로 해석돼야 발신자가 실제로 연결할 IP를 압니다.

여기서 사람들이 걸려 넘어집니다. 도메인이 MX를 하나도 발행하지 않으면 표준은 “포기하라”고 하지 않습니다. RFC 5321 §5.1은 발신자가 도메인의 A/AAAA 레코드로 폴백해 그것을 우선순위 0의 암묵적 MX로 취급’해야 한다(SHOULD)‘고 — 웹 서버 IP로 배달을 시도하고 포트 25에 뭔가 떠 있길 바라라고 — 합니다. 이 폴백 때문에 MX 없는 도메인 일부가 여전히 메일을 받습니다. 하지만 이건 MUST가 아니라 SHOULD고, 상당수 현대 발신자는 더 이상 이를 구현하지 않습니다. 그래서 “MX 없음”은 깔끔하게 실패하지 않습니다. 어느 서버가 보내느냐에 따라 확률적으로 실패합니다 — 그리고 간헐적 메일 유실은 깔끔한 전면 바운스보다 진단하기가 훨씬 어렵습니다.

Top 3 Causes

1. MX 레코드가 아예 발행되지 않음. 존에 웹사이트용 A/AAAA는 있는데 MX를 추가한 사람이 없거나, 마이그레이션이 그걸 떨어뜨렸습니다. A 폴백을 존중하는 발신자는 통과하고, 안 하는 발신자는 바운스됩니다. 단서: 일부 출처에선 되고 다른 데선 실패하는 배달, 그리고 dig MX example.com이 비어서 돌아옴.
2. MX 타깃이 해석 안 되거나 CNAME을 가리킴. MX 레코드는 있는데 그 호스트명에 A/AAAA가 없거나(오타, 폐기된 호스트, 글루 누락), CNAME 별칭을 가리킵니다 — RFC 2181 §10.3이 금지하는. 발신자는 MX를 찾고 교환 호스트를 해석하려다 쓸 만한 게 없으니 포기합니다. 단서: dig MX엔 레코드가 보이는데 dig A <그 호스트명>이 비어 있거나 CNAME을 반환.
3. 널 MX가 아직 발행돼 있거나, MX가 엉뚱한 이름에 있음. 남아 있는 MX 0 .(RFC 7505)는 모든 발신자에게 “이 도메인은 메일 안 받음”을 알려 즉시 영구 바운스를 강제합니다 — 호스트가 파킹하거나 템플릿화해준 도메인에서 흔합니다. 또는 메일은 @example.com으로 오는데 MX가 mail.example.com에 발행돼 있습니다; 레코드는 있지만 사람들이 실제로 보내는 이름에 없는 거죠.

Diagnose with DechoNet

• Email Check는 발신 서버가 하듯 도메인의 MX 레코드를 조회해 우선순위 값과 타깃 호스트명을 보여주고, MX 누락·널 MX·인증 공백을 한 번에 표시합니다 — “등록된 메일 서버 없음”인지 “등록은 됐는데 설정이 틀림”인지를 즉시 구분할 수 있습니다.
• DNS Check로는 MX 타깃 호스트명을 단독으로 해석해볼 수 있습니다. Email Check에 MX는 보이는데 메일이 계속 바운스되면, 여기서 교환 호스트의 A/AAAA를 질의하세요: 그 이름에서 빈 응답이나 CNAME이 나오면 그게 결정적 증거입니다.

Resolution Checklist

• 레코드가 실제로 있는지 확인: dig MX example.com +short. 빈 결과면 MX가 발행 안 됐다는 뜻 — 그게 답입니다.
• 출력에 0 .이 보이면 그건 널 MX(RFC 7505)입니다. 도메인이 메일을 받아야 한다면 삭제하고 진짜 MX를 발행하세요.
• MX 타깃이 해석되는지 확인: MX 레코드의 호스트명을 가져와 dig A mail.example.com +short. CNAME도 빈 값도 아닌 IP를 직접 반환해야 합니다.
• MX가 주소에 쓰이는 정점(apex)/존(example.com)에 있는지 검증 — 아무도 안 보내는 서브도메인이 아니라. MX 레코드 왼쪽의 이름이 @ 뒤의 부분과 일치해야 합니다.
• 우선순위 숫자를 점검: 낮을수록 우선. 백업 MX가 주 MX보다 낮은 숫자면 메일이 엉뚱한 서버로 먼저 갑니다.
• 변경 후엔 MX 레코드의 TTL이 만료될 때까지 기다렸다 다시 테스트하세요 — 옛 답은 그때까지 캐시에 남습니다.

When to Escalate

• dig MX가 올바른 레코드를 반환하고 타깃도 맞는 IP로 풀리는데 메일이 계속 바운스되면, 문제는 DNS를 지나 메일 서버 자체로 옮겨간 겁니다: 포트 25에 아무것도 안 떠 있거나, 연결을 거부하고 있습니다. 메일 서버 운영자에게 넘기세요.
• DNS 존을 직접 관리하지 않고(관리형 호스트, 레지스트라 기본 존), 틀렸거나 널 MX가 그들의 템플릿에 박혀 있다면, 제공자가 바꿔줘야 합니다 — 클라이언트가 자기가 관리하지 않는 권한 레코드를 덮어쓸 수는 없습니다.