DNS 상태가 녹색으로 바뀌지 않는 경우

DNS 인증은 선택한 구성에 필요한 레코드를 확인합니다. TrekMail을 통해 메일을 받는 도메인에는 보통 MX, SPF, DKIM 및 DMARC가 필요합니다. MTA-STS와 TLS-RPT 같은 권장 레코드는 별도로 표시될 수 있습니다. 이 가이드는 추측하지 않고 대시보드와 DNS 공급자를 비교하도록 돕습니다.

대시보드 레코드 표에서 시작하기

도메인을 열고 해당 도메인과 DNS 상태를 선택합니다. 표에서 유형, 호스트, 값과 MX의 우선순위를 복사합니다. DKIM 값과 일부 정책 레코드는 도메인마다 고유하므로 이 표가 기준입니다.

레코드를 바꾸기 전에 다른 서비스에 기존 값이 필요한지 확인하세요. 특히 SPF 레코드는 하나만 유지하고 다른 정상적인 발신 서비스가 쓰는 include는 보존합니다.

전파에는 얼마나 걸리나요?

DNS 갱신이 나타나는 시간은 공급자, 이전 레코드의 TTL 및 리졸버 캐시에 따라 다릅니다. 대기 상태가 값이 틀렸다는 증거는 아니며, 시간이 지났다고 값이 맞는 것도 아닙니다.

다음 순서로 확인하세요.

1. 권한 DNS 영역을 호스팅하는 공급자에서 레코드를 저장합니다.
2. MX 우선순위와 전체 DKIM 값을 포함해 저장된 레코드를 대시보드 표와 비교합니다.
3. DNS 확인을 한 번 사용해 TrekMail 재검사를 요청합니다.
4. 계속 대기 중이면 충돌 세부 정보와 독립 조회를 이용해 현재 공개 값을 확인합니다.

필수 레코드

일반 메일 호스팅의 주요 레코드는 다음과 같습니다. 다른 도메인의 값이 아니라 자신의 대시보드에서 값을 복사하세요.

권장 레코드는 전송 보안을 개선하지만 핵심 레코드를 대체하지 않습니다.

선택 사항인 클라이언트 자동 구성 CNAME(autoconfig, autodiscover)은 앱 설정을 빠르게 하지만 메일 전송에는 영향을 주지 않습니다.

확인 1: 중복 SPF 레코드 합치기

도메인 루트에는 v=spf1로 시작하는 TXT 레코드가 하나만 있어야 합니다. 두 개면 수신 서버가 정책을 확실히 판단할 수 없고 TrekMail도 올바르게 인증할 수 없습니다.

증상: 두 레코드가 DNS에 있지만 TrekMail은 여전히 SPF가 구성되지 않았다고 표시합니다.

해결 방법: 발신자 규칙을 하나로 합칩니다. 다음 두 줄이 있다면:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all

다음으로 바꿉니다.

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

사용할 끝부분: -all 또는 ~all

하나만 사용합니다. include:spf.trekmail.net이 끝부분 앞에 있으면 둘 다 TrekMail 검사를 통과합니다. 선택은 다른 서비스가 보내는 메일에 영향을 줍니다.

끝부분에 대한 권고는 인증 실패가 아닙니다. 어느 쪽으로도 도메인을 인증할 수 있습니다.

다음은 사용하지 마세요.

• ?all은 유용한 승인 정책을 제공하지 않습니다.
• +all은 인터넷의 모든 발신자를 승인합니다.

SPF 레코드는 최대 10회의 DNS 조회를 사용할 수 있습니다. 외부 발신자가 많으면 include 수를 줄이거나 해당 공급자에게 지원되는 통합 방법을 문의하세요.

확인 2: Cloudflare 메일 CNAME이 프록시됨

Cloudflare는 웹 트래픽을 프록시할 수 있지만 메일 관련 CNAME은 DNS 전용이어야 합니다. mta-sts, autoconfig, autodiscover 또는 대시보드가 요구한 다른 호스트가 해당됩니다.

증상: Cloudflare DNS 목록에 있지만 레코드가 차단되었거나 인증할 수 없다고 표시됩니다.

해결 방법: Cloudflare에서 DNS를 열고 호스트를 찾아 주황색 구름을 회색 DNS 전용으로 바꿉니다. 그런 다음 TrekMail에서 DNS 확인을 실행합니다.

웹사이트의 A 또는 기본 웹 CNAME은 프록시 상태로 유지해도 됩니다. 대시보드가 지정한 메일 호스트만 변경하세요.

확인 3: DMARC가 잘못된 호스트에 있음

DMARC는 루트가 아니라 _dmarc.yourdomain.com에 있어야 합니다. 일부 DNS 양식은 @를 미리 채워 잘못된 위치에 저장하기 쉽습니다.

증상: DNS에 DMARC가 있지만 TrekMail은 찾지 못합니다.

해결 방법: _dmarc에 레코드를 추가합니다. 어떤 인터페이스는 _dmarc를, 다른 곳은 _dmarc.yourdomain.com을 요구합니다. 양식 안내를 확인하세요. @의 잘못된 레코드는 다른 용도가 없음을 확인한 뒤 삭제합니다.

확인 4: DKIM을 잘못 붙여 넣거나 분할함

DKIM 값은 깁니다. DNS 공급자가 긴 TXT를 여러 연결된 텍스트 부분으로 저장할 수 있지만 공개 결과는 대시보드의 전체 값과 일치해야 합니다.

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

