이메일 DNS 자동 설정: 승인과 토큰 사용법

이메일 DNS 설정에는 보통 여섯 개나 일곱 개의 레코드가 필요합니다. 긴 문자열도 여럿 있어 한 글자만 틀려도 단순한 오타로는 보이지 않는 장애가 생깁니다. DKIM 키는 수백 글자의 base64 문자열입니다. SPF 레코드는 순서가 중요한 메커니즘을 나열하고, 마지막 지정에 따라 정책의 의미도 달라집니다. DMARC에 사용하는 하위 도메인 이름도 처음에는 잘못 입력하기 쉽습니다.

도메인 하나를 설정할 때는 별문제 없을 수 있습니다. 고객 도메인 마흔 개를 관리하면 실수를 놓칠 가능성이 커집니다. 한 달 뒤 청구서가 스팸함에 들어가고 나서야 발견할 수도 있습니다.

자동 설정을 사용하면 값을 일일이 옮겨 적지 않아도 됩니다. 방법은 두 가지입니다. 단일 도메인은 DNS 제공업체에서 변경을 승인한 뒤 토큰을 전달하지 않고 TrekMail로 돌아올 수 있습니다. 여러 도메인은 권한을 제한한 API 토큰으로 백 개 규모까지 여러 배치로 나누어 설정할 수 있습니다. 두 방법 모두 적용 전에 변경 사항을 확인할 수 있습니다.

이메일에 필요한 DNS 레코드는 무엇인가

레코드	유형	역할	필수 여부
MX	MX	수신 이메일을 전달할 서버를 지정	설정한 메일 서비스로 수신을 연결하려면 필요
SPF	도메인 루트의 TXT	RFC 7208에 따라 SMTP 봉투 발신자 도메인의 송신 서버를 허용	SPF 인증에 필요
DKIM	선택자 이름의 TXT	발신 이메일의 서명을 검증할 공개 키를 제공	많은 발송 환경에서 필요
DMARC	`_dmarc`의 TXT	SPF와 DKIM 중 어느 것도 도메인 정렬을 충족해 인증에 성공하지 못할 때의 정책과 보고서 수신처를 지정	많은 발송 환경에서 필요
MTA-STS	TXT + 호스팅한 정책 파일	지원하는 송신 서버가 수신 서버로 전달할 때 공개 정책에 따라 TLS를 사용하도록 요구	권장
TLS-RPT	`_smtp._tls`의 TXT	TLS와 관련된 전달 문제의 보고서를 요청	권장
autoconfig / autodiscover	CNAME	지원하는 메일 앱이 주소를 바탕으로 설정 정보를 찾도록 지원	선택 사항이며 지원 문의를 줄이는 데 도움

“많은 발송 환경에서 필요”하다는 말은 RFC가 모든 도메인에 DKIM과 DMARC를 의무화한다는 뜻이 아닙니다. Google과 Yahoo는 2024년에 대량 발신자 요구 사항을 도입했지만, 실제 적용은 발신자 범주와 현행 규칙에 따라 달라집니다. 기업 수신 시스템도 자체 요구 사항을 둘 수 있습니다. 이 레코드가 없다고 모든 발송이 불가능해지는 것은 아니지만, 인증이나 수신 측의 메시지 수락에 불리할 수 있습니다.

수동 DNS 설정에서 흔한 네 가지 실수

SPF 레코드를 두 개 게시하기.흔하면서도 영향이 큰 실수입니다. 평가하는 이름에는 SPF 레코드가 하나만 있어야 합니다. 새 발송 서비스를 위해 두 번째 레코드를 추가해도 정책이 확장되지 않습니다. 프로토콜을 따르는 평가에서는 permerror가 나옵니다. 메커니즘을 하나의 레코드로 합쳐야 합니다. SPF 레코드 예시를 참고하세요.

붙여넣는 과정에서 DKIM 키 손상하기.2048비트 키의 문자열 표현은 TXT 문자열 하나당 255글자 제한을 넘습니다. 따라서 하나의 레코드 안에 여러 문자열을 넣고 읽을 때 연결해야 합니다. 일부 DNS 관리 화면은 이를 자동으로 처리하지만, 직접 분할해야 하는 곳도 있고 값을 잘라 버릴 가능성도 있습니다. 불완전한 키는 서명 검증을 막으며 원인이 바로 드러나지 않을 수 있습니다.

