일회용 이메일 도메인 목록: 차단 방법

제품이 무료 플랜을 제공하면 가짜 회원가입이 뒤따릅니다. 대부분의 팀은 이메일 반송률이 올라가거나, 트라이얼에서 유료 전환율이 이유 없이 떨어지거나, 추천 크레딧이 악용될 때야 비로소 문제를 알아챕니다. 그때쯤에는 이미 피해가 발생한 뒤입니다.

우리는 프리미엄 제품을 운영하는 B2B SaaS 기업과 함께 일했습니다. 그들은 잘 구성된 온보딩 흐름, 좋은 활성화 이메일, 구조화된 드립 시퀀스를 갖추고 있었습니다. 하지만 아무것도 기대한 대로 작동하지 않았습니다. 함께 회원가입 데이터를 살펴보니, 새 계정 여덟 개 중 하나 꼴로 일회용 이메일 주소로 만들어져 있었습니다. Veille API를 사용해 회원가입 시 일회용 이메일 탐지를 추가한 후, 첫 달에 가짜 가입이 10% 이상 줄었습니다. 전환 지표가 다시 의미 있는 숫자가 되었고, 이메일 성과 데이터가 마침내 현실을 반영하기 시작했습니다.

이 가이드는 그 탐지 레이어를 구축하는 방법을 설명합니다. 어떤 오픈소스 차단 목록이 유용한지, 어디서 한계에 부딪히는지, 그리고 실시간 API 검사와 결합해 회원가입 흐름을 깨끗하게 유지하는 방법을 다룹니다.

일회용 이메일 도메인이란?

일회용 이메일 도메인은 요청 즉시 받은 편지함을 만들어 주는 서비스에 속한 도메인입니다. 계정 생성도, 신원 확인도, 약정도 필요 없습니다. 사용자는 몇 초 만에 작동하는 주소를 받습니다. 받은 편지함은 몇 분 또는 몇 시간 후에 사라지며, 때로는 아무 제한 없이 유지되기도 합니다. 환영 이메일을 보낼 때쯤이면 주소는 이미 사라지거나 버려진 상태입니다.

가장 잘 알려진 서비스로는 Mailinator, Guerrilla Mail, YOPmail, 10MinuteMail, Temp-Mail이 있습니다. 하지만 이것들은 가장 눈에 띄는 것들일 뿐입니다. 명백한 서비스를 겨냥한 차단 목록을 피하기 위해 특별히 만들어진 도메인을 포함해, 더 작고 덜 알려진 제공업체가 수백 곳 있습니다.

일회용 이메일을 사용하는 모든 사람이 플랫폼을 악용하려는 것은 아닙니다. 개인정보 보호를 중시하는 사용자, 연동을 테스트하는 개발자, 마케팅 이메일을 피하려는 사람 모두 임시 주소를 사용할 타당한 이유가 있습니다. 문제는 악의적인 행위자들 - 여러 가짜 계정을 만들거나, 무료 트라이얼을 반복해서 신청하거나, 추천 프로그램을 악용하는 사람들 - 도 이를 사용한다는 점입니다. 그리고 이들은 나중에 걸러내기가 훨씬 더 어렵습니다.

핵심 포인트: 일회용 이메일은 전달성 문제가 아니라 회원가입 문제입니다. 반송, 발신자 점수 하락, 받은 편지함 도달률 감소는 결과이지 원인이 아닙니다. 회원가입 양식에서 문제를 막는 것이 몇 주 후에 이메일 분석 데이터로 문제를 파악하는 것보다 훨씬 낫습니다.

사용할 가치가 있는 차단 목록

GitHub에는 커뮤니티가 관리하는 여러 목록이 있습니다. 각각 포함된 도메인 수, 업데이트 빈도, 정확도에서 차이가 있습니다.

disposable-email-domains/disposable-email-domains

증거 자료를 요구하는 커뮤니티 기여를 통해 업데이트되는 약 4,000개의 도메인입니다. 신중한 선택지입니다. 오탐이 적지만 완전한 커버리지는 아닙니다. 처음 설정하는 경우 여기서 시작하기 좋습니다.

disposable/disposable-email-domains

매일 자동 업데이트되는 약 100,000개의 도메인입니다. 더 넓은 커버리지를 제공하지만 정확도는 낮습니다. 일부 항목에는 진정한 일회용은 아닌 개인정보 보호 서비스가 포함되어 있습니다. 오탐보다 누락이 더 큰 문제가 되는 고위험 플랫폼 - 예를 들어 게임 플랫폼, 쿠폰 사이트, 암호화폐 서비스 - 에 적합합니다.

7c/fakefilter

약 5,000개의 도메인으로, 매일 업데이트되며 각 항목이 출처와 연결되어 있습니다. 도메인이 목록에 오른 이유를 추적할 수 있어서, 실제 사용자가 차단된 사례를 조사할 때 유용합니다.

