SPF·DKIM·DMARC는 PASS인데, 왜 스팸함에 들어갈까?

‘발송 성공’과 ‘받은편지함 도착’ 사이에는 단계가 있습니다

발송 서비스 화면의 성공 표시부터 뜻을 확인해야 합니다. 어떤 서비스는 발송 요청을 접수하면 성공으로 표시하고, 다른 서비스는 상대 서버가 메일을 받아들인 뒤에 배달 완료로 표시합니다. 이름이 같아도 확인한 지점이 다를 수 있습니다.

서버끼리 메일을 주고받는 절차를 SMTP라고 합니다. 메일 본문 전송이 끝난 뒤 상대 서버가 250 같은 성공 응답을 돌려주면, 해당 서버가 메일 처리 책임을 받아들였다는 뜻입니다. “고객의 기본 받은편지함에 표시했고 고객이 읽었다”는 뜻은 아닙니다. 중간 발송 서버가 준 응답인지, 최종 수신 서비스가 준 응답인지도 구분해야 합니다. SMTP 전송 완료 응답의 의미 ↗

특히 Gmail의 프로모션 탭은 스팸함이 아닙니다. 기본 받은편지함을 카테고리로 나눌 때 홍보성 메일을 정리하는 위치입니다. 뉴스레터가 프로모션 탭에 있다는 사실만으로 인증이나 배달이 실패했다고 판단하면 안 됩니다. Gmail 받은편지함 카테고리 설명 ↗

가온상사는 고객의 “안 왔다”는 말을 모두 같은 장애로 묶지 않기로 했습니다. 발송 로그에서 수락을 확인하고, 고객이 직접 찾은 위치를 따로 기록했습니다. 실제 반송이 확인됐다면 이 글의 평판 조사보다 Gmail·Outlook 반송 오류 해설에서 상세 오류부터 살펴보는 편이 빠릅니다.

문제가 생긴 바로 그 메일에서 PASS를 확인합니다

도메인 검사 사이트의 초록색 표시가 실제 뉴스레터의 인증 결과와 같지는 않습니다. DNS에 필요한 정보가 있는지와, 그 메일이 어떤 경로로 발송되어 수신 측 검사를 통과했는지는 다른 확인입니다. 직원이 보낸 테스트 메일이 통과했다고 외부 뉴스레터까지 검증된 것도 아닙니다.

가온상사는 고객이 스팸함에서 찾은 메일의 원본을 확보했습니다. Gmail에서는 해당 메일의 더보기 메뉴에서 원본을 확인할 수 있습니다. 화면 캡처에 PASS만 보이면 인증된 도메인까지 알아보기 어려우므로, 기술 담당자는 수신 서비스가 기록한 Authentication-Results를 함께 확인합니다. 원본을 공유할 때에는 불필요한 본문·개인정보를 제거하고 분석에 필요한 헤더는 보존합니다. Gmail에서 인증 결과 확인하기 ↗

From: 가온상사 소식 <news@example.com>
Return-Path: <bounce@bounce.example.com>
Message-ID: <campaign-0922-01@example.com>

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

이 기록에서는 SPF가 반송 도메인 bounce.example.com으로 통과했고, DKIM은 example.com의 서명으로 통과했습니다. DMARC도 화면의 From 도메인 example.com에 대해 PASS입니다. 그러므로 이 사본을 조사할 때는 “회사 도메인 인증이 실패해서 스팸함에 갔다”는 설명으로 출발할 근거가 없습니다.

반대로 SPF와 DKIM만 PASS이고 DMARC가 FAIL이면 확인할 일이 달라집니다. 인증된 도메인이 회사 From과 연결되지 않았을 수 있으므로 DMARC 정렬 오류 해결 방법을 먼저 봅니다. 세 인증의 역할부터 정리하려면 이메일 인증의 동작 원리를 참고하세요.

DMARC 표준도 수신 측의 다른 판단을 대신하지 않습니다. 발신자가 도메인을 인증했다는 사실과, 수신자가 그 메일을 받고 싶어 한다는 사실은 같지 않습니다. DMARC와 수신 측 처리 판단 ↗

어디서, 어떤 메일만 문제인지 좁혀 봅니다

이제 “회사 메일이 스팸으로 간다”를 조금 더 구체적인 문장으로 바꿉니다. 모든 발송 경로인지 뉴스레터만인지, 모든 고객인지 특정 수신 서비스인지, 언제부터 달라졌는지를 적습니다. 그 차이가 다음에 조사할 곳을 알려줍니다.

