예전에 추가하던 sip·lyncdiscover CNAME과 SRV 레코드 2개, 지금도 필요한가요?

거의 확실히 필요 없습니다. 그 네 개 — CNAME sip·lyncdiscover와 SRV _sip._tls·_sipfederationtls._tcp — 는 Skype for Business Online용이었고, 마이크로소프트는 2021년 7월 31일에 이 서비스를 종료했습니다. Teams만 쓰는 테넌트라면 하나도 필요 없고, 존에 없어도 Teams는 정상 작동합니다. 아직 의미가 있는 경우는 Skype for Business Server 하이브리드가 남아 있거나, Skype for Business를 계속 쓰는 파트너와 페더레이션하는 상황뿐입니다. 그게 아니라면 아예 넣지 마세요. 마이크로소프트가 DNS 레코드 페이지에서 이 레거시 시나리오용으로 여전히 '선택'으로 안내하기 때문에 튜토리얼과 일부 등록기관의 '마이크로소프트365 레코드 추가' 버튼이 계속 발행하는 것뿐입니다 — 쓰지도 않는 레코드는 소음이고, SRV의 경우 나중에 문제를 추적할 때 혼선만 더합니다.

도메인 인증은 됐는데 Outlook에서 메일이 안 들어옵니다. 왜죠?

인증과 라우팅은 별개의 작업이고, TXT 인증 레코드는 메일 흐름에 아무 일도 하지 않습니다. MS=ms... TXT는 도메인 소유만 증명해 관리 센터가 도메인을 추가하도록 허용할 뿐입니다. 메일은 MX가 .mail.protection.outlook.com을 가리켜야, 그리고 이전 공급자의 MX가 사라져야 Exchange Online으로 들어오기 시작합니다. '인증됐는데 메일 없음'의 전형은 split-MX입니다 — 마이크로소프트365 MX는 켜졌는데 예전 호스트의 MX가 그대로 남아, 보내는 서버가 둘 중 아무거나 골라 넣고 메일 절반이 아무도 안 여는 사서함으로 떨어집니다. 마이크로소프트가 아닌 MX를 전부 지우고, mail.protection.outlook.com 호스트 하나만 남았는지 확인한 뒤, 뭔가 고장났다고 판단하기 전에 DNS를 최대 72시간 기다리세요.

DKIM CNAME이 contoso-com처럼 깨진 주소를 가리키는데 정상인가요?

깨진 게 아니라 점을 하이픈으로 바꾼 당신 도메인이고, MX 레코드에 나오는 바로 그 토큰입니다. 마이크로소프트는 DKIM 타깃을 selector1- ._domainkey. .onmicrosoft.com으로 만듭니다. 예를 들어 테넌트가 example.onmicrosoft.com인 도메인 example.com이면 selector1._domainkey는 selector1-example-com._domainkey.example.onmicrosoft.com으로 가는 CNAME이고, selector2는 2만 바뀐 같은 모양입니다. 이 CNAME들은 실제 공개키를 발행하는 마이크로소프트 호스팅 레코드를 가리키고, 그래서 마이크로소프트가 당신이 DNS를 다시 건드리지 않고도 키를 교체할 수 있습니다. 다만 CNAME 두 개를 발행하는 건 절반일 뿐 — Defender 포털에서 DKIM 서명을 켜지 않으면 레코드는 풀려도 아무것도 서명하지 않습니다.

마이크로소프트365 도메인 연결 MX·SPF·DKIM

무엇을 설정하는가

도메인을 마이크로소프트365에 연결하는 건 순서대로 들어가야 하는 짧은 DNS 레코드 목록이고, 하루가 사라지는 지점이 바로 그 순서다. 먼저 도메인 소유를 증명한다(TXT). 그다음 받는 메일을 Exchange Online으로 보낸다(MX 하나). 그다음 나머지 인터넷이 스팸으로 떨어지지 않고 당신으로서 메일을 보내게 허용한다(SPF·DKIM). 순서를 뒤집거나, 마이크로소프트 MX를 추가하면서 옛 메일 호스트를 지우지 않으면 전형적인 증상에 걸린다 — 관리 센터는 도메인이 정상이라는데 메일은 딴 데로 간다.

여기에 더해, 마이크로소프트가 예전에 쥐여주던, 이제는 거의 확실히 필요 없는 레코드 한 무더기가 있다. 뒤에서 다룬다. 엉뚱한 걸 발행하는 것도 오후 하나를 날리는 방법이니까.