FGRibreau/mailchecker

Node.js, PHP, Ruby 등 여러 언어를 위한 라이브러리로 제공됩니다. 원시 텍스트 파일보다 통합된 라이브러리를 선호한다면 좋은 선택입니다.

이 목록들 중 어느 것도 완전하지 않습니다. 가장 일반적인 제공업체를 포함하고 어느 정도 최신 상태를 유지하지만, 항상 새로운 서비스보다 뒤처집니다.

차단할 주요 일회용 도메인

적절한 탐지 시스템을 구축하는 동안 빠른 출발점이 필요하다면, 가짜 회원가입 활동에서 자주 나타나는 도메인들입니다.

mailinator.com
guerrillamail.com
temp-mail.org
yopmail.com
10minutemail.com
trashmail.com
emailondeck.com
maildrop.cc
sharklasers.com
guerrillamailblock.com
grr.la
mailnesia.com
getnada.com
mohmal.com
throwam.com
dispostable.com
tempail.com
fakeinbox.com
throwaway.email
tempinbox.com

이 목록은 임시방편이지 장기적인 해결책이 아닙니다. 매주 새로운 일회용 도메인이 나타납니다. 일부는 금방 사라지지만 다른 것들은 몇 달씩 활성 상태를 유지합니다. 한 번 만들어 놓고 업데이트하지 않는 목록은 마지막 편집 이후 만들어진 모든 것을 놓치게 됩니다.

정적 목록이 시간이 지나면서 쓸모없어지는 이유

일회용 이메일 서비스가 변화하고 있습니다. 많은 서비스가 이제 REST 또는 GraphQL API를 제공합니다. 이는 공격자가 브라우저를 열지 않고도 자동으로 새 이메일 주소를 만들 수 있다는 뜻입니다. 새 일회용 도메인은 등록 후 한 시간 이내에 이메일을 받을 준비가 될 수 있으며, 이는 어떤 공개 목록에도 나타나기 훨씬 전입니다.

일부 공격자는 기존 서비스를 전혀 사용하지 않습니다. 대신 저렴한 도메인을 등록하고, 기본 메일 서버 설정을 구성하고, 주소를 한 번 사용한 뒤 이동합니다. 이런 도메인은 어떤 정적 목록 검사에서도 합법적으로 보입니다. 이를 탐지하는 유일한 방법은 DNS 설정, 도메인 등록 시점, 메일 서버가 올바르게 응답하는지 같은 신호를 분석하는 것입니다.

여기서 정적 목록은 한계에 도달합니다. 알려진 제공업체를 차단하는 데는 효과적이고 집합 검색이기 때문에 지연도 없습니다. 하지만 단 한 번만 사용하는 맞춤 도메인이나 새로 생긴 서비스는 탐지할 수 없습니다.

Veille API를 통한 실시간 탐지

Veille 이메일 검증 API(GET /v1/intelligence/email)는 지속적으로 업데이트되는 100,000개 이상의 알려진 일회용 도메인 데이터베이스와 실시간 DNS 및 메일 서버 분석을 결합하여 이메일 주소를 확인합니다. 반환되는 정보:

disposable - 도메인이 알려진 일회용 제공업체인 경우 true
risk_score - 0(안전)에서 100(고위험)까지의 점수로, 사용 가능한 모든 신호를 결합
role_account / role_type - info@, noreply@, admin@ 같은 공유 받은 편지함 감지
dns.mx - 도메인에 유효하게 구성된 메일 서버가 있는지 여부
smtp_valid - 특정 받은 편지함이 이메일을 수신할 수 있는지 여부(qualification_check=true 필요)

risk_score 필드는 세밀한 결정을 내리는 데 가장 유용합니다. 단순히 차단하거나 허용하는 대신, 임계값을 정할 수 있습니다. 낮은 점수는 통과시키고, 중간 점수는 추가 인증을 요구하고, 높은 점수는 양식에서 바로 거부합니다.

일회용 이메일 차단 구현 방법

Python - 정적 차단 목록 확인

GitHub에서 목록을 다운로드하여 메모리에 저장합니다. 이 작업은 애플리케이션 시작 시 또는 정기 스케줄에 따라 한 번만 수행하고, 매 요청마다 하지 않습니다.

import requests

BLOCKLIST_URL = (
    "https://raw.githubusercontent.com/"
    "disposable-email-domains/disposable-email-domains/"
    "refs/heads/main/disposable_email_blocklist.conf"
)

def load_blocklist() -> set[str]:
    response = requests.get(BLOCKLIST_URL, timeout=10)
    return set(response.text.strip().splitlines())

DISPOSABLE_DOMAINS = load_blocklist()

