MX 레코드

3. MX 레코드 작동 방식

이메일이 인터넷을 통해 전송될 때, 발신 메일 전송 에이전트(MTA)는 각 수신자의 도메인 이름에 대한 MX 레코드를 도메인 네임 시스템에 질의한다.^[3] 이 쿼리는 해당 도메인에 대한 수신 메일을 수락하는 메일 교환 서버의 호스트 이름 목록과 해당 서버의 우선순위를 반환한다. 발신 에이전트는 "우선순위" 값이 가장 낮은 호스트부터 SMTP 연결을 시도한다.^[3] RFC 5321에 따르면, 번호가 가장 낮은 레코드가 가장 우선적으로 사용된다.^[4]

가장 단순한 경우, 도메인은 하나의 메일 서버만 가질 수 있다. 예를 들어, MTA가 example.com의 MX 레코드를 조회하고 DNS 서버가 우선순위 번호 50과 함께 mail.example.com만을 응답한 경우, MTA는 나열된 서버로 메일 전송을 시도한다.

MX 쿼리에 대해 둘 이상의 서버가 반환되면, 가장 작은 우선순위 번호의 서버를 먼저 시도해야 한다. 동일한 우선순위 번호로 둘 이상의 MX 레코드가 있는 경우, 낮은 우선순위 항목으로 이동하기 전에 해당 레코드를 모두 시도해야 한다. SMTP 클라이언트는 배달 시도가 성공할 때까지 목록에 있는 각 관련 주소를 순서대로 시도(및 재시도)할 수 있어야 한다.^[8] 이러한 시스템을 사용하면 필요한 경우 하나의 도메인에 대해 고가용성 클러스터의 메일 게이트웨이를 구축할 수 있다.^[3]

MX 메커니즘은 대체 포트 번호에서 메일 서비스를 제공하는 기능이나, 각 메일 서버에 가중치 값을 할당하여 우선순위가 다른 메일 서버 집합에 메일 전달을 분산하는 기능은 제공하지 않는다.

4. MX 레코드와 부하 분산

MX 로드밸런싱도 참고하십시오.

여러 개의 MX 레코드에 동일한 우선순위 값을 설정하면, 여러 메일 서버 간에 부하 분산(로드 밸런싱)을 구현할 수 있다. 예를 들어, `example.com` 도메인에 대해 다음과 같이 두 개의 MX 레코드를 설정할 수 있다.

위의 경우, 우선순위 값이 모두 10으로 동일하므로 메일은 `onemail.example.com`과 `twomail.example.com` 두 서버에 균등하게 전송될 것으로 예상된다. 이는 일반적인 구성이다.^[1] 호스트 이름은 DNS에서 하나 이상의 주소 레코드(A 또는 AAAA)에 직접 매핑되어야 하며, CNAME 레코드를 가리키지 않아야 한다.^[2]

발신 메일 전송 에이전트(MTA)는 수신자의 도메인 이름에 대한 MX 레코드를 쿼리하여 해당 도메인에 대한 수신 메일을 수락하는 메일 교환 서버의 호스트 이름 목록과 우선순위를 받는다. "우선순위" 값이 가장 낮은 호스트부터 SMTP 연결을 시도한다.^[3]

수신 메일 부하를 여러 서버에 분산하는 표준적인 방법은 각 서버에 동일한 선호도 번호를 반환하는 것이다. 우선순위가 같은 서버로 메일을 보낼 서버를 결정할 때 보내는 측 SMTP는 여러 메일 교환기 간에 부하를 분산하기 위해 무작위로 선택해야 한다.^[9]

DNS 라운드 로빈 방식을 사용하여 여러 IP 주소를 가진 메일 서버에 대한 부하 분산을 수행할 수도 있다.^[3] 이 방법은 부하 분산 책임을 SMTP 발신자가 아닌 DNS에 둔다.

5. 백업 MX 레코드

MX 로드밸런싱도 참고하십시오.

일부 도메인은 여러 개의 MX 레코드를 가지며, 그중 하나는 "백업"으로 사용된다.^[1] 이 백업 MX 레코드는 더 높은 우선순위 번호를 갖기 때문에 일반적으로 이메일 전송 대상으로 선택되지 않는다.

