SPF, DKIM & DMARC: 정의, 설정 방법, 중요한 이유

이메일은 잘 작성되어 있습니다. 목록은 깨끗합니다. 발송 일정은 일관적입니다. 하지만 오픈율은 계속 떨어지고 Gmail은 계속 스팸으로 분류합니다. 문제는 보내는 내용이 아닐 수 있습니다 -- 실제로 자신이라는 것을 증명하지 않았기 때문일 수 있습니다.

이메일 인증은 도메인에서 왔다고 주장하는 이메일이 실제로 도메인에서 왔음을 메일 서비스 제공업체에 증명하는 방법입니다. 이것 없이는 누구나 "From" 주소를 위조하고 브랜드를 사칭하는 피싱 이메일을 보낼 수 있습니다. 메일 서비스 제공업체는 이를 알고 있으므로 -- 인증되지 않은 이메일은 기본적으로 의심스러운 것으로 취급됩니다.

세 가지 프로토콜이 이메일 인증의 근간을 형성합니다: SPF, DKIM, DMARC. 이들은 함께 수신 서버에 누가 대신 발송할 수 있는지, 메시지가 변조되지 않았는지, 무언가 실패했을 때 어떻게 해야 하는지 알려줍니다. 이 가이드에서는 세 가지 모두를 쉬운 언어로 설명하고, 각각의 정확한 설정 방법을 보여주며, 경험 많은 발신자도 빠지는 실수를 다룹니다.

이메일 인증이란?

우편으로 편지를 보낼 때 수신자는 반송 주소를 볼 수 있습니다 -- 하지만 누구나 봉투에 아무 반송 주소나 쓸 수 있습니다. 이메일도 같은 방식으로 작동합니다. 이메일의 "From" 필드는 단순한 텍스트입니다. 인증 없이는 스패머가 you@yourdomain.com에서 보낸 것처럼 이메일을 보내는 것을 막을 수 없습니다.

이메일 인증은 메시지에 검증 가능한 증명을 추가하여 이 문제를 해결합니다. 수신 메일 서버가 세 가지 질문에 답할 수 있게 하는 DNS 레코드와 암호화 기술의 집합입니다:

• 이 서버가 이 도메인에 대해 이메일을 보낼 권한이 있나요? (SPF)
• 이 메시지가 발송된 후 변경되었나요? (DKIM)
• 인증 실패 시 어떻게 해야 하나요? (DMARC)

문 앞에서 신분증을 보여주는 것과 같습니다. SPF는 게스트 리스트입니다. DKIM은 입구에서 확인되었음을 증명하는 팔찌입니다. DMARC는 일치하지 않는 사람이 있을 때 어떻게 해야 하는지에 대한 경비원의 지시입니다.

SPF 설명

SPF란

SPF (Sender Policy Framework)는 도메인을 대신하여 이메일을 보낼 수 있는 모든 IP 주소와 메일 서버를 나열하는 DNS TXT 레코드입니다. 수신 서버가 도메인에서 이메일을 받으면 SPF 레코드를 확인하여 발신 서버의 IP 주소가 승인된 목록에 있는지 확인합니다.

IP가 일치하면 SPF가 통과합니다. 일치하지 않으면 SPF가 실패합니다 -- 수신 서버는 이메일이 위조될 수 있음을 알게 됩니다.

SPF 작동 방식 (단계별)

1. 이메일 서비스 제공업체(ESP)를 통해 hello@yourdomain.com에서 이메일을 보냅니다.
2. 수신 서버는 이메일이 yourdomain.com에서 왔다고 주장하는 것을 봅니다.
3. yourdomain.com의 DNS에서 SPF 레코드를 찾습니다.
4. SPF 레코드는 "이 서버들만 내 도메인에서 발송할 수 있습니다: 192.0.2.1, 그리고 Mailchimp의 SPF 레코드에 나열된 것들"이라고 말합니다.
5. 수신 서버는 실제로 이메일을 보낸 IP가 SPF 레코드와 일치하는지 확인합니다.
6. 일치하면: SPF 통과. 일치하지 않으면: SPF 실패.

SPF 설정 방법

SPF 설정에는 도메인의 DNS에 단일 TXT 레코드를 추가해야 합니다. 일반적인 SPF 레코드는 다음과 같습니다:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

분석해 봅시다:

• v=spf1 -- SPF 레코드임을 식별
• include:_spf.google.com -- Google Workspace에 도메인 대신 발송 권한 부여
• include:servers.mcsv.net -- Mailchimp에 도메인 대신 발송 권한 부여
• -all -- 위에 나열되지 않은 모든 서버의 이메일을 거부하도록 수신자에게 지시