가온상사는 자신이 관리하거나 확인에 협조한 외부 계정으로, 실제 뉴스레터 경로의 테스트 메일을 보냈습니다. 직원 메일도 별도로 보냈지만 두 결과를 합산하지 않았습니다. 처음 확인한 기록은 다음과 같았습니다.

이 표로 말할 수 있는 것은 “확인한 표본에서는 Gmail로 보낸 뉴스레터 경로에 문제가 모인다”까지입니다. Gmail 전체가 회사를 차단했다거나, 직원용 메일과 뉴스레터의 차이가 발신 IP 하나뿐이라고 결론 내릴 수는 없습니다. 경로마다 서명 도메인, 내용, 발송 이력이 함께 다르기 때문입니다.

Outlook 앱을 쓴다는 말도 수신 서비스 이름으로 그대로 적지 않는 편이 좋습니다. 그 앱에 개인 Outlook.com, Microsoft 365 회사 계정, 다른 회사의 메일 계정이 모두 연결될 수 있습니다. 기업 계정에서만 문제가 나면 해당 회사의 보안 정책이나 격리 기록을 담당자에게 확인할 필요가 있습니다.

메일을 찾은 뒤 수신자가 “스팸 아님”을 누르거나 별도 필터를 만든 경우도 기록합니다. 그다음 메일이 받은편지함에 들어와도 발신 측 수정의 효과만으로 해석하기 어렵습니다. 최초 위치와 사용자의 조치를 나눠 적어야 전후 비교가 흔들리지 않습니다.

DNS 다음에는 발송 이력과 수신자 경험을 살핍니다

인증을 확인했다면 최근 달라진 일을 발송 기록과 나란히 놓아 보세요. 평판은 어느 검사 사이트의 점수 하나로 원인을 확정하는 장치가 아닙니다. 수신 서비스마다 관찰 범위와 판단이 다르고, 정확한 분류 이유가 모두 공개되는 것도 아닙니다.

명단에 주소가 있다는 것과 메일을 기다린다는 것은 다릅니다

그 주소를 어디서 받았는지, 어떤 메일을 얼마나 자주 보내기로 했는지, 수신거부한 사람이 다시 포함되지 않았는지 확인합니다. 행사 참석 신청과 월간 뉴스레터 신청은 다른 의사 표현일 수 있습니다. 담당자가 바뀌며 오래된 명단을 합쳤다면 수집 경로와 구독 기록부터 대조해 보세요.

Yahoo는 수신자가 요청한 메일을 약속한 빈도로 보내고, 유효하지 않은 주소와 신고·반송을 관리하도록 안내합니다. 월간 소식을 기대한 사람에게 갑자기 매일 홍보 메일을 보내는 문제는 DKIM 키를 바꿔 해결할 수 없습니다. Yahoo의 명단·구독·발송 빈도 권고 ↗

발송량과 발송 경로가 한꺼번에 바뀌었나요?

가온상사는 평소 월 800통 정도 보내다가 이번에는 행사 연락처를 합쳐 한 번에 4,000통을 발송했습니다. 이 숫자는 정상·비정상을 가르는 기준이 아닙니다. 명단 구성과 발송 패턴이 동시에 달라졌다는 조사 단서입니다. 담당자는 발송 날짜, 수신 서비스별 건수, 지연·반송 발생 시점을 이전 캠페인과 비교했습니다.

최근 발송 업체나 IP가 바뀌었다면 그 변경도 기록합니다. Microsoft는 새 IP의 이력과 신고율 등이 전달에 영향을 준다고 설명합니다. 공유 IP라면 업체에 해당 발송 구간의 장애·차단 정보를 요청할 수 있지만, 스팸함에 있다는 사실만으로 다른 고객의 문제라고 단정할 수는 없습니다. Outlook.com의 발신 IP와 평판 설명 ↗

본문과 링크는 수신자가 이해할 수 있나요?

회사를 알아볼 수 있는 발신 이름인지, 제목이 실제 내용과 맞는지, 버튼이 어디로 연결되는지 확인합니다. 가온상사처럼 발송 기록 추적용 링크를 쓰면, 클릭 후 최종 도착 페이지까지 열어 만료된 주소나 뜻밖의 외부 페이지가 없는지 살핍니다. 업체가 제공한 주소라는 이유만으로 점검을 생략할 필요는 없습니다.