1단계: 도메인 소유 증명 (TXT)

마이크로소프트365가 도메인 메일을 켜주기 전에, DNS를 당신이 통제한다는 증거를 요구한다. 관리 센터는 MS=ms 뒤에 숫자가 붙은 인증값을 주고, 당신은 그걸 도메인 루트(호스트 @ 또는 공란 — www도 서브도메인도 아님)에 TXT 레코드로 발행한다.

여기서 두 가지에 걸린다:

루트에 TXT 하나다. 서브도메인마다 따로 만들 필요 없고, 지어낼 것도 없다 — 관리 센터가 보여주는 MS=ms… 값을 그대로 붙여넣는다.
전파는 실재한다. 추가한 뒤 마이크로소프트 체커가 몇 분에서 두어 시간 못 볼 수 있다. 처음에 인증 실패하면 레코드를 또 넣지 말고 기다렸다 다시 확인하라.

구글 인증 TXT와 달리 마이크로소프트의 MS=ms…는 초기 소유 확인에만 필요하다 — 도메인이 인증되면 남겨도, 지워도 아무것도 깨지지 않는다. 남겨두는 비용이 없으니 대개 그냥 둔다.

2단계: Exchange Online으로 메일 라우팅 (MX)

실제로 메일을 배달하는 단계이고, 진짜 실패가 사는 곳이다. MX 레코드는 정확히 하나이고, 그 타깃은 당신 도메인 이름에서 점을 하이픈으로 바꿔 만든다:

# example.com  →  example-com.mail.protection.outlook.com
example.com.   3600   IN   MX   0   example-com.mail.protection.outlook.com.

preference 숫자는 0 — 가장 낮은 숫자, 가장 높은 우선순위다. 일부 등록기관은 preference 칸에 0을 못 넣게 하는데, 허용되는 가장 낮은 값(보통 1)을 쓰면 MX가 하나뿐이라 똑같이 동작한다. 정확한 <도메인키>.mail.protection.outlook.com 호스트는 관리 센터의 도메인 DNS 목록에 나오니 토큰을 추측하지 말고 복사하라.

split-MX 함정

‘마이크로소프트365가 메일을 못 받는다’의 가장 흔한 원인은 틀린 마이크로소프트 값이 아니라 옛 값이 그대로 있는 것이다. Exchange Online MX를 추가하고 이전 호스트의 MX를 안 지우면, 도메인이 메일 목적지 두 개를 광고한다. 인터넷의 모든 보내는 서버가 preference 숫자와 각자의 재시도 논리로 하나를 고르는데, 그 선택이 일정하지 않다. 어떤 메일은 Exchange Online으로, 어떤 건 아무도 안 들어가는 옛 사서함으로 가고, DNS 캐시가 만료되며 그 비율이 흔들린다. 더 나쁘게는, 경쟁 MX가 있으면 Exchange Online Protection이 당신 도메인을 권위(authoritative) 아님으로 판단해 반송 처리를 그르칠 수 있다. 마이크로소프트 MX가 작동하는 걸 확인한 순간, 도메인의 다른 MX를 전부 지워라. 유일한 예외는 의도적으로 설계한 하이브리드나 서드파티 게이트웨이 메일 흐름인데, 그런 걸 운영한다면 설정 가이드를 읽고 있지 않을 것이다.

3단계: 보낼 권한 부여 (SPF 먼저, 그다음 DKIM)

받는 건 끝났다. 이제 나가는 메일이 정크로 떨어지는 걸 막는다.

SPF는 루트에 있는 TXT 하나로, 수신자에게 마이크로소프트 서버가 당신을 위해 보낼 수 있다고 알린다:

example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

여기 함정은 조용하고 치명적이다: 도메인은 SPF 레코드를 하나만 발행할 수 있다. 이미 다른 서비스용 SPF가 있으면 두 번째 v=spf1 줄을 추가하지 마라 — SPF 레코드 두 개는 permerror라 SPF 전체가 실패한다. 병합한다: 레코드 하나를 유지하고 그 안에 이미 있던 것 옆에 include:spf.protection.outlook.com을 더한다.

DKIM은 CNAME 레코드 두 개인데, 타깃에 점을 하이픈으로 바꾼 당신 도메인이 들어 있어 처음 보면 놀란다:

