TrekMail 도메인에 필요한 DNS 레코드 설정

도메인을 활성화할 때 TrekMail은 네 가지 핵심 DNS 레코드를 확인합니다. 대시보드에 표시된 정확한 값을 DNS 제공업체에 입력하세요. 빠진 항목이나 일치하지 않는 값이 있으면 TrekMail이 수정할 내용을 알려 줍니다.

도메인의 수신 메일은 다른 제공업체에 두고 해당 주소로 발송만 하려는 경우에는 MX를 변경하지 않습니다. TrekMail에서 호스팅하지 않는 도메인으로 발송하기를 참고하세요. 이 방식을 선택하면 대시보드가 필수 항목에서 MX를 자동으로 제외합니다.

대상 사용자

• DNS를 설정하는 시스템 관리자
• 배달 문제나 빨간색 DNS 상태를 해결하려는 사용자

이메일 DNS의 네 가지 핵심 레코드

1. 수신용 MX 레코드

호스트: @ 또는 도메인 루트

값: mail.trekmail.net.

우선순위: 10

이 레코드는 수신 메일을 TrekMail 서버로 보냅니다.

• 흔한 실수: Google이나 GoDaddy와 같은 이전 서비스의 MX를 TrekMail MX와 함께 남겨 두는 경우입니다. 메일이 여러 제공업체로 나뉘어 일부 메시지가 유실될 수 있습니다. 다른 MX 레코드를 모두 삭제하세요.
• 발송만 하나요? MX는 그대로 두세요. 도메인을 열고 이름 아래의 수신 메일 옵션에서 현재 제공업체가 계속 수신하도록 선택합니다. 대시보드는 SPF, DKIM, DMARC만 요구하고 감지된 MX에 대한 경고를 중단합니다. 이 도메인으로 발송할 수는 있지만 TrekMail에 편지함을 만들 수는 없습니다.

2. 허용된 발신자를 위한 SPF 레코드

호스트: @

필수 include: include:spf.trekmail.net

SPF(Sender Policy Framework)는 도메인을 대신해 발송할 수 있는 IP 주소와 서비스 목록입니다.

• SPF가 없다면: 값이 v=spf1 include:spf.trekmail.net -all인 TXT 레코드를 만드세요.
• SPF가 이미 있다면: 기존 레코드에 TrekMail include를 추가하고 현재 사용 중인 끝맺음 메커니즘은 유지하세요.
  • 잘못된 예: TXT 레코드를 두 개로 나눕니다.
  • 올바른 예: v=spf1 include:spf.google.com include:spf.trekmail.net -all
  • 이것도 올바름: v=spf1 include:spf.google.com include:spf.trekmail.net ~all

끝맺음 메커니즘 안내: TrekMail은 -all과 ~all을 모두 허용합니다. include:spf.trekmail.net이 선택한 끝맺음보다 앞에 있으면 됩니다. 합법적인 모든 발송 서비스를 아직 파악하는 중이라면 ~all을 신중한 임시 설정으로 사용하세요. 모든 서비스를 SPF에 포함한 뒤에만 -all로 전환합니다. 전달된 메일은 별개의 문제이며 어느 설정에서도 SPF가 깨질 수 있습니다. 이 때문에 DKIM 정렬이 중요합니다. ?all과 +all은 허용하지 않습니다. ?all은 SPF를 게시하지 않은 것과 같고 +all은 누구에게나 발송을 허용합니다.

SPF 실패 안내: DMARC 보고서에서 SPF는 실패했지만 DKIM은 통과한 경우라면 흔히 정상적인 상황입니다. Gmail 자동 전달처럼 메일이 전달되었거나 보안 게이트웨이를 거쳤을 가능성이 큽니다. DKIM이 정렬되어 있으면 DMARC는 여전히 통과해야 합니다. SPF와 DKIM이 모두 실패할 때만 조사하세요.

3. 디지털 서명을 위한 DKIM 레코드

호스트: dkim._domainkey

값: v=DKIM1...으로 시작하는 도메인 전용 긴 문자열

DKIM(DomainKeys Identified Mail)을 사용하면 수신 서버가 서명한 도메인과 메시지에서 서명으로 보호된 부분을 확인할 수 있습니다.

