10. 오류 / 거부 / 스팸 분류 시나리오

이메일 전송 과정에서 발생할 수 있는 오류 시나리오와 그 처리는 다양합니다. 몇 가지 대표적인 경우를 살펴보겠습니다:

• 인증 실패로 인한 차단: 발신자의 SPF이나 DKIM이 실패하고, 해당 도메인의 DMARC 정책이 reject인 경우 수신 서버는 메일을 수신 단계에서 거부하거나 아예 삭제해버릴 수 있습니다. 이때 발신 서버는 수신 측에서 보내온 5xx 에러 응답을 받고 발신자에게 반송 메일을 전달합니다. 반송 메일에는 보통 "DMARC failure" 또는 "SPF not authorized" 등의 오류 메시지가 담겨 있어 발신자에게 원인을 알려줍니다. 만약 정책이 quarantine이었다면 메일은 받긴 받되 스팸함으로 분류하여 사용자에게 전달할 수 있습니다. 예를 들어, 어떤 공격자가 bob@paypal.com으로 위조된 메일을 보냈는데 PayPal의 DMARC 정책이 reject이면, Gmail 등의 수신측에서 그 메일을 아예 차단해버리고 사용자에게 전달하지 않습니다.
• 네트워크 차단 및 블랙리스트: 발신 메일 서버의 IP가 수신 측 방화벽이나 RBL(실시간 블랙홀 목록)에 의해 차단된 경우, 수신 서버는 SMTP 연결 시도를 즉시 거부하거나 ("554 blocked" 등 응답) 메일을 받아도 삭제합니다. 발신자는 이 경우도 반송 메일을 받게 됩니다. 흔히 Spamhaus나 Proofpoint의 PDR 등에서 악성 IP로 분류된 IP는 많은 메일 서버들이 사전 차단합니다. 발신 측에서는 자신들의 IP가 블랙리스트에 올라가지 않도록 평판 관리가 중요합니다. Office 365나 Gmail 같은 대형 서비스는 자체적으로 높은 평판을 유지하지만, 만약 사용자 계정이 해킹당해 스팸을 대량 발송하면 일시적으로 해당 IP 대역이 블랙리스트에 오르거나, Microsoft/Google이 능동적으로 해당 계정의 발송을 차단하기도 합니다.
• 일시적인 전달 실패(소프트 에러): 수신 측 메일 서버가 다운되어 있거나 네트워크 장애로 연결이 안 되는 경우, 발신 서버는 메일을 큐(queue)에 보관하고 일정 시간 이후 **재시도(retry)**를 합니다. SMTP 표준상 임시 에러(코드 451, 421 등)는 발신 측에 “나중에 다시 시도해달라”는 의미이므로, 발신 서버는 보통 최초 실패 후 몇 분~수십 분 간격으로 재시도하며, 최대 시도 기간(기본 2일 또는 48시간 등)이 지나도록 못 보내면 최종 실패로 간주합니다. 그렇게 최종적으로 배달 실패가 확정되면 발신자에게 영구 실패(bounce) 알림을 보냅니다. 이 알림에는 “호스트 응답 없음”이나 “타임아웃” 등 이유가 포함됩니다. 예를 들어 수신 도메인의 MX가 존재하지만 서버가 장시간 응답하지 않으면 이런 시나리오가 벌어집니다.
• 수신자 사서함 오류: 수신자의 이메일 주소가 존재하지 않는 경우(오타 또는 탈퇴 계정) 수신 서버는 RCPT TO 단계에서 "550 No such user"와 같은 에러로 거부합니다. 이는 **영구 실패(permanent error)**이므로 발신 서버는 즉시 해당 주소로의 메일 전송을 포기하고 발신자에게 반송합니다. 또한 수신자의 사서함 용량이 초과된 경우 "552 Quota exceeded"와 같은 에러가 발생할 수 있습니다. 이 경우에는 수신 서버 설정에 따라 메일을 거부하거나, 발신자에게 “상대편 사서함이 가득 차서 못 받았다”는 알림을 보낼 수 있습니다.
• 스팸으로 분류되는 경우: 메일이 완전히 차단되지는 않았지만 수신자의 스팸 폴더로 들어가는 것도 일종의 전달 실패 시나리오로 볼 수 있습니다. 예를 들어 발신자의 SPF는 통과했지만 메일 내용이 스팸 필터에 의해 의심스러우면, 수신 측은 메일을 받되 받은편지함 대신 Junk/Spam 폴더로 넣습니다. 이때 발신자는 따로 실패 통지를 받지 못하므로 상대방이 메일을 확인하지 못해도 알 방법이 없습니다. 이것이 기업에서 종종 문제되는 “메일을 보냈는데 상대가 못 받았다(스팸함에 있었다)” 상황입니다. 이러한 경우를 방지하려면, 메일 발신 평판을 좋게 유지하고, 중요한 메일은 상대방에게 스팸함도 확인해보도록 연락하는 등 추가 조치가 필요합니다.

이상이 일반적인 이메일 송수신의 전체 흐름과 다양한 요소들입니다. 정리하면, 사용자가 Outlook이나 Gmail에서 메일을 보내면 → 발신 서버가 메일을 받아 필요한 DNS 조회와 보안 검사를 거쳐 → 인터넷을 통해 수신 서버로 전달하고, TLS 등으로 암호화하며 → 수신 서버/게이트웨이가 스팸·악성 여부를 다단계로 검사하고 → 최종적으로 수신자의 사서함에 안전하게 메일을 저장한 뒤 → 수신자 클라이언트에 메일이 표시됩니다. 이러한 복잡한 과정 덕분에 우리는 일상적으로 몇 초 내로 전세계 어디로든 안전하게 이메일을 주고받을 수 있게 된 것입니다. 각 단계에서 문제가 발생하면 메일 지연, 반송 또는 스팸 분류 등이 이루어지며, 이는 시스템 관리자가 로그와 반송 메시지를 통해 원인을 분석할 수 있습니다. 이 글에서 다룬 원리들을 이해하면 이메일 시스템에 대한 면접 질문에도 체계적으로 답할 수 있고, 실제 업무에서도 메일 트러블슈팅에 큰 도움이 될 것입니다.

 

참고 자료

• 이메일 송수신시 DNS MX 레코드의 역할 (Mailtrap 블로그)
• Proofpoint 메일 흐름 단계 (공식 문서)
• Exchange Online Protection(EOP)의 메일 필터 단계 (Spanning 블로그)
• SPF/DKIM/DMARC 인증 기술 개요 (Mailtrap 블로그)