MX 레코드 설정·확인: 우선순위와 페일오버

지금 설정하려는 것

MX(Mail eXchanger) 레코드는 인터넷의 모든 메일 서버에게 이 도메인 메일을 어디로 배달할지 알려주는 DNS 한 줄입니다. 한 번 제대로 넣으면 몇 년간 신경 쓸 일이 없습니다. 그런데 숫자 하나, 호스트명 하나가 틀리면 메일이 DNS 문제로는 절대 안 보이는 방식으로 고장 납니다 — 간헐적 바운스, 어떤 발신자한테선 오고 다른 발신자한테선 안 오는 메일, 어제까지 되다가 마이그레이션 후 멈춘 배달. MX를 추가·변경하거나 다시 확인하면서, 자리를 뜨기 전에 정말 맞게 됐는지 확인하고 싶을 때 보는 가이드입니다.

MX 레코드의 두 부분

모든 MX 레코드는 정확히 두 필드로 되어 있고, 둘 다 사고를 냅니다:

example.com.   3600   IN   MX   10   mail.example.com.
                              │    │
                       preference   타깃 호스트명

• preference — 낮을수록 우선인 숫자. 발신자는 가장 낮은 번호의 호스트를 먼저 시도합니다. 사람들이 거꾸로 넣는 필드입니다.
• 타깃 — A 또는 AAAA 레코드로 풀리는 호스트명. CNAME도, IP 주소도, 아무 데도 안 풀리는 이름도 안 됩니다.

“레코드가 있다”와 “레코드가 작동한다” 사이의 간극은 전부 이 두 필드에 있습니다.

preference 설정: 주 서버와 백업

메일 서버가 하나뿐이면 MX 레코드 하나면 되고 preference 숫자는 거의 의미가 없습니다 — 10이 관례지만 비교 대상이 없으면 5나 50도 똑같이 동작합니다. 이 숫자는 다른 MX 레코드와의 상대값으로만 의미가 있습니다.

백업이 흥미로워지는 지점입니다. 더 높은 번호(예: 20)의 두 번째 MX는 폴백입니다: 주 서버가 죽으면 발신자가 백업에 큐를 쌓습니다. 그런데 백업 MX는 주 서버가 돌아왔을 때 메일을 붙잡아 넘겨줄 줄 알아야 쓸모가 있고, 대부분의 가이드가 건너뛰는 부분이 여기 있습니다: 유효한 수신자 목록을 모르는 백업 MX는 안전망이 아니라 부채입니다. 아무한테나 온 메일을 다 받아놓고 배달 못 하는 것들에 대해 위조된 발신자에게 바운스를 쏘는데 — 이 백스캐터가 당신의 백업을 블록리스트에 올립니다. 스패머가 백업 MX 호스트를 노리는 이유가 바로 주 서버보다 덜 엄격한 경향 때문입니다. 백업이 완전한 수신자 검증을 하지 않는 한, 백업 MX 없이 SMTP가 이미 보장하는 것 — 며칠간 큐잉·재시도 — 에 맡기는 편이 대개 낫습니다.

동급 preference는 다른 패턴입니다. 둘 다 10인 호스트는 수신 메일을 나눠 받습니다 — 진짜 부하 분산이고, 메일을 받을 능력이 동등한 서버 두 대가 있을 때 맞는 선택입니다. 다만 개념을 섞지 마세요: 같은 숫자는 “둘 다 살아 있다”지 “하나는 예비”가 아닙니다.

스플릿 MX 함정

가장 파괴적인 MX 실수는 메일 마이그레이션 중에 일어나고, MX 문제로 진단되는 경우가 거의 없습니다. 옛 제공업체에서 새 제공업체로 옮깁니다. 새 제공업체 MX를 추가합니다. 그리고 옛 것을 지우는 걸 잊습니다. 이제 도메인은 MX 레코드 두 개 — 옛것과 새것 — 를 발행하고, 인터넷의 모든 발신 서버가 preference 숫자와 각자의 재시도 로직에 따라 어디로 배달할지 고릅니다.

결과는 두 시스템 사이에서 무작위처럼 갈라지는 메일입니다. 어떤 메시지는 새 메일함에, 어떤 건 아무도 안 보는 옛 메일함에 떨어지고, 캐시가 만료되면서 패턴이 바뀝니다. 사용자들은 메일이 “사라진다”고 합니다. 사라진 게 아니라 — 도착은 하는데 죽어 있어야 할 메일함에 도착하는 겁니다. 해결은 시시합니다: 마이그레이션 중엔 새 MX가 작동하는 걸 확인하는 즉시 옛 MX를 내립니다. “언젠가”가 아니라.

DechoNet으로 진단

• 이메일 점검은 도메인의 MX 레코드를 발신 서버와 똑같이 읽어 — 모든 MX와 preference 숫자, 타깃 호스트명이 풀리는지를 보여줘 — 거꾸로 된 preference, 남아 있는 스플릿 MX 레코드, 아무 데도 안 가는 타깃을 SPF·DMARC 상태와 함께 한 번에 잡아냅니다.
• DNS 점검으로 MX 타깃을 따로 풀어볼 수 있습니다. 이메일 점검이 MX는 보여주는데 뒤의 호스트가 진짜인지 확인하고 싶으면, 그 호스트명의 A/AAAA 레코드를 여기서 조회하세요 — 빈 결과나 그 이름의 CNAME이 문제입니다.

확인 체크리스트

• 레코드가 발행돼 읽히는지 확인: dig MX example.com +short. preference 숫자와 타깃 호스트명이 보여야 하고, 넣지 않은 건 없어야 합니다.
• 잔여 레코드 확인. MX가 두 개 이상 뜨는데 하나만 의도했다면, 옛 레코드가 아직 살아 있는 것 — 메일을 잃을 스플릿 MX입니다.
• 타깃이 별칭이 아니라 주소로 풀리는지 확인: dig A mail.example.com +short는 CNAME이 아니라 IP를 바로 반환해야 합니다.
• MX가 사람들이 메일 보내는 정확한 이름에 있는지 확인. 주소가 @example.com이면 레코드는 example.com에 있어야 합니다 — mail.example.com의 MX는 apex로 온 메일엔 아무 역할도 못 합니다.
• preference 순서 점검: 진짜 주 서버가 가장 낮은 숫자여야 합니다. 낮은 게 먼저 시도됩니다.
• 옛 레코드의 TTL이 지날 때까지 기다린 뒤 성공을 선언하세요. 이전 응답의 TTL이 만료되기 전엔 발신 서버가 옛 MX를 캐시에 들고 있을 수 있습니다 — 즉시 말고 TTL 창이 지난 뒤 재확인하세요.

MX 문제가 아닐 때

dig MX가 올바른 레코드를 보여주고, 타깃이 맞는 IP로 풀리고, preference도 멀쩡한데 메일이 여전히 안 오면, DNS는 제 몫을 다한 것이고 문제는 하류로 내려간 겁니다: 그 호스트의 25번 포트에서 아무것도 안 듣고 있거나, 메일 서버가 연결을 거부하거나, 방화벽이 인바운드 SMTP를 떨어뜨리는 중입니다. 수신 호스트를 운영하는 쪽의 메일 서버·네트워크 문제입니다 — MX 레코드는 이정표일 뿐 메일함이 아닙니다.

내 도메인에서 바로 확인

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

진단