인기 도구

테마

MX 조회 — 메일 서버 레코드 확인

MX 레코드 조회로 모든 도메인의 MX 레코드를 확인하세요: 전달 순서대로 정렬된 메일 서버, 운영 주체, IPv4·IPv6 주소, STARTTLS 응답 여부까지 보여 줍니다. 도메인 자체 네임서버에서 직접 가져와 Google과 Cloudflare의 캐시된 사본과 나란히 표시합니다.

출처: 루트 서버에서 찾아간 도메인의 네임서버 · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · 뭄바이에 있는 저희 서버에서 메일 서버 테스트

입력한 이름을 그대로 조회합니다: www.나 서브도메인도 다른 이름으로 바꾸지 않습니다.

예시

MX 레코드란?

MX(mail exchange, 메일 교환) 레코드는 도메인의 이메일을 받는 서버를 지정하며, 각 서버에는 우선순위 숫자가 붙습니다: 발신 측은 가장 낮은 숫자부터 시도합니다.

누군가 name@airbnb.com으로 메일을 보내면, 그 사람의 메일 서버가 DNS에 airbnb.com의 MX 레코드를 묻고, 숫자가 가장 낮은 서버를 골라 포트 25에서 SMTP로 전달합니다. 레코드에는 IP 주소가 아닌 호스트 이름이 들어가며, 그 이름에는 자체 A 또는 AAAA 레코드가 있어야 합니다: 별칭(CNAME, RFC 2181 §10.3)이어서는 안 됩니다.

MX 레코드 조회는 이 레코드를 읽고 각 서버를 주소, 네트워크, 그 뒤의 제공업체까지 따라갑니다. MX는 들어오는 메일의 방향만 정합니다: 누가 이 도메인으로 메일을 보낼 수 있는지는 SPF, DKIM, DMARC가 정합니다.

MX 레코드의 구조airbnb.com 자체 네임서버에서
airbnb.com.이름300TTLIN클래스MX유형1우선순위aspmx.l.google.com.메일 서버(exchange)
이름 · TTL메일을 받는 도메인과, 캐시가 이 응답을 보관할 수 있는 시간: 300초 = 5분.
우선순위낮을수록 먼저 시도합니다. airbnb.com은 1, 5, 5, 10, 10입니다.
메일 서버자체 A 및 AAAA 레코드가 있는 호스트 이름: 192.178.211.27, 2404:6800:4000:1025::1b.
1 aspmx.l.google.com.A 및 AAAA 레코드가 있는 호스트 이름
1 192.0.2.25IP 주소는 유효한 exchange가 아님
1 mail → CNAMEexchange는 별칭일 수 없음(RFC 2181 §10.3)
airbnb.com 자체 네임서버가 제공하는 그대로의 모든 필드입니다. 이 도구는 IP 주소, CNAME, 주소가 없는 이름을 가리키는 MX를 표시해 알려 줍니다.

MX 레코드 확인 방법

위에 도메인을 입력하고 MX 조회를 누르거나, 터미널에서 DNS에 질의하세요: macOS와 Linux에서는 dig example.com MX, 모든 시스템에서 nslookup -type=mx example.com, Windows PowerShell에서는 Resolve-DnsName example.com -Type MX입니다.

응답의 각 줄이 서버 하나이며, 우선순위 다음에 호스트 이름이 옵니다. IN 앞의 숫자는 TTL로, 리졸버가 이 사본을 계속 제공할 수 있는 초 단위 시간입니다. @ 기호와 네임서버를 추가하면(dig @dns1.p08.nsone.net airbnb.com MX) 캐시 대신 존 자체의 응답을 읽을 수 있습니다.

dig example.com MX +short

각 줄은 우선순위, 메일 서버 순입니다. 캐시를 건너뛰려면 @와 네임서버를 추가하세요.

dig 응답 읽는 법2026-10-23 기록
bash · zsh
$ dig airbnb.com MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR1
;; flags: qr rd ra; QUERY: 1, ANSWER: 5

;; ANSWER SECTION:
airbnb.com.    3002  IN  MX   13 aspmx.l.google.com.4
airbnb.com.    300   IN  MX   5 alt1.aspmx.l.google.com.
airbnb.com.    300   IN  MX   5 alt2.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt3.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt4.aspmx.l.google.com.

