도메인의 메일 서버
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터MX(Mail Exchanger) 레코드는 어떤 호스트가 도메인의 이메일을 어떤 우선순위로 수신하는지를 발신 서버에 알려 줍니다. 누군가 귀하에게 메일을 보내면 그 서버는 MX 레코드를 조회해 어디로 전달할지 찾습니다. MX 레코드가 없거나 잘못 구성되면 수신 메일이 전달되지 못하고 메시지가 반송되거나 사라집니다.
각 MX 레코드는 메일 호스트와 우선순위 번호를 짝지습니다. 낮은 숫자가 우선합니다. 발신 서버는 가장 낮은 우선순위의 호스트를 먼저 시도하고, 연결할 수 없을 때만 더 높은 숫자로 넘어갑니다. 동등한 성능의 서버 간에 부하를 분산하려면 같은 우선순위를 부여하면 트래픽이 그 사이에 나뉩니다. 예를 들어 일반적인 Google Workspace 설정은 우선순위 1로 smtp.google.com을 가리킵니다. MX 값은 IP 주소나 CNAME이 아니라 자체 A 또는 AAAA 레코드를 가진 호스트명이어야 하며, 그렇지 않으면 전송이 깨집니다.
IPeek는 도메인의 모든 MX 호스트를 우선순위와 함께 나열하며, 낮은 순으로 정렬해 선호 서버가 맨 위에 오게 합니다. 호스트가 이메일 제공업체와 일치하는지 확인하세요. Google Workspace, Microsoft 365, 자체 서버, 또는 필터링 게이트웨이일 수 있습니다. 중복, 호스트명 오타, 잘못 구성된 영역을 나타내는 후행 점을 주의하세요. 목록이 비어 있으면 도메인에 MX 레코드가 없어 메일을 받을 수 없습니다. 나열된 호스트가 유효한 IP 주소로 확인되는지 신뢰하기 전에 교차 확인하세요.
가장 잦은 실패는 MX 레코드가 아예 없어 발신 서버가 도메인의 A 레코드로 대체하거나 반송하는 것입니다. MX를 CNAME으로 가리키는 것은 사양을 위반하며 많은 서버가 이를 거부하므로, 항상 직접 A/AAAA 레코드를 가진 호스트명을 대상으로 하세요. 이메일 제공업체를 전환한 뒤에는 DNS가 전파되고 캐시가 만료될 때까지 오래된 MX 레코드가 메일을 이전 호스트로 계속 보냅니다. 우선순위가 잘못 정렬되면 메일을 기본 서버보다 백업으로 먼저 보낼 수 있습니다. 새 조회로 변경 사항을 확인하고 TTL 기반 캐싱을 감안하세요.
MX 레코드가 없으면 발신 서버는 도메인의 A 또는 AAAA 레코드로 대체해 그곳으로 전송을 시도합니다. 그 호스트가 메일 서버를 운영하지 않으면 메시지가 반송됩니다. 이메일을 처리하는 도메인은 수신 메일이 올바른 서버에 안정적으로 도달하도록 항상 적어도 하나의 MX 레코드를 게시해야 합니다.
우선순위는 발신 서버가 메일 호스트를 시도하는 순서를 정하며, 낮은 숫자가 선호됩니다. 서버는 가장 낮은 우선순위의 호스트를 먼저 시도하고, 연결할 수 없을 때만 더 높은 숫자로 넘어갑니다. 동등한 우선순위는 서버가 부하를 나누게 합니다. 실제 값은 임의이며 상대적인 순서만 중요합니다.
아니요. MX 레코드는 자체 A 또는 AAAA 레코드를 가진 호스트명을 가리켜야 합니다. IP 주소를 가리키는 것은 유효하지 않고, CNAME을 가리키는 것은 RFC 규칙을 위반해 많은 메일 서버가 거부합니다. 항상 직접 확인되는 실제 메일 호스트명을 대상으로 하세요.
MX 변경은 레코드의 TTL에 따라 전파되며, TTL은 리졸버가 이전 값을 얼마나 오래 캐시할지 제어합니다. TTL이 낮으면 변경이 몇 분 안에 적용될 수 있고, 높으면 발신 서버가 몇 시간 동안 오래된 레코드를 계속 사용할 수 있습니다. 계획된 마이그레이션 전에 TTL을 낮춰 전환을 앞당기세요.
네. 도메인은 흔히 중복성과 부하 분산을 위해 여러 MX 레코드를 게시합니다. 서로 다른 우선순위는 기본-백업 구성을 만들고, 동일한 우선순위는 동등한 성능의 서버에 메일을 분산합니다. 발신 서버는 연결을 수락하는 호스트를 찾을 때까지 우선순위 순으로 목록을 훑습니다.