TXT 레코드: SPF, DKIM, 그리고 도메인 인증

TXT 레코드는 DNS의 잡동사니 서랍입니다 — 원래는 "이 서버는 Bob이 관리합니다"처럼 사람이 읽을 수 있는 메모를 저장하려고 만든 필드입니다. 그런데 누군가 이런 사실을 깨달았습니다. 지구상의 모든 기계가 읽고 확인할 수 있는 텍스트를 게시할 수 있다면, 자신의 도메인에 대한 공개적인 주장을 할 수 있다는 것을. 누가 여러분의 이메일을 보낼 수 있는지. 이 도메인의 실제 소유자가 누구인지. 어떤 보안 정책을 적용하는지.

그 묘수가 핵심 인프라가 되었습니다. TXT 레코드는 이제 매일 수십억 건의 이메일을 인증하고, Google과 Microsoft에 도메인 소유권을 증명하며, 피싱으로부터 사용자를 보호하는 보안 정책을 게시합니다. 메모지용으로 설계된 필드가 이메일 신뢰의 토대가 되었습니다.

TXT 레코드란 무엇인가

TXT 레코드는 DNS에 임의의 텍스트를 저장합니다. IP 주소를 담는 A 레코드나 메일 서버를 가리키는 MX 레코드와 달리, TXT 레코드는 최대 255자의 어떤 문자열도 담을 수 있습니다. 이 유연성 덕분에 TXT 레코드는 프로토콜을 바꾸지 않고도 DNS에 새로운 기능을 덧붙이는 기본적인 수단이 되었습니다.

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

이것이 의미하는 바는 이렇습니다. "example.com의 TXT 레코드를 조회하는 누구에게나 이 문자열을 반환하라." 그 문자열의 의미는 전적으로 그것을 읽는 애플리케이션에 달려 있습니다. DNS는 텍스트를 저장하고 제공할 뿐입니다 — 해석하지 않습니다.

핵심은 이렇습니다. TXT 레코드는 근본적인 문제를 해결합니다. 지구상의 모든 기계가 확인할 수 있도록, 자신의 도메인에 대한 공개적이고 검증 가능한 주장을 어떻게 할 수 있을까요? DNS에 게시하면 됩니다.

SPF: 이메일을 보낼 수 있는 서버 선언하기

SPF(Sender Policy Framework)는 TXT 레코드를 사용하여 간단한 질문에 답합니다. "이 서버가 이 도메인을 대신하여 이메일을 보낼 권한이 있는가?"

SPF가 없으면 누구든지 이메일의 "From" 주소를 위조할 수 있습니다. 이메일 프로토콜에는 이를 막는 장치가 없습니다. 공격자가 your-bank.com에서 보낸 것처럼 이메일을 발송해도 이메일 시스템 어디에도 이를 걸러낼 방법이 없습니다.

SPF가 이를 바꿉니다. 여러분을 대신하여 이메일을 보낼 권한이 있는 모든 서버를 나열하는 TXT 레코드를 게시합니다.

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

이것을 분석하면:

• v=spf1 — 이것은 SPF 레코드입니다
• ip4:192.0.2.0/24 — 이 IP 대역에서 이메일을 보낼 수 있습니다
• include:_spf.google.com — Google 서버에서도 이메일을 보낼 수 있습니다 (Workspace 사용자의 경우)
• -all — 다른 모든 곳에서 온 이메일은 거부합니다

메일 서버가 해당 도메인에서 보낸 것으로 주장하는 메시지를 받으면, SPF 레코드를 확인합니다. 발신 서버가 목록에 없으면 메시지는 인증에 실패합니다.

마지막 지시자가 적용 방식을 결정합니다:

• -all (강한 실패): 권한 없는 이메일 거부
• ~all (약한 실패): 의심스럽다고 표시하지만 전달
• ?all (중립): 적용 없음

SPF는 메시지 내용을 검증하거나 발신자가 자신이 주장하는 사람임을 증명하지 않습니다. 발신 서버에 권한이 있는지만 확인합니다. 하지만 이메일 위조의 가장 손쉬운 형태인 "From" 주소 조작은 막아냅니다.