• 키 생성: 값에 '생성 중...'이 표시되면 대시보드에 키가 나타날 때까지 기다리세요. 그런 다음 표시된 호스트와 값을 정확히 게시하고 DNS 확인을 실행합니다.
• 형식: Route 53과 같은 일부 DNS 제공업체는 값을 따옴표로 묶인 여러 조각으로 나누도록 요구합니다. 대부분은 전체 문자열을 받습니다. 대시보드에 보이는 그대로 붙여 넣으세요.
• 같은 이름의 레코드가 이미 있나요? 다른 서비스도 이 도메인의 메일에 서명한다는 뜻입니다. 기존 레코드를 바꾸지 마세요. 일반적인 이름이 사용 중이면 TrekMail이 다른 선택자로 키를 만들고 DNS 탭에 정확한 이름을 표시합니다. 두 키는 함께 사용할 수 있습니다.
• 외부 SMTP를 사용하나요? 외부 제공업체가 다른 선택자의 자체 DKIM 레코드를 요구할 수 있습니다. 그 제공업체가 준 레코드도 게시하세요. TrekMail 키만으로 외부 제공업체의 메일이 DKIM을 통과하지는 않습니다.

4. 정책을 적용하는 DMARC 레코드

호스트: _dmarc

값: v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

DMARC는 SPF와 DKIM의 검사 결과를 함께 사용합니다.

• 정책(p):
  • none: 모니터링만 합니다. 합법적인 발신자를 아직 모두 확인하지 못했다면 여기서 시작하세요.
  • quarantine: 검사에 실패한 메일을 의심스러운 것으로 처리하도록 수신 서버에 요청합니다. TrekMail의 기본 템플릿입니다.
  • reject: 검사에 실패한 메일을 거부하도록 수신 서버에 요청합니다. 보고서를 검토하고 정렬 상태를 확인한 뒤에만 이 정책으로 전환하세요.
• TrekMail 확인 방법: v=DMARC1을 포함한 유효한 레코드라면 인식합니다. 보고서 수신 주소를 정하는 rua 같은 태그는 필요에 맞게 바꿀 수 있습니다.

새 도메인에서 TrekMail만 발송한다면 대시보드의 p=quarantine 템플릿이 실용적인 시작점입니다. Google Workspace, Microsoft 365, 고객 지원 도구나 다른 서비스도 같은 도메인으로 발송한다면 p=none부터 시작하세요. 보고서를 검토하면서 정책을 단계적으로 강화해야 정상 메일이 실수로 격리되는 일을 피할 수 있습니다.

5. 권장 고급 배달 보호

다음 레코드는 기본 메일 흐름에 필수는 아니지만 보안과 배달 보고를 개선하므로 추가를 권장합니다. 자세한 내용은 권장 DNS 레코드 안내를 확인하세요.

TLS 보고(TLS-RPT)

호스트: _smtp._tls

값: v=TLSRPTv1; rua=mailto:tlsrpt@trekmail.net

• 용도: 다른 메일 서버가 도메인에 연결할 때 발생한 암호화 실패를 보고할 수 있습니다.

MTA-STS

MTA-STS 정책(TXT):

호스트: _mta-sts

값: 대시보드에 표시된 v=STSv1; id=... 값을 정확히 복사하세요. 게시된 정책이 바뀌면 ID도 바뀝니다.

MTA-STS CNAME:

호스트: mta-sts

값: mta-sts.trekmail.net.

• 용도: 수신 메일에 엄격한 TLS 암호화를 적용하고 다운그레이드 공격을 방지합니다.

자주 발생하는 문제와 해결 방법

• 증상: SPF 상태가 '충돌'로 표시됩니다.
  • 해결: v=spf1으로 시작하는 TXT 레코드가 여러 개인지 확인하세요. SPF 레코드는 하나만 둘 수 있습니다.
• 증상: DNS 변경 사항이 나타나지 않습니다.
  • 가능한 원인: DNS 제공업체의 게시와 각 확인자의 캐시 갱신에는 시간이 걸릴 수 있습니다.
  • 해결: DNS 제공업체에서 유형, 호스트, 값, MX 우선순위를 확인하세요. 변경 사항이 게시된 후 다시 검사를 실행합니다.