# 이메일 반송률: 측정법과 개선 기준

URL: https://notificationharbor.com/ko/journal/email-bounce-rate-measure-fix-ko
Type: blog
Locale: ko
Published: 2026-11-03
Updated: 2026-11-03

---

> 이메일 반송률은 반송 수를 발송 수로 나눈 값이지만, 분모와 반송 유형, 스트림에 따라 결과가 달라집니다. 측정 방법과 경보 기준을 정리했습니다.

이메일 반송률은 발송한 메시지 중 수신 서버가 거부한 메시지의 비율입니다. 건강한 리스트라면 하드 바운스를 1% 미만으로 유지하고, 2%에 도달하면 원인을 조사하며, 5%는 장애로 취급하세요. 대부분의 팀은 대시보드에서 숫자 하나만 읽고 넘어가지만, 분모와 바운스 유형, 집계 기간에 따라 같은 데이터도 전혀 다른 값이 나온다는 점을 놓칩니다.

이 글은 숫자를 정확하게 얻는 것을 먼저 다루고, 그다음에 무엇을 할지 결정하는 순서로 진행합니다.

## 공식은 단순합니다. 팀이 갈리는 지점은 분모입니다

이메일 반송률은 반송된 메시지 수를 발송한 메시지 수로 나눈 뒤 100을 곱한 값입니다. 일부 ESP는 발송 수 대신 전달된 메시지 수를 분모로 씁니다. 전달 수는 이미 반송분을 제외한 값이므로 비율이 더 높게 보입니다. 벤치마크와 비교하기 전에 제공업체가 어떤 분모를 쓰는지 먼저 확인하세요.

예를 들어 Amazon SES는 하드 바운스만으로 반송률을 계산하고, 발송한 메시지 수를 기준으로 삼습니다. 소프트 바운스와 하드 바운스를 한 줄로 섞은 대시보드는 제공업체가 계정을 평가할 때 쓰는 숫자보다 높게 나타납니다.

정의를 하나로 정하고 지표 옆에 적어 두세요. 저희는 발신 도메인별로, 24시간과 7일 단위에서 하드 바운스를 발송 수로 나눠 측정합니다. 팀원 두 명이 같은 주를 두고 서로 다른 숫자를 말한다면, 가장 먼저 비교할 것은 분모입니다.

![키보드 옆에 상승 그래프를 스케치한 노트가 놓인 책상](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0de2bf-img1.webp)

## 하드, 소프트, 블록 바운스는 서로 다른 신호입니다

