Microsoft 365 / 회사 도메인을 등록하고 DNS 설정을 확인하는 방법
회사 도메인을 Microsoft 365에 연결하려면 먼저 도메인 소유권을 확인하고, 사용할 서비스에 맞는 DNS 레코드를 설정해야 합니다. 소유권 확인용 TXT 레코드와 메일을 Microsoft 365로 보내는 MX 레코드는 목적이 다릅니다. 기존 메일을 사용 중이라면 MX 변경 전에 사용자 사서함과 이전 계획을 준비하세요.
시작 전 준비할 정보
- 도메인을 등록한 업체와 실제 DNS 레코드를 관리하는 업체의 로그인 권한
- 현재 웹사이트, 메일, 외부 발송 서비스에서 사용하는 DNS 레코드 목록
- Microsoft 365에서 사용할 사용자 주소와 사서함 준비 상태
- 메일 전환 일시, 담당자, 테스트 주소, 문제가 생겼을 때 되돌릴 기준
도메인 등록 업체와 DNS 호스팅 업체는 다를 수 있습니다. 레코드를 잘못된 관리 화면에 추가하면 검증되지 않습니다. Microsoft의 사용자 지정 도메인 추가 안내는 Domain Connect 자동 설정과 수동 DNS 설정을 모두 설명합니다.
Microsoft 365에서는 도메인 추가 권한이 있는 역할을 준비합니다. DNS 업체 계정의 권한과 Microsoft 365 관리자 권한은 서로 별개이므로 두 곳 모두 접근할 수 있어야 합니다. 도메인을 구매한 업체에 로그인되더라도 네임서버가 다른 업체를 가리키면 실제 DNS 수정은 그 업체에서 해야 합니다.
작업 전 현재 레코드를 내보내거나 목록으로 보관하세요. 유형, 이름, 값, 우선순위, TTL을 함께 기록해야 복구할 수 있습니다. TTL(Time To Live)은 DNS 응답을 캐시에 보관하는 시간입니다. DNS 화면에 저장되었다고 모든 외부 이용자가 즉시 새 값을 조회하는 것은 아닙니다.
도메인 소유권 확인하기
- Microsoft 365 관리 센터의 [설정] → [도메인]에서 [도메인 추가]를 선택합니다. 메뉴가 접혀 있다면 [모두 표시]를 누릅니다.
- 추가할 도메인을 입력하고 안내된 소유권 확인 방법을 선택합니다. DNS를 수동 관리한다면 화면에 표시된 TXT 레코드의 호스트와 값을 정확히 복사합니다. Microsoft가 제시하는 값은 도메인마다 다르므로 예시 값을 그대로 넣지 마세요.
- DNS 호스팅 업체에서 해당 TXT 레코드를 추가합니다. 기존에 같은 호스트에 다른 TXT 레코드가 있다면 무작정 삭제하거나 덮어쓰지 말고 별개의 레코드로 추가할 수 있는지 확인합니다.
- 관리 센터로 돌아와 [확인]을 누릅니다. 바로 실패해도 DNS 반영 지연일 수 있으니 입력 값과 DNS 관리 위치를 먼저 확인하고 잠시 뒤 다시 시도합니다.
DNS 입력 칸을 잘못 해석하지 않으려면
아래 표의 값은 입력 방식 설명용입니다. 실제 TXT 검증 값이나 MX 대상을 만들어 쓰지 말고 관리 센터가 해당 도메인에 제시하는 값을 복사해야 합니다.
| 입력 칸 | 의미와 선택 기준 | 자주 생기는 오류 |
|---|---|---|
| 이름·호스트 | 도메인의 루트인지 특정 하위 이름인지 확인. 루트는 업체에 따라 @ 또는 빈칸 등으로 입력 | 업체가 도메인을 자동으로 붙이는데 전체 이름을 다시 입력해 도메인이 두 번 붙음 |
| 유형 | 소유 확인에는 안내된 TXT, 메일 수신 경로에는 MX 등 정확한 유형 사용 | TXT 값을 CNAME 대상에 넣는 등 유형을 혼동 |
| 값·대상 | 마법사가 제시한 문자열이나 서버 이름 | 공백·문자 누락, 다른 조직의 예시 값 재사용 |
| TTL·우선순위 | TTL은 캐시 시간, MX의 작은 우선순위 숫자는 더 높은 우선순위를 뜻함 | TXT에도 MX 우선순위를 적용하거나 이전 MX를 같은 우선순위로 방치 |
소유권 확인이 실패하면 실제 권한 있는 DNS에서 해당 이름의 TXT가 조회되는지 먼저 확인합니다. 다른 서비스의 소유 확인 TXT가 같은 이름에 있을 수 있으며, 이것을 지우는 방식으로 해결하지 않습니다. 이미 다른 테넌트에서 사용 중이라는 오류라면 DNS 지연과 다른 문제이므로 기존 연결과 도메인 소유 조직부터 확인해야 합니다.
메일과 기타 서비스 DNS 연결하기
소유권 확인만 마치면 메일 이전이 자동으로 끝나는 것은 아닙니다. Microsoft 365 설치 마법사는 선택한 서비스에 필요한 레코드를 제시합니다. 메일에 쓰는 MX, 클라이언트 자동 구성에 쓰는 CNAME, 발신 도메인 인증용 SPF·DKIM 관련 레코드는 각각 역할이 다릅니다. 필요한 레코드와 값은 테넌트 화면에서 확인하세요. Microsoft의 DNS 연결 절차도 이 순서를 안내합니다.
- 전환 전에 도메인으로 메일을 받는 모든 사용자와 공유 주소를 확인하고 Microsoft 365 사서함을 준비합니다.
- 설치 마법사에 표시된 서비스별 레코드를 검토합니다. 기존 발송 시스템이 있다면 SPF를 여러 개 만들지 말고 현재 구성과 통합 여부를 검토합니다.
- 메일 전환 시점을 정해 MX 레코드를 변경합니다. 이때부터 새 메일이 Microsoft 365로 들어올 수 있으므로 기존 메일 서버와의 전환 계획이 필요합니다.
- 관리 센터의 도메인 상태와 DNS 조회 결과를 확인하고, 조직 안팎에서 테스트 메일을 보내고 받습니다. 메일 도착만 보지 말고 발신 인증 결과도 확인합니다.
MX 변경 전후에 확인할 실제 결과
예를 들어 직원 20명과 대표 주소 2개를 이전한다면 직원 계정만 확인해서는 부족합니다. 모든 수신 주소와 별칭·공유 사서함을 목록으로 만들고, Microsoft 365 쪽에서 해당 주소로 받을 준비가 되었는지 확인해야 합니다. 기존 서버의 과거 메일을 옮기는 작업은 MX 변경과 별도입니다. MX를 바꿔도 이전 메일함의 내용이 자동으로 복사되지 않습니다.
- 전환 직전: 기존 MX와 웹사이트 레코드, 준비된 수신자 목록, 작업 시간을 대조합니다. 자동 설정을 쓰더라도 승인 화면에서 변경될 레코드를 읽고 기존 메일 경로가 바뀌는지 확인합니다.
- 전환 직후: DNS 조회에서 MX 대상과 우선순위가 계획과 같은지 확인하고 관리 센터에서 도메인 검사를 다시 실행합니다. DNS 검사가 통과해도 모든 사용자 사서함을 시험한 것은 아닙니다.
- 메일 시험: 외부 주소에서 직원·대표 주소로 각각 보내고 Microsoft 365에서도 외부로 회신합니다. 테스트 시각과 수신 주소를 남기고 배달 실패 알림이 있으면 보관합니다.
- 안정화 확인: 이전 서버에도 새 메일이 남는지 살펴봅니다. 캐시가 남은 발신 시스템은 한동안 기존 경로를 사용할 수 있으므로 이전 환경을 즉시 없애지 않습니다.
도착하지 않은 메일은 메시지 추적으로 경로를 확인하고, 발신 인증은 SPF·DKIM·DMARC 점검으로 이어서 조사합니다. 단순히 소유권 확인이 성공했다는 결과만으로 메일 이전을 완료 처리하지 마세요.
웹사이트도 Microsoft 365로 옮겨지나요?
아닙니다. 도메인을 Microsoft 365에 추가한다고 기존 웹사이트가 자동으로 이동하지는 않습니다. 다만 DNS 레코드를 잘못 바꾸면 웹사이트나 다른 서비스가 중단될 수 있습니다. 메일만 전환한다면 웹사이트의 A·AAAA·CNAME 레코드를 불필요하게 수정하지 마세요.
문제가 생기면 먼저 현재 DNS 레코드와 변경 전 기록을 비교합니다. MX를 이전 값으로 되돌려도 DNS 캐시 때문에 전환이 즉시 일치하지 않을 수 있으므로 두 메일 환경의 수신 상태를 함께 확인하세요. 복구 시에는 이번에 변경한 레코드만 변경 전 값으로 돌리고, 전환 중 어느 쪽에 도착한 메일이 있는지 대조합니다. DNS 복구가 두 사서함의 데이터를 합쳐 주지는 않습니다. 서비스 연결을 잠시 보류하려고 도메인이나 사용자를 삭제하는 방식도 피하세요.
