SPF, DKIM, DMARC: 이메일 인증 완벽 가이드

이메일 인증은 안정적인 이메일 전달의 기초입니다. SPF, DKIM, DMARC를 올바르게 구성하지 않으면 정성 들여 작성한 이메일이 고객의 받은 편지함에 도달하지 못할 수 있습니다. 대신 스팸 폴더로 가거나 완전히 거부될 수 있습니다.

이 종합 가이드는 각 이메일 인증 프로토콜이 무엇을 하는지 설명하고, 단계별 DNS 설정 지침을 제공하며, 일반적인 문제 해결 방법을 다루고, 구성이 올바르게 작동하는지 확인하는 방법을 알려줍니다.

이메일 인증이 중요한 이유

이메일은 보안이 주요 관심사가 아니었던 시대에 설계되었습니다. 원래 SMTP 프로토콜에는 이메일이 실제로 주장하는 발신자로부터 왔음을 확인하는 내장 검증 메커니즘이 없습니다. 이 근본적인 약점이 이메일 스푸핑, 피싱 공격, 스팸을 가능하게 합니다.

이메일 인증 프로토콜은 도메인 소유자가 다음을 지정할 수 있게 하여 이 문제를 해결합니다:

• 대신 이메일을 발송할 수 있는 서버 (SPF)
• 메시지가 진짜이고 변경되지 않았다는 암호화 증명 (DKIM)
• 인증에 실패한 메시지 처리 방법 (DMARC)

인증 부재의 비즈니스 영향

적절한 이메일 인증이 없으면:

• 낮은 전달성: Gmail, Microsoft, Yahoo와 같은 주요 공급업체가 인증되지 않은 이메일을 더 공격적으로 필터링
• 높은 스팸 비율: 합법적인 이메일이 도메인을 사용하는 스푸핑 메시지와 경쟁
• 브랜드 손상: 브랜드를 사칭하는 피싱 공격이 고객 신뢰 훼손
• 매출 손실: 마케팅 캠페인이 가입한 구독자에게 도달 실패
• 규정 준수 위험: 많은 규정이 이제 적절한 이메일 인증 요구

인증 트라이어드

SPF, DKIM, DMARC는 완전한 인증 시스템으로 함께 작동합니다:

각 프로토콜은 서로 다른 공격 벡터를 다룹니다. SPF는 권한 없는 서버가 대신 발송하는 것을 방지합니다. DKIM은 발송 후 메시지 변조를 방지합니다. DMARC는 이 둘을 연결하고 인증 결과에 대한 가시성을 제공합니다.

SPF (Sender Policy Framework) 이해

SPF (Sender Policy Framework)는 도메인을 대신하여 이메일을 발송할 권한이 있는 메일 서버를 지정하는 DNS 기반 이메일 인증 방법입니다.

SPF 작동 방식

이메일이 수신 서버에 도착하면, 해당 서버는 발신자 도메인의 SPF 레코드를 조회합니다. 그런 다음 이메일을 발송한 IP 주소가 승인된 것으로 나열되어 있는지 확인합니다. IP가 일치하면 SPF가 통과됩니다. 일치하지 않으면 SPF가 실패합니다.

SPF 검증 프로세스:

1. 마케팅 플랫폼에서 이메일 발송
2. 수신 서버가 Return-Path(봉투 발신자)에서 도메인 추출
3. 서버가 도메인의 SPF 레코드를 위해 DNS 쿼리
4. 발송 IP를 SPF 레코드의 승인 목록과 비교
5. 서버가 통과, 실패, 소프트실패, 또는 중립 결과를 기록

SPF 레코드 구문

SPF 레코드는 도메인의 DNS에 TXT 레코드로 게시됩니다. 기본 구조는 다음과 같습니다:

v=spf1 [mechanisms] [qualifier]all

버전 태그: 항상 v=spf1로 시작

메커니즘: 발송 가능한 주체 정의

한정자: 일치 처리 방법 정의

all 메커니즘: 이전 메커니즘과 일치하지 않는 모든 것에 적용

SPF 레코드 예시

이메일 공급업체 하나로 기본 설정:

v=spf1 include:spf.brevo.com -all

이는 Brevo가 도메인에 대한 이메일을 발송할 권한을 부여하고 다른 모든 발신자를 거부합니다.

여러 이메일 서비스:

v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all

이는 Brevo, Google Workspace, Microsoft 365를 승인합니다.

자체 메일 서버 포함:

v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all

이는 특정 IP 주소(서버)와 Brevo를 승인합니다.

테스트 중 소프트 실패로 시작:

v=spf1 include:spf.brevo.com ~all

-all 대신 ~all을 사용하면 실패를 표시하되 거부하지 않습니다. 초기 설정 시 유용합니다.

SPF 레코드 설정

단계 1: 발송 소스 파악

도메인에서 이메일을 발송하는 모든 서비스를 나열하세요:

• 이메일 마케팅 플랫폼 (Brevo, Mailchimp 등)
• 트랜잭셔널 이메일 서비스
• CRM 시스템
• 헬프데스크 소프트웨어
• 회사 이메일 (Google Workspace, Microsoft 365)
• 자체 메일 서버

단계 2: SPF include 구문 수집

각 이메일 서비스 공급업체는 필요한 SPF include를 문서화합니다. 일반적인 예시:

단계 3: SPF 레코드 생성

모든 include를 하나의 레코드로 결합하세요:

v=spf1 include:spf.brevo.com include:_spf.google.com -all

단계 4: DNS 레코드 추가

DNS 관리 인터페이스에서:

• 유형: TXT
• 호스트/이름: @ (또는 루트 도메인은 비워두기)
• 값: 완전한 SPF 레코드
• TTL: 3600 (또는 기본값)

단계 5: 레코드 확인

DNS 조회 도구로 확인하세요:

dig TXT yourdomain.com

또는 MXToolbox SPF Lookup과 같은 온라인 도구를 사용하세요.

SPF 제한 사항 및 모범 사례

DNS 조회 10회 제한:

SPF는 최대 10번의 DNS 조회가 있습니다. 각 include:는 하나의 조회로 계산되며, 포함된 레코드에 자체 include가 포함될 수 있어 제한에 포함됩니다. 이를 초과하면 SPF 퍼마에러(영구 오류)가 발생하여 모든 확인이 실패합니다.

제한 내에 유지하는 전략:

• 가능한 경우 IP 주소를 직접 사용 (ip4:는 조회로 계산되지 않음)
• 동일한 공급업체를 사용하는 서비스 통합
• include를 IP 주소로 변환하는 SPF 평탄화 서비스 사용
• 이전 서비스의 사용하지 않는 include 제거

기타 SPF 모범 사례:

• 도메인당 하나의 SPF 레코드만 사용 (여러 레코드는 실패 유발)
• 설정 중에는 ~all (소프트실패)로 시작하고 확인 후 -all로 이동
• 이메일 공급업체 변경 시 SPF 업데이트
• 사용 중단된 ptr 메커니즘 사용 금지
• 레코드를 최대한 간단하게 유지

일반적인 SPF 실수

여러 SPF 레코드:

잘못된 방법:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

올바른 방법:
v=spf1 include:spf.brevo.com include:_spf.google.com -all

DNS 조회 제한 초과:

include가 많은 경우 총 조회 수를 확인하세요. SPF 분석기를 사용하여 10개 미만인지 확인하세요.

공급업체 변경 후 업데이트 잊기:

하나의 이메일 서비스에서 다른 서비스로 전환할 때 이전 include를 제거하고 새 것을 추가하세요.

+all 사용:

+all은 모든 사람이 도메인 대신 발송할 수 있도록 승인하므로 절대 사용하지 마세요.

DKIM (DomainKeys Identified Mail) 이해

DKIM (DomainKeys Identified Mail)은 이메일에 암호화 서명을 추가하여, 메시지가 도메인에서 발생했고 전송 중에 수정되지 않았음을 증명합니다.

DKIM 작동 방식

DKIM은 공개 키 암호화를 사용합니다:

1. 이메일 공급업체가 공개/개인 키 쌍을 생성
2. DNS에 공개 키를 게시
3. 공급업체가 개인 키로 발신 이메일에 서명
4. 수신 서버가 DNS에서 공개 키를 검색
5. 공개 키를 사용하여 서명 확인
6. 유효한 서명이 진위 및 무결성 증명

DKIM이 서명하는 내용:

DKIM 서명은 일반적으로 특정 헤더와 메시지 본문을 포함합니다:

• From 헤더 (필수)
• Subject 헤더
• Date 헤더
• 메시지 본문
• 구성된 기타 헤더

이는 공격자가 발송 후 이러한 요소를 수정하는 것을 방지합니다.

DKIM 레코드 구조

DKIM 레코드는 특정 명명 형식으로 TXT 레코드로 게시됩니다:

selector._domainkey.yourdomain.com

선택자는 여러 DKIM 키를 가질 수 있게 하는 고유 식별자입니다. 서로 다른 이메일 서비스는 다른 선택자를 사용합니다 (예: brevo, google, s1, s2).