설정하려면: DNS 제공업체(GoDaddy, Cloudflare, Namecheap 등)에 로그인하고, DNS 레코드로 이동하여, 호스트가 @(루트 도메인)로 설정된 새 TXT 레코드를 추가하고 SPF 값을 붙여넣으세요. ESP에서 정확히 무엇을 포함해야 하는지 알려줄 것입니다 -- 해당 문서를 확인하세요.

일반적인 SPF 실수

• 다중 SPF 레코드. 도메인에는 SPF 레코드가 하나만 있을 수 있습니다. 두 번째를 추가하면(예: Google용 하나와 Mailchimp용 하나) 둘 다 깨집니다. 여러 include: 문을 사용하여 단일 레코드로 합치세요.
• 너무 많은 DNS 조회. SPF에는 10개의 DNS 조회 제한이 있습니다. 각 include:는 조회로 계산되며, 중첩된 include도 포함됩니다. 10개를 초과하면 보내는 모든 이메일에 대해 SPF가 자동으로 실패합니다. 한계에 도달하면 SPF 플래트닝 도구를 사용하세요.
• -all 대신 +all 사용. +all 플래그는 "모든 사람이 내 도메인으로 발송할 수 있도록 허용"을 의미합니다 -- SPF의 전체 목적을 무력화합니다. 항상 -all(하드 실패) 또는 최소한 ~all(소프트 실패)을 사용하세요.
• 타사 발신자 누락. CRM, 헬프데스크, 트랜잭션 이메일 서비스를 사용하는 경우 해당 서버도 SPF 레코드에 있어야 합니다. 일반적인 패턴: 마케팅 이메일은 SPF를 통과하지만 헬프데스크의 트랜잭션 이메일은 추가하는 것을 잊어 실패합니다.

DKIM 설명

DKIM이란

DKIM (DomainKeys Identified Mail)은 보내는 모든 이메일에 암호화 디지털 서명을 추가합니다. 이 서명은 발신 서버만 가지고 있는 개인 키를 사용하여 생성됩니다. 해당하는 공개 키는 누구나 서명을 확인할 수 있도록 DNS에 게시됩니다.

발신 서버만 확인하는 SPF와 달리, DKIM은 이메일이 발송된 후 내용이 변경되지 않았는지 확인합니다. 누군가 이메일을 가로채고 수정하면 DKIM 서명이 깨지고 수신 서버는 메시지가 변조되었음을 알게 됩니다.

DKIM 설정 방법

DKIM 설정은 이메일 제공업체가 키 쌍을 생성해야 하므로 SPF보다 약간 더 복잡합니다. 일반적인 과정은 다음과 같습니다:

1. ESP에서 DKIM 키를 생성합니다. 이메일 제공업체의 설정으로 이동하여 "DKIM" 또는 "이메일 인증"을 찾으세요. 대부분의 제공업체(Google Workspace, Mailchimp, SendGrid 등)가 키를 생성하고 추가할 DNS 레코드를 제공합니다.
2. DNS에 DKIM 레코드를 추가합니다. google._domainkey와 같은 호스트와 공개 키를 포함하는 긴 값이 있는 TXT 또는 CNAME 레코드를 받게 됩니다. DNS 제공업체에 추가하세요.
3. ESP에서 DKIM을 활성화합니다. 일부 제공업체는 DNS 레코드 추가 후 "인증 시작" 등을 클릭해야 합니다. 이 단계를 건너뛰지 마세요.
4. 작동하는지 확인합니다. 테스트 이메일을 보내고 이메일 헤더에서 dkim=pass를 확인하세요.

일반적인 DKIM 실수

• 모든 발신자에 대해 DKIM을 설정하지 않음. 사용하는 각 이메일 서비스에 자체 DKIM 키가 필요합니다. Google Workspace에 DKIM을 설정했지만 Mailchimp에는 하지 않으면 Mailchimp의 이메일은 DKIM 검사에 실패합니다.
• 키 길이가 너무 짧음. 최소 1024비트 키를 사용하되 2048비트가 2026년 표준입니다. 일부 제공업체는 여전히 1024으로 기본 설정합니다 -- 가능하면 업그레이드하세요.
• 키를 회전하지 않음. 필수 회전 일정은 없지만, DKIM 키를 매년 회전하는 것이 보안 모범 사례입니다.

DMARC 설명

DMARC란