;; SERVER: 8.8.8.8#53(8.8.8.8)5
  1. 상태: 응답이 있는 NOERROR. NXDOMAIN은 이름이 없다는 뜻이고, 응답이 없는 NOERROR는 MX가 없다는 뜻입니다.
  2. TTL: 이 사본을 앞으로 제공할 수 있는 초 단위 시간: 원본에서는 300이며 캐시에서는 줄어듭니다.
  3. 우선순위: 발신 측이 시도하는 순서로, 낮은 숫자부터입니다.
  4. 메일 서버: 포트 25로 연결할 호스트이며, 끝의 점이 이름을 끝맺습니다.
  5. 응답한 서버: 8.8.8.8은 캐시입니다. @dns1.p08.nsone.net은 존 자체에 묻습니다.
도구의 서버 보기에도 같은 다섯 줄이 우선순위별로 정렬되고 묶여, 각 서버의 주소와 함께 표시됩니다.

MX 레코드 조회 결과 읽는 법

맨 위의 한 문장은 도메인의 메일을 누가 받는지, 그 뒤에 서버가 몇 대 있는지 제공업체 로고와 함께 알려 줍니다. 그 아래 색이 칠해진 행이 중요한 발견 사항입니다.

서버 보기는 모든 MX 호스트를 우선순위 순으로 주소, 네트워크, 역방향 DNS와 함께 보여 줍니다. 첫 번째 서버는 포트 25에서 자동으로 테스트하고, 나머지는 요청하면 테스트합니다. 오른쪽의 전달 경로는 발신 측이 이 응답으로 무엇을 하는지 그림으로 보여 줍니다.

MX 레코드 조회 결과: Google Workspace의 MX 레코드 5개, 각 메일 서버의 주소와 STARTTLS 테스트, 전달 경로MX 레코드 조회 결과: Google Workspace의 MX 레코드 5개, 각 메일 서버의 주소와 STARTTLS 테스트, 전달 경로판정메일을 받는 곳, 서버와 우선순위 단계, 네트워크, TTL, 응답한 네임서버.서버우선순위별 각 MX 호스트와 IPv4·IPv6 주소, AS 번호, 정방향 확인된 PTR.SMTP 테스트저희 서버에서 포트 25로 확인한 STARTTLS와 TLS 버전. 행을 열면 전체 대화를 볼 수 있습니다.전달 경로발신 측, 첫 구간의 보호 장치, 각 우선순위 단계, 그리고 메일함과 그 근거.
airbnb.com의 MX 레코드 조회 예시입니다. 판정, 우선순위 순으로 정렬된 서버와 그 주소 및 STARTTLS 테스트, 메일이 거치는 경로를 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

MX 우선순위란?

우선순위(RFC 5321에서는 preference라고 부릅니다)는 순서를 정합니다: 발신 측은 가장 낮은 숫자부터 시도하며, 그 서버가 응답하지 않거나 일시적인 4xx 응답으로 메시지를 미룰 때만 다음으로 넘어갑니다.

숫자가 같은 서버는 부하를 나눕니다: 발신 측이 그중 하나를 무작위로 고릅니다. 중요한 것은 순서뿐이며 간격은 상관없고, 0도 유효한 숫자입니다. Microsoft 365나 Mimecast처럼 그 이름 뒤에 서버가 많이 분산되어 있다면 MX 레코드 하나로 충분합니다.

백업 MX에 대한 저희의 조언: 기본 서버보다 필터링이 약한 다른 회사의 백업은 잘 알려진 스팸 경로이며, 호스팅형 제공업체는 이미 MX 이름 하나 뒤에 이중화된 서버를 운영합니다. 백업을 둔다면 기본 서버와 같은 SPF 및 스팸 검사를 적용해야 합니다(RFC 7208, 부록 F).

발신 측이 airbnb.com의 서버 5대를 거치는 순서우선순위 1 · 5 · 10
1번째 시도우선순위 1
aspmx.l.google.com항상 가장 먼저 시도
250 OK

응답이 없거나 4xx로 응답할 때만