DKIM 레코드 내용:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

DKIM 설정

단계 1: DKIM 키 생성

이메일 서비스 공급업체가 일반적으로 키를 생성합니다. Brevo에서:

1. 설정 > 발신자, 도메인 및 전용 IP로 이동
2. 도메인 선택
3. DKIM 섹션으로 이동
4. 제공된 DNS 레코드 복사

자체 호스팅 메일 서버의 경우 OpenSSL을 사용하여 키를 생성하세요:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

단계 2: DKIM DNS 레코드 추가

DNS 관리에서:

• 유형: TXT
• 호스트/이름: selector._domainkey (예: brevo._domainkey)
• 값: 공급업체의 DKIM 레코드
• TTL: 3600

단계 3: DKIM 서명 활성화

이메일 공급업체 설정에서 도메인에 대한 DKIM 서명을 활성화하세요. 이는 공급업체에게 발신 메시지에 서명하도록 알려줍니다.

단계 4: 설정 확인

테스트 이메일을 발송하고 헤더에서 DKIM-Signature를 확인하세요. 다음 도구를 사용하세요:

• mail-tester.com
• DKIM Validator
• MXToolbox DKIM Lookup

DKIM 모범 사례

2048비트 키 사용:

구형 1024비트 키는 취약한 것으로 간주됩니다. 현대 보안 표준은 최소 2048비트 RSA 키를 권장합니다.

정기적으로 키 교체:

엄격하게 요구되지는 않지만 연간 DKIM 키 교체가 좋은 보안 관행입니다. 공백을 방지하기 위해 이전 키를 제거하기 전에 새 키를 추가하세요.

키 침해 모니터링:

개인 키가 침해되면 공격자가 대신 메시지에 서명할 수 있습니다. 비정상적인 인증 패턴을 모니터링하세요.

서비스별 다른 선택자 사용:

각 이메일 공급업체는 고유한 선택자를 사용해야 합니다. 이를 통해 독립적인 키 관리가 가능하고 다른 서비스와 충돌하지 않습니다.

DNS 전파 확인:

DKIM 키는 길 수 있습니다. DNS 공급업체가 충분한 길이의 TXT 레코드를 지원하는지 확인하세요. 일부 공급업체는 키를 여러 문자열로 분리할 것을 요구합니다.

DKIM 헤더 읽기

이메일을 받으면 DKIM-Signature 헤더에 다음이 표시됩니다:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;

DMARC (Domain-based Message Authentication, Reporting, and Conformance) 이해

DMARC는 SPF와 DKIM을 기반으로 정책 적용 및 보고를 제공합니다. 인증이 실패할 때 수신 서버가 무엇을 해야 하는지 알려주고 인증 결과에 대한 보고서를 전송합니다.

DMARC 작동 방식

DMARC는 두 가지 중요한 기능을 추가합니다:

1. 정책 적용: 수신자가 인증 실패를 처리하는 방법 정의
2. 보고: 도메인을 사용하여 이메일을 발송하는 사람에 대한 데이터 수신

DMARC 검증 프로세스:

1. 수신 서버가 도메인에서 온 것으로 주장하는 이메일 수신
2. SPF 확인 (발송 IP가 일치합니까?)
3. DKIM 확인 (서명이 유효합니까?)
4. DMARC 정렬 확인 (인증된 도메인이 From 헤더와 일치합니까?)
5. 정렬 실패 시 DMARC 정책 적용
6. 집계 및/또는 포렌식 보고서 전송

DMARC 정렬

DMARC는 From 헤더의 도메인과 SPF 또는 DKIM을 통과하는 도메인 간의 정렬을 요구합니다:

SPF 정렬: Return-Path(봉투 발신자)의 도메인이 From 헤더 도메인과 일치하거나 하위 도메인이어야 합니다.

DKIM 정렬: DKIM 서명의 도메인(d= 태그)이 From 헤더 도메인과 일치하거나 하위 도메인이어야 합니다.

정렬 모드:

완화 정렬에서 From 헤더가 [email protected]이고 DKIM이 brevo.example.com으로 서명하면, 두 도메인이 example.com 조직 도메인을 공유하기 때문에 정렬이 통과됩니다.

DMARC 레코드 구문

DMARC 레코드는 _dmarc.yourdomain.com에 TXT 레코드로 게시됩니다:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

필수 태그:

선택적 태그:

DMARC 정책 설명

p=none (모니터링만):

실패에 대한 조치 없음. 이메일이 정상적으로 전달됩니다. 보고서를 분석하고 인증 문제를 수정하는 동안 사용하세요.

