MX 레코드는 한 가지 좁은 질문에 답합니다: 이 도메인에 대한 메일을 어느 서버가 받아야 하는가? 임시 이메일 맞춤 도메인의 경우, Cloudflare가 권한 있는 DNS를 호스팅할 수 있지만, GPTMail—Cloudflare가 아닌—이 수신함 서비스를 제공합니다. DNS 대시보드가 올바르게 보이지만 공개 DNS 응답이 다른 내용을 표시하면 설정이 혼란스러워집니다.
해결 방법은 형태를 판단하지 말고 실제 인터넷에서 볼 수 있는 응답을 검사하는 것입니다.
DNS 변경 전
세 가지 사항을 확인하세요:
- 도메인의 권한 있는 네임서버에 대한 DNS를 편집할 수 있습니다.
- 메일을 수신하려는 정확한 도메인이어야 합니다.
- GPTMail이 표시하는 현재 공개 MX 대상값을 복사했습니다.
GPTMail은 현재 도메인 추가 패널과 도메인 페이지에서 필요한 대상을 표시합니다. 오래된 스크린샷이나 다른 서비스에서 복사한 레코드 대신 해당 값을 사용하세요.
최소 레코드
현재 GPTMail 공개 대상에 대해 레코드는 일반적으로 다음과 같습니다:
Type: MX
Name: @
Target: email.chatgpt.org.uk
Priority: 1DNS 제공업체마다 호스트 필드에 대한 설명이 다릅니다. @, 빈 값, 혹은 도메인 자체가 모두 영역 최상위를 의미할 수 있습니다. 제공업체의 관례를 따르세요; 인터페이스가 빈 필드를 요구한다면 @를 문자 그대로 입력하지 마세요.
일부 제공업체는 대상 뒤에 마침표를 요구하고, 일부는 자동으로 추가합니다. 올바르게 처리하면 두 형태는 동일한 DNS 이름을 나타냅니다.
복사하기 전에 공개 또는 비공개를 선택하세요
GPTMail에는 두 가지 맞춤 도메인 모드가 있으며, 항상 동일한 MX 대상을 사용하는 것은 아닙니다.
- 공개 도메인은 도메인 페이지에 표시된 공개 대상을 사용합니다. 인증이 완료되면 공개 도메인 목록에 표시되고 서버 측 요청을 위한 API 키를 받습니다.
- 비공개 도메인은 공개 목록에 나타나지 않으며, 내 GPTMail 계정에 연결됩니다. 먼저 로그인해야 하며, 해당 계정만 메시지를 볼 수 있습니다. GPTMail 홈페이지의 비공개 도메인 탭에서 시작하여 전용 DNS 설정을 생성한 후 MX를 편집하세요.
이 문서에 있는 공개 예시를 비공개 도메인 설정에 복사하지 마세요. 추가하려는 도메인에 표시된 값이 최종 기준입니다.
우선순위는 속도 설정이 아닙니다
숫자가 낮을수록 우선순위가 높습니다. 우선순위 1은 명확한 기본값이지만, 유일한 MX 경로인 경우 0이나 10도 작동합니다. 위험한 구성은 낮은 번호를 가진 오래된 레코드가 다른 곳을 가리키는 경우입니다. 발신자는 먼저 그 경로를 시도합니다.
마이그레이션 중에는 테스트된 백업 수신기를 의도적으로 운영하지 않는 한 오래된 MX 레코드를 제거하세요. 여러 레코드는 무해한 장식이 아니라 대체 전달 경로를 정의합니다.
권한 있는 응답 확인
레코드를 저장한 후 공개 DNS를 조회합니다:
dig MX your-domain.example응답에 GPTMail 대상이 포함되어야 합니다. 포함되지 않으면 권한 있는 네임서버가 어느 것인지 확인하세요:
dig NS your-domain.example그런 다음 해당 네임서버 중 하나에 직접 질의합니다:
dig @authoritative-nameserver.example MX your-domain.example이는 전파 지연과 잘못된 DNS 영역 편집을 구분합니다. 권한 있는 서버가 이미 새 레코드를 반환하지만 공개 리졸버가 그렇지 않다면 캐시된 데이터가 만료될 때까지 기다리세요. 권한 있는 서버가 여전히 오래된 값을 반환한다면, 기다려도 해결되지 않으며 변경이 잘못된 위치에 저장되었거나 공개되지 않은 것입니다.
올바른 레코드가 알 수 없는 것으로 보이는 이유
DNS 검사는 해결자 타임아웃, 네임서버 문제, DNSSEC 오류, 혹은 아직 전파 중인 레코드 때문에 일시적으로 응답이 없을 수 있습니다. 한 번의 조회 실패가 도메인이 잘못 구성되었다는 증거는 아닙니다.
GPTMail이 MX 레코드가 필요한 서버를 가리키지 않는다고 보고할 경우:
- 도메인 관리자에 표시된 실제 MX 값을 복사합니다.
- 전체 호스트명을 포함한 요구 대상과 비교합니다.
- 우선순위가 더 높은 경쟁 레코드가 있는지 확인합니다.
- 권한 있는 네임서버에 직접 질의합니다.
- 몇 분 기다린 후 새로운 DNS 변경 후 다시 시도합니다.
DNS가 전파되는 동안 도메인을 반복적으로 삭제하고 다시 만들지 마세요. 이는 애플리케이션 상태를 변경하지만 DNS 응답은 바꾸지 않습니다.
Cloudflare‑인증 설정
이 흐름에서 Cloudflare가 DNS 제공자이며, GPTMail이 임시 수신함 수신자입니다. 이 설정은 Cloudflare Email Routing을 사용하지 않습니다.
인증하기 전에 다음을 확인하십시오:
- 실제로 도메인을 제어하는 Cloudflare 계정 및 영역을 선택합니다.
- Cloudflare Email Routing이 활성화되어 있으면 먼저 비활성화합니다. GPTMail은 라우팅 MX 레코드를 감지하고 DNS를 변경하지 않은 채 중단한 뒤 충돌을 해결하도록 요청합니다.
- GPTMail이 표시한 대상을 검토합니다. 일회성 인증은 해당 도메인에 대한 MX 레코드만 교체하며, 다른 DNS 레코드 유형은 수정되지 않고, 콜백이 완료된 후 액세스 토큰이 폐기됩니다.
자동 레코드는 우선순위 0을 사용하고, 위의 수동 예시는 1을 사용합니다. 두 경우 모두 MX 경로가 하나뿐이면 유효합니다. 인증은 입력 오류를 줄여 주지만 최종 검증은 여전히 공개 DNS에 의존합니다.
도메인이 다른 DNS 제공자를 사용한다면 레코드를 수동으로 추가하고 GPTMail으로 돌아가 검증을 다시 시도하십시오.
실제 전달 테스트
MX 조회는 라우팅을 확인할 뿐, 종단 간 전달을 보장하지 않습니다. 검증 후:
- 도메인에 새 주소를 생성합니다;
- 관련 없는 제공업체에서 짧은 텍스트 메시지를 보냅니다;
- 수신자 주소가 정확히 일치하는지 확인합니다;
- 실패라고 가정하기 전에 발신자가 전달을 완료할 때까지 기다립니다;
- 첫 번째 메시지가 지연되면 두 번째 발신자를 시도합니다.
최근에 오래된 MX 경로를 캐시한 시스템에서만 테스트하는 것을 피하세요.
소유권 및 복구를 분리 유지
맞춤 도메인은 이름 관리 권한을 제공하지만 GPTMail은 여전히 임시 인박스 서비스입니다. 레지스트라 접근, DNS 복구, 중요한 계정 복구는 임시 도메인 외부의 영구적인 메일함에 보관하세요.
프라이빗 도메인이 처음부터 적합한지 판단하려면 결과에 따라 인박스 선택하기, 편의가 아니라를 읽으세요. MX 검증 후에도 테스트 메시지가 도착하지 않으면 인증 이메일이 도착하지 않음: 문제 단계 찾기를 사용하세요.