SPF, DKIM, DMARC 이후의 이메일 인증 점검

이메일 인증: SPF, DKIM, DMARC를 설정해도 충분하지 않은 이유

필요한 설정은 모두 마쳤습니다. DNS 화면에서 몇 시간 동안 이메일 서비스 업체가 제공한 복잡한 문자열을 복사하고, 검증 도구도 실행해 모든 항목에 초록색 확인 표시가 뜨는 것을 보았습니다. 그런데도 열람률은 왜 떨어질까요? 비밀번호 재설정, 청구서, 알림 같은 트랜잭션 메일은 왜 스팸함에 들어가거나 아예 사라질까요?

SPF, DKIM, DMARC 이메일 인증에서 기억할 사실은 분명합니다. 유효한 설정과 좋은 발신 평판은 같은 것이 아닙니다. 유효한 신분증이 있다고 해서 누구나 출입을 허가받는 것은 아닌 것과 같습니다. 2024년 이월 이후 Google과 Yahoo 같은 사업자는 대량 발신자 요건을 강화했고, Microsoft도 자체 신호와 정책을 적용합니다. 관리 화면에는 초록불이 켜져 있는데 매출 지표에 경고가 나타난다면, 기본 인증 규약 밖에 있는 숨은 관문에 걸렸을 가능성이 큽니다.

대량 발신자의 함정: 생각보다 낮은 기준

가장 위험한 오해는 이렇습니다. "하루에 5,000통보다 적게 보내니 대량 발신 규칙은 나에게 적용되지 않는다."

두 가지 이유에서 틀린 생각이며, SPF, DKIM, DMARC를 정확히 설정해도 이 함정을 피할 수는 없습니다. 첫째, Google은 기본 도메인 단위로 발신량을 합산합니다. news.example.com에서 마케팅 메일 2,000통, app.example.com에서 트랜잭션 메일 2,000통, corp.example.com에서 내부 알림 1,500통을 보낸다면 대량 발신자에 해당합니다. 하위 도메인의 발신량도 루트 도메인에 합산됩니다.

둘째, 한 번 도달한 최고 발신량이 기준이 됩니다. 블랙 프라이데이 캠페인이나 일회성 데이터베이스 안내로 5,000통 기준을 한 번이라도 넘으면 Google은 해당 기본 도메인을 계속 대량 발신자로 취급합니다. 이후 하루 발신량이 50통으로 줄어도 강화된 준수 요건은 계속 적용됩니다.

Microsoft는 여러 신호를 자체 방식으로 평가합니다. SPF, DKIM, DMARC 레코드가 완벽해도 IP 주소의 사용 기간과 평판이 영향을 줄 수 있습니다. 새 도메인과 새 IP를 만든 직후 2,000통을 한꺼번에 보내면 SPF 결과와 별개로 4xx 제한을 받을 수 있습니다. 새 발신자에게는 아직 쌓인 평판이 없기 때문입니다.

SPF, DKIM, DMARC가 실패하는 지점: 세 요소의 연결

많은 운영자가 SPF, DKIM, DMARC를 설정하고 문법 검사를 통과하면 더 이상 살펴보지 않습니다. 그러나 올바른 문법이 실제 동작까지 보장하지는 않습니다. 다음 지점에서 문제가 자주 발생합니다.

SPF: 전달 과정에서 생기는 사각지대

SPF는 허용된 IP 목록과 비슷합니다. 이를테면 "IP 1.2.3.4는 example.com을 대신해 발신할 수 있다"라고 알립니다. 수신자가 자동 전달을 설정하기 전까지는 잘 동작합니다.

client@smallbiz.com으로 청구서를 보냈다고 가정해 보겠습니다. 이 고객은 모든 메일을 client@gmail.com으로 전달합니다. Gmail에는 원래 발신 IP가 아니라 smallbiz.com의 IP에서 연결된 것으로 보입니다. Gmail이 발신 도메인의 SPF 레코드를 확인하면 smallbiz.com이 포함되어 있지 않아 SPF가 실패할 수 있습니다. SPF에만 의존하면 전달된 메일이 스팸으로 분류되거나 거부될 수 있습니다. 이 구간을 통과하려면 유효하고 정렬된 DKIM 서명이 필수입니다. 전체 설정 방법은 SPF 레코드 안내서를 참고하세요.

DKIM: 도메인 정렬 문제

