이메일 검증 안티 패턴: 스팸을 통한 주소 확인

이메일 검증은 사용자에게 확인 링크를 보내고 상호작용을 확인하는 방식으로 처리하는 것이 가장 좋습니다. 확인 링크를 보내기 전에 이메일 주소를 검증하려는 시도는 일반적으로 무의미한 것으로 간주되지만, 최근 발견된 사례는 이 단계의 매우 이례적이고 역효과를 내는 구현 방식을 보여줍니다.

"스팸을 검증으로 활용"하는 구현 방식

특정 가입 흐름, 특히 Pangram 가입 양식에서 식별된 방식은 이메일 주소가 입력되는 즉시 이메일 주소를 검증하기 위해 외부 API 요청을 트리거합니다. 이 요청은 이메일 주소를 POST body에 담아 https://www.pangram.com/api/validate-email로 전송됩니다.

표준 구문 검사나 DNS 조회를 수행하는 대신, 이 프로세스는 대상 주소로 원치 않는 이메일을 발송하는 것을 트리거합니다. 이 이메일은 트랜잭션 확인 메시지가 아니라, 관련 없는 도메인(예: sifgoldenshine.com을 통한 "Winwin Insights")에서 발송되는 "오늘의 사실(Fact of the Day)" 스팸 이메일입니다.

스팸 발송을 위한 인프라

이러한 검증 이메일의 발송을 보장하기 위해, 시스템은 전문적인 스팸 운영에서 전형적으로 사용하는 전술을 채택합니다:

• 도메인 로테이션: 시스템은 단일 도메인의 평판 저하를 피하기 위해 대량의 발송 도메인 목록을 순환하며 사용합니다. 예로는 apiaryapiaries.com, bonfirebeat.com, catnipblissfulhaven.com, strategycrit.com 등이 있습니다.
• 공격적인 재시도: 메일 서버가 DNSBL (DNS-based Blackhole List) 차단으로 인해 연결을 거부할 때, 시스템은 즉시 다른 서버를 통해 발송을 재시도합니다.

발송 실패의 증거

서버 로그를 보면 대상 서버가 발송자를 차단할 때 서로 다른 IP와 도메인에서 여러 번의 시도가 이루어짐을 확인할 수 있습니다. 예를 들어, 로그에는 mta2.icicleglimmerfrost.com에서의 거부(spam.spamrats.com에 의해 차단됨) 직후에 mailc.plowdairy.com에서의 재시도(b.barracudacentral.org에 의해 차단됨)가 이어졌으며, 최종적으로 servidor.classmerge.com을 통해 성공한 기록이 나타납니다.

왜 이 방식이 실패하는가

스팸 발송을 이메일 검증의 대리 지표로 사용하는 것은 기술적으로 두 가지 주요 이유로 결함이 있습니다:

1. 거짓 부정(False Negatives): 목적지 메일 서버가 엄격한 콘텐츠 필터링이나 평판 기반 차단을 적용하는 경우, 스팸이 거부됩니다. 이 시나리오에서는 이메일 주소가 완벽하게 유효함에도 불구하고 "검증"이 실패하게 됩니다.
2. 사용자 경험: 가입 프로세스 중에 사용자에게 원치 않는 관련 없는 콘텐츠를 보내는 것은 이메일 권장 사항 및 사용자 신뢰를 명확하게 위반하는 행위입니다.

특히, 해당 서비스의 실제 트랜잭션 이메일은 합법적인 제공업체(Mailgun)를 통해 발송된다는 점은, 스팸 기반 검증이 별도의 분리된 프로세스이며, 잠재적으로 제3자 SaaS 또는 자동화된 에이전트에 의해 관리될 수 있음을 시사합니다.