MX 레코드 조회
도메인의 MX 레코드를 조회하면, 그 도메인의 메일을 받는 메일 서버를 발신 서버가 시도하는 순서대로 확인할 수 있습니다.
도메인의 MX 레코드를 확인하는 방법
- 위 입력란에 도메인을 입력합니다. 전체 이메일 주소나 웹사이트 링크를 입력해도 됩니다. 도구는 도메인 부분만 사용합니다.
- “MX 레코드 조회”를 클릭합니다. 공개 DNS에서 레코드를 읽기 때문에, 지금 발신 서버가 보는 것과 같은 내용이 표시됩니다.
- 먼저 요약을 읽습니다. 요약을 보면 도메인이 이메일을 받을 수 있는지 알 수 있습니다.
- 그다음 표를 읽습니다. 한 행이 메일 서버 하나이며, 우선순위 숫자, IP 주소, TTL이 표시됩니다.
최근에 레코드를 변경했는데 이전 내용이 계속 보인다면, 표에 표시된 TTL이 끝날 때까지 기다리십시오. TTL은 리졸버가 이전 응답을 보관할 수 있는 시간(초)입니다. 주소창의 링크를 열면 같은 MX 레코드 확인을 다시 실행합니다. 이 링크를 동료나 DNS 호스팅 업체에 보낼 수도 있습니다.
MX 레코드란
MX 레코드(mail exchanger record)는 도메인으로 온 이메일을 어디로 전달할지 다른 메일 서버에 알려 주는 DNS 항목입니다. 누군가 anna@example.com으로 메일을 보내면, 발신자의 메일 서버는 example.com의 MX 레코드를 조회하고 거기에 적힌 서버에 연결합니다. 이 레코드를 읽는 것이 MX 레코드 조회, 즉 메일 서버 조회입니다. 단계별 예시가 포함된 쉬운 설명은 용어집의 MX 레코드 항목을 참고하십시오.
각 레코드는 우선순위 숫자와 메일 서버 이름, 두 부분으로 이루어집니다. Google Workspace 설정 가이드는 다음과 같은 레코드 하나를 추가하도록 안내합니다.
example.com. 3600 IN MX 1 smtp.google.com.
오래된 Workspace 도메인에는 ASPMX.L.GOOGLE.COM으로 시작하는 레코드 5개가 아직 남아 있는 경우가 많습니다. Google은 이 설정도 계속 지원하므로 바꿀 필요가 없습니다.
MX 레코드는 받는 메일만 처리합니다. 보내는 메일은 다른 레코드, 주로 SPF, DKIM, DMARC가 담당합니다. 이 세 가지가 작동하는 방식은 SPF, DKIM, DMARC 설명을 참고하십시오.
우선순위 숫자의 의미
발신 서버는 숫자가 가장 작은 서버를 먼저 시도합니다. 응답이 없으면 그다음으로 작은 숫자의 서버로 넘어갑니다. 두 서버의 숫자가 같으면 발신 서버가 둘 중 하나를 무작위로 고르므로 부하가 분산됩니다(RFC 5321, 5.1절).
중요한 것은 순서뿐이며, 숫자의 크기는 상관없습니다. 우선순위 10과 20은 1과 2와 똑같이 작동합니다. 예를 들어 Gmail 자체 도메인은 우선순위가 5, 10, 20, 30, 40인 서버 5개를 등록해 두었습니다.
MX 레코드 조회 결과의 의미
| 결과 | 의미 | 조치 |
|---|---|---|
| 이메일을 받을 수 있음 | 도메인에 MX 레코드가 있고, 모든 메일 서버에 IP 주소가 있습니다. | 조치할 것이 없습니다. 그래도 메일이 도착하지 않으면 메일 서버 자체나 스팸 필터를 확인하십시오. |
| MX 레코드는 있지만 수정할 문제가 있음 | 레코드 하나 이상에 문제가 있습니다. 도구는 그 문제를 해당 서버 아래에 표시합니다. | DNS 호스팅 업체에서 레코드를 수정하십시오. 자주 발생하는 문제는 이 표 아래에서 설명합니다. |
| MX 레코드가 없음 | 발신 서버는 도메인 자체의 주소(A 레코드 또는 AAAA 레코드)로 대신 전달을 시도합니다. | 도메인으로 이메일을 받아야 한다면 MX 레코드를 추가하십시오. 입력할 값은 이메일 서비스에서 알려 줍니다. |
| 이메일을 받을 수 없음 | MX 레코드가 없고, 대신 사용할 주소도 없습니다. | MX 레코드를 추가하십시오. 이메일에 쓰지 않는 도메인이라면 그대로 두어도 됩니다. |
| 이메일을 전혀 받지 않음 | 도메인이 Null MX 레코드(0 .)를 게시하고 있습니다. 이 레코드는 발신 서버에 전달을 시도하지 말라고 알립니다(RFC 7505). | 이메일에 쓰지 않는 도메인이라면 조치할 것이 없습니다. 메일을 보내는 도메인에는 이 레코드를 두지 마십시오. 답장과 반송 메일이 돌아올 수 없기 때문입니다. |
| 존재하지 않음 | DNS에 이 도메인의 기록이 전혀 없습니다. | 철자를 확인하고, 도메인이 등록되어 있는지도 확인하십시오. |
도구는 개별 레코드의 문제 4가지도 표시합니다. 첫째, 레코드가 호스트 이름 대신 IP 주소를 가리키는 경우입니다. 둘째, 서버 이름이 별칭(CNAME)인 경우로, RFC 2181에서 허용하지 않습니다. 셋째, 서버 이름에 IP 주소가 없어 그 서버로 보낸 메일을 전달할 수 없는 경우입니다. 넷째, 도메인이 일반 MX 레코드와 함께 Null MX를 게시해 설정이 서로 모순되는 경우입니다.
Google Workspace, Microsoft 365 등 이메일 서비스별 MX 레코드
MX 레코드 조회에서 아래 서버 이름 중 하나가 보이면, 그 도메인의 이메일을 어느 서비스가 처리하는지 알 수 있습니다. 각 이름 앞의 숫자는 우선순위입니다. 이메일 서비스를 설정할 때는 해당 서비스의 설정 페이지에서 값을 복사하십시오. 일부 값은 도메인이나 지역에 따라 다릅니다.
| 이메일 서비스 | MX 레코드 |
|---|---|
Google Workspace 오래된 설정은 ASPMX.L.GOOGLE.COM과 ALT 서버 4개를 사용합니다. Google은 이 설정도 계속 지원합니다. | 1 smtp.google.com |
Microsoft 365 앞부분은 도메인마다 다릅니다. DNSSEC을 사용하는 도메인은 mx.microsoft로 끝나는 이름을 받습니다. 정확한 값은 관리 센터에서 복사하십시오. | yourdomain-com.mail.protection.outlook.com |
Zoho Mail 끝부분은 데이터 센터에 따라 다릅니다. 예를 들어 EU는 mx.zoho.eu입니다. | 10 mx.zoho.com 20 mx2.zoho.com 50 mx3.zoho.com |
Proton Mail | 10 mail.protonmail.ch 20 mailsec.protonmail.ch |
Fastmail | 10 in1-smtp.messagingengine.com 20 in2-smtp.messagingengine.com |
iCloud Mail iCloud+의 사용자 지정 도메인용입니다. | 10 mx01.mail.icloud.com 10 mx02.mail.icloud.com |
Namecheap Private Email | 10 mx1.privateemail.com 10 mx2.privateemail.com |
Cloudflare Email Routing 메일을 다른 받은편지함으로 전달합니다. 우선순위는 Cloudflare가 설정합니다. | route1.mx.cloudflare.net route2.mx.cloudflare.net route3.mx.cloudflare.net |
Amazon SES 메일 수신용입니다. 가운데 부분은 AWS 리전입니다. | 10 inbound-smtp.us-east-1.amazonaws.com |
Hostinger | 5 mx1.hostinger.com 10 mx2.hostinger.com |
IONOS 일부 국가는 mx00.ionos.de처럼 자체 끝부분을 사용합니다. | mx00.ionos.com mx01.ionos.com |
OVHcloud | 1 mx0.mail.ovh.net 5 mx1.mail.ovh.net 50 mx2.mail.ovh.net 100 mx3.mail.ovh.net 200 mx4.mail.ovh.net |
Yandex 360 | 10 mx.yandex.net |
MX 레코드가 Proofpoint, Mimecast, Barracuda를 가리키는 경우도 있습니다. 이들은 보안 게이트웨이입니다. 메일은 먼저 게이트웨이를 거쳐 필터링된 뒤 실제 메일함 서비스로 이동하며, 조회로는 그 서비스를 볼 수 없습니다. 게이트웨이는 모든 주소에 응답하기 때문에 이메일 검증도 어려워집니다. 보안 이메일 게이트웨이 뒤의 이메일을 검증하는 방법을 참고하십시오.
MX 레코드 변경하기
이메일을 새 서비스로 옮기려면 DNS 호스팅 업체에서 새 서비스의 MX 레코드를 추가하고 이전 레코드를 삭제합니다. 발신 서버는 DNS가 돌려주는 내용을 따르므로, 캐시된 응답이 만료되는 대로 메일이 새 서버에 도착하기 시작합니다.
걸리는 시간은 이전 레코드의 TTL에 따라 다릅니다. 이전을 계획한다면 미리 TTL을 몇 분으로 낮추십시오. 전환하는 날까지 이전의 긴 TTL이 끝나도록, 적어도 TTL 한 주기 전에 낮추어야 합니다. 모든 것이 정상적으로 작동하면 TTL을 다시 올리십시오. 그래도 일부 메일이 이전 메일함에 도착할 수 있으므로 이전 메일함은 며칠 동안 유지하십시오.
이메일 서비스는 변경이 반영되는 데 최대 48시간 또는 72시간이 걸린다고 안내하는 경우가 많습니다. 이는 안전하게 잡은 최대치이며, 일반적인 대기 시간이 아닙니다. MX 레코드가 없던 도메인에 MX 레코드를 추가하면 조금 더 오래 걸릴 수 있습니다. 리졸버가 “레코드 없음”이라는 응답도 캐시했을 수 있기 때문입니다. 그 응답을 보관하는 기간은 도메인의 SOA 레코드가 정합니다.
전환한 뒤에는 새 서비스가 대신 메일을 보낼 수 있도록 SPF 레코드를 업데이트하고, 그 서비스의 DKIM 서명을 켜십시오. 자체 서버에서 메일을 보낸다면 DKIM 생성기로 키를 만들고, DMARC 생성기로 두 가지를 하나로 묶는 DMARC 레코드를 만들 수 있습니다.
MX 레코드 조회로는 메일함을 확인할 수 없습니다
MX 레코드는 도메인이 메일을 받는다는 사실만 알려 줍니다. 특정 주소가 실제로 있는지는 알려 주지 않습니다. example.com의 MX 레코드에 문제가 없어도 jane@example.com으로 보낸 메일은 반송될 수 있습니다. Jane이 퇴사했거나 그 주소가 처음부터 없었을 수 있기 때문입니다.
메일함을 확인하려면 메일 서버에 직접 물어봐야 하며, 이것이 이메일 검증 도구가 하는 일입니다. 주소 하나는 이메일 유효성 검사로, 캠페인 전에 리스트 전체는 대량 이메일 검증으로 확인하십시오.
자주 묻는 질문
도메인의 메일 서버를 지정하는 DNS 레코드입니다. 누군가 그 도메인의 주소로 이메일을 보내면, 발신자의 메일 서버가 MX 레코드를 조회합니다. 이 레코드를 보고 메시지를 어디로 전달할지 정합니다.
이 페이지 위쪽의 MX 레코드 조회 도구에 도메인을 입력하십시오. 터미널에서는 Windows의 경우 nslookup -type=mx example.com, macOS와 Linux의 경우 dig mx example.com으로 확인할 수 있습니다.
네, 대부분의 도메인이 여러 개를 둡니다. 발신 서버는 우선순위 숫자가 가장 작은 레코드를 먼저 시도하고, 나머지는 예비로 둡니다. 숫자가 같은 레코드는 부하를 나눠서 처리합니다.
발신 서버는 도메인 자체의 A 레코드 또는 AAAA 레코드로 대신 전달을 시도합니다. 이 방식은 그 주소에서 메일 서버가 실행 중일 때만 작동합니다. 따라서 이메일을 받아야 하는 도메인에는 MX 레코드가 필요합니다.
아니요. 자체 A 레코드 또는 AAAA 레코드가 있는 호스트 이름을 지정해야 합니다. 레코드에 IP 주소를 넣으면 표준에 어긋나며, RFC 2181은 이 이름이 별칭이어서는 안 된다고 정합니다. 별칭을 처리하는 발신 서버도 있지만, 모든 발신 서버가 그렇게 처리한다고 기대할 수는 없습니다.
도메인의 DNS를 운영하는 곳입니다. 보통 도메인을 구매한 등록 대행업체이며, 네임서버를 Cloudflare 같은 서비스로 옮겼다면 그 서비스입니다. 모든 발신 서버가 읽어야 하므로 레코드 자체는 공개되어 있습니다.
최대 이전 레코드의 TTL만큼 걸립니다. 이전 레코드를 캐시한 리졸버는 TTL이 끝날 때까지 이전 응답을 사용합니다. 따라서 TTL이 3600이면 최대 1시간입니다. DNS 호스팅 업체가 변경을 게시하는 데 몇 분이 더 걸릴 수도 있습니다.
아니요. MX 레코드는 메일을 받기 위한 것입니다. 보내는 메일은 SPF, DKIM, DMARC에 달려 있습니다. 다만 일부 수신 서버는 MX 레코드도 A 레코드도 전혀 없는 도메인에서 온 메일을 거부합니다. 그런 도메인은 답장을 받을 수 없습니다.
도메인만이 아니라 메일함까지 확인하십시오
무료 크레딧 1,000개를 드립니다. 신용카드는 필요 없습니다.