Yahoo는 URL과 도메인 등 여러 요소를 평판 판단에 사용한다고 설명합니다. 다만 제목의 ‘무료’라는 단어 하나를 빼거나 이미지를 줄이면 해결된다는 보편적인 공식은 없습니다. 실제 문제가 있는 링크나 오해를 부르는 표현을 고치고, 관찰 결과로 확인해야 합니다. Yahoo가 설명하는 평판 요인 ↗

안내 메일과 홍보 메일이 같은 방식으로 나가나요?

결제 영수증이나 비밀번호 재설정과 뉴스레터는 수신자가 기대하는 상황이 다릅니다. 발신 주소·서명 도메인·발송 경로를 정리하면 어떤 메일 유형에서 문제가 생겼는지 추적하기 쉬워집니다. Yahoo도 메일 종류에 따른 IP 또는 DKIM 도메인 분리를 권고합니다. 다만 하위 도메인을 만들었다는 사실만으로 모든 평판 영향이 분리되거나, 새 경로의 전달이 좋아진다고 보장할 수는 없습니다. Yahoo의 발송 유형 분리 권고 ↗

RUA, 평판 도구, 개봉률은 서로 다른 것을 보여줍니다

가온상사의 담당자는 RUA에서 대부분의 정상 발신 메일이 인증을 통과한 것을 확인했습니다. 하지만 그 결과로 고객의 스팸함 신고를 반박할 수는 없습니다. RUA의 disposition은 DMARC 정책 처리와 관련된 값이며, 받은편지함의 최종 위치를 기록하는 항목이 아닙니다. DMARC 집계 리포트의 처리 결과 정의 ↗

Postmaster Tools에는 발송량이 적은 날 개인정보 보호를 위해 일부 데이터가 표시되지 않을 수 있습니다. 데이터가 없다는 이유로 평판이 좋다고 판단하지 않습니다. 스팸 신고율이 0%여도 이미 많은 메일이 자동으로 스팸함에 들어가 사용자가 받은편지함에서 신고할 기회가 줄어든 상황일 수 있습니다. Postmaster 데이터 누락과 신고율 해석 ↗

개봉률 역시 보조 자료로 다룹니다. Google은 제삼자가 제공하는 개봉률의 정확성을 확인할 수 없으며, 낮은 개봉률이 곧 전달 장애나 스팸 분류를 뜻하지는 않는다고 설명합니다. “개봉률이 떨어졌으니 DNS 문제”라는 식으로 조사 단계를 건너뛰지 마세요. Google의 개봉률 안내 ↗

가온상사는 해당 기간의 Postmaster 그래프가 비어 있어 평판 추이를 확인할 수 없었다고 기록했습니다. 대신 실제 고객 사본, 발송 로그, 명단 변경 내역으로 조사 범위를 좁혔습니다. RUA를 읽는 방법은 RUA 리포트 해설에서 자세히 볼 수 있습니다.

가온상사는 명단과 발송 방식을 먼저 정리했습니다

조사에서 확인된 문제는 분명했습니다. 행사 연락처 일부는 뉴스레터 구독 기록을 확인할 수 없었고, 기존보다 큰 명단을 한 번에 발송했습니다. 반면 확인한 사본의 인증은 통과했고, 링크에서 잘못된 연결은 발견되지 않았습니다. 이를 “스팸 원인을 100% 찾았다”고 발표하지 않고, 확인된 운영 문제부터 수정하기로 했습니다.

1. 수신 의사를 확인할 수 없는 명단을 발송 대상에서 분리합니다

   행사 참석자라는 이유만으로 뉴스레터 대상에 넣지 않습니다. 구독 기록이 있는 명단을 기준으로 다시 구성하고, 기존 수신거부·신고·영구 반송 주소가 재등록되지 않도록 확인합니다.

2. 수신거부가 실제로 반영되는지 시험합니다

   담당자의 테스트 구독으로 해지를 실행한 뒤 다음 발송 대상에서 제외됐는지 확인합니다. 화면에 완료 문구가 뜨는 것과 실제 명단에서 빠지는 것을 함께 봅니다.

3. 발송 규모와 속도를 운영자가 확인할 수 있게 나눕니다

   최근에 구독했고 이 소식을 기다리는 수신자부터 정상적인 발송을 재개합니다. 업체의 권고와 과거 발송 이력을 기준으로 규모를 정하고, 지연·반송·신고가 늘면 다음 발송 전에 원인을 확인합니다.

4. 바꾼 항목과 유지한 항목을 기록합니다

   명단 기준과 발송 방식은 바꿨고, 검증된 From·DKIM·DMARC 설정은 유지했다고 적습니다. 담당자가 교체돼도 다음 발송과 비교할 수 있도록 캠페인 기록에 남깁니다.