DKIM: 메시지가 변조되지 않았음을 증명하기

DKIM(DomainKeys Identified Mail)은 한 걸음 더 나아갑니다. 발신 이메일에 암호화 서명을 추가하여, 수신 서버가 전송 중에 메시지가 변조되지 않았음을 검증할 수 있게 합니다.

1. 메일 서버가 개인 키로 각 발신 메시지에 서명합니다
2. 서명이 이메일 헤더에 추가됩니다
3. 수신 서버가 TXT 레코드에서 공개 키를 가져옵니다
4. 공개 키를 사용하여 서명이 메시지와 일치하는지 확인합니다

DKIM 공개 키는 "셀렉터"라는 서브도메인에 저장되어, 모든 이메일에 영향을 주지 않고도 키를 교체할 수 있습니다.

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

구조:

• v=DKIM1 — 이것은 DKIM 레코드입니다
• k=rsa — 키 유형 (RSA 암호화)
• p= — Base64로 인코딩된 공개 키

공개 키는 길어서 종종 수백 글자에 달합니다. 개별 TXT 문자열은 255자로 제한되어 있기 때문에, DNS는 여러 개의 인용 세그먼트로 분할합니다.

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" "3yBhP6aF7x9E2NvLmR8qT5uWz1jK4pQ6sD8cF9nV2hL" "remainder-of-key-here"

DNS는 값을 반환할 때 이것들을 연결합니다. 대부분의 이메일 제공업체는 키를 생성하고 추가해야 할 정확한 TXT 레코드를 알려줍니다 — 암호화를 따로 이해할 필요가 없습니다.

DKIM은 SPF를 보완합니다. SPF는 발신 서버를 검증하고, DKIM은 메시지 내용이 온전함을 증명합니다. DMARC(또 다른 TXT 레코드 기반 정책)와 함께, 이것들이 현대적인 이메일 인증 체계를 이룹니다.

도메인 인증: 소유권 증명하기

Google Workspace, Microsoft 365, 또는 대부분의 SaaS 플랫폼에 가입할 때, 서비스들은 접근 권한을 부여하기 전에 실제로 해당 도메인을 제어하는지 확인해야 합니다.

이 방식은 단순하지만 영리합니다.

1. 서비스가 고유한 임의의 토큰을 생성합니다
2. 그 토큰을 도메인의 TXT 레코드로 추가합니다
3. 서비스가 DNS에서 토큰을 조회합니다
4. 토큰이 있으면 제어권이 증명된 것입니다

Google의 인증 레코드는 다음과 같습니다:

example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

Microsoft는 다음을 사용합니다:

example.com.  IN  TXT  "MS=ms12345678"

DNS 제어권을 가진 사람만이 레코드를 추가할 수 있기 때문에 이 방식이 통합니다. 인증 토큰을 게시한다는 것 자체가 소유권의 증명입니다.

왜 이것이 영리한 방식인지 생각해 보세요. 이메일 인증은 가로챌 수 있습니다. 웹 인증은 기존 웹사이트가 필요합니다. 하지만 DNS 인증은 어떤 도메인에서도 작동합니다 — 5분 전에 등록하고 아무것도 설정하지 않은 도메인에서도요. 도메인을 대신하여 말할 수 있음을 보여줌으로써 소유권을 증명하는 것입니다.

긴 레코드 처리하기

255자 제한은 DNS 패킷 구조에서 비롯됩니다. 각 TXT 문자열 앞에는 길이 바이트가 붙으며, 한 바이트는 0에서 255까지의 값을 저장할 수 있습니다.

더 긴 데이터를 위한 방법은 두 가지입니다.

문자열 연결 (단일 레코드, 여러 문자열):

example.com.  IN  TXT  "first-255-characters" "next-portion" "final-portion"

여러 개의 별도 TXT 레코드:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z..."
example.com.  IN  TXT  "MS=ms12345678"

둘 다 작동합니다. TXT 레코드를 조회하면 일치하는 모든 레코드를 받아 각각을 독립적으로 처리합니다. 하나의 도메인이 SPF 정책, DKIM 키, 인증 토큰을 충돌 없이 동시에 게시할 수 있습니다.

