Show HN 도메인 8,062개 중 223개는 Resend를 쓰지만 MX가 없다

Show HN에 올라온 도메인 8,062개를 조사한 결과, 223개는 Resend를 사용하면서 MX 레코드가 없는 것으로 나타났다. MX 레코드 확인 도구는 도메인이 메일을 받을 수 있는지, 설정에 문제가 있는지 공개 DNS를 조회해 보여준다.

MX(메일 교환기) 레코드는 메일을 받을 서버의 호스트 이름과 우선순위를 지정한다. 발신 서버는 우선순위 숫자가 낮은 호스트부터 시도한다. 조회는 호스트 이름별로 이뤄지므로 updates.yourdomain.com은 별도의 MX 레코드로 메일을 받으면서 yourdomain.com은 Google Workspace를 계속 사용할 수 있다. 하위 도메인 이메일 설정 안내에서 실제 도메인에 설정하는 방법을 확인할 수 있다.

MX 레코드가 전혀 없는 호스트 이름이 메일을 단순히 거부하는 것은 아니다. RFC 5321 5.1절에 따라 발신 서버는 해당 호스트의 A 레코드를 대신 조회한다. 이 주소는 대개 메일 서버가 아니라 웹 서버를 가리킨다.

결과와 확인 방법

도구는 각 도메인에 상태를 표시한다. MX 호스트가 있고 확인 대상이 모두 주소로 연결되면 ‘메일 수신’으로 표시한다. 메일은 받을 수 있지만 확인이 필요한 문제가 있으면 경고를 붙인다. 예를 들어 백업 호스트가 더는 연결되지 않거나, MX가 별칭(CNAME)을 가리키거나, 서로 다른 제공자의 호스트가 함께 등록된 경우다.

MX가 없는데 A 레코드는 있는 경우, MX가 IP 주소를 가리키는 경우, 연결되는 MX 호스트가 하나도 없는 경우, 다른 MX와 함께 null MX가 있는 경우, 또는 도메인이 DNS에 존재하지 않는 경우에는 메일을 받을 수 없는 상태로 표시한다. MX와 주소가 모두 없는 도메인은 메일을 받지 않는다면 문제가 없을 수 있어 경고 상태로 분류한다. null MX만 설정해 메일을 받지 않는다고 명시한 도메인은 정상으로 표시한다. DNS 응답이 제때 오지 않으면 확인 실패로 표시되며, 1분 뒤 다시 시도할 수 있다.

상태 옆에는 호스트 이름으로 제공자를 판별할 수 있을 때 제공자 이름을 표시하고, 그렇지 않으면 호스트 자체를 보여준다. 도메인을 열면 우선순위별 MX 목록과 캐시된 TTL, 각 호스트가 IPv4와 IPv6 주소로 연결되는지 확인할 수 있다. TTL은 DNS 조회기가 레코드를 캐시에 보관하는 시간으로, 변경 내용이 전파되는 데 걸리는 시간과 관련이 있다. ‘TTL(캐시됨)’에는 공개 DNS 조회기의 캐시에 남은 시간이 표시되므로 설정한 TTL보다 짧을 수 있다. 각 조회는 공개 DNS를 실시간으로 확인한다.

제공자별 설정 확인

제공자 표시가 맞지 않는 것 같다면 해당 서비스가 요구하는 레코드와 비교해야 한다. Google Workspace는 smtp.google.com 하나를 사용한다. 2023년 이전 설정은 기존 aspmx.l.google.com 레코드 집합을 사용할 수 있으며, 이 설정도 계속 작동한다. 개인 Gmail 주소는 구글의 gmail-smtp-in.l.google.com 호스트를 이용하며 도구에서는 Gmail로 표시한다. 구글의 MX 설정 안내에서 설정을 확인할 수 있다.

Microsoft 365는 <MX token>.mail.protection.outlook.com을 사용하거나, 2026년 7월 이후 추가한 도메인에서는 contoso-com.l-v1.mx.microsoft처럼 .mx.microsoft로 끝나는 호스트를 사용할 수 있다. 우선순위는 다른 모든 MX보다 낮은 숫자로 설정한다. 토큰은 관리 센터에서 확인하며, 자세한 내용은 Microsoft 365 외부 DNS 레코드 안내에 나와 있다.

