보안 이메일 게이트웨이 뒤의 이메일 주소를 검증하는 방법

검증 보고서를 내보냈을 때, 가장 중요한 대기업 연락처 중 이상할 만큼 많은 수가 알 수 없음(unknown)으로 돌아온 적이 있다면, 보안 이메일 게이트웨이(SEG)가 중간에 있었을 가능성이 꽤 높습니다. 증상은 캐치올(catch-all) 도메인과 똑같지만, 원인은 캐치올 도메인이 아니라 게이트웨이입니다.

이 차이가 중요한 이유는 해결 방법이 다르기 때문입니다. 또한 게이트웨이 뒤에 있는 연락처는 대개 실제로 연락하고 싶었던 상대입니다. 작은 회사는 게이트웨이를 거의 쓰지 않습니다. 은행, 보험사, 병원, 대학과 Fortune 500 기업 대부분은 게이트웨이를 씁니다.

검증이 실패할 때 검증 도구가 하는 일

일반적인 검증은 짧은 대화입니다. 검증 도구는 도메인의 MX 레코드에 등록된 메일 서버에 연결해 인사를 하고, 발신자를 밝힌 다음, 수신자를 밝히고 응답을 기다립니다. 메일함의 실제 목록을 가진 서버는 정확하게 답합니다. 존재하는 주소에는 예, 존재하지 않는 주소에는 아니요라고 답하고, 검증 도구는 그 답을 기록합니다.

보안 이메일 게이트웨이는 실제 메일 서버 앞에 있는 필터링 계층입니다. 해당 도메인으로 오는 모든 메시지는 먼저 게이트웨이에 도착해 악성코드, 피싱, 정책 위반 여부를 검사받은 뒤에야 안쪽으로 전달됩니다. Proofpoint, Mimecast, Barracuda, Cisco와 그 밖의 소규모 업체 10여 곳이 모두 이 방식으로 작동합니다.

게이트웨이는 어떤 메일함이 존재하는지 알 필요가 없습니다. 게이트웨이의 역할은 필터링이지 디렉터리 조회가 아닙니다. 그래서 검증 도구가 특정 수신자에 대해 물으면 게이트웨이는 수락합니다. 실제 주소도 수락하고, 오타도 수락하고, 2019년에 퇴사한 사람의 이름도 수락합니다. 수락은 경계에서 이루어지고, 메일함이 존재하는지에 대한 판단은 그 뒤 어딘가에서 이루어집니다. 검증 도구는 그곳까지 닿지 못합니다.

외부에서 보면 이 동작은 캐치올 도메인과 구별할 수 없습니다. 대화도 같고, 답도 같고, 쓸모없는 결과도 같습니다.

“위험” 결과에서 멈추면 안 되는 이유

대부분의 검증 도구는 이런 주소에 라벨을 붙여 대응합니다. 라벨은 업체마다 다릅니다. 어느 업체의 내보내기 파일을 보느냐에 따라 risky, unknown, accept-all(모든 주소 수신), catch-all, ok_for_all 등이 보입니다. 의미는 모두 같습니다. 판단할 수 없었다는 뜻입니다.

그 범위 안에서는 정직한 답입니다. 문제는 그다음입니다. 발송 도구는 이런 라벨을 약한 거절로 다루는 경향이 있고, 대부분의 사람도 그렇게 따릅니다. 아무도 불확실한 주소에 발신자 평판을 걸고 싶어 하지 않기 때문입니다. 그래서 이 주소들은 캠페인에서 걸러지고 조용히 잊힙니다.

B2B 리스트에서는 연락처의 약 30%가 여기에 해당합니다. 대기업 위주의 리스트라면 더 많습니다. 연락처를 확보하는 데 비용을 들이고 검증하는 데 또 비용을 들였는데, 결과는 “모르겠다”였습니다.

게이트웨이를 고려한 검사는 무엇이 다른가

간단히 말하면, 게이트웨이가 답할 수 없는 질문을 그만하고 답할 수 있는 다른 질문을 찾는 것입니다.

게이트웨이가 아무 신호도 보내지 않는 것은 아닙니다. 제품, 설정, 개별 주소에 따라 일정한 패턴으로 동작합니다. 게이트웨이가 결국 전달할 주소와 결국 거부할 주소는 응답 시간이 다릅니다. 오류 코드와 정확한 문구는 업체마다, 버전마다 다릅니다. 어떤 게이트웨이는 대부분의 검증 도구가 응답 확인을 멈추는 시점보다 뒤의 단계에서 거부를 드러냅니다. 어떤 게이트웨이는 같은 도메인에서 실제 메일함과 무작위 문자열에 대해 다르게 동작합니다. 무엇을 비교해야 하는지 알면 이 차이를 볼 수 있습니다.

이런 신호를 읽으려면 먼저 게이트웨이를 식별(핑거프린팅)한 다음, 일반적인 검사가 아니라 해당 제품에 맞게 만든 검사를 적용해야 합니다. 그래서 게이트웨이 지원 범위는 보통 숫자로 표시됩니다. Giggal.ai는 Proofpoint, Mimecast, Barracuda를 포함해 15종을 감지합니다. 이를 시도하는 다른 도구가 밝히는 수는 3종이나 5종입니다. 지원하는 게이트웨이를 하나도 밝히지 않는 검증 도구는 거의 확실히 일반적인 결과를 돌려주면서 risky 라벨을 붙이고 있습니다.