v=DMARC1; p=none; rua=mailto:[email protected]

p=quarantine (스팸 폴더):

실패한 이메일이 스팸/정크 폴더로 발송됩니다. 완전한 거부 전 좋은 중간 단계입니다.

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

p=reject (차단):

실패한 이메일이 완전히 거부됩니다. 최대 보호이지만 모든 합법적인 소스가 먼저 통과하는지 확인하세요.

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

DMARC 설정

단계 1: SPF와 DKIM이 작동하는지 확인

DMARC는 SPF와 DKIM에 의존합니다. DMARC를 추가하기 전에 두 가지가 올바르게 구성되었는지 확인하세요.

단계 2: 모니터링으로 시작 (p=none)

전달에 영향을 주지 않고 데이터를 수집하기 위해 가장 허용적인 정책으로 시작하세요:

v=DMARC1; p=none; rua=mailto:[email protected]

단계 3: DNS 레코드 추가

DNS 관리에서:

• 유형: TXT
• 호스트/이름: _dmarc
• 값: DMARC 레코드
• TTL: 3600

단계 4: 2~4주 동안 보고서 분석

DMARC 집계 보고서는 XML 파일로 매일 도착합니다. 다음을 보여줍니다:

• 도메인을 사용하여 이메일을 발송한 IP
• SPF 및 DKIM 통과/실패율
• DMARC 정렬 결과
• 수신 서버 조치

이 데이터를 시각화하기 위해 DMARC 보고서 분석기를 사용하세요:

• DMARC Analyzer
• Postmark DMARC
• Valimail
• dmarcian

단계 5: 인증 문제 수정

보고서에서 드러나는 일반적인 문제:

• SPF에서 누락된 합법적인 서비스
• 발송 서비스에 DKIM 미활성화
• 제대로 인증되지 않은 제3자 서비스 발송
• 전달이 SPF 정렬을 깨뜨림

단계 6: 점진적으로 적용

합법적인 소스가 일관되게 통과하면:

1. p=quarantine; pct=10으로 이동 (실패의 10% 격리)
2. pct를 25, 50, 75, 100으로 증가
3. p=reject; pct=10으로 이동
4. 완전한 거부로 증가

단계 7: 유지 및 모니터링

계속 보고서를 검토하세요. 새로운 발송 소스, 공급업체 변경, 또는 구성 이탈이 인증 실패를 유발할 수 있습니다.

DMARC 보고서 이해

집계 보고서 (rua):

다음을 보여주는 일일 XML 요약:

• 보고 기관
• 날짜 범위
• 게시된 정책
• 소스 IP별 인증 결과
• 이메일 발송량

예시 발췌:

<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>

포렌식 보고서 (ruf):

실패에 대한 개별 메시지 세부 정보. 더 상세하지만 개인 정보에 민감합니다. 많은 수신자가 포렌식 보고서를 발송하지 않습니다.

DMARC 모범 사례

항상 p=none으로 시작:

reject로 직접 전환하면 합법적인 이메일이 차단될 수 있습니다. 먼저 모니터링하세요.

보고서를 위한 전용 이메일 주소 사용:

DMARC 보고서는 방대할 수 있습니다. 전용 주소나 제3자 서비스를 사용하세요.

하위 도메인 정책 설정 (sp=):

하위 도메인에서 이메일을 발송하지 않는다면 sp=reject를 설정하여 스푸핑으로부터 보호하세요.

점진적 배포를 위한 비율 (pct=) 사용:

pct 태그를 통해 나머지를 모니터링하면서 실패의 일부 비율에 정책을 적용할 수 있습니다.

전용 DMARC 서비스 고려:

대형 조직의 경우 Valimail, dmarcian, 또는 Postmark DMARC와 같은 서비스가 원시 XML 파일보다 더 나은 보고서 분석을 제공합니다.

DNS 레코드 설정: 완전한 안내

이메일 인증을 설정하려면 특정 DNS 레코드를 추가해야 합니다. 이 섹션은 주요 DNS 공급업체에 대한 완전한 안내를 제공합니다.

필요한 값 수집

시작 전에 이메일 공급업체에서 다음 값을 수집하세요:

SPF의 경우:

• 모든 include 구문 (예: include:spf.brevo.com)
• 승인해야 하는 특정 IP 주소

DKIM의 경우:

• 선택자 이름 (예: brevo, google, s1)
• 전체 DKIM 키 값

DMARC의 경우:

• 보고 이메일 주소

일반적인 DNS 공급업체에서 레코드 추가