그러나 낮은 번호의 호스트에서 오류가 발생한 경우 (아마도 어떤 종류의 중단으로 인해), 이메일 전송 서버는 "백업" 호스트로 메일을 전달한다. 아래 예시에서는 ''queue.example.com''이 해당한다.

백업 서버가 사용자 메일함에 직접 접근할 수 있다면, 메일은 해당 서버로 전송되지만, 그렇지 않은 경우 ''queue.example.com''에 대기될 가능성이 높으며, 중단이 해결될 때까지 유지된다.

이러한 종류의 구성이 없는 경우, 도메인의 메일 서버가 모두 오프라인 상태일 때, ''보내는'' 서버는 해당 도메인으로 전송될 메시지를 대기했다가 나중에 다시 시도해야 한다. 그러나 이러한 보내는 서버는 이전에 오프라인 상태였던 도메인 서버가 이제 사용 가능하다는 것을 알릴 방법이 없으므로 폴링 스케줄에 의존한다. 따라서 도메인이 사용 가능한지 여부는 다음에 전송을 시도할 때만 발견된다. 따라서 받는 도메인의 서버가 온라인 상태가 된 시점과 지연된 메시지가 최종적으로 전달되는 시점 사이의 지연 시간은 보내는 서버의 재시도 스케줄에 따라 몇 분에서 며칠까지 다양할 수 있으며, 받는 도메인은 이에 대한 가시성이나 제어 권한이 없다.

6. 스팸 대응과 MX 레코드

일부 스패머는 스팸 메일이 스팸 방지 필터가 덜 효과적일 것이라는 가정 하에, 의도적으로 메일을 도메인의 백업(높은 거리) MX 서버 중 하나로 먼저 보낼 수 있다. 미등록이라고 하는 스팸 방지 기술은 이러한 행동을 가정하여 만들어졌다.

7. 배달 실패 처리

SMTP RFC 5321에 따르면, MTA가 메일 전송 시 임시 오류(4xx)를 만나면 동일한 서버나 우선순위가 낮은 다른 MX 레코드로 재시도해야 한다. 그러나 어떤 배달 실패가 더 낮은 우선순위의 MX 레코드로 재시도해야 하는지는 명확하지 않다.^[4]

서버가 4xx 오류를 명시하거나 연결을 예기치 않게 종료하여 임시 실패를 알리면, 보낸 사람은 재시도를 늦춰야 한다.^[4]

Sendmail과 Postfix 2.1 이상 등 일부 메일 서버는 인사 실패와 같은 특정 임시 배달 실패 후, 다음 우선순위 MX 서버를 시도한다.^[10][11] 반면, qmail과 Postfix 2.0 이하 등은 최단 거리 MX 레코드 서버에 연결할 수 없을 때만 더 낮은 우선순위 MX 레코드를 사용한다. RFC에 명확한 규정이 없으므로 두 방식 모두 유효하다.

8. A 레코드로의 폴백

메일 전송 에이전트(MTA)는 특정 도메인에 대한 MX 레코드가 없는 경우, 해당 도메인의 A 레코드(또는 AAAA 레코드)를 사용하여 메일 서버의 IP 주소를 확인하고 메일 전송을 시도한다.^[1] 이는 RFC 5321 5.1절에 명시된 내용으로, MX 레코드가 없으면 해당 도메인을 대상 호스트 이름과 기본 설정 값 0을 가진 MX 레코드가 있는 것처럼 처리하고, A 또는 AAAA 조회를 통해 IP 주소를 결정하는 방식이다.

8. 1. 역사적 배경

9. 표준 문서

참조

_[1] 문서
_[2] 간행물 Clarifications to the DNS Specification 1997-07
_[3] 웹사이트 HOWTO - Configure Round Robin and Load Balancing http://zytrax.com/bo[...] zytrax.com 2014-02-28
_[4] 간행물
_[5] 간행물
_[6] 간행물
_[7] 간행물
_[8] 간행물
_[9] 간행물
_[10] 웹인용 If the primary MX responds, but fails mid-transaction, Postfix 1.2 and 2.0 will not try a backup MX. http://archives.neoh[...] 2009-06-23
_[11] 문서
_[12] 간행물 MAIL ROUTING AND THE DOMAIN SYSTEM IETF 2011-11-18
_[13] 웹인용 ietf-smtp message http://www.imc.org/i[...] 2008-06-01