2번째 시도우선순위 5
alt1.aspmx.l.google.com무작위 선택 · ½alt2.aspmx.l.google.com또는 이 서버 · ½
같은 숫자는 부하를 나눔

그다음

3번째 시도우선순위 10
alt3.aspmx.l.google.com½alt4.aspmx.l.google.com½
모두 실패: 대기열에 넣고 며칠 동안 재시도
0도 유효github.com은 유일한 MX에 우선순위 0을 게시합니다.
1, 5, 10 ≡ 10, 20, 30중요한 것은 순서이며, 간격은 상관없습니다.
MX 하나로 충분할 수 있음hp.com의 MX 호스트 하나 뒤에는 주소 6개가 있습니다.
발신 측은 서버가 응답하지 않거나 일시적 오류로 응답할 때만 목록의 다음으로 넘어갑니다. 모든 서버가 실패하면 메시지는 대기열에서 기다리며 4~5일 동안 재시도됩니다(RFC 5321).

Google Workspace MX 레코드

새 Google Workspace 도메인에는 MX 레코드 하나만 있으면 됩니다: 우선순위 1의 smtp.google.com입니다. 2023년 이전에 설정한 도메인은 aspmx.l.google.com으로 시작하는 5개 레코드 세트를 아직 게시하는 경우가 많습니다. Google은 둘 다 작동하며, 잘 작동하는 설정은 바꿀 필요가 없다고 밝힙니다.

이 도구는 두 세트 모두 Google Workspace로 표시하고, 이전 세트는 레거시로 표시할 뿐 오류로 다루지 않습니다. MX와 함께 SPF include:_spf.google.com과 관리 콘솔에서 설정하는 DKIM을 갖추세요. Google은 새 MX 레코드가 모든 곳에 보이기까지 최대 72시간을 잡습니다.

Google Workspace의 두 가지 설정 비교실제 MX, 2026-10-23
현재레코드 1개권장
1 smtp.google.com.
사용 예: google.comsendgrid.com
레거시레코드 5개여전히 유효
1 aspmx.l.google.com.5 alt1.aspmx.l.google.com.5 alt2.aspmx.l.google.com.10 alt3.aspmx.l.google.com.10 alt4.aspmx.l.google.com.
사용 예: airbnb.comnytimes.comuber.comspotify.com
google.com 자체의 MTA-STS 정책은 둘 다 허용합니다:smtp.google.comaspmx.l.google.com*.aspmx.l.google.com
spotify.com은 이전 aspmx2–aspmx5.googlemail.com 호스트를 우선순위 10으로 아직 나열하고 있어 레코드가 모두 7개입니다: 레거시 이름이 더 있어도 해롭지 않습니다.

Microsoft 365 MX 레코드

Microsoft 365는 각 도메인에 mail.protection.outlook.com 아래의 MX 레코드 하나를 부여합니다. 예를 들면 microsoft-com.mail.protection.outlook.com이며, 우선순위는 보통 0입니다. 앞부분은 Microsoft 365 관리 센터에서 복사하는 토큰으로, 도메인의 점을 대시로 바꾼 모양인 경우가 많지만 항상 그렇지는 않습니다.

인바운드 SMTP DANE을 켠 도메인은 대신 mx.microsoft 아래의 호스트를 받습니다. 예를 들면 siemens-com.h-v1.mx.microsoft입니다. 이 존은 DNSSEC로 서명되어 있어 발신 측이 DANE으로 서버 인증서를 확인할 수 있습니다. 전환하는 동안에는 두 레코드가 모두 활성 상태이며, 새 레코드가 처음에는 기존 레코드 뒤에, 그다음에는 앞에 놓이고, 마지막으로 기존 레코드가 삭제됩니다. Microsoft는 mail.protection.outlook.com에 서명할 계획이 없으므로, 레거시 호스트가 낡은 것은 아닙니다.