대부분 자동 처리합니다. 잘못 붙여 넣으면 문자, 공백 또는 따옴표가 추가되거나 빠질 수 있습니다.

증상: DNS에 DKIM이 보이지만 TrekMail이 "DKIM key invalid" 또는 "p= does not match"를 표시합니다.

해결 방법:

• 대시보드에 표시된 값을 그대로 붙여 넣습니다.
• 공급자가 긴 TXT를 자동 분할하면 전체 값을 붙이고 처리하게 둡니다.
• 별도 구간을 요구하면 공급자 지침을 따르고 모든 문자를 유지합니다.
• 독립 DNS 조회로 공개 TXT에 전체 키가 포함되었는지 확인합니다.

확인 5: MTA-STS에 조치가 필요함

MTA-STS는 TrekMail로 수신하는 도메인에 권장되는 전송 보안 기능입니다. 대시보드에 표시되면 해당 TXT와 mta-sts CNAME이 모두 필요합니다. 대시보드가 명시적으로 요구하지 않으면 발신 전용 도메인에는 추가하지 마세요.

DNS로 차단됨. mta-sts CNAME이 없거나 다른 곳을 가리킵니다. 대시보드의 현재 대상으로 추가하거나 수정합니다.

Cloudflare로 차단됨. CNAME은 있지만 프록시됩니다. 확인 2에 따라 호스트를 DNS 전용으로 설정합니다.

이전에는 작동했으나 저하됨. TXT와 CNAME을 대시보드와 비교합니다. 보통 레코드 변경이나 삭제가 원인입니다. 필요한 값을 복원하고 DNS 확인을 실행해 갱신된 상태를 확인합니다.

확인 6: 공개 조회와 대시보드 비교

변경이 전파되는 동안 로컬 네트워크와 TrekMail이 다른 DNS 결과를 볼 수 있습니다. 공개 조회는 다른 네트워크에 보이는 값을 확인하는 데 유용합니다.

비교 방법:

1. dnschecker.org 또는 whatsmydns.net을 엽니다.
2. 전체 호스트 이름과 레코드 유형을 입력합니다. DMARC는 _dmarc.yourdomain.com과 TXT를 사용합니다.
3. 반환된 호스트, 값 및 MX 우선순위를 대시보드 표와 비교합니다.
4. 공개 조회에는 올바른 값이 있지만 TrekMail이 불일치를 보고하면 결과를 지원 티켓에 포함합니다.

확인 7: 이전 DNS 값이 캐시에 남음

DNS 레코드를 변경하면 이전 값이 TTL(Time To Live, 초 단위)이 만료될 때까지 중간 리졸버에 남을 수 있습니다. 이전 레코드에는 24시간(86400초) TTL이 흔합니다.

증상: 한 시간 전에 변경했지만 전 세계 검사 도구에 이전 값이 표시됩니다.

해결 방법: 같은 변경이 전파되는 동안 반복 편집하지 마세요. 계획된 이전에서는 공급자가 지원한다면 미리 TTL을 낮출 수 있습니다. 안정화된 뒤에는 일반 DNS 관리에 적합한 TTL을 선택합니다.

단계별 디버깅

1. 도메인 페이지를 열고 도메인을 클릭합니다.
2. 충돌 보기가 있으면 엽니다. 수정 필수 레코드와 권장 및 정보 항목을 구분합니다.
3. 예상 호스트, 값 및 MX 우선순위를 DNS 공급자에 저장된 레코드와 비교합니다.
4. 필요한 최소 변경만 하고 다른 서비스에 필요한 레코드는 유지합니다.
5. TrekMail에서 DNS 확인을 클릭합니다.
6. 갱신된 상태를 읽습니다. 선택한 구성에 필요한 레코드가 유효하면 도메인이 활성화됩니다. 권장 레코드는 별도로 표시될 수 있습니다.

직접 확인할 수 있는 레코드는 터미널(Mac/Linux/WSL)에서 다음 명령을 사용합니다.

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

출력을 대시보드에 표시된 자신의 도메인 값과 비교하세요. 예제에서 DKIM 키, MTA-STS 정책 ID 또는 기타 도메인별 값을 복사하지 마세요.

DNS 공급자에서 흔한 문제

• Cloudflare: 메일 CNAME은 DNS 전용이어야 합니다. 공급자가 대상 끝의 점을 숨길 수 있으므로 중복 점을 추가하지 말고 해석된 대상을 비교합니다.
• GoDaddy: 루트에는 @, DMARC 호스트에는 _dmarc를 사용합니다. GoDaddy가 도메인 이름을 붙입니다.
• Namecheap: Namecheap이 권한 DNS 공급자인 경우에만 Advanced DNS에서 레코드를 추가합니다. 루트에는 @를 사용합니다.
• Route 53: 실제로 도메인에 연결된 호스팅 영역을 선택하고 대시보드의 전체 값을 붙여 넣습니다.
• 웹사이트 제작 서비스 및 등록 기관: 도메인 구매처가 DNS를 관리하지 않을 수 있습니다. 네임서버를 확인하고 실제 공급자에서 편집합니다.

모든 것이 맞지만 계속 빨간색인 경우

대시보드와 독립 공개 조회에 같은 필수 레코드가 표시되는데 TrekMail이 불일치를 보고하면 지원 티켓에 다음을 포함합니다.

• 도메인 이름.
• 해당 레코드의 공개 조회 결과.
• 가능한 경우 충돌 보기 패널의 스크린샷.

계정 암호, 메일함 암호, 복구 코드 또는 액세스 토큰을 포함하지 마세요.