def is_known_disposable(email: str) -> bool:
    domain = email.rsplit("@", 1)[-1].lower()
    return domain in DISPOSABLE_DOMAINS

예약 작업으로 목록을 주 1회 갱신합니다. 목록은 오래된 버전이 실제 악용을 놓칠 만큼 충분히 변하지만, 지속적인 업데이트가 필요할 만큼 자주 변하지는 않습니다.

Python - 실시간 탐지를 위한 Veille API 사용

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.veille.io/v1"

def validate_email(email: str) -> dict:
    response = requests.get(
        f"{BASE_URL}/intelligence/email",
        params={"query": email},
        headers={"x-api-key": API_KEY},
        timeout=3,
    )
    response.raise_for_status()
    return response.json()

def signup_gate(email: str) -> tuple[bool, str]:
    data = validate_email(email)

    if data["disposable"]:
        return False, "Please use a permanent email address to sign up."

    if data["risk_score"] >= 75:
        return False, "We could not verify this email address. Please try a different one."

    return True, ""

TypeScript - Express용 검증 미들웨어

import express, { Request, Response, NextFunction } from "express";

const API_KEY = "YOUR_API_KEY";
const BASE_URL = "https://api.veille.io/v1";

interface EmailValidation {
  disposable: boolean;
  risk_score: number;
  smtp_valid: boolean;
}

async function validateEmailMiddleware(
  req: Request,
  res: Response,
  next: NextFunction
): Promise<void> {
  const { email } = req.body as { email: string };

  try {
    const response = await fetch(
      `${BASE_URL}/intelligence/email?query=${encodeURIComponent(email)}`,
      { headers: { "x-api-key": API_KEY }, signal: AbortSignal.timeout(3000) }
    );

    const data = (await response.json()) as EmailValidation;

    if (data.disposable || data.risk_score >= 75) {
      res.status(422).json({ error: "This email address cannot be used for registration." });
      return;
    }

    next();
  } catch {
    // If the API is unreachable, allow the request through and log the failure
    console.warn(`[veille] email validation failed for ${email}, allowing through`);
    next();
  }
}

const app = express();
app.use(express.json());
app.post("/auth/signup", validateEmailMiddleware, (req, res) => {
  res.json({ status: "ok" });
});

중요한 구현 참고 사항: 검증 API에 접근할 수 없거나 오류를 반환할 경우, 요청을 통과시킵니다. 네트워크 문제로 사용자를 차단하지 마세요. 실패를 기록하고 해당 가입 건을 별도로 검토합니다.

검증을 추가할 위치

회원가입 양식이 가장 중요한 곳이지만 유일한 곳은 아닙니다.

이메일 변경 흐름 - 기존 사용자가 일회용 주소로 변경하려는 것은 경고 신호입니다
대기자 명단 및 얼리 액세스 가입 양식
쿠폰 및 프로모션 코드 양식
추천 프로그램 가입

일회용 주소를 일찍 탐지할수록 나중에 데이터를 정리하는 데 드는 작업이 줄어듭니다.

오탐 방지

일부 합법적인 서비스는 일회용처럼 보이는 이메일 주소를 생성합니다. Apple Hide My Email, Firefox Relay, Proton Mail 별칭, SimpleLogin, addy.io는 모두 비정상적인 패턴의 전달 주소를 만듭니다. 지나치게 엄격한 차단 목록은 이를 실수로 차단할 수 있습니다.

중요한 차이점: 이 주소들은 개인정보 보호를 선택한 실제 사람이 소유한 실제 받은 편지함으로 전달됩니다. 이런 사용자를 차단하면 사기를 방지하는 것이 아니라 실제 고객을 잃는 것입니다.

두 가지 방법으로 이 문제를 방지할 수 있습니다. 먼저, 알려진 개인정보 보호 릴레이 서비스 목록을 관리하고 해당 도메인에 대해서는 모든 검사를 건너뜁니다.

PRIVACY_RELAY_DOMAINS = {
    "privaterelay.appleid.com",
    "relay.firefox.com",
    "simplelogin.co",
    "addy.io",
    "anonaddy.com",
}

def should_skip_check(email: str) -> bool:
    domain = email.rsplit("@", 1)[-1].lower()
    return domain in PRIVACY_RELAY_DOMAINS

둘째, 단순한 도메인 일치 대신 risk_score 임계값을 사용합니다. 알려진 개인정보 보호 서비스의 전달 주소는 보통 낮은 점수를 받습니다. 지난주에 만들어진 알려지지 않은 일회용 도메인은 높은 점수를 받습니다. 이 두 점수 사이의 차이에서 Veille API가 가장 큰 가치를 발휘합니다.

프로덕션에서 차단 로직을 활성화하기 전에, 일주일 동안 테스트 모드로 실행합니다. 실제로 요청을 거부하지 않고 차단되었을 항목만 기록합니다. 결과를 수동으로 검토합니다. 실제 사용자가 기록에 나타나면 임계값을 조정합니다.

