전달성 · 2026년 9월 21일
반송 vs 스팸 신고: 전달성에 실제로 타격을 주는 것은
반송은 기술적 실패이지만 스팸 신고는 평판을 무너뜨립니다. 두 가지를 모두 처리해 발신 평판을 지키고 이메일이 받은편지함에 도달하게 하는 방법을 알아보세요.
핵심 차이
반송은 수신 서버가 이메일을 거부하는 기술적 실패입니다. 스팸 신고는 수신자가 이메일을 스팸으로 표시하는 사용자 행동입니다. 높은 반송률은 목록 관리가 부실하다는 신호이고, 스팸 신고는 수신 동의나 관련성이 부족하다는 신호입니다. 스팸 신고는 콘텐츠가 원치 않는 메일이라는 직접적인 신호를 ISP에 보내기 때문에 평판에 훨씬 큰 타격을 주며, 더 빠른 차단 목록 등재와 IP 대역 전체의 전달률 하락으로 이어집니다.
반송 이해하기
반송은 이메일을 수신자의 메일함에 전달할 수 없을 때 발생합니다. 엔지니어링 관점에서는 전송 시도의 실패입니다. 반송은 하드 바운스와 소프트 바운스 두 가지로 분류됩니다.
하드 바운스
하드 바운스는 영구적 실패입니다. 이메일 주소가 존재하지 않거나, 도메인이 유효하지 않거나, 수신 서버가 사용자의 IP를 영구적으로 차단한 경우입니다. 이런 주소로는 즉시 발송을 중단해야 합니다. 하드 바운스된 주소로 계속 보내면 오래되었거나 구매한 목록을 사용하고 있다는 주된 신호로 ISP에 전달되며, 이는 원치 않는 대량 메일의 전형적인 특징입니다.
하드 바운스에 흔히 나타나는 SMTP 오류 코드는 다음과 같습니다.
- 550: User unknown
- 554: Transaction failed
- 550 5.1.1: Bad destination mailbox address
소프트 바운스
소프트 바운스는 일시적 실패입니다. 메일함이 가득 찼거나, 서버가 일시적으로 다운되었거나, 메시지 크기가 한도를 초과했을 수 있습니다. 이것만으로 연락처를 바로 삭제해야 하는 것은 아니지만, 소프트 바운스가 반복되면 결국 하드 바운스로 취급해야 합니다.
소프트 바운스에 흔히 나타나는 SMTP 오류 코드는 다음과 같습니다.
- 421: 서비스를 사용할 수 없음, 전송 채널 종료(Service not available)
- 450: 요청한 메일 작업이 수행되지 않음, 메일함 사용 불가(mailbox unavailable)
- 451: 요청한 작업 중단, 처리 중 로컬 오류(local error in processing)
스팸 신고 이해하기
스팸 신고는 사용자가 메일 클라이언트에서 "스팸 신고" 또는 "정크로 표시"를 클릭할 때 발생합니다. 반송과 달리 이메일은 메일함에 성공적으로 전달된 상태입니다. 여기서의 실패는 기술적인 것이 아니라 행동에 따른 것입니다.
Gmail이나 Outlook 같은 ISP(인터넷 서비스 제공업체)는 전체 발송량 대비 스팸 신고 비율을 추적합니다. 스팸 신고율이 매우 낮은 임계값(종종 0.1%처럼 낮은 수준)을 넘으면 평판이 떨어집니다. 이는 진행 중인 특정 캠페인에만 영향을 주는 것이 아니라, 해당 IP나 도메인에서 발송하는 모든 이메일에 영향을 줍니다.
전달성의 위계
제공업체 수락, 전달, 받은편지함 도달이라는 세 가지 개념을 구분하는 것이 중요합니다.
- 제공업체 수락: 수신 서버가 연결과 메시지를 수락합니다. 이 단계에서 실패하면 반송이 발생합니다.
- 전달: 메시지가 수신자의 메일 저장소에 성공적으로 배치됩니다.
- 받은편지함 도달: 메시지가 스팸함이 아닌 받은편지함에 배치됩니다. 스팸 신고는 이 단계에 직접 영향을 줍니다.
스팸 신고율이 높으면 이메일이 여전히 "전달"(서버가 수락)될 수 있지만, 해당 사용자가 직접 신고했는지와 관계없이 모든 사용자에게 곧바로 스팸함으로 분류됩니다.
대응 체계 구축하기
인시던트 큐를 담당하는 엔지니어라면 수동 정리에 의존할 수 없습니다. 전송 이벤트를 처리하는 자동화된 파이프라인이 필요합니다.
발송 제외 목록
전문적인 발송 환경에는 반드시 발송 제외 목록이 필요합니다. 다시는 이메일을 보내지 말아야 할 주소를 모아 둔 데이터베이스입니다. 웹훅으로 bounce 또는 complaint 이벤트를 받으면 시스템은 해당 주소를 즉시 발송 제외 목록에 추가해야 합니다.
SendHQ를 사용하면 이런 발송 제외 처리가 API 수준에서 이루어집니다. 애플리케이션 로직이 발송 제외된 주소로 보내려고 해도 시스템이 전송되기 전에 차단합니다.
웹훅 처리하기
웹훅 핸들러는 대략 다음과 같은 모습이어야 합니다(개념 설명용 Node.js 예시).
app.post('/webhooks/email', async (req, res) => {
const event = req.body;
switch (event.type) {
case 'bounce':
if (event.detail.category === 'permanent') {
await suppressionService.add(event.detail.email, 'hard_bounce');
}
break;
case 'complaint':
await suppressionService.add(event.detail.email, 'spam_complaint');
break;
case 'delivered':
await trackingService.markAsDelivered(event.detail.messageId);
break;
}
res.sendStatus(200);
});
AI 에이전트 문제: 멱등성과 승인
AI 에이전트에게 이메일 발송을 맡기면 전달성 사고의 위험이 커집니다. 루프에 빠진 에이전트가 한 사용자에게 동일한 이메일 1,000통을 실수로 보내 스팸 신고가 쏟아질 수 있습니다.
멱등성 키
중복 발송을 방지하려면 항상 멱등성 키를 사용하세요. 에이전트가 타임아웃 때문에 요청을 재시도해도 이메일이 한 번만 발송되도록 보장합니다.
휴먼 인 더 루프(HITL)
중요도가 높은 커뮤니케이션을 보내는 에이전트에는 승인 큐를 구현하세요. 에이전트는 초안을 생성하고, 최종 API 호출은 사람이 실행해야 합니다. 이렇게 하면 에이전트가 관련 없는 콘텐츠를 대규모 목록에 보내 스팸 신고율을 급등시키는 "환각 스팸" 시나리오를 막을 수 있습니다.
인프라와 비용 트레이드오프
제공업체를 고를 때는 사용 편의성과 비용 사이에서 균형을 맞추는 경우가 많습니다. 규모를 키우면 대용량 요금의 차이가 뚜렷하게 드러납니다.
Amazon SES 요금 페이지에 따르면 SES 종량제 요금은 이메일 1,000통당 0.10 USD입니다. 50,000통 기준으로 약 5 USD입니다. 반면 Postmark 요금으로는 50,000통에 대략 66 USD가 듭니다(10,000통 기본 15 USD에 1,000통당 1.20~1.80 USD의 초과 요금).
다른 선택지는 다음과 같습니다.
- Resend: 무료 요금제는 월 3,000통(일 100통 제한)입니다. Pro는 월 20 USD에 50,000통이며 초과분은 1,000통당 0.90 USD입니다(Resend 요금).
- SendGrid: 무료 요금제는 이제 60일 체험판이며, Essentials는 월 19.95 USD부터 시작합니다(SendGrid 요금).
- Mailgun: 월 15 USD에 10,000통이며 초과분은 1,000통당 1.10~1.80 USD입니다(Mailgun 요금).
SES가 더 저렴하지만 발송 제외 목록과 평판을 직접 관리하는 운영 부담은 더 큽니다. SendHQ는 검증된 도메인 기반 트랜잭션 발송과 기본 제공되는 발송 제외 관리를 통해, 순수 AWS 설정의 복잡함 없이 이 간극을 메웁니다.
엔지니어를 위한 전달성 체크리스트
반송과 스팸 신고를 모두 최소화하려면 다음 기술 체크리스트를 따르세요.
- DNS 검증: SPF, DKIM, DMARC 레코드가 올바른지 확인하세요. SendHQ DNS 검사기로 검증하세요. 설정 상세 정보는 DKIM, SPF, DMARC 가이드를 참고하세요.
- 더블 옵트인: 명시적 확인 없이 이메일을 목록에 추가하지 마세요. 스팸 신고율을 0에 가깝게 유지하는 유일한 방법입니다.
- 원클릭 수신 거부:
List-Unsubscribe헤더를 구현하세요. 사용자가 스팸으로 표시하는 것보다 수신 거부하는 편이 낫습니다. - 실시간 발송 제외: 웹훅 핸들러가 5분 이내에 데이터베이스를 업데이트하도록 하세요.
- 모니터링: 반송률이 2%를 넘거나 스팸 신고율이 0.1%를 넘을 때 알림을 설정하세요.
요약표: 반송 vs 스팸 신고
항목 | 반송 | 스팸 신고
원인 | 기술적 실패(잘못된 이메일, 가득 찬 메일함) | 사용자 행동(스팸으로 표시)
신호 | 부실한 목록 관리 / 오래된 데이터 | 관련 없는 콘텐츠 / 수신 동의 없음
즉시 조치 | 하드 바운스 즉시 제거 | 즉시 제거
평판 영향 | 보통(매우 높지 않다면) | 심각
주요 지표 | 반송률 | 스팸 신고율
목표 | 깨끗한 목록 유지 | 사용자 신뢰 유지
마무리
반송은 성가신 문제이지만 스팸 신고는 위기입니다. 높은 반송률은 ISP에 사용자가 허술하다고 알려 주고, 높은 스팸 신고율은 ISP에 사용자가 악의적인 발신자라고 알려 줍니다. 발송 제외 로직을 자동화하고 엄격한 옵트인 절차를 도입하면 발신 평판을 지킬 수 있습니다.
트랜잭션 메일과 에이전트 기반 커뮤니케이션을 안정적으로 처리할 방법이 필요한 제품 팀은 SendHQ를 확인해 보세요.