Google도 발송량을 갑자기 늘리기보다 수신자 반응과 서버 응답을 보며 점진적으로 조정하도록 안내합니다. 모든 회사에 맞는 일일 건수나 “며칠이면 회복된다”는 일정은 없습니다. 기존 이력과 수신 서비스의 반응을 기준으로 판단해야 합니다. Google의 발송량 조정 권고 ↗

이 작업은 실험을 위해 원하지 않는 메일을 다시 보내는 과정이 아닙니다. 확인된 문제를 정리하고 필요한 정상 발송을 관찰하는 과정입니다. 명단과 발송량을 함께 바꿨으므로, 이후 결과가 좋아져도 두 조치 중 하나만의 효과라고 설명할 수는 없습니다.

새 메일의 원본과 도착 위치로 다시 확인합니다

수정 후에는 발송 서비스의 간단한 미리보기만 보내지 않고, 실제 뉴스레터와 같은 경로·발신 주소·링크 설정으로 확인용 사본을 보냅니다. 새로운 메일의 인증 결과와 도착 위치를 적고, 이전 조사 때 썼던 수신 계정과 조건을 대조합니다.

테스트 계정만 좋아졌다면 조사를 끝내기는 이릅니다. 이 예시에서는 테스트 계정의 변화는 확인했지만 실제 고객의 문제는 남았습니다. 담당자는 그 고객에게 받은 시각과 원본을 다시 요청하고, 수신 규칙·차단 설정·전달 경로 차이를 확인했습니다. 동시에 발송 업체에 해당 메일의 전달 로그와 사용한 발신 IP를 묶어 문의했습니다.

반복 확인할 때에는 발송 일시와 시간대, 캠페인 ID, Message-ID, 수신 서비스, 인증 결과, 실제 위치, 수신자의 수동 조치를 같은 양식으로 남깁니다. 필요한 업무 발송을 관찰하면서 여러 날짜의 결과를 모으되, 테스트를 위해 불필요한 메일을 반복 발송하지 않습니다.

완료 기준도 처음부터 정해 두면 좋습니다. “인증 PASS”에 더해 실제 고객의 문제 재발 여부, 수신 서비스별 지연·반송 추이, 운영상 잘못된 명단 재유입 여부를 함께 확인합니다. 현재 표본에서 좋아졌다는 사실과 전체 수신 환경에서 문제가 해소됐다는 판단을 나눠 두세요.

해결이 더디다면 이 기록을 담당 업체에 전달하세요

“메일이 스팸으로 갑니다”라는 한 문장만 보내면 업체도 처음부터 질문해야 합니다. 아래처럼 영향을 받는 경로와 확인한 사실을 묶으면 조사 시작점을 공유할 수 있습니다.

증상: 일부 개인 Gmail 수신자의 뉴스레터가 스팸함에 위치
발송 경로: 뉴스레터 서비스 / From: news@example.com
범위: 직원용 메일의 확인용 사본에서는 같은 증상이 없음
시간: 2026-09-22 10:00 KST (UTC+09:00)
추적 정보: 캠페인 ID, Message-ID, 수신자별 발송 이벤트
수신 원본: SPF·DKIM·DMARC PASS, 실제 위치와 함께 보관
최근 변경: 행사 명단 추가와 발송량 증가
조치: 구독 기록 확인, 제외 목록 반영, 발송 방식 조정
남은 문제: 후속 뉴스레터도 스팸함에 들어간 고객 사본 존재
요청: 해당 사본의 발신 IP·SMTP 응답·관련 장애 또는 차단 정보 확인

원본은 공개 게시판에 그대로 올리기보다 업체의 적절한 지원 경로로 공유하세요. Message-ID와 발생 시각이 있으면 발송 로그를 찾기 쉬워집니다. 기업 수신 계정의 격리 문제라면 발신 업체뿐 아니라 수신 회사의 관리자 확인도 필요할 수 있습니다.

도메인 DNS 진단은 SPF·DKIM·DMARC 설정의 빠진 부분을 찾는 출발점입니다. 특정 메일의 스팸 분류 원인이나 받은편지함 도착은 실제 발송·수신 자료까지 봐야 합니다. 인증 관리와 이런 후속 조사를 누가 맡을지 고민된다면 DMARC 직접 운영과 관리 서비스 비교에서 필요한 운영 범위를 정리해 보세요.