인증, 메일 서비스 제공업체의 응답, 오디언스 품질, 수신 거부 동작을 점검해 이메일이 거부되거나 스팸함으로 가는 이유를 찾아보세요.
전달과 받은편지함 도달은 서로 달라요. 수신 서버는 메시지를 받아들인 뒤 스팸함에 넣을 수도 있어요. 캠페인 대시보드에 ‘전달됨’이라고 표시돼도, 독자가 그 이메일을 봤다는 증거는 아니에요.
문제가 생기면 카피를 바꾸거나 이메일 제공업체를 바꾸기 전에 먼저 증거부터 모으세요. 문제는 인증에 있을 수도 있고, 평판이나 오디언스, 메시지 자체에 있을 수도 있어요.
거부되거나 지연된 메시지는 실제 SMTP 응답과 확장 상태 코드를 확인하세요. 일시적 실패와 영구적 거부는 대응 방법이 달라요. Google의 발신자 FAQ는 두 가지를 모두 설명하지만, 요건을 지키지 않으면 이제 모두 영구 오류가 난다고 말하지는 않아요.
메시지가 수락됐는데 스팸함에 들어간다면, 수신된 메일 헤더의 인증 결과, 확인할 수 있다면 메일 서비스 제공업체의 평판 데이터, 그리고 최근의 오디언스나 발송량 변화를 살펴보세요. 시드 메일함 몇 개는 문제를 진단하는 데 도움이 되지만, 리스트 전체의 받은편지함 도달을 측정해 주지는 않아요.
확장 상태 코드는 점으로 구분한 세 개의 숫자로 이루어지며, RFC 3463에 정의되어 있어요. 첫 번째 숫자는 클래스예요. 4로 시작하는 코드는 일시적 실패라서, 발신 서버가 나중에 다시 시도해야 해요. 5로 시작하는 코드는 영구적 실패라서, 같은 메시지를 그대로 다시 보내도 소용없어요.
두 번째 숫자는 문제의 주제를 좁혀 줘요. X.1.X 범위의 코드는 주소와 관련이 있고, 5.1.1은 보통 메일함이 존재하지 않는다는 뜻이에요. 이 주소는 발송 제외하세요. X.7.X 범위의 코드는 보안이나 정책과 관련이 있으며, 인증과 평판 문제는 대개 여기에서 나타나요.
Gmail이 돌려주는 응답은 Google의 SMTP 오류 참조 문서에 정리되어 있어요. 코드 하나가 여러 가지 이유를 포괄할 수 있으니, 코드뿐 아니라 응답 전문도 읽으세요.
Google Postmaster Tools는 Gmail이 내 발신 도메인을 어떻게 보는지 보여 줘요. Google 요건에서 말하는 사용자가 신고한 스팸률도 여기에서 확인할 수 있어요. 도메인 인증은 DNS 레코드로 해요. Gmail은 도메인이 Gmail 사용자에게 매일 충분한 양의 메일을 보내야 데이터를 보여 주므로, 발송량이 적은 발신자는 대시보드가 비어 있을 수 있어요.
Microsoft의 Smart Network Data Services, 줄여서 SNDS는 특정 IP 주소에서 Outlook.com 개인 메일함으로 보낸 메일에 대해 스팸 신고율과 스팸 트랩 적중 등을 보고해요. 직접 관리하는 IP 주소를 등록하는 방식이라, 전용 발신 IP를 쓸 때 가장 유용해요. 공유 IP를 쓴다면 이메일 제공업체가 무엇을 모니터링하는지 물어보세요.
두 도구 모두 캠페인 하나가 어디에 도착했는지는 알려 주지 않아요. 대신 일별 추세를 보여 주는데, 여러 번의 발송에 걸쳐 쌓인 문제를 진단할 때 필요한 게 바로 이 추세예요.
SPF는 엔벨로프 도메인을 대신해 메일을 보낼 수 있는 발송 인프라를 승인해요. DKIM은 도메인 식별 정보로 메시지에 서명해요. DMARC는 눈에 보이는 From 도메인과의 정렬을 확인하고, 정책과 보고 방식을 게시해요. 셋 중 어느 것도 받은편지함 도달을 보장하지는 않아요.
이메일 제공업체가 알려 준 레코드를 쓰고, 실제로 받은 메시지에서 결과를 확인하세요. 서로 충돌하는 SPF 레코드를 추가하지 말고, DNS 레코드가 있다고 해서 모든 발송 경로가 그 레코드를 올바르게 쓰고 있다고 가정하지 마세요. 인프라에는 적절한 역방향 DNS와 보안 전송도 필요해요.
Brew에서는 도메인 인증 절차를 따라 요청하는 레코드를 등록하세요. 실제 캠페인이나 자동화에 쓰이는 From 주소도 확인하세요. 에이전트가 여러 브랜드를 운영할 때는 특히 중요해요.
DMARC 정책은 From 주소에 쓰인 도메인의 _dmarc 호스트에 두는 TXT 레코드예요. p=none으로 시작하세요. 인증에 실패한 메일에 특별한 조치를 하지 말라고 수신 측에 요청하는 정책이며, 수신 측은 이때도 rua 주소로 집계 보고서를 보내요.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"보고서에는 내 도메인으로 메일을 보내는 모든 발신원과, 각 발신원이 정렬된 SPF 또는 DKIM을 통과했는지가 나와요. 결제 시스템이나 헬프데스크처럼 잊고 있던 도구가 나올 거예요. 실패하는 발신원은 하나씩 고치거나 없애세요.
정상적인 메일이 모두 통과하면 p=quarantine으로 넘어가세요. 실패한 메일을 의심스러운 메일로 취급하라고 수신 측에 요청하는 정책으로, 보통 스팸함에 넣는다는 뜻이에요.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"가장 엄격한 정책인 p=reject는 실패한 메일을 거부하라고 수신 측에 요청해요. quarantine을 한동안 운영하면서 실패하는 정상 메일이 없을 때만 넘어가세요. 모든 단계에서 보고서를 계속 읽으세요. 내 도메인으로 메일을 보내기 시작한 새 도구는 보고서에 가장 먼저 나타나요.
mail.example.com 같은 전용 발신 하위 도메인은 예외예요. 다른 곳에서 이 도메인으로 발송하지 않고, 이메일 제공업체가 SPF와 DKIM을 인증했다면 처음부터 p=reject로 시작해도 돼요. Brew는 직접 설정한 전용 하위 도메인에는 p=reject를, 다른 서비스도 발송할 수 있는 메인 도메인에는 p=none을 권장해요.
Google 가이드라인은 모든 발신자에게 적용되는 요건과, 개인 Gmail 계정에 하루 약 5,000통을 보내는 발신자에게 적용되는 더 엄격한 규칙을 구분해요. Google은 스팸률을 0.1% 미만으로 유지하라고 요구하고, 0.3%에 이르지 않도록 경고해요. 대량 발신자 요건에는 SPF와 DKIM, DMARC, 정렬, 그리고 해당하는 구독 메일의 원클릭 수신 거부가 포함돼요.
발송량과 관계없이 모든 발신자에게 적용되는 Google의 요건은 다음과 같아요.
대량 발신자는 다음 요건도 지켜야 해요.
p=none 정책도 허용해요.Google은 기준을 적용할 때 같은 기본 도메인에서 보낸 메일을 합산하며, 한 번이라도 기준을 넘은 도메인은 계속 대량 발신자로 분류돼요. 집계 방식은 Google의 발신자 FAQ에서 다뤄요.
Yahoo의 가이드도 인증, 스팸 신고, 수신 거부를 다뤄요. Yahoo는 Gmail과 같은 대량 발신자 수치 기준을 공개하지 않으니, Gmail의 수치를 모든 메일 서비스 제공업체에 적용하지 말고 Yahoo의 FAQ를 확인하세요.
Microsoft는 개인용 메일함인 outlook.com, hotmail.com, live.com 주소로 하루 5,000통 넘게 보내는 도메인은 SPF와 DKIM을 통과하고 DMARC를 게시해야 한다고 2025년에 발표했어요. DMARC 정책은 p=none이어도 되지만, From 도메인이 SPF나 DKIM과 정렬되어야 해요.
메일 서비스 제공업체 가이드 확인일: 2026년 9월 28일. 새로운 문제를 진단할 때는 링크한 페이지를 다시 확인하세요.
RFC 8058에 따른 원클릭 수신 거부는 헤더와 HTTPS POST로 작동하는 방식이에요. 눈에 보이는 푸터 링크도 유용하고 관련 규정에서 요구하기도 하지만, 수신 설정 페이지만으로는 이 프로토콜을 구현했다고 할 수 없어요.
원클릭 수신 거부를 지원하는 메시지에는 헤더가 두 개 들어 있어요.
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click독자가 받은편지함에서 수신 거부를 누르면, 메일 서비스 제공업체가 HTTPS URL로 List-Unsubscribe=One-Click 본문을 담은 POST 요청을 보내요. mailto: 주소는 원클릭을 지원하지 않는 메일 소프트웨어를 위한 대안이에요. RFC 8058은 두 헤더를 모두 포함하는 유효한 DKIM 서명도 요구해요. URL은 수신자별로 다르고 추측하기 어렵게 만드세요. 보안 스캐너는 수신 메일의 링크를 자주 열어 보므로, 이 URL에 단순한 GET 요청이 왔다고 해서 누군가가 수신 거부 처리되면 안 돼요.
Brew는 마케팅 발송에 List-Unsubscribe 헤더와 List-Unsubscribe-Post 헤더를 추가해요. 두 헤더는 원클릭 POST 요청을 받는, 서명된 수신자별 HTTPS URL을 가리켜요.
마케팅 수신 거부를 하면 사용하는 모든 경로에서 이후 마케팅 발송이 막히는지 확인하세요. 연락처를 가져오거나 플랫폼을 옮길 때도 발송 제외 기록을 그대로 유지하세요. 꼭 필요한 트랜잭션 메시지는 목적과 발송 설정을 분리해 두세요.
주소를 어디에서 수집했는지, 사람들이 가입할 때 무엇을 기대했는지 검토하세요. 유효하지 않은 주소는 이메일 제공업체의 발송 제외 절차로 제거하고, 스팸 신고가 급증하면 원인을 조사하세요. 추적 데이터상 오픈하지 않았다는 이유만으로 같은 사람에게 다시 보내지는 마세요.
전달을 보장하는 리스트 수집 기간, 이미지 대 텍스트 비율, 금지어 같은 보편적인 기준은 없어요. 잘 모르는 리스트로 발송량을 갑자기 늘리는 것이 ‘무료’라는 단어를 쓰는 것보다 훨씬 심각한 문제예요.
에이전트가 캠페인을 보낼 때도 같은 점검이 필요해요. 검증된 사실, 관련성 있는 오디언스, 누군가 확인하는 회신 주소를 쓰세요. 파악한 원인을 고치고, 범위를 통제한 테스트 발송을 한 뒤, 메일 서비스 제공업체의 응답을 확인하고 나서 발송 규모를 다시 늘리세요.