Microsoft 365 MX 호스트 읽는 법microsoft.com · siemens.com
Exchange Online일반적인 형식
microsoft-com관리 센터의 토큰.mail.protection.outlook.comExchange Online Protection
사용 예: microsoft.comgithub.comunilever.com
DANE 사용DNSSEC로 서명된 존DANE
siemens-com관리 센터의 토큰.h-v1샤드.mx.microsoft서명된 존
사용 예: siemens.comshell.com
새 호스트로 전환하는 동안두 레코드 모두 활성, 낮은 숫자가 우선
0contoso-com.o-v1.mx.microsoft.새 레코드 · 먼저 시도
30contoso-com.mail.protection.outlook.com.기존 레코드 · 삭제될 때까지
레거시 호스트 하나와 mx.microsoft 호스트 하나가 서로 다른 우선순위로 있는 것은 Microsoft가 문서화한 절차에 따른 전환 과정이며 오류가 아닙니다: 이 도구는 경고 대신 그렇게 알려 줍니다.

MX 레코드가 없거나 null MX이면 어떻게 되나요?

MX 레코드가 없는 도메인도 메일을 받을 수 있습니다: 발신 측은 도메인 자체의 A 또는 AAAA 주소로 대신 전달합니다(RFC 5321 §5.1). 도메인이 메일을 받지 않는다는 것을 모든 발신 측에 알리는 것은 null MX, 즉 0 . 레코드 하나뿐입니다(RFC 7505).

그래서 이메일을 전혀 받지 않는 도메인에는 null MX가 알맞은 레코드입니다: 발신 측은 며칠 동안 재시도하는 대신 556 5.1.10으로 즉시 반송합니다. example.com처럼 v=spf1 -all과 DMARC p=reject도 추가해 누구도 이 도메인으로 메일을 보낼 수 없게 하세요. MX 레코드는 이름 하나에만 속합니다: www.example.com은 example.com의 MX를 상속하지 않습니다.

네 가지 응답, 네 가지 결과각 경우에 발신 측이 하는 일
MX 레코드 있음airbnb.com우선순위 순서대로 서버에 전달합니다.전달됨250 OK
MX 없음, A/AAAA 있음www.google.com이름 자체의 주소로 전달: A 및 AAAA 레코드입니다. 그곳의 포트 25가 응답하지 않으면 메일은 대기한 뒤 반송됩니다.암시적 MXRFC 5321 §5.1
null MX: 0 .example.com전달을 아예 시도하지 않습니다. 발신 측이 메시지를 즉시 반송합니다.거부됨556 5.1.10
이름이 존재하지 않음airbnb.cmo반송: 루트에 .cmo가 없으므로 그 아래의 어떤 이름도 존재하지 않습니다.반송됨5.1.2

메일을 보내지도 받지도 않는 도메인:MX 0 .v=spf1 -all_dmarc p=reject

각 행은 해당 예시에 대한 도구 자체의 판정입니다: 도구 위의 예시 칩에서 열 수 있습니다.

메일이 도착하지 않나요? 문제 해결에서 MX의 위치

먼저 반송 메일을 읽으세요: 상태 코드가 어느 단계에서 실패했는지 알려 줍니다. MX 문제는 "host not found"(호스트를 찾을 수 없음)나 긴 지연으로 나타납니다. 메일함이 없으면 5.1.1, 인증 실패는 5.7.x 거부입니다.

목록을 차례로 확인하세요: 도메인이 존재해야 하고, MX가 사용 중인 제공업체를 가리켜야 하며, 각 MX 호스트가 해석되고 포트 25에서 응답해야 합니다. 그다음에야 SPF, DKIM, DMARC와 블랙리스트가 메시지가 어디에 도착할지를 결정합니다.

반송 메일에서 해결까지확장 상태 코드, RFC 3463
호스트 또는 도메인을 찾을 수 없음5.1.2 · NXDOMAIN도메인이나 그 MX 호스트가 존재하지 않습니다. 철자와 네임서버를 확인하세요.DNS 조회
메일이 아직 이전 제공업체로 감MX 변경 후캐시는 TTL이 끝날 때까지 이전 MX를 유지합니다. 존의 응답을 Google과 Cloudflare의 사본과 비교하세요.사본 보기
지연된 뒤 반송4.4.1 · 호스트 응답 없음MX 호스트가 다운되었거나, 주소가 없거나, 포트 25가 차단되었습니다. 저희 쪽에서 서버를 테스트하세요.서버 테스트
알 수 없는 사용자5.1.1MX는 작동하지만, 제공업체에 해당 메일함이 없습니다.이메일 주소 확인
거부됨: 인증되지 않음5.7.1수신 측이 발신자를 거부했습니다. 발신 도메인의 SPF, DKIM, DMARC를 수정하세요.SPF 레코드 확인
주소 때문에 차단되거나 스팸함에 들어감등록됨발신 서버의 IP가 블랙리스트에 올라 있습니다.IP 블랙리스트 확인
강조된 두 단계는 이 도구 자체의 보기이며, 나머지는 해당 도구를 엽니다.