Zoho Mail의 미국 데이터 센터는 mx.zoho.com, mx2.zoho.com, mx3.zoho.com을 우선순위 10, 20, 50으로 사용한다. 다른 데이터 센터는 호스트가 다르므로 Zoho 관리 콘솔에 표시된 값을 따라야 한다. Zoho의 설정 안내에서 확인할 수 있다.

Cloudflare Email Routing은 route1.mx.cloudflare.net, route2.mx.cloudflare.net, route3.mx.cloudflare.net을 사용하며 우선순위는 Cloudflare가 지정한다. 대시보드에 표시된 값을 사용해야 한다. 자세한 내용은 Cloudflare Email Routing DNS 설정 안내를 참고하면 된다.

메일을 받을 수 없는 흔한 원인

MX가 없으면 발신 서버가 A 레코드로 대체 조회한다. 도메인이 메일을 전혀 받지 않는다면 RFC 7505에 정의된 단일 null MX 레코드 0 .을 게시할 수 있다. 이렇게 하면 발신 서버에 메일을 받지 않는다고 명시한다.

이전 제공자의 MX 호스트가 더는 연결되지 않거나 호스트 이름에 오타가 있으면 발신 서버는 해당 호스트를 건너뛰고 다음 호스트를 시도한다. 연결되는 호스트가 남지 않으면 메일은 반송된다. 도메인 주차에 사용한 null MX가 남아 있는 것도 문제다. null MX는 다른 MX 레코드와 함께 둘 수 없으므로, 실제 수신 호스트와 같이 설정하면 발신 서버가 메일을 거부할 수 있다.

같은 호스트 이름에 CNAME이 있으면 그 이름에 MX 레코드를 함께 둘 수 없다. 하위 도메인에 남은 CNAME이 새 MX 설정을 막을 수 있다. MX는 별칭이나 IP 주소가 아니라 자체 주소를 가진 호스트를 가리켜야 한다. RFC 2181 10.3절은 이 조건을 설명한다. 일부 발신 서버는 별칭을 처리하지만 그렇지 않은 서버도 있으며, IP 주소는 유효한 MX 값이 아니다. 이런 도메인에서 보낸 메일에 대한 답장은 반송될 수 있어 영수증에 답장한 고객의 메일을 받지 못할 수 있다. 맞춤 도메인으로 답장받는 방법에서 설정을 다룬다.

MX 변경 시 주의할 점

변경 하루 전 TTL을 300초 정도로 낮추면 새 설정이 몇 시간이 아니라 몇 분 안에 조회기에 반영될 수 있다. 새 MX를 먼저 추가하고, 새 호스트가 조회되며 주소로 연결되는 것을 확인한 뒤 기존 레코드를 제거한다. 같은 호스트 이름에 두 제공자의 레코드를 오래 섞어 두면 우선순위와 장애 시 대체 동작에 따라 메일이 예측하기 어렵게 나뉘어 전달될 수 있다.

이미 Gmail이나 Outlook으로 메일을 받는 도메인의 MX는 그대로 두고 싶다면 루트 도메인 대신 updates.yourdomain.com 같은 하위 도메인에 새 수신 설정을 둘 수 있다. 새 MX가 제공하는 기능도 확인해야 한다. 예를 들어 Cloudflare Email Routing은 메일을 수신해 전달만 한다. 도메인에서 답장을 보내려면 별도의 발신 서비스가 필요하다.

MX는 메일 수신 설정이다. 발신 설정은 DMARC 검사 도구에서 DMARC와 SPF를 확인할 수 있다. 여러 도메인의 이메일 호스팅을 선택할 때는 이메일 호스팅 비교 안내를 참고할 수 있다.

도구 페이지에서 도메인을 입력하고 ‘Check MX records’를 누르면 확인할 수 있다. 터미널에서는 macOS나 Linux에서 dig MX yourdomain.com, Windows에서 nslookup -type=mx yourdomain.com을 실행하면 된다. 한 번에 도메인이나 하위 도메인을 최대 10개까지 계정 없이 검사할 수 있다.

조회는 공개 DNS를 실시간으로 확인하며, Cloudflare 조회기를 사용하고 응답이 없으면 Google 조회기를 대체로 이용한다. 검사한 도메인은 저장하거나 기록하지 않는다. 분석 데이터에는 검사한 도메인 수만 집계하고 어떤 도메인을 확인했는지는 포함하지 않는다. 결과 공유 링크에서 도메인은 # 뒤에 포함되므로 브라우저가 서버로 전송하지 않는다.