한계도 솔직하게 말씀드립니다. 이는 디렉터리 조회가 아니라 관찰한 동작을 바탕으로 한 추론입니다. 따라서 틀릴 수 있으며, 정직한 업체라면 틀리지 않는다고 말하지 않습니다. 이 방법이 안정적으로 해내는 것은 쓸 수 없던 큰 부분을 대부분 쓸 수 있는 부분으로 바꾸는 것입니다. 이는 완벽하다는 주장과는 다른, 더 신중한 주장입니다.

리스트의 어느 정도가 영향을 받는지 확인하기

게이트웨이가 문제인지 확인하는 데 도구는 필요하지 않습니다. 리스트에 있는 도메인의 MX 레코드만 있으면 됩니다.

모든 주소에서 도메인 부분을 뽑아 중복을 없애고, 각 도메인의 MX 레코드를 조회하십시오. Proofpoint 뒤에 있는 도메인은 pphosted 또는 ppe-hosted가 들어간 호스트 이름을 가리킵니다. Mimecast 도메인은 보통 지역 코드가 붙은 mimecast.com 호스트를 가리킵니다. Barracuda는 barracudanetworks.com으로 나타납니다. Cisco는 iphmx.com으로 나타납니다. Microsoft 365와 Google Workspace 도메인은 각각 outlook.com과 google.com 호스트를 가리킵니다. 이들은 게이트웨이가 아니지만, 캐치올로 설정되어 있을 수는 있습니다.

그 목록을 검증 도구가 판정을 포기한 주소와 대조하십시오. 겹치는 부분이 크다면 원인은 게이트웨이이며, 같은 도구를 아무리 다시 실행해도 결과는 바뀌지 않습니다.

이 문제에 맞는 도구 고르기

세 가지 질문으로 이 문제를 처리하는 검증 도구와 그렇지 않은 도구를 구별할 수 있습니다.

감지하는 게이트웨이의 이름을 밝히는가? 이 부분을 실제로 해내는 업체라면 목록을 공개하거나 적어도 개수를 밝힙니다. 그것이 판매하는 기능이기 때문입니다. 제품 이름 없이 고급 감지 같은 모호한 표현만 쓴다면, 보통은 판정이 아니라 감지만 한다는 뜻입니다. 게이트웨이가 있다는 것은 알려 주지만, 메일함이 실제로 있는지는 여전히 알려 주지 못합니다.

유효 또는 무효를 돌려주는가, 아니면 라벨을 돌려주는가? Mimecast 뒤에 있는 주소의 결과가 어떻게 나오는지 구체적으로 물어보십시오. risky 표시와 신뢰도 점수가 나온다는 답이라면, 조금 더 나은 라벨을 산 것입니다.

추가 처리가 필요한 주소의 비용은 얼마인가? 게이트웨이와 캐치올 판정은 업체에 더 많은 처리 비용이 들기 때문에, 대부분의 업체는 요금을 따로 정합니다. 일반 크레딧의 몇 배를 청구하는 업체도 있습니다. 별도의 작은 사용 한도에서 차감해 일반 한도보다 먼저 소진되게 하는 업체도 있습니다. 둘 다 부당하지는 않지만, 대기업 도메인이 40%인 리스트를 업로드하기 전에 알아 두어야 합니다. Giggal.ai는 모든 검증에 주소 1개당 크레딧 1개를 동일하게 청구하며, 다른 모든 검증과 같은 잔액에서 차감합니다.

실제 진행 순서

지금 쓰는 도구로 리스트를 검증하고 내보낸 파일을 보관합니다. risky, unknown, accept-all로 돌아온 행을 모두 뽑습니다. 그 도메인의 MX 레코드를 확인해, 단순한 캐치올이 아니라 게이트웨이인 도메인이 몇 개인지 봅니다. 그다음 그 부분만 이 문제에 맞게 만든 도구로 검증하고, 두 내보내기 파일을 나란히 비교합니다.

핵심은 이 비교입니다. 저희를 포함해 이 분야의 모든 업체가 요금 페이지에서 비슷하게 들리는 정확도를 내세웁니다. 의미 있는 수치는 하나뿐입니다. 자신의 연락처 중 쓸 수 없던 연락처가 몇 개나 다시 쓸 수 있게 되었는지, 그리고 유효로 표시된 주소가 실제로 발송했을 때 메일을 받았는지입니다.

직접 시험해 보고 싶다면, Giggal.ai는 신용카드 없이 무료 크레딧 1,000개를 제공합니다. 이 크레딧은 주소를 하나씩 확인할 때뿐 아니라 대량 업로드에도 쓸 수 있으며, 이 테스트로 의미 있는 결과를 얻으려면 대량 업로드가 유일한 방법입니다. 캐치올 도메인과 accept-all 도메인을 검증하는 방법이나 SEG 검증 방식(영어)에 대해 더 자세히 읽어 볼 수도 있습니다.