Cloudflare:

1. Cloudflare 대시보드에 로그인
2. 도메인 선택
3. DNS > 레코드로 이동
4. 레코드 추가 클릭
5. SPF의 경우: 유형=TXT, 이름=@, 내용=SPF 레코드
6. DKIM의 경우: 유형=TXT, 이름=selector._domainkey, 내용=DKIM 키
7. DMARC의 경우: 유형=TXT, 이름=_dmarc, 내용=DMARC 레코드
8. 저장 클릭

Google Domains/Squarespace:

1. 도메인의 DNS 설정으로 이동
2. 사용자 정의 레코드로 스크롤
3. 사용자 정의 레코드 관리 클릭
4. 적절한 유형, 호스트, 데이터로 각 레코드 추가
5. SPF의 경우: 호스트=@, 유형=TXT, 데이터=SPF 레코드
6. DKIM의 경우: 호스트=selector._domainkey, 유형=TXT, 데이터=DKIM 키
7. DMARC의 경우: 호스트=_dmarc, 유형=TXT, 데이터=DMARC 레코드

GoDaddy:

1. 내 제품 > 도메인으로 이동
2. 도메인 옆의 DNS 클릭
3. 레코드 섹션으로 스크롤
4. 각 새 레코드에 대해 추가 클릭
5. 유형에 TXT 선택
6. 이름 입력 (SPF의 경우 @, DKIM의 경우 selector._domainkey, DMARC의 경우 _dmarc)
7. 값 입력
8. 저장

Namecheap:

1. 도메인 목록 > 관리로 이동
2. 고급 DNS 클릭
3. 각각에 대해 새 레코드 추가
4. TXT 레코드 선택
5. 호스트: SPF의 경우 @, DKIM의 경우 selector._domainkey, DMARC의 경우 _dmarc
6. 값: 레코드 내용
7. 모든 변경 저장

DNS 전파

레코드를 추가한 후 변경 사항이 전 세계적으로 전파되는 데 시간이 걸립니다. 일반적으로 다음 시간이 걸립니다:

• 초기 가시성에 5~30분
• 완전한 전 세계 전파에 최대 48시간

dig 또는 nslookup으로 확인하세요:

dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

또는 whatsmydns.net과 같은 온라인 도구를 사용하여 전 세계 전파를 확인하세요.

완전한 설정 예시

Brevo와 Google Workspace를 사용하는 도메인의 경우:

SPF 레코드 (@의 TXT):

v=spf1 include:spf.brevo.com include:_spf.google.com -all

Brevo의 DKIM 레코드 (brevo._domainkey의 TXT):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [Brevo 대시보드의 키]

Google의 DKIM 레코드 (google._domainkey의 TXT):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [Google Admin의 키]

DMARC 레코드 (_dmarc의 TXT):

v=DMARC1; p=none; rua=mailto:[email protected]

일반적인 문제 해결

신중하게 설정하더라도 이메일 인증이 실패할 수 있습니다. 일반적인 문제와 해결 방법입니다.

SPF 문제 해결

SPF 레코드를 찾을 수 없음:

증상: SPF 확인이 “none” 또는 “no record” 표시

원인:

• DNS에 레코드가 추가되지 않음
• 잘못된 위치에 레코드 추가 (루트 대신 하위 도메인)
• DNS 전파 미완료

해결책:

• dig TXT yourdomain.com으로 레코드 존재 확인
• 이름/호스트 필드 확인 (루트 도메인의 경우 @ 또는 비워두기)
• DNS 전파 대기 (최대 48시간)

SPF PermError (조회 수 초과):

증상: SPF 결과가 “permerror” 표시

원인:

• SPF 레코드에 10개 이상의 DNS 조회
• 과도한 중첩 include가 포함된 include

해결책:

• include를 감사하고 사용하지 않는 것 제거
• 가능한 경우 ip4: 항목으로 include 교체
• SPF 평탄화 서비스 사용
• 더 적은 공급업체에 서비스 통합

합법적인 메일에 대한 SPF SoftFail 또는 Fail:

증상: 합법적인 이메일이 SPF 실패

원인:

• 발송 서비스가 SPF에 포함되지 않음
• 승인되지 않은 IP에서 발송
• 봉투 발신자를 변경하는 릴레이 사용

해결책:

• 발송 서비스를 위한 누락된 include 추가
• 실제로 이메일을 발송한 IP 확인 (헤더에서)
• 올바른 SPF 설정을 위해 이메일 공급업체에 문의

여러 SPF 레코드:

증상: SPF가 퍼마에러 또는 무작위 실패 표시

원인:

• v=spf1을 포함하는 두 개 이상의 TXT 레코드

해결책:

• 모든 메커니즘을 단일 SPF 레코드로 결합
• 중복 SPF 레코드 삭제

DKIM 문제 해결

DKIM 서명 누락:

증상: 이메일에 DKIM-Signature 헤더 없음

원인:

• 이메일 공급업체에서 DKIM 서명 미활성화
• 도메인 검증 미완료
• DKIM이 아닌 경로를 통해 발송

해결책:

• 공급업체 설정에서 DKIM 활성화
• 도메인 검증 단계 완료
• DKIM 설정을 위한 공급업체 문서 확인

DKIM 검증 실패:

증상: DKIM이 인증 결과에서 “fail” 표시

원인:

• DNS 레코드가 게시되지 않았거나 잘못됨
• 잘못된 선택자 사용
• DNS와 서명 간의 키 불일치
• 전송 중 메시지 수정

해결책:

• selector._domainkey.domain에 DNS 레코드 존재 확인
• DKIM-Signature 헤더의 선택자와 DNS 비교
• 불일치가 의심되면 키 재생성
• 메시지를 수정하는 메일 필터 또는 릴레이 확인

DNS에서 DKIM 키가 너무 긴 경우:

증상: DKIM 레코드를 저장할 수 없음, 잘림 오류

원인:

• 2048비트 키가 단일 TXT 레코드 길이 초과
• DNS 공급업체에 문자 제한

해결책:

• 키를 여러 인용 문자열로 분할 (대부분의 공급업체가 자동으로 처리)
• DNS 공급업체가 긴 TXT 레코드를 지원하는지 확인
• 임시로 1024비트 키 사용 (보안 낮음)

분할된 DKIM 레코드 예시:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...키의 계속..."

DMARC 문제 해결

DMARC 정렬 실패:

증상: SPF와 DKIM은 통과하지만 DMARC 실패

원인:

• 인증된 도메인이 From 헤더 도메인과 일치하지 않음
• 제3자 발송 서비스가 자체 도메인 사용
• 봉투 발신자 잘못 구성

해결책:

• 이메일 공급업체가 도메인으로 서명하는지 확인 (사용자 정의 DKIM)
• 사용자 정의 Return-Path/봉투 발신자 구성
• 완화 정렬 모드 사용 (adkim=r; aspf=r)

DMARC 보고서를 받지 못하는 경우:

증상: 집계 보고서가 도착하지 않음

원인:

• rua 주소 잘못됨
• 이메일 주소가 외부 이메일을 받을 수 없음
• 보고서가 스팸으로 분류됨
• 수신 서버가 보고서를 발송하지 않음

해결책:

• rua 구문 확인: rua=mailto:[email protected]
• 보고 주소가 외부 메일을 받을 수 있는지 테스트
• 보고서를 위해 스팸 폴더 확인
• 참고: 모든 수신자가 DMARC 보고서를 발송하지는 않음

DMARC 레코드를 찾을 수 없음:

증상: DMARC 확인이 “no record” 표시

원인:

• 잘못된 위치에 레코드 게시
• 잘못된 형식 사용 (반드시 _dmarc 하위 도메인의 TXT여야 함)

해결책:

• 레코드는 _dmarc.yourdomain.com에 있어야 함
• dig TXT _dmarc.yourdomain.com으로 확인

일반적인 문제 해결 도구

온라인 유효성 검사기:

• MXToolbox (mxtoolbox.com) - SPF, DKIM, DMARC 조회
• Mail Tester (mail-tester.com) - 전체 분석을 위한 테스트 이메일 발송
• DMARC Analyzer - 보고서 시각화
• Google Admin Toolbox - MX, SPF, DKIM 확인

명령줄 도구:

# SPF 확인
dig TXT yourdomain.com

# DKIM 확인
dig TXT selector._domainkey.yourdomain.com

# DMARC 확인
dig TXT _dmarc.yourdomain.com

# 특정 DNS 서버에서 확인
dig @8.8.8.8 TXT yourdomain.com

이메일 헤더 분석:

수신 이메일의 Authentication-Results 헤더 확인:

Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com

이메일 인증과 Brevo

Brevo는 포괄적인 이메일 인증 지원을 제공하여 발송 도메인에 대한 SPF, DKIM, DMARC 구성을 간단하게 만들어줍니다.

Brevo에서 인증 설정

단계 1: 도메인 추가

1. Brevo 계정에 로그인
2. 설정 > 발신자, 도메인 및 전용 IP로 이동
3. 도메인 추가 클릭
4. 도메인 이름 입력