DMARC는 두 가지를 확인합니다. RFC 6376에 따른 DKIM 또는 SPF가 통과했는지, 그리고 관련 도메인이 정렬되는지입니다. 정렬이란 From 헤더의 도메인이 기술 헤더의 도메인, 즉 SPF의 Return-Path 또는 DKIM의 d= 값과 일치하는 관계를 뜻합니다.

고객 지원에서 흔히 만나는 사례가 있습니다. Zendesk나 HubSpot 같은 CRM으로 support@yourcompany.com 주소에서 메일을 보냅니다. 반송 처리는 CRM이 맡으므로 Return-Path는 bounces.zendesk.com이 되고 SPF 정렬이 실패합니다. 사용자 지정 CNAME을 설정하지 않았다면 DKIM은 d=zendesk.com으로 서명되어 DKIM 정렬도 실패합니다. 이 메일은 Zendesk가 보낸 것으로 기술적인 인증을 받았지만, DMARC 관점에서는 자사 도메인과 정렬된 인증 방식이 없습니다. 정책이 p=reject라면 메일이 거부될 수 있습니다.

DNS 조회 10회 제한

RFC 7208이 정의한 SPF에는 평가당 DNS 조회 10회라는 엄격한 상한이 있습니다. 여러 SaaS 도구를 쓰는 고객을 관리하는 대행사라면 쉽게 마주치는 문제입니다. Google Workspace만으로도 조회 4회를 사용할 수 있습니다. 여기에 Mailchimp, HubSpot, 티켓 시스템과 인사 관리 도구를 추가해 보겠습니다.

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com ~all

각 include: 방식은 DNS 조회를 일으키며, 포함된 레코드 안에 또 다른 include가 중첩될 수도 있습니다. 전체 조회가 10회를 넘으면 수신 서버는 PermError를 반환합니다. 이 경우 SPF에서 기대한 유효한 결과를 얻지 못합니다. 꼼꼼하게 추가하려던 설정이 오히려 인증을 무효로 만들 수 있습니다.

SPF, DKIM, DMARC 밖에 있는 숨은 관문

잘 알려진 세 가지 인증 방식 외에도 눈에 띄는 이름은 없지만 메일 수신을 막을 수 있는 기술 요건이 있습니다.

FCrDNS(정방향 확인 역방향 DNS)

각 발신 IP에는 호스트 이름으로 해석되는 PTR 레코드가 있어야 하며, 해당 호스트 이름의 A 레코드는 다시 원래 IP를 가리켜야 합니다. 이런 순환 검증은 발신 인프라를 일관되게 식별하는 데 도움이 됩니다. 클라우드 가상 머신을 만들고 Postfix를 설치한 뒤 PTR 레코드 없이 메일을 보내면 Gmail이 트래픽을 의심스럽게 판단해 550 5.7.1 같은 응답을 반환할 수 있습니다.

RFC 8058: 원클릭 수신 거부

2024년 유월 이후 특정 대량 발신자의 마케팅 메일은 바닥글 링크만으로 요건을 충족하지 못합니다. 해당 메일에는 다음 두 헤더가 필요합니다.

List-Unsubscribe: <https://example.com/unsub>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

HTTPS 엔드포인트는 GET이 아니라 POST 요청을 받아야 합니다. 스팸 방지 봇은 링크를 따라가며 메일을 검사하기도 합니다. GET 요청만으로 즉시 구독을 취소하면 봇이 실제 사용자를 실수로 해지할 수 있습니다. 사용자가 쉽게 수신을 거부하지 못하면 대신 "스팸 신고"를 누를 가능성이 커지고, 신고율은 0.3% 기준에 가까워질 수 있습니다.

0.3% 기준: 평판이 만드는 결과

SPF, DKIM, DMARC가 모두 통과하고 FCrDNS와 헤더가 정확해도 수신자가 콘텐츠를 원하지 않으면 충분하지 않습니다.

핵심 지표 중 하나는 스팸 신고율입니다. Google은 이를 0.3% 미만, 즉 신고 3건보다 적은 수준으로 관리하되 전달된 메일 1,000통을 기준으로 그보다 훨씬 낮게 유지할 것을 권고합니다. 높은 신고율이 반복되면 발신이 제한되거나 차단될 수 있습니다.

Yahoo 지표에서 분모를 오해하는 함정