DMARC (Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM을 연결하고 중요한 빠진 조각인 정책을 추가하는 프로토콜입니다. DMARC는 도메인의 이메일이 인증에 실패했을 때 수신 서버에 무엇을 해야 하는지 알려줍니다.

DMARC 없이는 수신 서버가 추측해야 합니다. 어쨌든 배달해야 하나요? 스팸 폴더에 넣어야 하나요? 완전히 거부해야 하나요? DMARC는 DNS에 명확한 정책을 게시하여 여러분이 결정할 수 있게 합니다.

DMARC 정책: none, quarantine, reject

DMARC는 세 가지 정책 수준을 제공합니다:

DMARC 설정 방법

1단계: 모니터링으로 시작. DNS에 이 TXT 레코드를 추가하세요:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

2단계: 2-4주간 보고서 검토. 주요 메일 서비스 제공업체로부터 XML 보고서를 받게 됩니다. 모든 정당한 발신자가 SPF와 DKIM을 통과하는지 확인하세요.

3단계: quarantine으로 이동. 모든 정당한 이메일이 통과하는 것이 확인되면:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

4단계: reject로 이동. 몇 주간의 깨끗한 보고서 후:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

먼저 모니터링 없이 p=reject로 바로 이동하지 마세요. 정당한 발신자가 올바르게 인증되지 않으면 이메일이 조용히 삭제되며 -- 누군가가 메시지를 받지 못했다고 불만을 제기할 때까지 모를 것입니다.

SPF vs. DKIM vs. DMARC: 비교

핵심: 각 프로토콜은 다른 틈을 채웁니다. SPF만으로는 보이는 "From" 주소를 확인하지 못합니다. DKIM만으로는 인증 실패 시 수신자에게 무엇을 해야 하는지 알려주지 않습니다. DMARC만으로는 SPF나 DKIM 없이 작동하지 않습니다. 세 가지가 함께 작동해야 합니다.

인증이 전달률에 미치는 영향

이메일 인증은 발신자 평판의 기본 기둥 중 하나입니다. 메일 서비스 제공업체는 인증을 기본 신뢰 신호로 사용합니다. 받은 편지함 배치를 보장하지는 않습니다 -- 여전히 깨끗한 목록, 낮은 불만, 좋은 참여가 필요합니다 -- 하지만 인증 없이는 다른 모든 것이 약화됩니다.

• 인증 없음: 대부분의 주요 제공업체가 이메일을 스팸 폴더에 넣거나 완전히 거부합니다.
• SPF만: 없는 것보다 낫지만 틈이 있습니다. 전달된 이메일은 SPF를 깨뜨리며, 보이는 From 필드의 도메인 스푸핑에 대한 보호가 없습니다.
• SPF + DKIM: 훨씬 낫습니다. 서버 권한과 메시지 무결성을 모두 증명합니다. 하지만 DMARC 없이는 정책도 보고서도 없습니다.
• SPF + DKIM + DMARC (reject): 골드 스탠다드. 완전한 인증, 완전한 보호, 완전한 가시성. Gmail과 Yahoo가 대량 발신자에게 요구하는 것이며 모든 도메인이 목표로 해야 하는 것입니다.

이메일 인증 체크리스트

결론

이메일 인증은 더 이상 선택 사항이 아닙니다. Gmail, Yahoo, Microsoft 모두 SPF, DKIM, DMARC를 이메일이 받은 편지함에 속하는지 스팸 폴더에 속하는지 결정하는 기본 신호로 사용합니다. 2024년부터 Gmail과 Yahoo는 대량 발신자에게 명시적으로 세 가지 모두를 요구하며 -- 추세는 명확합니다: 인증 요구사항은 점점 더 엄격해질 것입니다.

좋은 소식은 인증 설정은 영구적인 혜택을 가진 일회성 작업이라는 것입니다. SPF, DKIM, DMARC 레코드가 올바르게 구성되면 보내는 모든 이메일이 그들이 확립한 신뢰의 혜택을 받습니다. 전달률을 개선할 뿐만 아니라 -- 평판과 고객의 신뢰를 손상시킬 수 있는 피싱 및 스푸핑 공격으로부터 브랜드를 보호합니다.

하지만 인증은 전달률 퍼즐의 한 조각에 불과합니다. 완벽하게 인증된 이메일도 유효하지 않은 주소로 보내면 반송됩니다. 이메일 검증은 실제로 존재하고 소식을 듣고 싶어하는 사람들에게 발송하고 있는지 확인합니다. 함께하면 일관되게 받은 편지함에 도달하는 기반이 됩니다.