회사 메일을 연결할 때
DNS에는 무엇을 설정해야 할까?

00 / PLAIN EXPLANATION

회사 메일 DNS는 “메일을 어디로 받을지”와 “누가 우리 도메인 이름으로 메일을 보내도 되는지”를 정하는 설정입니다.

메일 설정이 어려운 이유는 수신과 발신 인증을 한꺼번에 보기 때문입니다. 역할을 나누면 훨씬 단순해집니다.

01 / SEPARATE ROUTES

웹사이트 서버와 메일 서버는 같은 도메인을 공유하면서도 완전히 독립적으로 운영할 수 있습니다.

예를 들어 example.com 홈페이지는 GitHub Pages에 올리고, info@example.com 메일은 Google Workspace를 사용할 수 있습니다. 이때 사이트를 GitHub로 연결하는 A·CNAME과 메일을 Google로 연결하는 MX·TXT 레코드는 서로 다른 역할을 합니다.

02 / MX

MX 레코드는 “example.com으로 온 메일을 어느 우체국에 맡길지”를 정합니다.

누군가 info@example.com으로 메일을 보내면 발신 측 메일 서버는 example.com의 MX 레코드를 조회합니다. 거기에 적힌 서버로 메시지를 전달합니다.

Google Workspace, Microsoft 365, 네이버웍스 같은 메일 서비스를 사용하면 해당 서비스가 지정한 MX 값을 DNS에 입력합니다. 서비스마다 여러 개의 MX와 우선순위 값을 제공하기도 합니다.

MX를 잘못 바꾸면 어떻게 될까?

웹사이트는 정상적으로 열리는데 새 메일이 도착하지 않을 수 있습니다. 그래서 네임서버 이전 시 가장 먼저 백업해야 할 값 중 하나가 MX입니다.

03 / SPF & DKIM

메일을 “받는 곳”을 정했다면, 이제 “우리 이름으로 누가 보내도 되는지”를 증명해야 합니다.

SPF — 허용된 발신 서버 목록

SPF는 TXT 레코드로 “이 도메인을 대신해 메일을 보낼 수 있는 서버는 여기까지”라고 선언합니다. Google Workspace뿐 아니라 뉴스레터, CRM, 문의폼 발송 서비스 등을 함께 쓴다면 그 서비스들의 발신 경로도 고려해야 합니다.

위 문자열 자체를 외우는 것이 목적은 아닙니다. 중요한 것은 현재 어떤 서비스가 우리 도메인 이름으로 메일을 보내는지 파악하고 하나의 SPF 정책 안에서 정리하는 것입니다.

DKIM — 발신 메일의 디지털 서명

DKIM은 메일 서버가 발송할 때 메시지에 서명을 붙이고, 수신 서버가 DNS에 공개된 키를 조회해 그 서명을 검증합니다. 따라서 “이 메일이 실제로 해당 발신 서비스에서 만들어졌는지”를 확인하는 데 도움이 됩니다.

04 / DMARC

DMARC는 SPF와 DKIM을 바탕으로 “인증 실패 메일을 어떻게 처리할지”까지 정합니다.

DMARC는 단순히 하나의 인증을 더 추가하는 것이 아니라, SPF·DKIM 결과와 발신 주소의 정합성을 보고 수신 서버에 처리 정책을 전달합니다.

처음부터 가장 강한 정책을 적용하기보다 실제 사용하는 발신 서비스를 먼저 정리하고 모니터링한 뒤 단계적으로 강화하는 것이 안전합니다.

05 / MIGRATION CHECK

네임서버를 바꿀 때 메일이 끊기는 이유는 “웹 연결만 복사하고 메일 레코드를 빠뜨렸기 때문”인 경우가 많습니다.

예를 들어 가비아 네임서버에서 Cloudflare로 옮긴다면 기존 가비아 DNS의 MX·TXT·CNAME까지 새 DNS 서비스에 먼저 복제해야 합니다. 웹사이트 A 레코드만 옮기면 홈페이지는 정상인데 메일은 수신되지 않는 상태가 될 수 있습니다.

이전 전에 저장할 것

• MX 레코드 전체와 우선순위
• SPF TXT 레코드
• DKIM selector와 공개키 레코드
• DMARC TXT 레코드
• Google·Microsoft·네이버웍스 등의 소유권 인증값
• 뉴스레터·CRM·문의폼 발송 서비스의 인증 레코드

이전 후 테스트