단계 2: SPF 구성

Brevo는 DNS에 추가할 SPF include를 제공합니다:

include:spf.brevo.com

기존 SPF 레코드에 추가하거나 새로 만드세요:

v=spf1 include:spf.brevo.com -all

단계 3: DKIM 구성

Brevo는 DKIM 키를 자동으로 생성합니다. 제공된 레코드를 복사하세요:

1. Brevo에서 도메인 설정으로 이동
2. DKIM 섹션 찾기
3. DNS 레코드 이름과 값 복사
4. DNS에 TXT 레코드 추가

단계 4: 구성 확인

Brevo는 자동으로 DNS 레코드를 확인합니다. 녹색 체크마크는 성공적인 구성을 나타냅니다.

Brevo 인증의 올바른 구성의 이점

Brevo로 인증을 올바르게 구성하면:

• 높은 받은 편지함 도달: Gmail, Microsoft 등이 인증된 메시지를 신뢰
• 브랜드 보호: DMARC가 도메인 스푸핑 방지
• 더 나은 분석: 열람 및 클릭의 정확한 추적
• 평판 구축: 일관된 인증이 발신자 평판 향상

Tajo 통합의 이점

Tajo를 사용하여 Shopify 스토어를 Brevo와 연결하면 추가 이점이 있습니다:

• 자동 고객 동기화: 개인화된 이메일을 위한 고객 데이터 원활한 흐름
• 이벤트 추적: 구매, 브라우징, 장바구니 이벤트가 인증된 트랜잭셔널 이메일 트리거
• 멀티채널 조율: 이메일, SMS, WhatsApp 전반에 걸쳐 일관된 인증 유지
• 통합 분석: 다른 마케팅 지표와 함께 이메일 성과 추적

적절한 이메일 인증과 실시간 고객 데이터 동기화의 결합은 이메일이 받은 편지함에 도달할 뿐만 아니라 각 수신자에게 공감하도록 보장합니다.

자주 묻는 질문

SPF, DKIM, DMARC의 차이점은 무엇입니까?

SPF는 도메인에 대한 이메일을 발송할 수 있는 서버를 지정합니다. DKIM은 메시지 진위를 증명하는 암호화 서명을 추가합니다. DMARC는 수신자가 인증 실패를 처리하는 방법에 대한 정책을 설정하고 보고를 제공합니다. 세 가지 모두 완전한 이메일 인증을 위해 함께 작동합니다.

SPF, DKIM, DMARC 세 가지 모두 필요합니까?

최적의 전달성과 보안을 위해서는 그렇습니다. SPF 단독은 스푸핑에 취약합니다. DKIM 단독은 정책을 지정하지 않습니다. DMARC는 SPF 또는 DKIM이 있어야 작동합니다. 세 가지를 함께 사용하면 포괄적인 보호와 최고의 받은 편지함 도달률을 제공합니다.

이메일 인증이 작동하는 데 얼마나 걸립니까?

DNS 변경은 일반적으로 30분에서 48시간 내에 전파됩니다. 전파되면 인증이 즉시 적용됩니다. 그러나 일관된 인증을 기반으로 발신자 평판을 쌓는 데는 몇 주에서 몇 달이 걸립니다.

p=reject로 DMARC를 설정하면 합법적인 이메일이 차단됩니까?

잘못 구성하면 그럴 수 있습니다. 항상 p=none (모니터링)으로 시작하고, 2~4주 동안 보고서를 분석하고, 문제를 수정한 다음, 점진적으로 quarantine과 reject로 이동해야 하는 이유입니다. 모니터링 단계를 절대 건너뛰지 마세요.

SPF 정렬 vs DKIM 정렬이란 무엇입니까?

정렬은 인증된 도메인이 표시되는 From 헤더 도메인과 일치한다는 의미입니다. SPF 정렬은 Return-Path 도메인을 비교합니다. DKIM 정렬은 서명 도메인(d= 태그)을 비교합니다. DMARC는 최소 하나가 정렬되어야 합니다.

하나의 도메인에 여러 DKIM 키를 가질 수 있습니까?

그렇습니다. 각 이메일 서비스는 다른 선택자를 사용할 수 있습니다 (예: brevo._domainkey, google._domainkey). 이를 통해 여러 서비스가 DKIM으로 독립적으로 서명할 수 있습니다. DKIM 선택자의 수에는 제한이 없습니다.

인증 설정 후에도 이메일이 스팸으로 가는 이유는 무엇입니까?

