MX 우선순위는 숫자가 큰 쪽이 먼저인가요?

아닙니다. 숫자가 작은 쪽이 먼저입니다. preference 값은 순위가 아니라 거리에 가까운 개념으로, 발신 서버는 가장 작은 값을 가진 서버에 먼저 접속하고 실패하면 다음으로 작은 값을 시도합니다. 값이 같은 MX가 여럿이면 그 사이에서는 무작위로 나누어 보냅니다.

MX 레코드를 CNAME으로 만들면 왜 안 되나요?

MX 레코드의 값 자리에는 CNAME이 아닌 실제 A 또는 AAAA 레코드를 가진 호스트 이름이 와야 한다고 규격에 정해져 있습니다. CNAME을 가리키면 발신 서버에 따라 조회를 거부하거나 메일을 반송할 수 있습니다. 메일 서비스가 안내하는 호스트 이름을 그대로 MX 값에 넣으세요.

MX가 아예 없으면 메일은 어디로 가나요?

MX가 없으면 발신 서버는 도메인의 A 레코드로 메일을 보내려 시도합니다(implicit MX). 그 A 레코드가 웹 서버라면 메일을 받을 수 없어 반송됩니다. 웹사이트는 잘 열리는데 메일만 들어오지 않는 증상이 여기서 나옵니다.

MX를 바꾸면 전환되는 데 얼마나 걸리나요?

바꾼 레코드가 퍼지는 속도는 기존 레코드의 TTL에 달려 있습니다. TTL이 3600초면 한 시간 안에 대부분 반영되지만, 중간 서버의 캐시 때문에 최대 48시간까지 옛 서버로 메일이 들어올 수 있습니다. 그래서 바꾸기 전에 TTL을 먼저 낮춰 둡니다.

MX를 여러 서비스로 동시에 둘 수 있나요?

같은 도메인의 메일을 두 서비스가 나누어 받게 하는 구성은 권장하지 않습니다. 우선순위가 낮은 쪽이 받은 메일은 그 서비스의 메일함에만 남아, 어느 계정에 메일이 들어왔는지 찾기 어려워집니다. 한 도메인의 MX는 한 서비스로 모으고, 필요하면 서브도메인을 분리하세요.

MX 레코드 이해하기

MX 레코드는 "이 도메인 주소로 온 메일을 어느 서버가 받는가"를 DNS에 적어 두는 레코드입니다. 누군가 회사 주소로 메일을 보내면 발신 서버는 먼저 그 도메인의 MX를 조회하고, 거기 적힌 호스트로 접속해 메일을 건넵니다. 그래서 MX가 없거나 잘못 적혀 있으면 보낸 쪽에는 정상으로 보이지만 메일은 들어오지 않습니다.

MX 값은 메일 서비스가 알려 줍니다. 우리가 이해해야 하는 것은 우선순위 숫자를 읽는 법과, 바꿀 때 메일을 잃지 않는 순서입니다.

MX 레코드가 하는 일

MX 레코드는 두 부분으로 되어 있습니다. 앞의 숫자는 우선순위(preference), 뒤는 메일을 받을 서버의 호스트 이름입니다.

example.com.   IN   MX   10   mail.example.com.
#                        ↑    ↑
#                우선순위     메일을 받을 호스트

발신 서버의 동작 순서는 이렇습니다.

받는 주소의 @ 뒤 도메인으로 MX를 조회합니다.
돌아온 MX 목록을 우선순위 값이 작은 것부터 정렬합니다.
가장 작은 값의 호스트를 A 또는 AAAA로 조회해 IP를 얻고, 25번 포트로 접속합니다.
접속이나 전달이 실패하면 다음으로 작은 값의 호스트를 시도합니다.
모두 실패하면 일정 시간 뒤 처음부터 다시 시도하고, 재시도 한도를 넘기면 발신자에게 반송 메일을 보냅니다.

즉 MX는 수신 경로만 정합니다. 우리가 메일을 보낼 때 어떤 서버를 쓰는지, 그 발신이 인증을 통과하는지는 MX와 무관하며 SPF, DKIM, DMARC가 담당합니다.

우선순위 숫자는 작은 값이 먼저입니다

가장 많이 오해하는 부분입니다. preference 값은 "크면 중요하다"가 아니라 "작으면 먼저 간다"로 읽습니다. 값 자체의 크기에는 의미가 없고, 서로 간의 크기 순서만 의미가 있습니다.

@   MX   1    aspmx.example-mail.com.     # 여기로 먼저 갑니다
@   MX   5    alt1.example-mail.com.      # 위가 실패하면 여기
@   MX   5    alt2.example-mail.com.      # alt1과 5:5로 나뉩니다
@   MX   10   backup.example-mail.com.    # 위가 모두 실패하면 여기

1, 5, 10 과 10, 20, 30 은 동작이 같습니다. 나중에 서버를 끼워 넣을 자리를 남기려고 보통 10 단위로 띄워 적습니다. 값이 같은 MX가 여럿이면 발신 서버는 그 사이에서 부하를 나누어 보내므로, 같은 값은 "둘 중 아무 쪽이나"라는 뜻이 됩니다.

MX를 여러 개 두는 이유

MX가 여러 개 있으면 첫 번째 서버가 점검이나 장애로 응답하지 않을 때 메일이 두 번째 서버로 들어갑니다. 이때 두 번째 서버는 보통 메일을 잠시 보관하다가 첫 번째 서버가 살아나면 넘겨 줍니다.

