이메일이 스팸함으로 가는 문제 해결 방법: SPF, DKIM & DMARC 가이드

이메일이 스팸함으로 가는 이유

정상적인 이메일이 스팸함으로 분류되는 원인은 거의 항상 다음 세 가지 중 하나입니다. 인증(SPF, DKIM, DMARC)이 누락되었거나 잘못된 경우, 발신자 평판이 좋지 않은 경우(불량 IP, 역방향 DNS 부재, 스팸 신고), 또는 콘텐츠 및 목록 관리 문제입니다. Gmail, Outlook, 기업용 게이트웨이 같은 스팸 필터는 모든 메시지에 점수를 매기는데, 인증 문제를 해결하면 보통 가장 크고 빠른 개선 효과를 얻을 수 있습니다.

이 가이드는 중요도 순서대로 각 계층을 차근차근 짚어 갑니다. 아래 DNS 레코드는 일반적인 자리 표시자를 사용하므로, example.com을 본인의 도메인으로 바꾸고 메일 제공업체에서 제공하는 정확한 값을 사용하세요. 비즈니스 이메일이나 발송 애플리케이션을 Skyline Cloud에서 호스팅하는 경우, 이러한 레코드는 제어판에서 자동으로 생성됩니다.

1단계: 변경하기 전에 문제부터 확인하기

Gmail 계정으로 테스트 메시지를 보낸 뒤 메일을 열고 원본 보기(점 세 개 메뉴)를 사용하세요. 상단 부근에서 다음과 같은 내용을 확인할 수 있습니다.

SPF:   PASS with IP 203.0.113.10
DKIM:  PASS with domain example.com
DMARC: PASS

어느 한 줄이라도 FAIL, SOFTFAIL, 또는 NONE으로 표시된다면 그것이 바로 원인입니다. 또한 Google의 Check MX 또는 mail-tester.com 같은 도구로 메시지 헤더를 확인하면 수치 점수와 체크리스트를 제공받을 수 있습니다. 추측하지 말고, 어느 레코드가 잘못되었는지 진단 결과가 알려주도록 하세요.

2단계: 올바른 SPF 레코드 게시하기

SPF는 어떤 서버가 도메인을 대신해 메일을 보낼 수 있는지를 수신 측에 알려줍니다. 도메인 루트에 하나의 TXT 레코드를 게시합니다.

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.alskyline.com -all

사람들이 자주 걸려 넘어지는 규칙은 다음과 같습니다.

• 도메인당 SPF 레코드는 단 하나만 가질 수 있습니다. v=spf1 레코드가 여러 개이면 영구 실패(permanent fail)가 발생하므로 하나로 병합하세요.
• 여러분을 대신해 메일을 발송하는 모든 서비스(메일 호스트, 마케팅 플랫폼, 앱 서버)에 대해 include:를 사용하세요.
• 엄격한 적용을 원하면 -all(하드 페일)로 끝내고, 테스트 중이라면 ~all(소프트 페일)로 끝내세요.
• SPF는 DNS 조회 10회를 초과해서는 안 됩니다. include: 구문이 너무 많으면 permerror가 발생합니다.

3단계: DKIM 서명 활성화하기

DKIM은 각 메시지에 암호학적 서명을 추가하여 수신 측이 메시지가 변조되지 않았으며 실제로 여러분의 도메인에서 왔음을 확인할 수 있게 합니다. 제공업체는 셀렉터(selector) 서브도메인에 TXT(또는 CNAME) 레코드로 게시할 공개 키를 제공합니다.

Type:  TXT
Host:  s1._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

게시한 후에는 메일 제어판에서 해당 사서함 또는 도메인의 서명을 활성화하세요. 새 테스트 메시지에서 DKIM: PASS가 나오는지 확인합니다. 셀렉터(위의 s1)는 서버가 서명에 사용하는 값과 정확히 일치해야 합니다.

4단계: DMARC 정책 추가하기

DMARC는 SPF와 DKIM을 하나로 묶어, 인증 실패 시 수신 측이 어떻게 처리할지 알려주고 보고서를 보내줍니다. 본인의 메일을 차단하지 않도록 모니터링 모드로 시작하세요.

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

보고서를 통해 정상적인 메일이 통과되는 것이 확인되면(1~2주 정도 기다리세요), 정책을 강화하세요.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

