이메일이 메일 서버를 찾는 과정
발신자
you@gmail.com
MX 조회
메일을 받는 곳은?
메일 서버
우선순위 10 먼저
받은편지함
전달됨
우선순위 값이 낮을수록 먼저 사용되고, 높은 값은 백업입니다
MX 레코드란? 이메일 라우팅 설명
누군가 you@example.com으로 메시지를 보내면 상대의 메일 서버는 무엇보다 먼저 한 가지 질문에 답해야 합니다. example.com의 메일을 받는 컴퓨터는 어디인가? 그 답이 MX 레코드입니다.
MX는 Mail Exchange의 약자입니다. MX 레코드가 없으면 웹사이트가 완벽하게 동작하더라도 도메인으로 가는 메일은 반송됩니다. 웹사이트 레코드와 메일 레코드는 완전히 별개입니다.
이메일이 메일 서버를 찾는 과정
발신자
you@gmail.com
MX 조회
메일을 받는 곳은?
메일 서버
우선순위 10 먼저
받은편지함
전달됨
우선순위 값이 낮을수록 먼저 사용되고, 높은 값은 백업입니다
MX 레코드의 모양
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.호스트 이름 앞의 숫자가 우선순위(preference라고도 합니다)입니다. 나머지는 모두 표준적인 레코드 구성입니다.
우선순위가 실제로 동작하는 방식
발신 서버는 MX 레코드를 우선순위별로 정렬해 순서대로 시도합니다. 가장 낮은 우선순위의 호스트가 연결을 거부하거나 시간 초과되면 다음으로 넘어갑니다. 이것이 진정한 이중화입니다. 한 서버가 중단된 동안에도 메일이 계속 흐릅니다.
우선순위가 같은 레코드, 즉 위의 두 5 항목은 부하 분산됩니다. 발신자는 둘 중 하나를 무작위로 골라 양쪽에 발송량을 분산합니다.
MX 대상이 따라야 하는 규칙
- 대상은 IP 주소가 아니라 호스트 이름이어야 합니다.
MX 10 93.184.216.34는 유효하지 않습니다.MX 10 mail.example.com.을 쓰고 그 이름에A레코드를 두세요. - 대상은 CNAME이면 안 됩니다. 사양은 MX 대상이 주소 레코드로 직접 확인되도록 요구합니다. 그렇지 않으면 일부 메일 서버가 전달을 거부합니다. CNAME과 A 레코드를 참고하세요.
- 대상에는 자체
A또는AAAA레코드가 있어야 합니다. 확인되지 않는 이름을 가리키는 MX는 MX가 전혀 없는 것과 같습니다.
Null MX: 도메인이 메일을 받지 않음을 선언하기
도메인이 이메일을 절대 받지 않을 것이라면, 루트 존을 가리키는 MX 레코드 하나로 이를 명시적으로 밝히세요.
example.com. 3600 IN MX 0 .대상이 . 하나뿐이라면 이 도메인은 메일을 받지 않는다는 뜻입니다. 발신자는 며칠 동안 재시도하는 대신 영구 오류로 즉시 거부하며, 이는 해당 도메인을 스푸핑 대상으로 덜 매력적으로 만들어 줍니다. 이메일에 쓰지 않는 소유한 모든 도메인에 설정해 둘 만합니다.
MX 레코드가 없으면 어떻게 될까요
역사적으로 대체 동작은 발신자가 도메인의 A 레코드를 시도해 그곳으로 전달을 시도하는 것입니다. 이에 의존하는 것은 좋지 않습니다. 메일 서버마다 동작이 다르고, A 레코드가 메일 데몬이 없는 웹 서버나 CDN을 가리키면 메시지가 반송되기 때문입니다.
핵심 요약
메일을 받으려면 명시적인 MX를 게시하세요. 받지 않으려면 null MX를 게시하세요. 비워 두고 A 레코드 대체 동작이 되기를 바라는 것이 도메인이 메시지를 조용히 잃는 방식입니다.
MX 레코드가 전부는 아닙니다
MX는 메일이 어디로 전달될지를 정합니다. 다른 세 레코드는 메일이 신뢰받는지를 정하며, 이들이 없으면 정상 메일이 스팸함에 들어갑니다.
- SPF — 어떤 서버가 내 도메인으로 발송할 수 있는지 나열하는
TXT레코드입니다. - DKIM — 발신 메일에 서명하는 키를 공개하는
TXT레코드입니다. - DMARC — SPF나 DKIM이 실패했을 때 수신 측이 어떻게 처리할지 알려 주는
TXT레코드입니다.
세 가지 모두 SPF, DKIM, DMARC 설명에서 다룹니다. 네 번째 요소인 역방향 DNS는 메일을 직접 발송하는 서버에서 중요합니다.
메일을 잃게 만드는 장애와 찾아내는 방법
MX 설정 오류는 좀처럼 스스로를 드러내지 않습니다. 메일이 멈추는 것이 아니라 줄어들거나, 늦게 도착하거나, 다른 모든 사람은 괜찮은데 한 발신자만 불평합니다. 알아 둘 만한 패턴은 다음과 같습니다.
더 이상 쓰지 않는 제공업체를 가리키는 레코드
원인을 알 수 없는 메일 누락의 가장 흔한 원인입니다. 마이그레이션 후 이전 제공업체의 MX 레코드가 새 레코드와 함께 남아 있으면 발신자가 우선순위에 따라 둘 사이에 분산해 발송하고, 일부 메시지가 아무도 읽지 않는 사서함에 도착합니다. 증상은 일부 발신자의 메일은 도착하고 다른 발신자의 메일은 반송 메일도 없이 사라진다는 것입니다.
MX 대상에 주소 레코드가 없음
mail.example.com이 확인되지 않는데 MX가 이를 가리키면 기능적으로 MX가 전혀 없는 것과 같습니다. 발신자는 즉시 반송하거나, 포기하기 전까지 며칠 동안 대기열에 두고 재시도합니다. MX 레코드가 존재하는지만이 아니라 대상이 확인되는지 항상 검증하세요.
25번 포트를 막는 방화벽
DNS는 완벽한데 서버에 접근할 수 없는 경우입니다. 수신 SMTP는 25번 포트로 들어오며, 클라우드 제공업체는 새 인스턴스에서 기본적으로 이를 막는 경우가 많습니다. MX 조회는 성공하지만 연결이 끝내 완료되지 않아 발신자는 조용히 대기열에 쌓아 둡니다.
MX 레코드 확인하기
dig +short example.com MX조회 도구는 MX 레코드를 이미 우선순위순으로 정렬해 반환하며, null MX는 혼란스러운 빈 값이 아니라 명시적으로 표시합니다. 덕분에 기본 서버가 내가 예상한 서버인지 한눈에 확인할 수 있습니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
이 주제의 무료 도구
자주 묻는 질문
관련 글
거의 모든 존에서 만나게 되는 레코드
TXT 레코드 설명: SPF, DKIM, DMARC
세 개의 TXT 레코드가 내 이메일과 스팸함 사이를 가로막고 있습니다. 각각의 역할, 구문 읽는 법, 안전한 적용 순서를 설명합니다.
역방향 DNS는 조회를 거꾸로 수행합니다
IP 주소
93.184.216.34
출발점
PTR 조회
in-addr.arpa, 내 존이 아닌 상대의 존
호스트 이름
응답
역방향 존은 도메인 소유자가 아니라 IP 블록 소유자에게 속합니다
역방향 DNS란? PTR 레코드 설명
거꾸로 진행되는 조회입니다. 호스팅 제공업체가 이를 관리하는 이유와, 이것이 없으면 이메일이 조용히 스팸함으로 가는 이유를 설명합니다.
거의 모든 존에서 만나게 되는 레코드
DNS 레코드 유형 총정리: 완전한 레퍼런스
알아 둘 가치가 있는 모든 레코드 유형의 역할, 모양, 그리고 흔히 저지르는 실수를 한 페이지에 정리했습니다.