하드 바운스는 영구적인 실패입니다. 주소가 존재하지 않거나, 도메인이 해석되지 않거나, 사서함이 닫혀 있는 경우입니다. SMTP는 [RFC 3463](https://datatracker.ietf.org/doc/html/rfc3463)에 정의된 5.x.x 강화 상태 코드로 이를 알려줍니다.

소프트 바운스는 일시적인 실패입니다. 사서함이 가득 찼거나, 서버가 잠시 다운되었거나, 메시지가 너무 큰 경우가 여기에 해당합니다. 4.x.x 코드로 돌아오며, 정상적인 발신자는 이를 재시도합니다.

세 번째 범주는 대시보드가 가려 버리는 항목입니다. 블록은 주소가 아니라 발신자 쪽 문제를 뜻하는 5.x.x 거부입니다. 차단된 IP, 인증 실패, 콘텐츠나 평판 필터가 원인입니다. 블록을 하드 바운스로 집계하면 리스트가 더러워 보이지만, 실제 문제는 발송 설정입니다.

반송 한 줄만 보여 주는 리포트는 쓰지 마세요. 세 개의 시리즈로 나누지 않으면 문제가 없는 리스트를 정리하게 됩니다.

## 2026년 기준으로 좋은 반송률은 어느 정도일까요?

공식적으로 정해진 단일 수치는 없습니다. 이 점을 알고 있어야 숫자를 인용할 때 실수하지 않습니다. Gmail과 Yahoo는 스팸 신고율의 기준은 공개하지만 반송률 기준은 공개하지 않습니다. Google은 대량 발신자에게 Postmaster Tools에서 보고되는 스팸률을 0.10% 미만으로 유지하고 0.30%에는 절대 도달하지 않도록 요구합니다. 출처는 [Google 발신자 가이드라인 FAQ](https://support.google.com/a/answer/81126)입니다.

반송률의 실무 기준은 ESP와 현장 경험에서 나옵니다. 아래는 저희가 경보 수준으로 쓰는 기준이며, 메일함 제공업체가 보장하는 수치가 아닙니다. 발신 도메인별 24시간 하드 바운스율 기준입니다.

- 
**0.5% 미만:** 검증된 리스트에서 정상 범위입니다.

- 
**0.5%에서 1%:** 관찰하고, 새 주소가 들어오는 경로를 확인합니다.

- 
**1%에서 2%:** 조사하고, 반송률이 가장 높은 세그먼트를 일시 중지합니다.

- 
**2%에서 5%:** 해당 스트림의 대량 발송을 멈추고, 그 뒤에 있는 가져오기나 폼을 찾습니다.

- 
**5% 이상:** 장애입니다. Amazon SES는 이 수준에서 계정을 검토 대상으로 둡니다.

마지막 줄은 문서화된 기준입니다. [Amazon SES 평판 대시보드 문서](https://docs.aws.amazon.com/ses/latest/dg/reputationdashboardmessages.html)에 따르면 반송률이 5% 이상이면 계정이 검토 대상이 되고, 10% 이상이 계속되면 발송이 중지될 수 있습니다. 다른 제공업체는 다른 숫자와 표현을 씁니다. 본인의 계약 조건을 직접 확인하세요.

## 먼저 세그먼트로 나누세요. 전체 평균은 실패하는 스트림을 가립니다

계정 전체 반송률이 0.8%여도, 트랜잭션 스트림은 0.1%이고 재참여용 가져오기는 6%일 수 있습니다. 평균은 괜찮아 보이지만 두 번째 스트림이 발신 도메인을 조용히 망가뜨리고 있습니다.

스트림, 소스, 수신 도메인별로 반송률을 계산하세요. 네 가지 기준이면 대부분의 문제를 찾을 수 있습니다.

- 
**스트림별:** 트랜잭션, 라이프사이클, 대량 캠페인은 같은 숫자를 공유하면 안 됩니다.

- 
**가입 소스별:** 폼, API 가입, CSV 가져오기, 파트너 리스트는 주소 품질이 크게 다릅니다.

- 
**수신 도메인별:** 한 제공업체에서만 급증한다면 대개 리스트 문제가 아니라 거부 정책 문제입니다.

- 
**주소 수집 시점별:** 12개월 이상 전에 수집된 주소는 최근 주소보다 높은 비율로 반송됩니다.

이것은 보고서를 보기 좋게 만드는 작업이 아닙니다. 폼 검증 버그를 한 시간 안에 고칠지, 멀쩡한 리스트를 급하게 지워 버릴지를 가르는 차이입니다.

![노트북 화면에 터미널 로그가 흐르고 강조된 줄만 어두운 방에서 빛나는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/98b212-img2.webp)

다섯 번째 기준도 나머지가 자리 잡은 뒤에 추가할 만합니다. 발신 IP나 도메인별로 나누는 것입니다. 트랜잭션용 전용 IP와 캠페인용 공용 풀을 함께 쓴다면, 둘 중 한쪽의 급증이 로그를 한 줄 열어 보기도 전에 어디를 봐야 할지 알려 줍니다.

## 제공업체의 이벤트를 잃지 않고 읽는 방법

주요 ESP는 바운스를 웹훅, 알림 토픽, 이벤트 API 같은 형태의 이벤트로 제공합니다. 이 피드를 진실의 원천으로 삼고 자체 저장소에 기록하세요. 대시보드는 데이터를 집계하면서 나중에 필요한 세부 정보를 잃어버리기 때문입니다.

이벤트마다 다음 필드를 저장하세요. 메시지 ID, 수신자, 바운스 유형, 강화 상태 코드, 진단 텍스트, 타임스탬프입니다. 이 여섯 가지가 있으면 사후 분석에서 나오는 질문 대부분에 답할 수 있습니다.

`{
  "event": "bounce",
  "message_id": "msg_01H9",
  "recipient": "user@example.com",
  "bounce_type": "permanent",
  "status": "5.1.1",
  "diagnostic": "550 5.1.1 user unknown",
  "stream": "lifecycle",
  "ts": "2026-11-02T09:14:03Z"
}`웹훅은 재시도될 수 있으므로 핸들러는 멱등하게 만들어야 합니다. 제공업체 이벤트 ID와 메시지 ID를 조합해 키로 쓰세요. 같은 하드 바운스 이벤트가 두 번 카운트되면 반송률이 왜곡되고, 실제로는 정상인 주소가 억제 목록에 올라갈 수 있습니다.

Postmark와 Resend는 이벤트에서 바운스 유형을 구분하고, 메시지 스트림별로 조회할 수 있게 합니다. 그래서 앞에서 설명한 스트림별 분리를 적은 비용으로 구현할 수 있습니다.

## 억제 규칙이 대부분의 일을 합니다

가장 효과가 큰 통제 수단은 자동 억제입니다. 하드 바운스가 한 번 나면 해당 주소로의 발송을 영구히 중단하세요. 제공업체의 억제 목록에만 기대지 말고 애플리케이션 계층에서 처리해야 합니다.

대부분의 ESP는 하드 바운스를 대신 억제해 줍니다. 허점은 제공업체를 바꾸거나, 두 곳을 병행하거나, 억제 목록을 읽지 않는 시스템에서 발송할 때 생깁니다. 정규화한 주소를 키로 쓰는 자체 테이블이 그 틈을 막아 줍니다.

소프트 바운스는 단일 이벤트가 아니라 카운터로 다룹니다. 저희의 기본값은 최소 7일에 걸쳐 연속 3회 소프트 바운스가 나면 억제하는 것입니다. 일주일 동안 사서함이 가득 차 있던 주소는 라이프사이클 관점에서는 사실상 사라진 것입니다.

바운스된 주소를 사용자 테이블에서 지우지 마세요. 대신 상태 코드와 날짜를 표시해 두세요. 삭제된 행으로는 같은 주소가 지난 분기에 두 번 반송되었다는 사실을 알 수 없습니다. 다음 CSV에서 같은 주소를 다시 가져오지 않으려면 기록이 필요하며, 이것이 '정리된' 리스트가 다시 더러워지는 가장 흔한 경로입니다.

![봉투 여러 장이 쌓인 테이블과 그중 세 장만 따로 놓인 쟁반](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/dc3638-img3.webp)

## 반송률이 갑자기 오르는 이유: 흔한 원인 순위

반송률이 움직이면 다음 순서로 원인을 찾으세요. 앞의 세 가지가 대부분의 급증을 설명합니다.

- 
**새 가져오기.** 이벤트, 파트너, 오래된 CRM에서 내보낸 CSV입니다. 무엇보다 먼저 소스별 반송률을 확인하세요.

- 
**검증 없는 가입 폼.** gmial.com 같은 오타나 일회용 도메인이 여기에 해당합니다. 제출 시점의 문법 검사와 MX 검사가 대부분을 걸러내고, 확인 메일이 나머지를 라이프사이클 흐름에서 발송으로 집계되기 전에 걸러냅니다.

- 
**발송 설정 변경.** 새 IP, 새 도메인, 너무 빠르게 올린 워밍업이 여기에 해당합니다. 하드 바운스 대신 블록으로 나타납니다.

- 
**인증 깨짐.** DNS를 바꾼 뒤 SPF, DKIM 또는 DMARC 정렬이 실패한 경우입니다.

- 
**제공업체 측 거부 정책.** 한 수신 도메인이 필터를 강화했습니다. 반송률은 그 도메인에서만 올라갑니다.

진단은 급증과 같은 기간의 상태 코드 분포를 스트림과 수신 도메인별로 묶어 보는 것입니다. 5.1.1(사용자 없음)이 늘면 리스트 문제입니다. 5.7.x가 늘면 정책, 인증 또는 평판 문제입니다. 두 경우의 해결책은 정반대이므로 상태 코드를 반드시 저장해야 합니다.

## 무엇을 경보로 설정할 것인가

일일 평균에 거는 경보는 너무 느립니다. 잘못된 가져오기 하나가 한 시간 안에 40,000통을 보낼 수 있습니다. 대신 롤링 윈도우에 경보를 거세요.

- 
어느 스트림이든 최근 1,000통 기준 하드 바운스율이 1%를 넘을 때

- 
한 시간 동안 200통 이상 발송된 수신 도메인의 반송률이 5%를 넘을 때

- 
5.7.x 블록 수가 정상 기준선을 뚜렷하게 넘을 때

처음 두 가지는 사람에게 페이지를 보내기보다 해당 스트림을 자동으로 일시 중지하도록 연결하세요. 사람은 나중에 조사하면 됩니다. 평판을 지키는 것은 다음 10분 동안의 일시 중지입니다.

Grafana, Datadog 등 이미 쓰고 있는 모니터링으로 반송률을 내보내고, 스트림 라벨을 시리즈에 유지하세요. 그래야 내보낸 뒤에도 분리한 정보가 남습니다.

경영진에게 보고할 때는 7일 기준으로 스트림별 하드 바운스율과 블록 수를 사용하세요. 소프트 바운스는 엔지니어링 뷰에서는 유용하지만, 경영진 보고에서는 혼란만 주므로 빼는 편이 좋습니다. 계정 전체 평균 하나만 보고하지 마세요. 아무도 설명할 수 없는 이유로 움직이기 때문입니다.

하나의 숫자만 요청받는다면 트랜잭션 스트림의 하드 바운스율을 제시하세요. 이 스트림이 실패하면 비밀번호 재설정이나 청구서를 놓치게 되고, 인프라가 건강한지 가장 명확하게 보여 주는 지표이기도 합니다.

다음 단계는 작습니다. 최근 30일의 바운스 이벤트를 가져와 스트림과 상태 코드로 묶은 뒤, 예상하지 못한 행이 무엇인지 찾아보세요.

## FAQ

### 좋은 이메일 반송률은 몇 퍼센트인가요?

참여도가 높은 검증된 리스트라면 하드 바운스 0.5% 미만이 일반적입니다. 1%를 넘으면 조사가 필요하고, 5%는 장애 수준입니다. Gmail과 Yahoo는 반송률 기준을 공개하지 않으므로 이 수치들은 메일함 규정이 아니라 경보 기준으로 보아야 합니다.

### 이메일 반송률은 어떻게 계산하나요?

반송된 메시지 수를 발송한 메시지 수로 나눈 뒤 100을 곱합니다. 일부 ESP는 전달된 메시지 수를 분모로 쓰는데, 이 경우 값이 더 높게 나옵니다. 벤치마크와 비교하기 전에 분모가 무엇인지 확인하세요.

### 어떤 반송률이면 계정이 정지되나요?

제공업체마다 다릅니다. Amazon SES는 반송률 5%에서 계정을 검토 대상으로 두고, 10% 이상이 계속되면 발송을 중지할 수 있습니다. 다른 ESP는 자체 기준을 두므로 본인의 제공업체 약관을 확인하세요.

### 소프트 바운스도 반송률에 포함되나요?

제공업체에 따라 다릅니다. Amazon SES처럼 하드 바운스만 세는 곳도 있습니다. 일시적인 사서함 문제가 계정 상태를 결정하는 수치를 흐리지 않도록 소프트 바운스는 별도 시리즈로 추적하세요.

### 반송률을 빨리 낮추려면 어떻게 해야 하나요?

하드 바운스된 모든 주소를 애플리케이션 계층에서 억제하고, 가입 시 문법 및 MX 검사로 주소를 검증하세요. 반송률이 가장 높은 가져오기나 소스 발송을 중단하는 것이 전체 리스트를 지우는 것보다 효과적입니다.

### 차단(block)은 하드 바운스와 같은 것인가요?

아닙니다. 블록은 IP, 도메인 평판이나 인증 문제로 발생하는 5.x.x 거부이며, 주소가 잘못되어서 생기는 것이 아닙니다. 이를 하드 바운스로 세면 발송 설정이 원인인데도 리스트가 더러워 보이게 됩니다.