그런 다음 스푸핑에 대한 완전한 보호를 위해 p=reject로 전환하세요. 절대 처음부터 p=reject로 시작하지 마세요. 정렬(alignment)이 검증되기 전에 본인의 메시지가 격리될 위험이 있습니다.

5단계: 역방향 DNS(PTR)와 실제 HELO 이름 설정하기

자체 서버나 VPS에서 메일을 발송하는 경우, 발송 IP에는 호스트명으로 다시 해석되는 PTR 레코드가 있어야 하며, 그 호스트명에는 일치하는 정방향 A 레코드가 있어야 합니다. 역방향 DNS가 일치하지 않거나 없는 것은 메일이 거부되거나 스팸으로 채점되는 가장 흔한 이유 중 하나입니다.

# 발송 IP의 PTR 확인
dig -x 203.0.113.10 +short
# Expected: mail.example.com.

# 정방향 레코드가 일치하는지 확인
dig +short A mail.example.com
# Expected: 203.0.113.10

PTR 레코드는 DNS 등록 대행업체가 아니라 해당 IP 블록을 관리하는 주체, 즉 호스팅 제공업체가 설정합니다. Skyline VPS 또는 클라우드 서버에서는 제어판을 통해 PTR을 요청할 수 있습니다. 메일 서버의 HELO/EHLO 인사말이 짧거나 내부용 이름이 아니라 그와 동일한 정규화된 호스트명(FQDN)을 사용하도록 하세요.

6단계: 콘텐츠 및 목록 관리 개선하기

인증은 받은편지함까지 도달하게 해주지만, 거기에 머무르게 하는 것은 콘텐츠입니다.

• 메일을 기다리는 사람에게 보내세요. 높은 반송률과 스팸 신고는 그 무엇보다 빠르게 평판을 망칩니다. 유효하지 않은 주소를 제거하고 수신 거부 요청은 즉시 존중하세요.
• 텍스트와 이미지 비율을 깔끔하게 유지하세요. 이미지만 있는 이메일, 다수의 단축 링크, 또는 오해를 일으키는 제목은 점수를 높입니다.
• 대량 메일에는 List-Unsubscribe 헤더를 추가하세요.(대량 발신자의 경우 Gmail과 Yahoo가 요구합니다.)
• 새 IP와 도메인은 점진적으로 워밍업하세요. 콜드 IP에서 갑작스럽게 대량 발송하면 스팸처럼 보입니다.
• From 주소를 인증된 도메인과 일치시키세요. 다른 곳의 SPF/DKIM이 유효하더라도 정렬에 실패하는 From: you@example.com 봉투는 불이익을 받습니다.

7단계: 검증 및 모니터링

레코드가 전파된 후(DNS TTL에 따라 최대 몇 시간 정도 소요될 수 있음), Gmail 원본 보기 테스트를 다시 수행하여 세 줄 모두 PASS가 되는 것을 목표로 하세요. mail-tester.com으로 수치 점수를 확인하고 9~10/10점을 목표로 하세요. 그런 다음 평판 하락을 조기에 포착할 수 있도록 DMARC rua 보고서와 제공업체의 도달률 대시보드를 계속 주시하세요.

사우디/GCC 참고 사항

사우디 왕국 내 조직의 경우, 메일과 데이터를 왕국 내에 보관하면 PDPL 데이터 거주(data-residency) 요건을 충족하는 데 도움이 되고, 도달률 문제가 급할 때 아랍어로 지원받을 수 있습니다. 비즈니스 이메일과 발송 인프라를 현지 제공업체에서 호스팅하면 PTR/rDNS 및 DNS 변경을 여러 해외 업체가 아닌 하나의 책임 있는 팀을 통해 처리할 수 있다는 의미이기도 합니다. 애플리케이션 및 SMTP 발송에 대한 더 자세한 안내는 트랜잭션 이메일 & SMTP 클러스터를 참고하세요.

요약

대부분의 스팸 문제는 세 가지 레코드로 해결됩니다. 단일의 올바른 SPF, 정상 동작하는 DKIM 서명, 점진적인 DMARC 정책이며, 여기에 유효한 역방향 DNS와 깔끔한 발송 습관이 뒷받침됩니다. 실제 테스트 메시지로 검증한 다음, 보고서를 모니터링하세요.

이러한 레코드가 미리 구성된, 안정적인 왕국 내 비즈니스 이메일이 필요하신가요? Skyline Cloud 계정을 만들고 첫날부터 인증된 메일을 사용하세요.