SPF, DKIM & DMARC: 콜드 이메일을 위한 완벽한 DNS 인증 가이드

콜드 이메일 캠페인을 운영하고 있다면, "인증"이 전달률에 매우 중요하다는 말을 들어봤을 것입니다. 하지만 그것이 실제로 무엇을 의미할까요? 그리고 더 중요하게는, 어떻게 올바르게 설정할까요?

이 종합 가이드에서는 이메일 인증의 세 기둥인 SPF, DKIM, DMARC를 낱낱이 분석합니다. 각 프로토콜이 정확히 무엇을 하는지, 어떻게 올바르게 구성하는지, 그리고 콜드 이메일에 진지한 사람이라면 왜 이것들이 타협 불가능한지 배우게 됩니다.

최근 연구에 따르면, 제대로 인증된 이메일은 인증되지 않은 메시지에 비해 인박스에 도달할 가능성이 최대 50% 더 높습니다. Google과 Microsoft는 모두 2024년부터 더 엄격한 인증 요건을 시행한다고 발표했으며, 이는 이 지식을 그 어느 때보다 중요하게 만듭니다.

콜드 이메일에서 이메일 인증이 중요한 이유

이메일 인증은 두 가지 주요 목적을 수행합니다. 여러분이 주장하는 그 사람이 맞는지 검증하고, 여러분의 도메인이 악의적인 행위자에 의해 스푸핑되는 것을 막습니다. 콜드 이메일 발송자에게 이것은 곧 더 나은 전달률과 인박스 도달로 직결됩니다.

적절한 인증이 없으면, 이메일 제공업체는 여러분의 도메인에서 온 것이라고 주장하는 이메일이 실제로 여러분에게서 왔는지 검증할 방법이 없습니다. 이러한 불확실성은 종종 여러분의 이메일이 다음과 같이 처리되는 결과로 이어집니다:

• 곧바로 스팸함으로 필터링됨
• 보안 경고와 함께 표시됨(그 악명 높은 "이 메시지에 주의하세요")
• 수신 서버에 의해 완전히 거부됨
• 인박스 알고리즘에서 더 낮은 우선순위를 부여받음

SPF(Sender Policy Framework): 여러분의 1차 방어선

SPF란 무엇인가?

SPF는 어떤 메일 서버가 여러분의 도메인을 대신해 이메일을 발송할 권한이 있는지 지정하는 DNS 기반 인증 프로토콜입니다. 도메인의 DNS 레코드에 게시된 승인된 발송자 화이트리스트라고 생각하면 됩니다.

수신 메일 서버가 여러분의 도메인에서 온 이메일을 받으면, 여러분의 SPF 레코드를 확인하여 발송 서버의 IP 주소가 승인 목록에 있는지 살핍니다. 있다면 이메일은 SPF 인증을 통과합니다. 없다면 실패합니다.

SPF의 작동 방식 (단계별)

1. 여러분이 your-domain.com에서 이메일을 발송합니다
2. 수신 서버가 your-domain.com의 DNS 레코드를 확인합니다
3. 승인된 IP 주소와 서비스를 나열한 여러분의 SPF 레코드를 찾습니다
4. 발송 서버의 IP를 여러분의 승인 목록과 대조합니다
5. IP가 일치하는지 여부에 따라 이메일이 SPF를 통과하거나 실패합니다

SPF 레코드 구문과 예시

SPF 레코드는 도메인의 DNS에 추가되는 TXT 레코드입니다. 주요 구성 요소는 다음과 같습니다:

각 부분을 살펴보겠습니다:

• v=spf1 - 버전 식별자 (항상 spf1)
• include:_spf.google.com - Google의 메일 서버를 승인
• ~all - 승인되지 않은 발송자에 대한 소프트 페일 (권장)

콜드 이메일을 발송하는 Google Workspace 사용자의 경우, 완전한 SPF 레코드는 다음과 같은 모습일 수 있습니다:

SPF 한정자 설명

피해야 할 흔한 SPF 실수

