단일 smtp.google.com MX를 써야 하나요, 옛날 구글 MX 5개를 써야 하나요?

둘 다 되지만, 하나만 골라 그것만 쓰세요. 새로 만드는 워크스페이스 도메인은 MX 레코드 하나 — 우선순위 1의 smtp.google.com — 만 넣으면 되고, 구글도 지금은 이 방식을 권장합니다. 예전 구성은 5개였습니다: 우선순위 1의 ASPMX.L.GOOGLE.COM, 우선순위 5의 ALT1·ALT2.ASPMX.L.GOOGLE.COM, 우선순위 10의 ALT3·ALT4.ASPMX.L.GOOGLE.COM. 둘 다 같은 곳으로 배달합니다. 배달을 망가뜨리는 건 이 둘을 섞거나, 구글 MX 옆에 이전 호스팅 업체의 MX를 남겨두는 겁니다. 새 도메인이면 단일 smtp.google.com을 넣고, 이미 5개 세트로 잘 돌고 있다면 굳이 건드리지 마세요. 다만 두 방식을 함께 두지 말고, 전환 뒤엔 옛 호스팅 MX를 반드시 지우세요.

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

인증과 메일 라우팅은 별개의 단계라, 앞 단계를 통과해도 뒷 단계엔 아무 효과가 없습니다. TXT 인증 레코드는 구글에게 '이 도메인은 내 것'임을 증명해 서비스를 켤 수 있게 해줄 뿐입니다. 지메일로 메일이 흐르기 시작하는 건 MX 레코드가 구글을 가리키고 — 그리고 옛 MX 레코드를 지운 뒤 — 부터입니다. '인증은 됐는데 메일이 없다'의 가장 흔한 원인은 스플릿 MX입니다: 새 구글 MX는 살아 있는데 이전 업체의 MX도 여전히 게시돼 있어, 발송 서버가 둘 중 아무거나 골라 배달하면서 메일 절반이 아무도 안 보는 사서함으로 떨어집니다. 구글 것이 아닌 MX를 전부 지우고, 남은 게 구글 MX뿐인지 확인한 다음, 최대 72시간 전파를 기다린 뒤에 고장이라고 판단하세요.

구글이 도메인을 인증한 뒤 TXT 인증 레코드를 지워도 되나요?

아니요. 영구히 그대로 두세요. 구글은 주기적으로 도메인 소유를 재확인하는데, 인증 TXT 레코드가 사라지면 인증이 만료돼 다시 넣을 때까지 워크스페이스 서비스가 끊길 수 있습니다. 이 레코드는 그냥 도메인 루트에 있는 평범한 TXT 값이라 다른 무엇에도 영향을 주지 않으니 두는 게 무해합니다. 설정 중에 지우는 건 오직 이전 메일 업체의 *옛 MX 레코드*뿐이지, google-site-verification TXT는 절대 아닙니다. 나중에 DNS를 정리하다 이 값을 보더라도 지우고 싶은 충동을 참으세요 — 이건 하중을 떠받치는 레코드입니다.

구글 워크스페이스 도메인 연결: TXT 인증 후 MX

지금 설정하는 것

구글 워크스페이스에 도메인을 연결하는 건 순서가 정해진 세 가지 DNS 작업이고, 그 순서에서 하루가 날아갑니다. 먼저 도메인 소유를 증명하고(TXT 레코드), 그다음 수신 메일을 구글로 보내고(MX 레코드), 마지막으로 인터넷 나머지에게 구글이 당신 이름으로 메일을 보내도 된다고 알립니다(SPF·DKIM). 순서를 어기거나, 두 번째를 하면서 옛 메일 호스트를 안 지우면 전형적인 증상이 나옵니다: 관리 콘솔은 다 정상이라는데 메일은 딴 데로 떨어지는 거죠. 이 가이드는 그 순서와 정확한 값, 그리고 시간을 가장 많이 잡아먹는 두 함정입니다.

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

구글이 도메인에 지메일을 켜주기 전에, 당신이 DNS를 제어한다는 증거가 필요합니다. 관리 콘솔이 google-site-verification= 뒤에 긴 토큰이 붙은 고유 인증 문자열을 주고, 당신은 이걸 도메인 루트(에이펙스 — 호스트 칸은 @ 또는 공백, www나 서브도메인이 아님)에 TXT 레코드로 게시합니다.

여기서 걸리는 게 둘입니다:

루트에, 한 번만. 에이펙스에 TXT 레코드 하나면 됩니다. 서브도메인마다 따로 넣을 필요 없습니다.
전파는 실제로 걸립니다. 추가한 뒤 구글 체커가 몇 분에서 몇 시간 동안 못 볼 수 있습니다. 첫 시도에서 실패하면 레코드를 하나 더 넣지 말고 기다렸다 다시 확인하세요.

그리고 나중에 발목 잡는 규칙: 인증이 끝나면 TXT 레코드는 영원히 그대로 두세요. 구글이 주기적으로 재인증하므로 지우면 서비스가 중단될 수 있습니다.

2단계: 메일을 구글로 라우팅 (MX)

실제로 메일을 배달하는 단계이자, 진짜 고장이 사는 곳입니다. 유효한 선택지는 둘입니다:

# 현대식 — 단일 레코드 (새 도메인 권장)
example.com.   3600   IN   MX   1   smtp.google.com.

# 레거시 — 5개 레코드 (이미 잘 돌면 두세요)
example.com.   3600   IN   MX   1    ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   5    ALT1.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   5    ALT2.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   10   ALT3.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   10   ALT4.ASPMX.L.GOOGLE.COM.

한 가지 구성만 쓰고, 둘을 같이 쓰지 마세요. 우선순위 1의 단일 smtp.google.com이 구글이 지금 새 설정에 권장하는 값이고, 5개 세트는 옛 기본값이지만 여전히 작동합니다. 둘은 같은 인프라로 배달합니다 — 유일하게 잘못된 수는 둘을 함께 게시하거나, 더 나쁘게는 이전 업체의 남은 MX 옆에 두는 겁니다.

스플릿 MX 함정

‘워크스페이스가 메일을 못 받아요’의 가장 흔한 원인은 구글 값이 틀려서가 아니라 옛 값이 아직 거기 있어서입니다. 구글 MX를 추가하고 이전 호스트의 MX를 안 지우면, 이제 도메인이 두 개의 메일 목적지를 광고합니다. 인터넷의 모든 발송 서버가 우선순위 숫자와 자기 재시도 로직에 따라 고르게 되고, 그 선택은 안정적이지 않습니다. 어떤 메일은 지메일로, 어떤 메일은 이제 아무도 로그인 안 하는 옛 사서함으로 가고, 그 갈림은 DNS 캐시가 만료되면서 바뀝니다. 사용자는 메일이 ‘사라진다’고 신고합니다. 잃어버린 게 아닙니다 — 배달되고 있어요, 다만 죽어 있어야 할 시스템으로. 구글 MX가 정상 작동을 확인한 순간, 나머지 MX 레코드를 전부 지우세요.

3단계: 구글이 당신 이름으로 보내도록 인증 (SPF, 그다음 DKIM)

메일을 안으로 들이는 건 끝났습니다. 이제 나가는 메일이 스팸함에 떨어지지 않게 막습니다.

SPF는 루트에 두는 TXT 레코드 하나로, 수신자에게 구글 서버가 이 도메인 이름으로 보내도 된다고 알립니다:

example.com.   3600   IN   TXT   "v=spf1 include:_spf.google.com ~all"

여기 함정은 치명적이면서 조용합니다: 도메인에는 SPF 레코드가 딱 하나만 있을 수 있습니다. 이미 다른 서비스용 SPF 레코드가 있다면 두 번째 v=spf1 줄을 추가하는 게 아닙니다 — SPF 레코드 2개는 permerror로 SPF를 통째로 실패시킵니다. 병합하세요: 레코드 하나를 유지하고 그 안에 이미 있던 것과 나란히 include:_spf.google.com을 넣습니다.

DKIM은 구글 관리 콘솔 안에서 생성됩니다(앱 → Google Workspace → Gmail → 이메일 인증). 구글이 2048비트 공개키를 주면 이걸 google._domainkey.example.com에 TXT 레코드로 게시합니다. 사람들이 빼먹는 단계는 마지막입니다: DKIM 레코드를 게시하고 전파를 기다린 뒤, 콘솔로 돌아가 ‘인증 시작’을 클릭해서 DKIM을 실제로 켜야 합니다. 스위치를 안 켜고 키만 게시하면 아무것도 서명되지 않습니다.

DechoNet으로 진단하기

이메일 점검은 수신 서버가 하듯 도메인의 MX·SPF·DKIM을 읽습니다 — 구글 MX가 유일한 MX인지(스플릿 MX 잔재를 잡아냄), SPF가 _spf.google.com을 담은 유효한 단일 레코드인지, DKIM이 게시돼 해석되는지를 한 번에 확인할 수 있습니다.
DNS 점검은 개별 레코드를 따로 해석합니다. google-site-verification TXT가 루트에 살아 있는지, 또는 google._domainkey.example.com이 DKIM 키를 반환하는지 확인할 때 쓰세요.

확인 체크리스트

dig TXT example.com +short에 google-site-verification= 값이 보이고 — 지우지 않았다.
dig MX example.com +short에 오직 구글 MX(단일 smtp.google.com 또는 5개 ASPMX 호스트)만 있고 이전 업체 것이 없다.
SPF 레코드가 정확히 하나이고 include:_spf.google.com을 담고 있다.
dig TXT google._domainkey.example.com +short가 DKIM 공개키를 반환한다.
관리 콘솔에서 DKIM 인증이 DNS 게시만이 아니라 켜져 있다.
무엇이든 고장이라 결론짓기 전에 TTL / 최대 72시간을 기다렸다.

DNS 문제가 아닐 때

인증이 통과했고, 구글 MX가 유일한 MX이고, SPF가 단일에 정확하고, DKIM이 게시돼 켜져 있는데 — 그래도 메일이 이상하면 — DNS는 제 몫을 다했고 문제는 워크스페이스 안으로 옮겨간 겁니다: 라이선스 없는 사용자, 관리 콘솔의 라우팅 규칙이나 캐치올, 아직 안 만들어진 사서함. 그 지점부턴 DNS의 레코드 문제가 아니라 콘솔 안의 계정·라우팅 문제입니다.

내 도메인에서 바로 확인

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