DMARC를 잘못된 이름에 게시하기.레코드는 _dmarc.example.com에 있어야 합니다. 루트에 넣으면 수신 서버가 해당 도메인의 DMARC 정책을 조회할 때 찾지 못합니다.

SPF 조회 한도 넘기기.SPF는 한 번의 평가에서 DNS 조회가 필요한 항목을 최대 열 개까지 허용합니다. 평가된 include:는 중첩된 포함 관계에서도 모두 계산됩니다. 메일 제공업체, CRM, 마케팅 도구와 고객 지원 시스템을 함께 쓰면 각각의 정책에 따라 한도를 넘을 수 있습니다. 그때 결과는 permerror입니다. 처음 설정한 뒤 몇 달이 지나 도구 하나를 더 추가하면서 문제가 생기기도 합니다. SPF DNS 조회 한도를 참고하세요.

자동화는 복사 실수를 줄이고 충돌을 발견하지만, 결과 검토를 대신하지는 않습니다. SPF 병합은 두 번째 레코드 생성을 피하게 해 줄 뿐, 최종 정책이 평가 한도를 지킨다는 증거는 아닙니다.

방법 1: 클릭으로 DNS 설정, 토큰 불필요

Cloudflare에서 DNS를 관리하는 단일 도메인이라면 직접적인 방법입니다. TrekMail에 API 토큰이나 계정 로그인 정보를 전달할 필요가 없습니다.

도메인의 DNS 및 상태 탭을 엽니다.
DNS 자동 설정을 클릭합니다.
Cloudflare에서 승인하기 전에 제안된 레코드 변경을 확인합니다.
승인을 클릭합니다.
TrekMail로 돌아오면 검증이 요청됩니다. 돌아왔다는 사실만으로 레코드가 올바르게 게시되었다고 확인할 수는 없습니다.

이 과정은 공개 프로토콜인 Domain Connect를 사용합니다. 서비스가 필요한 레코드를 설명하고, DNS 제공업체가 도메인 소유자에게 변경 내용을 보여 주면 소유자가 승인합니다. 재사용 가능한 API 토큰은 생성하거나 저장하지 않습니다. 승인은 해당 도메인에 제안된 작업을 대상으로 합니다.

도메인의 네임서버가 Cloudflare를 가리켜야 합니다. Cloudflare에서 도메인을 등록만 했고 DNS는 다른 곳에서 관리한다면 이 방법을 사용할 수 없습니다. 레코드는 실제 DNS 영역을 관리하는 제공업체에서 변경해야 합니다.

방법 2: 제한된 API 토큰으로 DNS 설정

여러 도메인을 설정하거나 Domain Connect를 사용할 수 없을 때는 토큰으로 계정의 허용된 영역을 설정할 수 있습니다.

Cloudflare에서 Edit zone DNS 템플릿으로 토큰을 만들고 Zone → DNS → Edit 권한을 지정합니다. 영역 리소스에서 전체를 허용하려면 All zones, 범위를 제한하려면 Specific zone을 선택합니다. IP 제한과 유효 기간이 예정된 사용을 허용하는지 확인하세요. 이유 없이 설정을 바꿀 필요는 없습니다. 표시된 토큰을 복사해 TrekMail에 붙여넣습니다.

중요한 것은 이 권한으로 할 수 있는 일과 할 수 없는 일입니다.

토큰으로 가능한 작업	토큰으로 불가능한 작업
선택한 영역의 DNS 레코드 읽기와 변경	네임서버 변경
	청구, WAF, 페이지 규칙, Workers 또는 SSL 설정 관리
	도메인 이전 또는 삭제
	허용 대상에 포함하지 않은 영역 접근

TrekMail은 토큰을 암호화해 저장하고 그 값을 로그에 남기지 않도록 합니다. TrekMail에서 도메인 연결을 해제하거나 Cloudflare에서 토큰을 폐기해 이후 요청을 차단할 수 있습니다. 다만 도메인 하나의 연결을 해제해도 다른 도메인과 공유하는 토큰까지 폐기되는 것은 아닙니다. 토큰 폐기는 이미 적용된 변경을 되돌리지도 않습니다.