이 아키텍처가 중요한 이유

TXT 레코드가 인터넷 보안의 근간이 된 것은, DNS가 어려운 문제를 해결하기 때문입니다. 바로 분산되어 있고 전 세계 누구나 접근할 수 있는 시스템에서 기계가 읽을 수 있는 정책을 게시하는 것입니다.

DNS가 제공하는 것:

• 범용 접근성 — 어떤 서버든 별도의 인증 없이 조회 가능
• 권위 — 도메인 소유자만이 레코드를 제어
• 캐싱 — 보안을 희생하지 않고 성능 향상
• 유연성 — 텍스트 형식이 프로토콜 변경 없이 새로운 메커니즘을 수용

SPF와 DKIM 이전에는 이메일에 발신자 인증 수단이 없었습니다. 누구든지 어떤 도메인에서 보낸 것처럼 주장할 수 있었습니다. TXT 레코드를 활용함으로써, 이메일 생태계는 SMTP를 재설계하지 않고도 인증을 추가했습니다. 인프라는 이미 존재했습니다 — 그것을 그냥 활용한 것입니다.

이 패턴은 인터넷 인프라 전반에서 반복됩니다. 도메인 소유권을 증명해야 하나요? TXT 레코드. 어떤 인증 기관이 여러분의 도메인에 인증서를 발급할 수 있는지 제어하는 CAA 정책을 게시하고 싶나요? TXT 레코드. 새로운 인증 시스템을 구축하고 있나요? 아마도 TXT 레코드일 겁니다.

새로운 DNS 기능이 필요하지 않습니다. 복잡한 프로토콜도 필요 없습니다. 모든 조직이 게시하고 모든 서버가 읽을 수 있는 텍스트 문자열만으로 충분합니다.

TXT 레코드에 관한 자주 묻는 질문

같은 도메인에 여러 TXT 레코드를 가질 수 있나요?

네. 단일 도메인에 필요한 만큼 TXT 레코드를 게시할 수 있습니다. 각각은 서로 다른 목적으로 사용됩니다 — 하나는 SPF용, 하나는 Google 인증용, 하나는 Microsoft용. 서버가 TXT 레코드를 조회하면 모두 받고, 그중 필요한 것만 처리합니다.

SPF 레코드가 없거나 잘못되면 어떻게 되나요?

SPF가 없으면 수신 서버는 여러분의 이메일이 정상적인 것인지 확인할 방법이 없습니다. 메시지가 스팸 폴더에 들어가거나 완전히 거부될 가능성이 높아집니다. 잘못 설정된 SPF 레코드 — 예를 들어 이메일 제공업체의 서버를 누락한 경우 — 는 정상적인 이메일조차 인증에 실패하게 만들 수 있습니다.

TXT 레코드 변경이 전파되는 데 얼마나 걸리나요?

DNS 전파는 일반적으로 몇 분에서 몇 시간이 걸리며, 기존 레코드의 TTL(Time-To-Live) 값과 DNS 리졸버의 캐싱 상태에 따라 달라집니다. 대부분의 인증 서비스는 최대 48시간을 기다리도록 권장하지만, 변경 사항은 보통 훨씬 빨리 적용됩니다. dig이나 온라인 DNS 확인 도구를 사용하여 전파 상태를 확인할 수 있습니다.

DKIM을 설정하려면 암호화를 이해해야 하나요?

아니요. 이메일 제공업체가 키를 생성하고 추가해야 할 정확한 TXT 레코드를 알려줍니다. 복사해서 DNS 설정에 붙여넣기만 하면 됩니다. 서명과 키 관리는 제공업체가 알아서 처리합니다.

일부 서비스가 서브도메인에 TXT 레코드를 요청하는 이유는 무엇인가요?

인증 시스템마다 서로 다른 방식을 사용합니다. DKIM은 키 교체를 위해 셀렉터 서브도메인(default._domainkey.example.com 등)을 활용합니다. 일부 서비스는 루트 도메인의 TXT 레코드가 지저분해지는 것을 피하려고 서브도메인을 사용하기도 합니다. 동작 원리는 동일합니다 — DNS에서의 위치만 다를 뿐입니다.