소유한 도메인에 대해 브랜드 번호이동 도구 도메인과 인증된 이메일 발신을, MultiTEL이 귀하의 서비스에 대해 확인하는 호스트 이름과 DNS 값을 사용하여 설정하세요. 이러한 설정은 전화번호 이전과는 별개입니다.
이 설정의 용도
자체 브랜드(화이트 라벨) 번호이동 도구를 사용하면 자체 브랜드로 번호 이전 요청을 표시할 수 있으며, 구성된 경우 자체 이메일 도메인을 대신하여 요청 이메일을 보낼 수 있습니다. 이 가이드의 DNS 변경은 해당 브랜드 웹사이트와 이메일 식별 정보에 적용됩니다. 이러한 변경은 일반 전화번호 이전의 요건이 아니며 전화번호의 음성 라우팅을 변경하지 않습니다.
DNS를 변경할 도메인을 소유하고 제어해야 합니다. 소유하지 않은 타사 무료 메일 도메인의 주소에는 이러한 레코드를 구성할 수 없습니다.
DNS를 변경하기 전에 브랜드 서비스 확인
Number portability(번호이동)를 여세요. 그곳의 브랜딩 필드를 사용하여 해당 화면의 요청에 사용되는 브랜드 이름과 로고를 설정하세요. 사용자 지정 도메인 자체 브랜드(화이트 라벨) 사이트의 경우, DNS 레코드를 게시하기 전에 MultiTEL 지원에 귀하의 계정에 어떤 브랜드 설정이 적용되는지, 호스트 이름, 게시할 DNS 값, 발신자 도메인, HTTPS 인증서 설정을 확인하도록 요청하세요.
번호이동 요청을 브랜드화하기 위해서만 기존 프로덕션 웹사이트를 리디렉션하거나 기존 메일 전달을 변경하지 마세요. 필요할 때 복원할 수 있도록 이전 DNS 값을 기록해 두세요. 이후 변경이나 롤백의 더 빠른 전파가 필요한 경우, 영향을 받는 레코드의 TTL을 미리 낮추고 변경하기 전에 이전 TTL이 경과할 때까지 기다리세요. TTL을 낮춰도 기존에 캐시된 응답이 즉시 만료되지는 않습니다.
웹사이트 CNAME
MultiTEL이 귀하의 서비스의 사용자 지정 호스트 이름과 CNAME 대상을 확인한 후, DNS 공급자에서 요청된 CNAME을 만드세요. DNS 콘솔이 영역 이름을 자동으로 추가하는지 확인하고, 해당 콘솔의 지침에 따라 호스트 레이블 또는 전체 이름을 입력하되 도메인을 중복하지 마세요. 확인된 CNAME 호스트 이름에는 A, AAAA, MX 또는 TXT 레코드가 함께 있어서는 안 됩니다. 그곳에 다른 레코드가 이미 있는 경우, 변경하기 전에 어떤 서비스가 이를 사용하는지 확인하세요. 해당 이름이 여전히 다른 서비스를 제공하는 경우 MultiTEL이 승인한 다른 호스트 이름을 사용하고, 기존 레코드는 더 이상 필요하지 않음을 확인한 후에만 제거하세요.
다음은 예시일 뿐입니다. test123.com을 소유하고 MultiTEL이 porting.test123.com을 귀하의 호스트 이름으로, porting.multitel.net을 귀하의 서비스에 대한 CNAME 대상으로 모두 확인한 경우에 적용됩니다. 지원 담당자가 귀하의 서비스에 대해 이 대상을 확인하지 않는 한 이 대상을 사용하지 마세요:
porting.test123.com. IN CNAME porting.multitel.net.귀하의 서비스에 대해 확인된 정확한 대상을 사용하세요. CNAME만으로는 사용자 지정 도메인이 활성화되지 않으며, 유효한 HTTPS 인증서가 보장되지도 않습니다. 새 URL을 공유하기 전에 사이트의 인증서와 브랜드 요청 흐름을 확인하세요.
요청 이메일을 위한 SPF
MultiTEL이 요청 이메일이 귀하의 도메인을 대신하여 발송될 것이라고 확인하면, 지원 담당자에게 SPF에 사용되는 발신 도메인과 DKIM에 사용되는 서명 도메인을 식별해 달라고 요청하세요. 이들은 브랜드 웹사이트 호스트 이름일 필요는 없습니다. 확인된 SPF 도메인에 SPF를 게시하고, 아래에 설명된 셀렉터별 이름에 DKIM 공개 키를 게시하세요. 웹사이트 CNAME 호스트 이름에는 메일 인증 TXT 레코드를 추가하지 마세요. SPF 도메인의 정책에서 확인된 발신 서비스를 인가하세요. 여기에 표시된 MultiTEL SPF include는 include:_spf.multitel.net입니다. 지원 담당자가 귀하의 계정의 발신 서비스에 적용된다고 확인한 후에만 추가하세요.
도메인에 이미 SPF TXT 레코드가 있는 경우, 인가된 include를 그 기존 정책에 병합하세요. 다른 정당한 발신자와 의도한 최종 정책을 유지하고, 두 번째 SPF 레코드를 게시하지 마세요. 중첩된 include와 redirect를 포함한 전체 정책을 SPF의 DNS 조회 한도와 대조하여 확인하세요. SPF 평가는 include, a, mx, ptr, exists 및 redirect과 같은 DNS 조회를 유발하는 항목을 최대 10개까지 허용하며, 이 한도를 초과하면 permerror가 발생합니다. 깨진 SPF 정책은 정당한 메일이 SPF 인증을 통과하지 못하게 할 수 있습니다. 기존 정책이 없고 MultiTEL이 이것이 유일한 인가된 발신자임을 확인한 경우, 예시는 다음과 같습니다:
@ IN TXT "v=spf1 include:_spf.multitel.net ~all"요청 이메일을 위한 DKIM
서명 도메인에 대해 확인된 정확한 DKIM 셀렉터, DNS 레코드 이름, 공개 키 TXT 값을 게시하세요. DKIM DNS 이름은 셀렉터, _domainkey, 서명 도메인을 결합합니다. 예를 들어 example.com의 셀렉터 mail은 전체 레코드 이름 mail._domainkey.example.com을 만들며, mail._domainkey는 상대 레코드 이름이며 셀렉터가 아닙니다. 현재 값은 MultiTEL 지원에서 받으세요. 이전 문서, 다른 계정 또는 MultiTEL 자체의 DNS에서 복사한 셀렉터나 공개 키가 해당 계정에 사용되는 값이라고 가정하지 마세요. DKIM 공개 키는 DNS에 게시되며, 비공개 서명 키는 절대 요청하거나 게시해서는 안 됩니다.
DNS 콘솔이 영역 이름을 자동으로 추가하는지 확인하고, 레코드 이름에서 도메인 또는 _domainkey를 중복하지 마세요. DNS 콘솔이 긴 TXT 레코드를 따옴표로 묶인 청크로 분할하는 경우 전체 공개 키 값을 유지하세요.
전체 결과 확인
변경된 각 레코드에 대해 권한 있는 네임서버와 외부 리졸버를 조회하세요. 구성된 TTL과 DNS 캐시가 만료될 시간을 두세요. 캐시된 하나의 로컬 리졸버에서 나온 결과만으로는 충분하지 않습니다. 전체 도메인 이름이 포함된 레코드 이름(FQDN), 유형, 정확한 대상 또는 값, 따옴표, 후행 점을 확인된 지침 및 DNS 공급자의 입력 형식과 비교하세요. URL을 공유하거나 브랜드 이메일에 의존하기 전에 충돌하는 레코드, 잘못된 이름, 누락된 값, 유효하지 않은 인증서를 해결하세요.
확인된 브랜드 요청 URL을 열고 페이지가 유효한 인증서와 기대한 브랜드로 로드되는지 확인하세요. 어떤 테스트든 제출하기 전에 MultiTEL 지원에 어떤 테스트 흐름을 사용할 수 있는지, 제출이 실제 번호 이전을 시작하게 되는지 문의하세요. 지원 담당자가 귀하의 계정에 브랜드 이메일이 사용 설정되었음을 확인한 후, 실제 번호 이전을 시작하지 않도록 확인된 테스트 흐름과 지원 담당자가 제공하는 샘플 데이터 또는 테스트 절차로만 테스트하세요. 수신한 메시지의 SPF 및 DKIM 인증 결과를 검사하세요. 회신과 요청 링크가 의도한 목적지에 도달하는지 확인하세요. 대체가 검증될 때까지 이전 서비스와 레코드를 사용할 수 있는 상태로 유지하고, MultiTEL이 대체되었다고 확인한 레코드만 제거하세요.