EHLO와 HELO는 SMTP 대화의 맨 앞부분에 등장하는 아주 짧은 두 단어이지만, 이메일 전달률, 스팸 필터링, 그리고 사서함 제공업체가 당신의 발신 흐름을 “정상적인 메일 스트림”으로 해석하는 방식에 생각보다 큰 영향을 줄 수 있습니다.
로그에서 “HELO domain”, “EHLO string”, “HELO does not resolve” 같은 문구를 본 적이 있다면, 바로 이 SMTP 핸드셰이크 구간을 보고 있는 것입니다. 대부분의 팀은 문제가 생겼을 때에야 이 부분을 체감합니다. 예를 들어 메일이 갑자기 스팸함으로 들어가거나, 이메일 게이트웨이가 연결을 거부하거나, DMARC 프로젝트를 진행하다가 리포트에서 수상한 트래픽이 드러나는 경우입니다.
이 가이드는 EHLO/HELO가 무엇인지, 어떻게 동작하는지, “좋은” 설정은 어떤 모습인지, 그리고 흔한 문제를 어떻게 진단하고 해결하는지까지 정리합니다.
한 메일 서버가 다른 메일 서버에 SMTP로 연결할 때, 먼저 “자기소개”를 합니다. 역사적으로 그 소개가 HELO(기본 SMTP 인사말)였습니다. 이후 SMTP가 확장 기능(ESMTP)을 지원하도록 발전하면서, 인사말이 EHLO(Extended HELO)로 바뀌었습니다.
간단히 정리하면:
이 인사말에는 호스트명(때로는 도메인)이 포함됩니다. 이 값은 흔히 HELO domain 또는 EHLO name이라고 부릅니다. 여기서 중요한 점은, 이것이 사용자가 이메일 클라이언트에서 보는 “From” 도메인과는 다르다는 것입니다. EHLO/HELO는 서버 간 연결 과정에서 사용되는 식별자이며, 연결 신뢰도와 평판 확인에 활용됩니다.
일반적인 SMTP 전달 과정에서 EHLO/HELO가 어디에 들어가는지 순서로 보면 이해가 쉽습니다:
DMARC는 기본적으로 “From” 도메인 기준으로 정렬(alignment)을 평가하지만, 많은 사서함 제공업체와 보안 게이트웨이는 HELO/EHLO를 다음과 같은 용도의 중요한 신호로 사용합니다:
직접적으로 말하면, DMARC는 EHLO/HELO에 “기반”하지 않습니다. DMARC는 표시되는 “From” 도메인과 SPF 또는 DKIM 인증 도메인 간의 정렬(alignment)을 평가합니다. 하지만 EHLO/HELO는 여전히 이메일 프로그램에 몇 가지 중요한 방식으로 영향을 줄 수 있습니다.
SPF는 특정 도메인을 대신해 메일을 보낼 권한이 있는지 평가합니다. SPF에서 검사에 사용되는 “도메인”은 보통 MAIL FROM(Return-Path) 도메인이지만, SPF에는 HELO identity라는 개념도 있습니다. 일부 수신자는 다른 신호가 수상할 때, HELO/EHLO 이름이 “그럴듯하고 일관적인지”도 참고합니다.
DMARC 정렬을 위해 SPF를 정비하는 프로젝트를 하고 있다면(예: enforcement 단계로 넘어가는 과정), 같은 시기에 인프라 신호도 함께 정리하게 되는 경우가 많습니다. 이 흐름은 아래 가이드에서 더 자세히 다룹니다: DMARC 문제 해결 및 수정 방법.
SPF, DKIM, DMARC를 모두 올바르게 설정했더라도, SMTP 인사말이 명백히 잘못 구성되어 있으면 전달률 문제가 생길 수 있습니다. 예를 들면:
이는 특히 인박스 도달률에 민감한 대량 발신자에게 중요합니다. 전달률이 우선순위라면, 인증과 발신 평판의 기본을 함께 묶은 체크리스트로 다음 글이 도움이 됩니다: DMARC로 이메일 전달률 향상.
건강한 SMTP 인사말은 ‘특별할 것 없는’ 형태입니다. 즉, 지루할 정도로 일관되고 검증 가능해야 합니다. 일반적으로 이상적인 설정은 다음 규칙을 따릅니다:
mail.yourdomain.com, smtp.yourdomain.com).자체 운영 MTA, 어플라이언스, 레거시 시스템에서 흔히 발생합니다. 수신자 입장에서는 “최소한의 설정도 안 됨”으로 보일 수 있고, 더 나쁘면 “정체를 숨김”으로 해석될 수도 있습니다.
해결: MTA에서 공개적으로 해석 가능한 FQDN을 사용하도록 설정하세요. 예:
myhostname 설정 후 SMTP 인사말에 적용되는지 확인primary_hostname 조정많은 게이트웨이가 “HELO는 해석 가능해야 한다”는 검사를 합니다. 강제 거부까지는 하지 않더라도 신뢰도가 떨어져 필터링이 강화될 수 있습니다.
해결: 인사말에 사용하는 호스트명에 대해 A/AAAA 레코드를 게시하세요. 구조는 단순할수록 좋습니다. DNS를 직접 관리하지 않는다면, DNS 담당자에게 빠르게 요청하면 되는 작업입니다.
대량 발신 환경에서, 발신 IP에 PTR이 없거나 전혀 관련 없는 값으로 설정되어 있어 문제가 되는 경우가 많습니다. 일부 제공업체와 스팸 필터는 reverse DNS 누락이나 불일치를 저품질 인프라의 신호로 봅니다.
해결: 발신 IP에 대해 당신이 제어하는 호스트명(보통 mail.yourdomain.com 같은 하위 도메인)을 PTR로 설정하고, 그 호스트명이 다시 해당 IP로 해석되도록 구성하세요.
ESP, CRM, 티켓팅 시스템, 결제 제공업체 등을 사용하면, 그들의 SMTP 인사말을 직접 통제할 수 없는 경우가 많습니다. 괜찮습니다. 실무적으로 중요한 목표는 인증과 정렬이 올바른지, 그리고 벤더가 안정적이고 평판 좋은 인프라를 쓰는지입니다.
해결: 벤더 온보딩을 ‘정해진 프로세스’로 운영하세요. 우선 SPF, DKIM, DMARC 정렬을 검증하고, 전달률 문제가 있을 때 보조 신호(예: reverse DNS)를 추가로 점검하는 방식이 효율적입니다.
이것만으로 “잘못”이라고 볼 수는 없습니다. 많은 시스템이 SMTP 인사말용 호스트명과 Return-Path 도메인을 다르게 씁니다. 하지만 모든 식별자가 전반적으로 불일치하고 의도성이 없어 보이면, 다른 문제(불만율 상승, 낮은 참여도, 인증 실패)와 결합될 때 의심 신호가 될 수 있습니다.
해결: “일치”보다 “정상적이고 안정적이며 검증 가능”한 구성을 우선하세요. 모든 값이 같을 필요는 없지만, 각각이 의도적으로 설정되어 있고 제대로 동작해야 합니다.
원하는 수준의 ‘손맛’에 따라 몇 가지 방법이 있습니다:
DMARC 작업 중 반복적인 인증 실패를 보고 있다면, 보통은 인증 문제를 먼저 해결한 뒤 HELO 일관성 같은 2차 신호를 정리하는 것이 효율적입니다. 문제 해결 흐름은 여기에서 단계별로 정리되어 있습니다: DMARC 문제 해결 및 수정 방법.
Google과 Yahoo는 대량 발신자에 대한 기준을 올렸습니다. 공식 요구사항은 인증(SPF, DKIM, DMARC)과 사용자 경험 신호(불만율, 구독 취소 지원)에 집중되어 있지만, 실제 전달률은 여전히 기본적인 인프라 위생, 즉 일관되고 평판 좋은 SMTP 정체성에도 영향을 받습니다.
규정 준수 관련 전달 실패나 이해하기 어려운 반송(bounce) 메시지를 진단 중이라면, 이 가이드가 함께 도움이 될 수 있습니다: Google 및 Yahoo 오류 메시지 가이드(규정 준수).
DMARCeye는 EHLO/HELO 같은 저수준 SMTP 신호가 실제 인증 결과와 전달률에 어떻게 연결되는지 이해하는 데 도움을 줍니다. EHLO/HELO 자체가 DMARC 평가 항목은 아니지만, SMTP 연결 계층의 문제는 종종 인증 실패, 예상치 못한 발신 소스, 비정상 트래픽 패턴 형태로 간접적으로 드러납니다.
DMARC 집계 보고서를 분석하고 발신 IP 및 인프라 행동과 연관 지어 보면, DMARCeye를 통해 다음을 할 수 있습니다:
자체 운영 인프라에서 EHLO/HELO 설정 문제가 있다면, reverse DNS 누락, 불안정한 발신 호스트, 인증 정렬 미완성 같은 문제와 함께 나타나는 경우가 많습니다. DMARCeye는 우선순위를 정해 수정하고, 변경이 실제로 인증 성공률과 전달률 개선으로 이어졌는지 검증할 수 있는 가시성을 제공합니다.
지금 DMARCeye 무료 체험을 시작하고 이메일 도메인을 보호하세요.