레이어드 접근 방식

단일 검사만으로는 충분하지 않습니다. 신뢰할 수 있는 설정은 여러 레이어를 결합합니다.

개인정보 보호 릴레이 허용 목록 - 가장 먼저 확인하며, 이 도메인의 주소는 다른 모든 검사를 건너뜁니다
정적 차단 목록 - 빠른 검색으로 가장 잘 알려진 일회용 제공업체를 즉시 차단합니다
Veille API - 정적 목록을 통과한 모든 것에 대한 실시간 검사로, disposable, dns.mx, risk_score를 사용합니다
가입 후 행동 - 이메일을 한 번도 열지 않고, 온보딩을 완료하지 않고, 7일 후에도 활동이 없는 계정은 초기 검사를 어떻게 통과했든 검토해야 합니다

의사결정 로직:

신호	조치
개인정보 보호 릴레이 허용 목록의 도메인	허용
정적 차단 목록의 도메인	회원가입 양식에서 거부
API에서 `disposable: true`	회원가입 양식에서 거부
`risk_score` ≥ 75	회원가입 양식에서 거부
`risk_score` 50–74	허용 후 수동 검토를 위해 플래그
7일 후 활동 없음	보관 후 활성 목록에서 제거

자주 묻는 질문

차단 목록은 얼마나 자주 업데이트해야 하나요?

대부분의 팀에게는 주 1회가 충분합니다. 최신 버전을 다운로드하여 메모리에 다시 로드하는 자동화 작업을 설정합니다. 더 자주 업데이트해도 이점이 거의 없고, 덜 자주 업데이트하면 새로 식별된 제공업체를 놓치게 됩니다.

info@company.com 같은 역할 기반 주소를 차단해야 하나요?

제품에 따라 다릅니다. 소비자 대상 가입에서는 info@나 admin@ 같은 공유 주소가 낮은 품질의 리드나 공유 받은 편지함의 신호일 수 있습니다. 기업 대상 제품에서는 이것이 회사의 유일한 공개 이메일 주소일 수 있습니다. Veille API의 role_account 필드를 사용해 직접 차단하지 않고 별도로 플래그를 달고, 다른 온보딩 흐름으로 처리합니다.

캐치올 도메인은 어떻게 하나요?

일부 도메인은 실제 받은 편지함이 없어도 모든 주소로 보낸 이메일을 수락합니다. 정적 차단 목록으로는 이를 탐지할 수 없습니다. Veille API에서 qualification_check=true와 함께 smtp_valid를 사용하여 특정 받은 편지함이 실제로 이메일을 수신할 수 있는지 확인합니다. 도메인 설정 여부만 확인하는 것이 아닙니다.

무료 이메일 제공업체를 모두 차단할 수 있나요?

아니요. 대부분의 실제 사용자는 Gmail, Outlook, Yahoo 같은 무료 제공업체로 가입합니다. 무료 제공업체를 차단하면 실제 사용자 대부분을 잃게 됩니다. 올바른 구분은 무료 대 유료가 아니라 일회용 대 영구적입니다.

모든 일회용 도메인을 포함하는 목록이 있나요?

아니요. 새로운 일회용 이메일 서비스는 기존 차단 목록을 피하려는 목적으로 정기적으로 만들어집니다. 가장 효과적인 방법은 알려진 제공업체를 위한 정적 목록과 나머지를 위한 실시간 API를 결합하는 것입니다.

Veille 리소스

Veille는 953개 이상의 일회용 이메일 제공업체를 추적하며, 9가지 카테고리로 구성되어 있습니다. 10분 받은 편지함, 임시 서비스, 일회용 주소, 쓰레기 받은 편지함, 가짜 이메일 생성기, 익명 전달 서비스, 별칭 및 릴레이 서비스, 개인정보 보호 도구, 기타입니다. 데이터베이스는 매주 업데이트됩니다.

이 가이드와 함께 사용할 수 있는 두 가지 무료 도구:

일회용 이메일 제공업체 디렉토리 - 추적 중인 953개 이상의 제공업체를 모두 탐색하고, 각각의 카테고리 레이블과 설명을 확인합니다
차단 목록 비교 도구 - 임의의 도메인을 입력하고 disposable-email-domains/disposable-email-domains, disposable/disposable-email-domains, 7c/fakefilter, FGRibreau/mailchecker 등을 포함한 12개의 오픈소스 차단 목록에서 동시에 확인합니다

회원가입 시 disposable, risk_score, smtp_valid가 즉시 반환되어야 하는 실시간 탐지에는, Veille 이메일 검증 API가 어떤 정적 목록도 처리할 수 없는 것을 담당합니다.