MX 레코드: 이메일이 서버를 찾는 방법

모든 이메일 전송은 하나의 질문으로 시작됩니다: 이 도메인의 메일을 누가 받는가?

someone@example.com으로 이메일을 보낼 때, 발신 메일 서버는 example.com이 어디서 메일을 받는지 저절로 알 수 없습니다. 그래서 직접 물어봅니다. DNS에 MX(Mail Exchanger) 레코드를 질의합니다—"이메일 수신에 관해서 이 도메인을 대표하는 서버는 어디인가?"라는 질문에 답하는 DNS 레코드입니다.

답은 호스트명으로 돌아옵니다: "example.com의 메일은 mail.example.com으로 보내세요." 그러면 서버는 그 호스트명의 IP 주소를 조회하고 메시지를 전달합니다.

왜 IP 주소가 아닌 호스트명인가

두 단계로 이루어지는 과정에 주목해 보세요: MX 레코드가 호스트명을 가리키고, 호스트명이 IP 주소를 가리킵니다. 메일 서버를 교체할 필요가 생기기 전까지는 언뜻 불필요하게 돌아가는 것처럼 느껴집니다.

MX 레코드가 IP 주소를 직접 가리켰다면, 새 메일 서버로 이전할 때 호스팅하는 모든 도메인의 MX 레코드를 업데이트해야 하고—그런 다음 전 세계 DNS 캐시가 만료되기를 기다려야 합니다. 대신 메일 서버 호스트명의 A 레코드 하나만 업데이트하면, 그 호스트명을 사용하는 모든 도메인이 즉시 새 IP를 가리킵니다.

이 간접 참조 방식은 SMTP 규격인 RFC 5321에서 요구하는 사항입니다. MX 레코드는 반드시 호스트명을 가리켜야 하며, IP 주소를 직접 가리킬 수 없습니다. 이 규칙을 위반하는 도메인에서 온 메일은 많은 메일 서버가 거부합니다.

우선순위: 자동 장애 전환

MX 레코드에는 우선순위 값이 포함되어 있습니다—어느 서버를 먼저 시도할지 결정하는 숫자입니다:

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup.example.com.

숫자가 낮을수록 우선순위가 높습니다. example.com으로 이메일이 도착하면, 발신 서버는 먼저 mail.example.com(우선순위 10)을 시도합니다. 그 서버에 연결할 수 없을 때만 backup.example.com(우선순위 20)으로 전환합니다.

이것은 프로토콜에 내장된 장애 전환입니다. 백업 서버는 기본 서버와 미리 조율할 필요가 없습니다. 기본 서버가 다운되었다는 것을 알 필요도 없습니다. 발신 서버가 알아서 처리합니다—선호하는 서버를 먼저 시도하고, 안 되면 다음 서버로 넘어갑니다.

부하 분산

두 MX 레코드가 같은 우선순위를 공유하면 어떻게 될까요?

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.

발신 서버는 무작위로 하나를 선택합니다. 이렇게 하면 별도의 부하 분산기 없이도 여러 서버에 수신 이메일이 분산됩니다—무작위성이 프로토콜에 내장되어 있습니다.

이 패턴들을 조합하면 정교한 구성이 가능합니다:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.
example.com.  IN  MX  20  backup.example.com.

평소에는 mail1과 mail2에 부하를 분산하고, 둘 다 다운되면 backup으로 전환합니다.

클라우드 이메일 구성

Google Workspace와 Microsoft 365는 이중화에 대한 두 가지 다른 철학을 보여줍니다.

Google Workspace:

example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  IN  MX  10  alt4.aspmx.l.google.com.

기본 서버 하나(우선순위 1), 부하 분산을 위한 대체 서버 둘(우선순위 5), 더 깊은 단계의 장애 전환을 위한 서버 둘(우선순위 10). DNS에 명시된 다섯 겹의 이중화입니다.

Microsoft 365:

example.com.  IN  MX  10  example-com.mail.protection.outlook.com.

레코드 단 하나입니다. Microsoft는 모든 이중화를 내부적으로 처리합니다—단일 호스트명이 전 세계에 분산된 인프라로 라우팅됩니다. 단순함 자체가 핵심입니다.

MX 문제 진단

이메일이 도착하지 않을 때, MX 레코드가 가장 먼저 확인해야 할 항목입니다:

dig example.com MX

자주 발생하는 문제들:

• MX 레코드가 전혀 없음. 이메일이 갈 곳이 없습니다.
• 우선순위가 거꾸로 됨. 백업 서버의 번호가 기본 서버보다 낮아, 모든 트래픽을 백업 서버가 받게 됩니다.
• MX가 CNAME을 가리킴. RFC 5321은 이를 금지합니다. 일부 서버는 허용하지만, 다른 서버는 메일을 거부합니다.
• MX가 IP 주소를 직접 가리킴. SMTP 규격 위반입니다. 많은 서버가 해당 메일을 거부합니다.

조율 문제

MX 레코드는 언뜻 불가능해 보이는 문제를 풀어냅니다: 전 세계 수백만 개의 메일 서버가 어떤 중앙 기관의 지시 없이도, 수백만 개의 도메인으로 메일을 어디에 전달해야 하는지 알아야 합니다.

거대한 조회 테이블을 유지하거나 수동 설정을 요구하는 대신, MX 레코드는 각 도메인이 "내 메일은 여기로 보내세요"라고 선언할 수 있게 합니다. 우선순위 시스템이 장애 전환과 부하 분산을 제공합니다. 발신 서버가 논리를 처리합니다. 별도의 사전 조율이 필요 없습니다.

도메인의 MX 레코드는 여러분에게 연락하는 방법에 대한 공개 선언입니다. 전 세계 모든 메일 서버가 이를 찾아보고, 신뢰하고, 그에 따라 행동할 수 있습니다.

MX 레코드에 관한 자주 묻는 질문

MX 레코드 없이도 이메일을 사용할 수 있나요?

기술적으로는 가능합니다. MX 레코드가 없으면 일부 메일 서버가 도메인의 A 레코드로 대체하여 거기에 전달을 시도합니다. 하지만 이는 신뢰하기 어렵습니다—많은 서버가 이를 시도하지 않고, 장애 전환 기능도 모두 잃게 됩니다. 항상 MX 레코드를 명시적으로 설정하세요.

MX 레코드 변경이 전파되는 데 얼마나 걸리나요?

기존 레코드의 TTL(유효 시간, time-to-live)에 따라 다릅니다. MX 레코드의 TTL이 3600초(1시간)라면, 이전 레코드를 캐시한 서버는 최대 1시간 동안 그것을 사용합니다. 이전 작업 전에 미리 TTL을 낮춰두세요.

어떤 우선순위 값을 사용해야 하나요?

실제 숫자 자체는 중요하지 않습니다—상대적인 크기만 중요합니다. 우선순위 10/20은 1/2이나 100/200과 똑같이 작동합니다. 관례적으로 나중에 중간 우선순위를 삽입할 여지를 남기기 위해 10의 배수(10, 20, 30)를 사용합니다.

MX 레코드는 왜 IP 주소가 아닌 호스트명을 가리키나요?

유연성과 프로토콜 준수 때문입니다. 호스트명은 IPv4와 IPv6 주소 모두로 확인될 수 있고, MX 레코드를 수정하지 않아도 업데이트가 가능하며, DNS 캐싱이 효율적으로 작동하도록 합니다. RFC 5321은 호스트명을 요구하며, 많은 메일 서버가 이를 강제합니다.

출처