연결 후에는 사용 가능한 Cloudflare 영역과 예정된 작업이 표시됩니다. TrekMail 계정에 이미 있는 도메인은 DNS 설정, 같은 과정에서 추가하고 설정할 도메인은 추가 + DNS로 표시됩니다. Cloudflare 밖에서 DNS를 관리하는 도메인은 이 연동으로 설정할 수 있는 영역에 나타나지 않습니다.

변경 미리보기와 다섯 가지 상태

설정을 적용하기 전에 각 레코드를 확인할 수 있습니다. 미리보기는 다섯 가지 상태를 사용합니다.

상태	의미	결정이 필요한가
추가 예정	레코드가 없어 생성을 제안	해결할 충돌 없음
병합 예정	기존 SPF 메커니즘을 유지하면서 TrekMail을 추가	해결할 충돌 없음
설정됨	예상한 값이 이미 존재	해결할 충돌 없음
교체 예정	다른 DMARC 정책이나 이전 제공업체를 가리키는 autodiscover CNAME 등 기존 값과 충돌	필요: 교체 또는 유지 선택
건너뜀	레코드 선택을 해제함	이미 선택함

각 레코드에는 확인란이 있습니다. MX와 SPF를 먼저 적용하고 DKIM은 나중에 설정하거나, 다른 방법으로 관리하는 레코드를 제외할 수 있습니다. 선택하지 않은 레코드는 해당 작업에서 적용되지 않습니다.

충돌은 내용을 읽고 결정하세요. DMARC 정책 p=none은 잘못된 설정이 아니라 의도적인 모니터링 단계일 수 있습니다. 보고서를 보기 전에 p=quarantine으로 바꾸면 아직 올바르게 인증되지 않는 정상 메일이 영향을 받을 수 있습니다. 필요하면 유지하고, 도입을 마친 뒤 정책을 강화하세요. 기준은 DMARC 정책 선택에서 설명합니다.

기존 SPF 레코드를 병합하는 이유

SPF는 하나의 정책으로 여러 발송 서비스를 허용할 수 있어 특히 주의해야 합니다. 사용 중인 서비스를 확인하지 않고 레코드를 교체하면 아직 필요한 권한을 제거할 수 있습니다.

도메인이 이미 다음 값을 게시한다고 가정해 보겠습니다.

v=spf1 include:_spf.google.com ~all

이 정책은 Workspace나 이를 통해 보내는 도구 등 Google 인프라를 허용합니다. TrekMail만 포함한 레코드로 바꾸는 것은 발신자를 추가하는 데 그치지 않고 이전 허용을 제거합니다. 그 권한에 의존하던 이메일은 이후 SPF 검증에 실패할 수 있습니다.

따라서 기존의 유효한 SPF 레코드는 보통 다음처럼 병합합니다.

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

두 서비스가 하나의 레코드에서 계속 허용되고 마지막 한정자도 유지됩니다. 이전 허용을 없애지 않고 TrekMail을 추가하는 방식입니다. 그렇다고 절대 교체하지 않는다는 뜻은 아닙니다. 중복되거나 형식이 잘못된 SPF는 충돌 해결이 필요할 수 있으며, 최종 정책도 검토해야 합니다.

이후 두 가지를 확인하세요. 새 include:는 DNS 조회가 필요한 열 개 항목 한도에 포함되고 중첩 조회를 일으킬 수 있으므로 전체 정책을 평가해야 합니다. 이전 제공업체가 실제로 더 이상 도메인 메일을 보내지 않는다면 확인 후 수동으로 허용을 제거하세요. 활동이 없는 기간만으로 서비스가 중단되었다고 판단할 수는 없습니다.

DNS 일괄 설정

모든 영역에 권한이 있는 토큰을 사용하면 마법사가 지원 도메인을 처리하고, 새 도메인을 추가하고, DNS를 설정한 뒤 도메인별 결과를 보여 줄 수 있습니다. 배치당 최대 50개입니다. 새 도메인은 요금제 한도에 포함됩니다. 원문에 설명된 설정에서는 Nano가 10개, Starter가 50개, Pro가 100개, Agency가 1,000개입니다. 시작 전에 계정의 현재 한도를 확인하세요.

도메인 열두 개를 가진 고객을 받는 대행사라면 일괄 처리로 수동 작업을 많이 줄일 수 있습니다. 그만큼 미리보기도 중요해집니다. 열두 도메인 중 두 개는 DMARC 정책이 충돌하고, 하나는 autodiscover CNAME이 2023년에 떠난 이전 제공업체를 가리키는 상황을 생각해 보세요. 무엇을 확인해야 하는지 보여 주는 예시이지, 발생 빈도를 보장하는 수치는 아닙니다.