• 여러 개의 SPF 레코드: 도메인당 SPF 레코드는 단 하나만 둘 수 있습니다
• 너무 많은 DNS 조회: SPF에는 DNS 조회 10회 제한이 있습니다
• +all 사용: 이는 사실상 SPF 보호를 무력화합니다
• 서드파티 서비스 누락: 여러분을 대신해 발송하는 모든 서비스를 포함하세요

DKIM(DomainKeys Identified Mail): 암호화된 이메일 서명

DKIM이란 무엇인가?

DKIM은 공개 키 암호화를 사용하여 이메일에 디지털 서명을 추가합니다. (발송 서버를 검증하는) SPF와 달리, DKIM은 이메일 내용이 전송 중에 수정되지 않았음을 검증하고 메시지가 여러분의 도메인에서 왔음을 확인합니다.

DKIM을 소포에 붙은 변조 방지 봉인이라고 생각하세요. 이메일을 발송하면 여러분의 메일 서버가 개인 키로 서명합니다. 수신 서버는 (DNS에 게시된) 여러분의 공개 키를 사용해 서명을 검증합니다. 이메일이 어떤 식으로든 변경되었다면 서명이 일치하지 않습니다.

DKIM의 작동 방식

1. 여러분의 도메인에는 공개/개인 키 쌍이 있습니다 (공개 키는 DNS에, 개인 키는 메일 서버에)
2. 이메일을 발송하면 서버가 지정된 헤더와 본문의 해시를 생성합니다
3. 이 해시는 여러분의 개인 키로 암호화됩니다 (서명)
4. 서명이 이메일 헤더에 추가됩니다
5. 수신 서버가 DNS에서 여러분의 공개 키를 가져옵니다
6. 서명을 복호화하여 자체적으로 계산한 이메일 해시와 비교합니다
7. 일치하면 DKIM이 통과하고, 그렇지 않으면 실패합니다

DKIM 레코드 구조

DKIM 레코드는 특정 서브도메인에 게시되는 TXT 레코드입니다. Google Workspace의 경우 일반적으로 다음과 같은 모습입니다:

구성 요소를 살펴보겠습니다:

• google._domainkey - 셀렉터와 _domainkey 식별자
• v=DKIM1 - DKIM 버전
• k=rsa - 키 유형 (RSA 암호화)
• p=... - 공개 키 (base64 인코딩됨)

Google Workspace용 DKIM 키 생성하기

1. Google Admin Console > 앱 > Google Workspace > Gmail로 이동합니다
2. "이메일 인증"을 클릭합니다
3. 도메인을 선택하고 "새 레코드 생성"을 클릭합니다
4. 2048비트 키 길이를 선택합니다 (권장)
5. 생성된 레코드를 DNS 제공업체에 복사합니다
6. DNS 전파를 기다린 후 "인증 시작"을 클릭합니다

DMARC(Domain-based Message Authentication, Reporting & Conformance): 정책 계층

DMARC란 무엇인가?

DMARC는 SPF와 DKIM 위에 자리 잡은 정책 계층입니다. 세 가지 중요한 일을 합니다:

1. 정렬 확인: From: 헤더가 SPF/DKIM의 도메인과 일치하는지 보장합니다
2. 정책 시행: 실패한 이메일을 수신 서버가 어떻게 처리할지 알려줍니다
3. 보고: 여러분의 이메일 인증 결과에 대한 보고서를 보내줍니다

DMARC가 없으면 SPF와 DKIM이 개별적으로 통과하면서도 여전히 스푸핑된 이메일을 통과시킬 수 있습니다. DMARC는 눈에 보이는 From: 주소와 인증된 도메인 간의 정렬을 요구함으로써 이 허점을 막습니다.

DMARC 레코드 구조

DMARC 레코드는 _dmarc.yourdomain.com에 있는 TXT 레코드입니다:

각 태그의 의미는 다음과 같습니다:

• v=DMARC1 - 버전 (항상 DMARC1)
• p=quarantine - 정책: none, quarantine, 또는 reject
• rua=mailto:... - 집계 보고서를 보낼 곳
• pct=100 - 정책을 적용할 이메일의 비율
• adkim=s - DKIM 정렬 모드 (s=엄격, r=완화)
• aspf=s - SPF 정렬 모드 (s=엄격, r=완화)

DMARC 정책 진행 단계