selector1._domainkey.example.com.   3600   IN   CNAME   selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.   3600   IN   CNAME   selector2-example-com._domainkey.example.onmicrosoft.com.

example.onmicrosoft.com은 테넌트의 원래 가입 도메인이니 당신 걸로 바꾼다. 셀렉터가 둘인 이유는 마이크로소프트가 어느 쪽을 활성화할지 바꾸는 식으로 당신이 DNS를 다시 건드리지 않고 키를 교체하기 위해서다. 사람들이 잊는 마지막 단계: CNAME이 풀린 뒤, Microsoft Defender 포털에 들어가 그 도메인의 DKIM 서명을 켜야 한다. 스위치를 안 올리고 CNAME만 발행하면 아무것도 서명하지 않는다.

메일 인증 레코드를 만지는 김에 시작용 DMARC도 발행하라 — _dmarc TXT, 집행 전에 지켜볼 수 있게 리포트 주소와 함께 p=none으로 시작:

_dmarc.example.com.   3600   IN   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none으로 시작해 리포트를 읽고, 그다음에야 quarantine·reject로 올라간다. 당신으로서 보내는 시스템을 전부 알기 전에 곧장 reject로 뛰는 게 자기 청구서를 격리하는 길이다.

Skype/SIP 레코드는 건너뛰어라

옛날 마이크로소프트365 설정 안내 — 그리고 일부 등록기관의 ‘Office 365 레코드 추가’ 버튼 — 는 아직도 네 개를 더 발행한다: CNAME sip·lyncdiscover, SRV _sip._tls·_sipfederationtls._tcp. 이것들은 Skype for Business Online용이었고, 마이크로소프트는 2021년 7월 31일에 종료했으며 그 인프라를 2022년부터 해체하기 시작했다. Teams만 쓰는 테넌트는 하나도 필요 없고, 빼도 메일이나 Teams에 아무 변화가 없다. 남길 이유는 살아남은 Skype for Business Server 하이브리드나, Skype for Business를 아직 돌리는 파트너와의 페더레이션뿐이다. 그게 당신 세계가 아니라면 발행하지 마라 — 쓰지 않는 SRV 레코드는 나중에 디버깅할 때 잘못 읽을 거리만 늘린다.

DechoNet으로 진단

이메일 점검은 수신 서버가 보는 방식으로 도메인의 MX·SPF·DKIM을 읽는다 — Exchange Online MX가 유일한 MX인지(split-MX 잔재 포착), SPF가 spf.protection.outlook.com을 담은 유효한 레코드 하나인지, DKIM 셀렉터 둘이 다 풀리는지를 한 번에 확인한다.
DNS 점검은 개별 레코드를 따로 조회한다. MS=ms… TXT가 루트에 살아 있는지, selector1._domainkey.example.com이 …onmicrosoft.com으로 가는 CNAME을 돌려주는지 확인하는 데 쓴다.

확인 체크리스트

dig MX example.com +short가 …mail.protection.outlook.com만 보이고 이전 공급자 것은 없다.
SPF 레코드가 정확히 하나이고 include:spf.protection.outlook.com을 담는다.
dig CNAME selector1._domainkey.example.com +short와 selector2._domainkey.example.com이 둘 다 …onmicrosoft.com 타깃을 돌려준다.
DKIM 서명이 DNS 발행만이 아니라 Defender 포털에서 켜져 있다.
_dmarc TXT 레코드가 p=none으로 시작하며 존재한다.
실제로 Skype for Business 하이브리드를 돌리지 않는 한 sip/lyncdiscover CNAME과 SIP SRV 레코드를 발행하지 않았다.
뭔가 고장났다고 결론 내리기 전에 TTL / 최대 72시간을 기다렸다.

DNS 문제가 아닐 때

MX가 유일한 MX이고, SPF가 하나이며 맞고, DKIM이 풀리고 켜져 있는데 — 메일이 여전히 말썽이면 — DNS는 제 몫을 다했고 문제는 마이크로소프트365 안으로 옮겨간 것이다: 라이선스가 없는 사서함, Exchange 관리 센터의 메일 흐름 규칙이나 커넥터, 추가만 하고 기본으로 설정 안 한 도메인. 그 지점부터는 DNS의 레코드 문제가 아니라 관리 센터 안의 계정·라우팅 문제다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.