주의할 점이 있습니다. 백업 MX를 운영 능력 없이 두면 오히려 손해입니다. 스팸 발송자는 필터가 약한 낮은 우선순위 서버를 노려 메일을 밀어 넣는 경우가 많고, 백업 서버가 수신자 목록을 모르면 존재하지 않는 주소의 메일까지 일단 받아 두었다가 나중에 반송하게 됩니다. 백업 MX는 같은 서비스가 제공하는 것만 쓰고, 직접 구성할 때는 주 서버와 같은 필터와 수신자 검증을 적용해야 합니다.

MX 값은 CNAME을 가리킬 수 없습니다

MX 레코드의 값 자리에는 A 또는 AAAA 레코드를 가진 호스트 이름이 와야 합니다. 그 이름이 CNAME이면 규격 위반이며, 발신 서버 구현에 따라 조회를 포기하거나 메일을 반송합니다.

# 잘못된 구성
mail.example.com.   CNAME   ghs.example-mail.com.
example.com.        MX      10   mail.example.com.   # CNAME을 가리킴

# 올바른 구성
example.com.        MX      10   aspmx.example-mail.com.   # 서비스가 준 호스트를 그대로

같은 이유로 MX 값에는 IP 주소를 직접 적을 수 없습니다. 반드시 호스트 이름이어야 합니다. 또 MX 호스트 이름 쪽에 CNAME과 MX가 같은 이름으로 공존하는 것도 피해야 합니다. 레코드 종류별 제약은 DNS 레코드 설정에 더 자세히 있습니다.

없거나 잘못 걸렸을 때의 증상

상태	증상	확인 지점
MX 없음	웹사이트는 열리는데 메일만 들어오지 않음. 발신자에게 주소 없음 반송	`dig MX` 결과가 비어 있음
옛 서비스 MX가 남아 있음	일부 메일은 새 서비스로, 일부는 옛 메일함으로 갈라짐	MX 목록에 두 서비스의 호스트가 섞여 있음
호스트 이름 오타	전체 수신 중단. 발신자에게 도메인 조회 실패 반송	MX 값의 A 레코드 조회가 실패
끝 점 누락으로 도메인 중복	`aspmx.example-mail.com.example.com` 같은 값이 조회됨	MX 값 끝에 도메인이 한 번 더 붙어 있음
MX가 CNAME을 가리킴	일부 발신 서버에서만 반송되어 재현이 어려움	MX 값 호스트의 레코드 종류가 CNAME
방화벽이 25번 포트 차단	MX는 정상인데 접속 단계에서 실패	자체 서버 운영 시 인바운드 25번 포트

증상별 진단 순서는 메일이 오지 않을 때에 정리했습니다.

바꿀 때 메일을 잃지 않는 순서

MX를 바꾸는 순간 모든 발신 서버가 동시에 새 서버를 보기 시작하지는 않습니다. 옛 레코드의 TTL이 남아 있는 동안에는 옛 서버로도 메일이 계속 들어옵니다. 그래서 순서가 중요합니다.

바꾸기 며칠 전에 TTL을 낮춥니다
현재 MX 레코드의 TTL을 300초(5분)로 내리고, 원래 TTL만큼 기다립니다. 원래 값이 86400초(24시간)였다면 최소 하루를 기다려야 기존 캐시가 모두 만료됩니다. 이 단계를 빼면 전환 당일에 반영을 기다리는 시간이 길어집니다.
새 쪽에 계정과 별칭을 모두 만듭니다
MX를 바꾼 뒤 새 서비스에 없는 주소로 메일이 들어오면 바로 반송됩니다. 직원 계정, 공용 주소, 퇴사자 별칭까지 전부 새 쪽에 만들어 둔 다음 바꿉니다.
업무가 적은 시간에 MX를 교체합니다
옛 서비스의 MX 레코드를 지우고 새 값을 넣습니다. 두 서비스의 MX를 동시에 두지 않습니다. 수신이 갈라지면 어느 쪽에 메일이 들어왔는지 추적하기 어려워집니다.
양쪽 메일함을 며칠 함께 확인합니다
전파가 끝나도 캐시가 긴 일부 발신 서버는 한동안 옛 서버로 보냅니다. 옛 서비스 계정을 바로 해지하지 말고 며칠 동안 살려 두면서 새로 들어온 메일이 없는지 봅니다.
전파가 끝난 뒤 TTL을 되돌립니다
새 MX가 안정적으로 동작하는 것을 확인하면 TTL을 3600초 정도로 되돌립니다. TTL이 너무 짧으면 조회가 늘고, 너무 길면 다음 변경 때 또 기다려야 합니다.

서비스 이전 전체 절차는 메일 서비스 옮기기에 계정 이관과 인증 레코드 재설정까지 포함해 정리했습니다.

dig로 확인하기

MX는 명령 한 줄로 확인할 수 있습니다. 전파가 덜 끝났는지 판단할 때는 권한 네임서버에 직접 물어보는 방법이 확실합니다.

# 현재 보이는 MX 목록 (우선순위와 호스트)
dig +short MX example.com

# MX 값 호스트가 실제로 IP를 가지고 있는지
dig +short A aspmx.example-mail.com

# 권한 네임서버에 직접 질의 (캐시를 건너뜀)
dig MX example.com @ns1.example-dns.com +norecurse

# 남은 TTL 확인 (응답의 두 번째 열)
dig MX example.com | grep -A2 "ANSWER SECTION"

dig +short MX 결과에 새 서비스의 호스트만 보이고 옛 호스트가 없으면 교체가 끝난 것입니다. 응답이 비어 있다면 레코드가 없거나 호스트 이름 자리가 비어 있는 경우입니다. 조회 도구를 더 보려면 DNS 조회 도구를, 레코드를 바꿨는데 반영되지 않는 것처럼 보일 때는 DNS 변경이 반영되지 않을 때를 참고하세요.