변경의 영향 범위

앱에 DNS 쓰기 권한을 주기 전에 영향 범위를 묻는 것은 당연합니다.

연동은 이메일 레코드를 관리하도록 설계되었습니다. 대상은 MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT와 메일 자동 설정용 CNAME입니다. A 레코드, 웹사이트 CNAME, 다른 서비스의 TXT는 변경하지 않는 것이 의도된 동작입니다. 하지만 토큰의 DNS 편집 권한은 허용된 영역의 레코드에 적용되며 이메일용으로만 제한되지 않습니다. 다른 레코드의 보존은 앱 동작에도 달려 있습니다. 이 권한으로 네임서버를 변경할 수는 없습니다.

충돌 레코드를 교체하면 이전 설정을 잃을 수 있어 확인이 필요합니다. 다른 변경과 작업에 수반되는 중복 레코드 정리도 살펴보세요. 나머지 작업이 모두 영향 없는 것은 아닙니다. 복원이 필요하다면 이전 값을 저장해 두세요.

검증 대기는 DNS 캐시 때문일 수 있지만 잘못된 값이나 미완료 작업 때문일 수도 있습니다. 원문은 최대 48시간을 언급하지만 보편적인 기한은 아닙니다. TTL과 제공업체 상황에 따라 달라집니다. 검증은 자동으로 반복되며 DNS 검증을 눌러 재확인을 요청할 수도 있습니다. 다음 날에도 실패하면 게시된 값을 확인하고, 서명 문제라면 DKIM 문제 해결을 참고하세요.

자주 묻는 질문

클릭으로 설정하려면 Cloudflare 계정이 필요한가요?

Cloudflare가 도메인 DNS를 관리해야 하며 변경을 승인할 수 있는 계정 접근 권한이 필요합니다. TrekMail에 API 토큰을 줄 필요는 없습니다. Cloudflare 화면에서 작업을 승인하고, 재사용 가능한 토큰은 저장하지 않습니다.

DNS가 Cloudflare 밖에 있다면 어떻게 하나요?

이 자동 연동으로는 다른 제공업체를 설정할 수 없습니다. 레코드를 수동으로 만드세요. 도메인 DNS 페이지에 값과 복사 버튼이 있으며, 제공업체별 절차는 주요 제공업체의 DNS 설정에서 확인할 수 있습니다.

자동 설정이 웹사이트에 영향을 줄 수 있나요?

연동은 이메일 레코드를 변경하고 A 레코드, 사이트 CNAME, 무관한 TXT를 유지하도록 설계되었습니다. 다만 토큰이 기술적으로 해당 레코드를 편집하지 못한다는 뜻은 아닙니다. 권한은 허용된 영역의 DNS 레코드 전체에 적용됩니다. 제안된 변경을 확인하세요. 설명된 권한으로 네임서버를 바꿀 수는 없습니다.

기존 SPF 레코드는 어떻게 되나요?

보통 병합되어 TrekMail include가 추가되고 한정자는 유지됩니다. 다른 발송 서비스의 허용을 실수로 없애지 않기 위한 방식입니다. 중복이나 형식 오류가 있으면 확인을 거친 교체가 필요할 수 있습니다. 최종 정책의 조회 한도도 확인하세요.

일부 레코드만 적용할 수 있나요?

네. 미리보기의 각 레코드에 확인란이 있습니다. 다른 방법으로 관리하는 레코드는 선택을 해제하면 이번 작업에서 제외됩니다.

한 번에 도메인을 몇 개 설정할 수 있나요?

배치당 최대 50개이며 요금제의 전체 도메인 한도 안에서 가능합니다. 마법사가 추가한 새 도메인도 한도에 포함됩니다.

API 토큰은 보호되나요?

TrekMail은 암호화해 저장하고 값이 로그에 남지 않도록 합니다. 설명된 권한으로 선택한 영역의 DNS는 편집할 수 있지만 청구, WAF, 네임서버 또는 도메인 이전은 관리할 수 없습니다. Cloudflare에서 폐기하면 이후 요청을 막을 수 있으나 이전 변경은 되돌리지 않습니다. 필요한 영역만 허용하세요.