DMARC 구현에는 단계적 접근을 권장합니다:

1단계: 모니터링 (p=none)

전달에 영향을 주지 않으면서 데이터를 수집합니다. 2~4주간 실행하세요.

2단계: 격리 (p=quarantine)

25%로 시작하여 몇 주에 걸쳐 100%까지 점진적으로 늘리세요.

3단계: 거부 (p=reject)

최대 보호입니다. 충분한 테스트를 거친 후에만 구현하세요.

모두 종합하기: 콜드 이메일을 위한 완전한 DNS 설정

다음은 Google Workspace를 사용하는 콜드 이메일 도메인에 필요한 모든 DNS 레코드의 완전한 예시입니다:

이메일 인증 설정을 검증하는 방법

방법 1: 이메일 헤더 확인

Gmail에서 자신에게 테스트 이메일을 보낸 다음 원본 메시지를 확인하세요(점 세 개 > 원본 보기). Authentication-Results 헤더를 찾아보세요:

방법 2: 온라인 도구

• MXToolbox: 모든 DNS 레코드를 확인하고 상세한 진단을 받습니다
• mail-tester.com: 테스트 이메일을 보내고 전달률 점수를 받습니다
• DMARC Analyzer: DMARC 보고서를 파싱하고 시각화합니다
• Google Postmaster Tools: Gmail로 도메인 평판을 모니터링합니다

방법 3: 커맨드 라인 검증

콜드 이메일 발송자를 위한 고급 팁

1. 콜드 이메일에 서브도메인 사용하기

루트 도메인 대신 서브도메인(예: mail.yourdomain.com)에서 콜드 이메일을 발송하는 것을 고려하세요. 이는 캠페인에 문제가 생겼을 때 주 도메인의 평판을 보호합니다.

2. DMARC 보고서 모니터링

DMARC 집계 보고서(rua)는 이메일 인증에 대한 귀중한 통찰을 제공합니다. 다음을 보여줍니다:

• 어떤 IP가 여러분의 도메인에서 이메일을 발송하고 있는지
• 얼마나 많은 이메일이 인증을 통과하거나 실패하는지
• 여러분의 도메인에 대한 잠재적 스푸핑 시도

3. SPF 10회 조회 제한 다루기

SPF 레코드는 DNS 조회 10회로 제한됩니다. 많은 서비스를 사용하면 이 제한에 걸릴 수 있습니다. 해결책은 다음과 같습니다:

• include를 IP 주소로 변환하는 SPF 플래트닝 서비스
• 가능한 경우 include 대신 ip4/ip6 메커니즘 사용
• 이메일 서비스를 통합하여 조회 횟수 줄이기

4. 새 도메인 워밍업하기

완벽한 인증이 있더라도, 새 도메인은 평판을 쌓는 데 시간이 필요합니다. 낮은 발송량으로 시작하여 2~4주에 걸쳐 점진적으로 늘리세요. 워밍업 도구를 사용해 자연스러운 참여를 시뮬레이션하고 긍정적인 발송 패턴을 확립하세요.

결론: 인증은 타협 불가능하다

SPF, DKIM, DMARC는 이메일 전달률의 토대를 이룹니다. 이것들이 없으면, 인증되지 않은 이메일을 점점 더 의심하는 스팸 필터와 ISP 알고리즘을 상대로 힘겨운 싸움을 벌이게 됩니다.

좋은 소식은 일단 올바르게 구성하면 이 프로토콜들이 백그라운드에서 조용히 작동하며 여러분이 보내는 모든 이메일마다 인박스 도달률을 높여준다는 것입니다. 이것들을 제대로 설정하는 데 들이는 시간의 투자는 더 나은 전달률, 더 높은 오픈율, 더 많은 답장의 형태로 그 대가를 돌려줍니다.

기억하세요: Google과 Microsoft 같은 이메일 제공업체들은 인증 요건을 지속적으로 강화하고 있습니다. 5년 전에는 선택 사항이었던 것이 이제는 이메일 아웃리치에 진지한 모든 사람에게 필수가 되었습니다. 오늘 인증을 올바르게 설정하면, 요건이 계속 발전하는 가운데 여러분은 시대를 앞서 나가게 될 것입니다.