표시되는 신고율은 사업자가 어떤 전달 메일을 분모에 포함하는지에 따라 달라질 수 있습니다. 1,000통을 보냈다고 가정해 보겠습니다. 도메인 평판이 이미 좋지 않아 900통은 스팸함으로 가고 100통만 받은편지함에 도착합니다. 그중 한 명이 신고하면 이 예시의 받은편지함 집단에서는 1/100 = 1.0%가 되어 기준의 3x에 해당합니다. 따라서 사업자 대시보드의 지표 정의를 확인하고 전체 발신량만으로 판단하지 마세요.

문제 있는 이웃과 공유 IP

SPF, DKIM, DMARC를 정확히 구성해도 일반 공유 호스팅이나 저가형 "무제한" 이메일 플랫폼에서는 수천 고객과 같은 IP로 메일이 발송될 수 있습니다. 그중 한 발신자가 사기를 벌여 IP가 Spamhaus 같은 차단 목록에 오르면 정상적인 메일까지 영향을 받을 수 있습니다. 직접 잘못한 일이 없어도 인프라의 평판을 공유하기 때문입니다. 실제 위험은 서비스 업체의 감시와 격리 수준에 따라 달라집니다.

발신 방식	평판 관리 주체	적합한 대상
공유 IP(대부분의 ESP)	서비스 업체, 다른 발신자의 영향도 받을 수 있음	업체의 관리 정책을 신뢰하는 소량 발신자
관리형 SMTP(TrekMail Starter/Pro)	TrekMail, 엄격한 스팸 방지 정책을 적용하고 악성 발신자에 대응	관리형 전달 서비스를 원하는 기업
직접 연결 SMTP(TrekMail Free + 유료)	사용자, Amazon SES, SendGrid 또는 Mailgun 전용 IP 등을 연결	격리 수준을 직접 관리하려는 대행사와 대량 발신자

금요일에 확인할 SPF, DKIM, DMARC 점검표

1. 헤더 확인: 개인 Gmail 주소로 메일을 보냅니다. 메일을 열고 점 세 개 메뉴에서 "원본 보기"를 선택한 뒤 Authentication-Results를 찾습니다. SPF와 DKIM이 통과했나요? dkim= 도메인이 header.from 도메인과 일치하나요? 그렇지 않다면 정렬 문제를 확인해야 합니다.

2. FCrDNS 확인: dig -x <your-sending-ip>를 실행합니다. 호스트 이름이 반환되나요? 이어서 dig <that-hostname>을 실행했을 때 원래 IP가 나오나요? 순환이 맞지 않으면 발신량을 늘리기 전에 DNS를 바로잡으세요.

3. 트래픽 분리: 마케팅 메일은 기본 회사 도메인과 분리하는 편이 좋습니다. 사람이 주고받는 메일에는 team@company.com을, 캠페인에는 newsletter@marketing.company.com을 사용하세요. 마케팅 신고율이 0.3% 기준에 닿더라도 이런 분리는 기본 도메인의 평판을 보호하는 데 도움이 되지만 절대적인 보장은 아닙니다.

4. 더 알아보기: 평판을 개선하는 실제 방법은 이메일 발신자 평판 안내서와 이메일 도메인 평판 심층 안내서에서 확인하세요.

TrekMail 요금제

요금제	가격	인증 기능
Free	$0	직접 연결 SMTP, 전체 IP 제어(카드 불필요)
Starter	$3.50/월	관리형 SMTP, DKIM 자동 생성
Pro	$10/월	여러 도메인, DNS 검증 대시보드
Agency	.25/월	공유 스토리지, DNS 일괄 설정, 관리형 평판 정책

설명된 모든 유료 요금제에는 카드가 필요한 14일 체험이 포함됩니다. Free에는 카드가 필요하지 않습니다. 가입 전에 최신 가격과 조건을 확인하세요.

마무리

SPF, DKIM, DMARC 이메일 인증은 한 번 설정하고 잊어도 되는 작업이 아니라 지속적인 운영 요건입니다. 인증 통과는 기본 조건일 뿐입니다. 받은편지함에 도달할 가능성을 높이려면 정확한 도메인 정렬, FCrDNS를 포함한 네트워크 관리, 원클릭 수신 거부 헤더와 평판 관리가 함께 필요합니다. 어떤 단일 설정도 받은편지함 배치를 보장하지 않습니다. 결과를 계속 점검하고 발신 인프라를 통제하세요.