인증은 받은 편지함 도달에 필요하지만 충분하지 않습니다. 다른 요소로는 발신자 평판, 콘텐츠 품질, 참여율, 목록 위생이 있습니다. 인증으로 첫 번째 필터를 통과하고, 좋은 관행이 최종 배치를 결정합니다.

DMARC 집계 보고서를 어떻게 읽습니까?

DMARC 집계 보고서는 XML 파일입니다. dmarcian, Postmark DMARC, 또는 DMARC Analyzer와 같은 도구를 사용하여 파싱하고 시각화하세요. 이 도구들은 어떤 IP가 도메인으로 이메일을 발송하는지와 인증 통과/실패율을 보여줍니다.

SPF 10개 조회 제한을 초과하면 어떻게 됩니까?

SPF가 영구 오류(permerror)를 반환하고 모든 SPF 확인이 실패합니다. 이를 수정하려면 사용하지 않는 include를 제거하거나, 가능한 경우 IP 주소로 include를 교체하거나, SPF 평탄화 서비스를 사용하세요.

SPF 레코드에서 -all과 ~all 중 무엇을 사용해야 합니까?

테스트하고 신뢰를 구축하는 동안에는 ~all (소프트실패)을 사용하세요. 모든 합법적인 소스가 통과하는 것을 확인하면 더 강한 보호를 위해 -all (하드 실패)로 전환하세요. 소프트실패는 실패를 표시하지만 거부하지 않습니다. 하드 실패는 거부를 승인합니다.

DKIM 키를 얼마나 자주 교체해야 합니까?

엄격한 요구 사항은 없지만 연간 교체가 좋은 보안 관행입니다. 교체할 때는 새 키를 먼저 추가하고, DNS 전파를 기다리고, 새 키로 서명을 활성화한 다음, 전환 기간 후에 이전 키를 제거하세요.

하위 도메인에는 별도의 인증이 필요합니까?

SPF: 그렇습니다. 이메일을 발송하는 각 하위 도메인에는 자체 SPF 레코드가 필요합니다. DKIM: 키는 하위 도메인별로 공유하거나 별도로 사용할 수 있습니다. DMARC: 하위 도메인은 sp=가 설정되거나 하위 도메인에 자체 DMARC 레코드가 없는 한 상위 정책을 상속합니다.

결론

SPF, DKIM, DMARC를 통한 이메일 인증은 이메일 커뮤니케이션에 의존하는 비즈니스에게 더 이상 선택 사항이 아닙니다. 이 프로토콜들은 브랜드를 스푸핑으로부터 보호하고, 전달성을 향상시키며, 효과적인 이메일 마케팅에 필요한 신뢰를 구축합니다.

핵심 요점:

• SPF는 DNS를 통해 발송 서버를 승인합니다
• DKIM은 암호화 서명으로 메시지 진위를 증명합니다
• DMARC는 정책을 적용하고 보고서를 통해 가시성을 제공합니다
• 거부를 적용하기 전에 모니터링(p=none)으로 시작하세요
• 모든 합법적인 발송 소스가 올바르게 구성되어야 합니다
• 정기적인 모니터링이 구성 이탈을 방지합니다

Shopify를 사용하는 전자상거래 비즈니스에게, Tajo와 Brevo를 통한 고객 데이터 통합과 함께 적절한 이메일 인증을 결합하면 강력한 기반이 만들어집니다. 트랜잭셔널 이메일이 고객에게 안정적으로 도달하고, 마케팅 캠페인이 더 나은 받은 편지함 도달률을 달성하며, 브랜드가 스푸핑 공격으로부터 보호됩니다.

이메일 전달성을 향상시킬 준비가 되셨나요? 이 가이드에서 언급된 도구로 현재 인증 설정을 감사하는 것부터 시작한 다음, 제공된 단계별 지침에 따라 SPF, DKIM, DMARC를 체계적으로 구성하세요.

Tajo가 Brevo와 통합하는 방법 알아보기로 Shopify 스토어를 위한 실시간 고객 데이터 동기화와 함께 원활한 이메일 인증을 제공합니다.

관련 아티클

• 이메일 마케팅 캠페인: 계획, 실행, 최적화 완벽 가이드
• 이메일 마케팅 전략: 완벽한 계획 및 실행 가이드 [2025]
• 소규모 비즈니스를 위한 이메일 마케팅: 완벽 가이드 (2026)
• 이메일 마케팅 ROI: 계산, 추적 및 수익 개선 방법 [2025]
• 초보자를 위한 이메일 마케팅: 시작 완벽 가이드 (2026)