메일 서버의 MTA-STS, DANE, TLS

메일 서버는 양쪽 모두 STARTTLS를 제공할 때만 암호화하므로, 경로 중간의 누군가가 그 제안을 제거하면 메시지를 읽을 수 있습니다. MTA-STS와 DANE을 사용하면 도메인이 발신 측에 TLS를 요구할 수 있습니다.

MTA-STS는 허용된 MX 호스트와 모드를 나열한 정책을 HTTPS로 게시합니다(https://mta-sts.<domain>/.well-known/mta-sts.txt). enforce 모드에서는 발신 측이 그 호스트에 유효한 TLS로만 전달합니다(RFC 8461). DANE은 서버의 키를 _25._tcp.<mx host>의 TLSA 레코드에 넣으며, 이는 DNSSEC가 그 존에 서명한 경우에만 의미가 있습니다(RFC 7672). TLS-RPT는 발신 측에 실패를 보고하도록 요청합니다(RFC 8460). 이 도구는 모든 실제 MX가 정책의 mx: 줄과 일치하는지 확인합니다.

한 구간에 걸린 세 개의 잠금발신 측 → proton.me, 실시간
발신 측임의의 메일 서버
STARTTLS · 제공됨, TLS 1.3STARTTLS만으로는 전송 도중에 제거될 수 있습니다: 250-STARTTLS가 응답에서 그냥 사라집니다.
MTA-STS · enforce 모드mx: mail.protonmail.ch · mx: mailsec.protonmail.ch · max_age: 604800 ✓ 실제 MX 호스트 2대 모두 일치
DANE · TLSA 3 1 1_25._tcp.mail.protonmail.ch, DNSSEC로 서명됨(protonmail.ch) ✓
mail.protonmail.ch우선순위 10
TLS-RPT도 켜져 있습니다: v=TLSRPTv1; rua=https://reports.proton.me/reports/smtptls. 이 도구는 저희 서버에서 STARTTLS를 테스트하며, MTA-STS와 DANE은 DNS와 정책 파일에서 읽습니다.

주요 제공업체의 MX 호스트

대부분의 도메인은 수십 곳의 제공업체 중 하나로 MX를 지정하며, 각 제공업체는 알아보기 쉬운 호스트 이름을 게시합니다. 이 도구는 이를 바탕으로 도메인의 메일 제공업체를 알려 주며, 사용자도 설정을 제공업체 자체의 값과 대조할 수 있습니다.

Mimecast, Proofpoint, Barracuda 같은 게이트웨이는 메일함 호스트 앞에 놓입니다. 이 경우 도구는 SPF와 Autodiscover를 읽어 그 뒤에 있을 가능성이 높은 메일함을 알려 줍니다.

제공업체별 MX 호스트와 SPF include도구가 인식하는 110개 이상의 제공업체 중 16곳
제공업체MX(우선순위 호스트)SPF
Google Workspace1smtp.google.com또는 1 aspmx.l.google.com + 4 altinclude:_spf.google.com
Microsoft 3650<token>.mail.protection.outlook.com또는 <token>.<x>-v1.mx.microsoftinclude:spf.protection.outlook.com
Zoho MailTLD로 지역 구분10mx.zoho.com20mx2.zoho.com · 50 mx3.zoho.cominclude:zohomail.com
Proton Mail10mail.protonmail.ch20mailsec.protonmail.chinclude:_spf.protonmail.ch
iCloud Mail10mx01.mail.icloud.com10mx02.mail.icloud.cominclude:icloud.com
Fastmail10in1-smtp.messagingengine.com20in2-smtp.messagingengine.cominclude:spf.messagingengine.com
Yandex 36010mx.yandex.netredirect=_spf.yandex.net
Titan Email10mx1.titan.email20mx2.titan.emailinclude:spf.titan.email
GoDaddy Professional Email0smtp.secureserver.net10mailstore1.secureserver.netinclude:secureserver.net
Namecheap Private Email10mx1.privateemail.com10mx2.privateemail.cominclude:spf.privateemail.com
Cloudflare Email Routing포워딩route1/2/3.mx.cloudflare.net우선순위는 도메인마다 설정include:_spf.mx.cloudflare.net
Amazon SESWorkMail과 공유10inbound-smtp.<region>.amazonaws.cominclude:amazonses.com
Mimecast게이트웨이10<region>-smtp-inbound-1.mimecast.com10<region>-smtp-inbound-2.mimecast.cominclude:<region>._netblocks.mimecast.com
Proofpoint게이트웨이mx0a-<id>.pphosted.com · mx0b-<id>또는 mx1-us1.ppe-hosted.com (Essentials)a:dispatch-us.ppe-hosted.com (Essentials)
Barracuda게이트웨이1<id>.ess.barracudanetworks.com10<id>.ess.barracudanetworks.cominclude:spf.ess.barracudanetworks.com
NAVER WORKS한국10kr1-aspmx1.worksmobile.com20kr1-aspmx2.worksmobile.cominclude:spf.worksmobile.com

MX 레코드 조회 자주 묻는 질문

MX 레코드 조회는 어디에 쓰나요?

MX 레코드 조회를 하면 도메인의 이메일을 어떤 서버가 받고 누가 운영하는지 알 수 있습니다. 회사의 메일 제공업체를 확인하거나, 제공업체를 옮긴 뒤 MX 변경을 확인하거나, 반송과 지연을 진단하거나, 메일을 보내기 전에 도메인을 점검할 때 사용하세요. 이 도구는 저희 서버에서 각 메일 서버의 STARTTLS도 테스트하고, 도메인의 SPF, DMARC, MTA-STS도 읽습니다.

nslookup으로 MX 레코드를 확인하려면 어떻게 하나요?

nslookup -type=mx example.com을 실행하세요. 응답의 각 줄에는 우선순위가 "MX preference"로, 서버가 "mail exchanger"로 표시됩니다. nslookup -type=mx example.com 8.8.8.8처럼 끝에 서버를 추가하면 특정 리졸버에 질의하고, 도메인 자체의 네임서버를 지정하면 모든 캐시를 건너뜁니다. macOS와 Linux에서는 dig example.com MX로 같은 응답을 받을 수 있습니다.

한 도메인에 MX 레코드를 여러 개 둘 수 있나요?

네. 각 MX 레코드는 메일 서버 하나를 우선순위와 함께 지정합니다. 발신 측은 가장 낮은 숫자부터 시도하고, 서버가 응답하지 않거나 전달을 미룰 때만 다음으로 넘어가며, 숫자가 같은 서버 중에서는 무작위로 골라 부하를 나눕니다. gmail.com은 다섯 가지 우선순위로 MX 레코드 5개를, yahoo.com은 같은 우선순위로 3개를 게시합니다.

MX 레코드가 IP 주소나 CNAME을 가리킬 수 있나요?

아니요. MX 값은 자체 A 또는 AAAA 레코드가 있는 호스트 이름이어야 합니다. IP 주소는 유효한 값이 아니며, RFC 2181은 별칭(CNAME)인 MX 호스트를 금지합니다. 일부 발신 측은 그래도 CNAME을 따라가거나 IP로 연결하지만 다른 발신 측은 거부하므로, 어떤 발신 측의 메일은 도착하고 어떤 메일은 반송될 수 있습니다. 이 도구는 두 경우 모두 표시해 알려 줍니다.

MX 레코드 변경은 반영되기까지 얼마나 걸리나요?

이전 레코드의 TTL만큼 걸립니다. 이전 MX를 캐시한 리졸버는 사본이 만료될 때까지 그것을 계속 쓰고, 그다음 도메인의 네임서버에 다시 묻습니다. 캐시된 "MX 없음" 응답도 같은 방식으로 만료됩니다. 제공업체를 바꾸기 하루 전에 TTL을 낮추세요. 제공업체들은 안전 여유를 안내하며(Google은 최대 72시간), 사본 보기에서 Google과 Cloudflare의 사본이 언제 갱신되는지 확인할 수 있습니다.

null MX 레코드란 무엇인가요?

null MX는 우선순위 0에 호스트로 점 하나만 둔 단일 MX 레코드, 즉 0 .입니다(RFC 7505). 도메인이 이메일을 받지 않는다는 뜻이므로, 발신 측은 며칠 동안 재시도하지 않고 556 5.1.10으로 메시지를 즉시 반송합니다. null MX는 유일한 MX 레코드여야 합니다. example.com이 SPF -all, DMARC p=reject와 함께 null MX를 게시하고 있습니다.

도메인에 MX 레코드가 없으면 어떻게 되나요?

그래도 메일 전달은 시도됩니다. MX 레코드가 없으면 발신 측은 도메인 자체의 A 또는 AAAA 주소, 즉 암시적 MX로 전달합니다(RFC 5321 5.1절). 그곳의 포트 25에서 아무것도 응답하지 않으면 메시지는 발신 측 대기열에서 4~5일 동안 재시도된 뒤 반송됩니다. 메일을 받지 않아야 하는 도메인은 대신 null MX를 게시해야 합니다.

MX 레코드가 하나뿐이면 문제가 되나요?

아니요. 그 이름 뒤에서 부하가 분산된다면 MX 레코드 하나로 완전한 설정입니다: Google Workspace의 smtp.google.com과 Microsoft 365의 mail.protection.outlook.com 호스트는 각각 많은 서버에서 응답합니다. RFC 5321은 MX 레코드의 최소 개수를 요구하지 않습니다. 이 도구는 각 MX 호스트 뒤에 있는 IPv4와 IPv6 주소 수를 보여 주므로 이중화 정도를 확인할 수 있습니다.

MX에 예상과 다른 제공업체가 표시되는 이유는 무엇인가요?

메일함 앞에 게이트웨이가 있을 수 있습니다. Mimecast, Proofpoint, Barracuda, Cloudflare Email Security는 메일을 먼저 필터링하므로, MX에는 게이트웨이가 표시되고 메일함은 그 뒤의 Microsoft 365, Google Workspace 또는 다른 제공업체에 있습니다. 이 도구는 도메인의 SPF include와 Autodiscover 레코드를 읽어 메일함 제공업체를 추정하고, 그 근거를 보여 줍니다.

MX 레코드는 공개되어 있나요?

네. MX 레코드는 설계상 공개 DNS 데이터입니다: 세상의 모든 메일 서버가 여러분의 도메인으로 메일을 전달하려면 이를 조회할 수 있어야 합니다. MX 레코드는 어떤 서버가 메일을 받고 누가 운영하는지를 보여 줄 뿐, 누가 메일을 보내는지나 메일함에 무엇이 있는지는 보여 주지 않습니다. MX 레코드를 숨기면 이메일이 도착하지 않게 됩니다.

MX 레코드가 이메일 발송에 영향을 주나요?

아니요. MX 레코드는 들어오는 메일을 서버로 안내할 뿐입니다. 어떤 서버가 도메인으로 메일을 보낼 수 있는지는 SPF, DKIM, DMARC가 정하며, 수신 측은 모든 메시지에서 이를 확인합니다. 한 제공업체로 보내고 다른 제공업체에서 받을 수도 있으며, 이 경우 SPF에는 둘 다 나오고 MX에는 수신용 제공업체만 나옵니다.

내 컴퓨터에서 포트 25에 연결할 수 없는 이유는 무엇인가요?

대부분의 가정용·모바일 네트워크와 AWS, Google Cloud, Azure 같은 클라우드는 스팸을 막기 위해 포트 25로 나가는 연결을 차단하므로, 메일 서버로의 telnet이나 openssl 연결이 시간 초과됩니다. 이는 서버 상태와 무관합니다. 이 도구는 포트 25에 연결할 수 있는 뭄바이의 저희 서버에서 각 메일 서버를 테스트하고 전체 대화를 보여 줍니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

더 많은 DNS 및 이메일 도구