이메일 검증 2026 — 시장 · 기술원리 · 자체구현

1. 한눈에 보기

3극 시장 구도

2. 12개 서비스 프로파일

3. 가격 · 정확도 · Catch-All 비교표

3.1 1,000건당 가격 (PAYG 환산)

* 최소 묶음 단위 가격을 1K로 환산

3.2 Catch-All 도메인 처리 능력 — 진짜 차별점

3.3 Unknown · Catch-all 비율 (2024~2025 벤치마크)

* MillionVerifier는 unknown을 청구하지 않는 정책 — 운영상 0%지만 실제 검증 못 한 것

3.4 처리 속도 / API throughput

3.5 보안 · 컴플라이언스

4. 검증 8-Layer 기술 원리

이메일 검증은 8개 레이어의 누적 신호(stacked signal) 시스템이다. 단일 레이어로 끝나지 않으며, 각 레이어의 confidence를 누적해 threshold 정책으로 결정한다.

L1. Syntax Validation — RFC 5321 vs 5322

Local part ABNF

local-part   = dot-atom / quoted-string / obs-local-part
dot-atom     = [CFWS] dot-atom-text [CFWS]
atext        = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'"
             / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`"
             / "{" / "|" / "}" / "~"

따라서 다음도 syntax 적으로 valid:

weird!one#two$three%four&five'six*seven+eight-nine/ten=eleven?twelve^thirteen_fourteen`fifteen{sixteen|seventeen}eighteen~nineteen@example.com

"john..doe"@example.com              ← valid (5322), 일부 MTA 거부 (5321)
" "@example.com                      ← 공백만으로도 valid
用户@例子.中国                       ← IDN → xn--fsqu00a.xn--fiqs8s

왜 perfect regex가 불가능한가

RFC 5322 ABNF는 재귀적 nested comment((comment (nested)))와 obs-* productions를 포함한다. 정규언어(Chomsky type-3)는 재귀를 허용하지 않으므로 수학적으로 regex로 표현 불가능. 유명한 6,343자 짜리 "RFC 5322 regex"도 obsolete syntax/CFWS 일부를 빼먹는다.

// ❌ 잘못된 접근
const RE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/

// ✓ 옳은 접근 - layered library
import { validate } from 'email-validator'    // syntax only, RFC 5321 envelope
import * as mailauth from 'mailauth'          // SPF/DKIM/DMARC/ARC verify
import { isEmail } from 'validator'           // { allow_utf8_local_part, require_tld }

L2. DNS / MX Lookup

RFC 5321 §5.1 — MX 조회 절차

1. domain의 MX RR 조회
2. MX 있음 → preference 오름차순 정렬, 동일 pref는 random shuffle
3. MX 없음 → A/AAAA "implicit MX" (legacy fallback) 시도
4. A/AAAA도 없음 → 5.1.2 / 5.4.4 NDR

Null MX (RFC 7505)

example.com.  IN  MX  0  .

exchange가 . (zero-length label, root) → 이 도메인은 mail을 받지 않음. 클라이언트는 556 Server does not accept mail + 5.1.10으로 즉시 permfail. 검증 단에서 확정 invalid로 분류 가능.

DNS 캐싱 함정

• NXDOMAIN을 negative cache(SOA minimum TTL)에 5분~24시간 stale.
• BullMQ 워커에서 대량 verify 시 dig +nocookie +tries=1 또는 Unbound/CoreDNS 권장. Node dns.promises.resolveMx는 OS resolver 의존이라 캐시 동작이 불투명.
• DNSSEC 적용 도메인은 AD flag로 인증된 NXDOMAIN/null MX 신뢰 가능.

L3. SMTP Probing — 핵심이자 가장 어려운 부분

정상 케이스 wire-level

$ telnet aspmx.l.google.com 25
220 mx.google.com ESMTP ...
EHLO verifier.example.com
250-mx.google.com at your service, [203.0.113.10]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-PIPELINING
250-SMTPUTF8
250 CHUNKING
MAIL FROM:<probe@verifier.example.com>
250 2.1.0 OK
RCPT TO:<known.user@example.com>
250 2.1.5 OK
RCPT TO:<nonexistent-xyzqwerty@example.com>
550-5.1.1 The email account that you tried to reach does not exist.
QUIT
221 2.0.0 closing connection

RCPT TO 응답 코드 의미

RCPT TO가 거짓말을 하는 5가지 메커니즘

RCPT TO:<obviously-fake-zxcvbnm@catchall.com>
250 2.1.5 OK

RCPT TO:<real.user@example.com>
451 4.7.1 Greylisted, try again later

RCPT TO:<real.user@protected.com>
550 5.7.1 Verification probe denied

(e) Sender domain reputation 영향

수신 MTA가 MAIL FROM: 도메인의 SPF/DKIM/DMARC를 확인한 뒤 결정. Verifier가 자체 도메인으로 EHLO 하면 reputation 낮아 550. 대형 verifier는 회전 sender domain pool + 각각 SPF/DKIM/DMARC + warm-up으로 우회.

Gmail / M365 / Yahoo의 차단 — 2026 안티-프로빙 현실

L4. Catch-All Detection

Control probe 기법

1. RCPT TO:<target@domain.com>              → 250
2. RCPT TO:<random-abc123xyz-9182@domain.com> → 250  ← 동일 응답이면 catch-all
                                            → 550  ← target은 진짜 valid

random local part는 entropy ≥ 80 bit (UUID v4 권장). 일부 catch-all은 길이 휴리스틱으로 짧은 random만 250 → entropy 충분히 줘야 함.

왜 100%가 아닌가

• M365 tenant가 recipient filter를 꺼두면 모든 250 → catch-all 같지만 실제로는 mailbox만 inbox 도착, 나머지는 NDR 후처리 (deferred reject).
• Hybrid 환경 (on-prem Exchange + M365)에서 edge transport가 250, 내부 routing에서 550.
• 일부 MTA는 RCPT 250이지만 DATA 단계에서 554 5.7.1 No such user.

ML 기반 catch-all 추론

L5. Disposable Email Detection

정적 Blocklist (2026-05)

동적 회피의 진화

• Subdomain rotation: temp-mail.org → *.temp-mail.org 무한 생성.
• wildcard MX: 한 MX가 수백 도메인 서비스 → MX clustering으로 묶어 차단.
• registrar 시그널: Namecheap/Cloudflare WHOIS privacy + 7일 이내 등록 → high score.
• Cloudflare Workers / Vercel로 무료 disposable 서비스 다수 → IP/AS 추적 어려움.

인프라 기반 동적 탐지 (Castle 2026)

1. MX 클러스터링 — 같은 MX target 공유하는 도메인 그룹화
2. Web 페이지 fingerprint — "view inbox" UI 자동 크롤
3. Registrar/age/privacy — WHOIS, RDAP
4. ML classification — 위 feature로 binary classifier

L6-7. Role-Based · Honeypot · Freemail

Role-based 로컬파트 (de-facto 표준)

info, sales, support, contact, admin, administrator, webmaster,
postmaster (RFC 5321 §4.5.1 필수), abuse (RFC 2142 필수),
noc, security, hostmaster, marketing, billing, accounts,
hr, jobs, careers, office, mail, no-reply, noreply, do-not-reply

왜 risky인가

Spam Trap / Honeypot — 두 종류

알려진 honeypot 운영자

• Spamhaus (DNSBL 운영용 trap)
• SpamCop / Cisco Talos
• AOL / Yahoo의 inactive account 재활용
• Validity (Sender Score) — paid pristine trap
• Spamtrap.io, MailerCheck

Freemail 도메인 list

gmail.com, googlemail.com, yahoo.com (+ 30+ TLD variants),
outlook.com, hotmail.com, live.com, msn.com,
icloud.com, me.com, mac.com,
aol.com, protonmail.com, proton.me, tutanota.com,
zoho.com, gmx.com, yandex.com, mail.ru,
naver.com, daum.net, hanmail.net, kakao.com,
qq.com, 163.com, 126.com, sina.com

L7-8. IP 평판 · ML / AI Score

주요 DNSBL (2026)

DNSBL 조회 wire 예시

$ dig +short 1.2.0.192.zen.spamhaus.org
127.0.0.4              ← 응답 있음 = 등재. 4 = XBL CBL (botnet)

ML scoring feature set

features = {
  # Address-level
  "local_part_entropy": shannon_entropy(local),    # bot-generated 식별
  "local_part_keyboard_pattern": ...,              # 'qwerty', 'asdf'
  "local_part_role_score": role_lookup(local),

  # Domain-level
  "domain_age_days": whois_age(domain),
  "domain_mx_provider": classify_mx(mx_records),
  "domain_has_spf": bool, "domain_has_dmarc": bool,
  "domain_dmarc_policy": "none|quarantine|reject",
  "domain_alexa_rank": ...,
  "domain_https_cert_age": ...,

  # SMTP probe
  "smtp_250_returned": bool,
  "smtp_catchall_signal": bool,
  "smtp_greylist_signal": bool,
  "smtp_response_latency_ms": int,

  # Historical
  "past_bounce_rate_on_domain": float,
  "past_engagement_rate": float,
  "list_source_quality": "double_optin|single|scraped|purchased",
}

학습 데이터: ESP의 수억 건 send + bounce/open/click + complaint label. xgboost / LightGBM으로 0~1 deliverability score. 임계값별 분류:

LLM 보조 활용 (2025~)

• 도메인 정당성 평가: 도메인 + 회사명 + 웹사이트 텍스트를 LLM에 던져 "이게 진짜 운영되는 회사인가" 판단. 신규 도메인 false positive 감소.
• Role/department 분류 일반화: recruiting, talent-acquisition, people-ops 변형 잡음.
• 답장 의도 분류: bounce 가 아닌 OOO/Auto-reply/거절 분류.

Edge Cases

Subaddressing / Plus addressing

• Gmail: user+anything@gmail.com → user@gmail.com 라우팅. . 무시 (u.s.e.r == user).
• iCloud, FastMail, ProtonMail: 지원.
• M365: tenant-level (2021부터 기본 on).
• Yahoo: -tag 지원 (user-tag@yahoo.com), + 미지원.

function normalizeGmail(email: string): string {
  const [local, domain] = email.toLowerCase().split('@');
  if (domain !== 'gmail.com' && domain !== 'googlemail.com') return email;
  const stripped = local.split('+')[0].replace(/\./g, '');
  return `${stripped}@gmail.com`;
}

IDN (한글/일본어/중국어)

한국가나다.com  →  xn--bj0bj3in1f8a9ca.com   (Punycode, IDNA 2008)
日本語.jp       →  xn--wgv71a119e.jp

EAI UTF-8 local part — SMTPUTF8 확장

EHLO verifier.example.com
250-mx.example.com Hello
250-SMTPUTF8                       ← 이게 있어야 UTF-8 가능
250 8BITMIME
MAIL FROM:<probe@verifier.example.com> SMTPUTF8
250 OK
RCPT TO:<用户@example.com>
250 OK

IP literal · Loop MX · Sub-domain MX without parent A

• user@[192.0.2.1], user@[IPv6:2001:db8::1] — syntax valid, 검증 도구는 보통 reject.
• MX target에 A record 없으면 RFC 5321 §5.1 violation → 5.4.4.
• MX가 자기 자신 (loop): valid (implicit MX와 동일).

5. 자체 구현 타당성 — Layer별 난이도

Layer 3가 어려운 5가지 메커니즘

인프라 요구사항 — 자체 구축 시 BoM

정확도 공개 벤치마크 종합

상용이 자체보다 정확한 진짜 이유 — 3가지 해자

1. 수십억 건 historical bounce DB — 같은 이메일의 과거 30/60/90일 hard bounce 이력. SMTP probing으로 못 풀어도 "지난주에 bounce 났다" 한 줄로 invalid 판정.
2. Pristine spam trap 자체 DB — ISP/anti-spam org와의 파트너십·자체 honeypot 운영. 신규 트랩 추적.
3. Catch-all ML — 도메인 과거 bounce rate · 발송된 이메일 syntax 패턴 · role/personal 분류로 catch-all 도메인 내 유효/무효 확률 예측.

6. 비용 · ROI 시나리오

가격 카드 (2026)

시나리오별 Break-even

7. 하이브리드 전략 (월 10만~1000만 구간)

┌──────────────────────────────────────────────────────────────┐
│ L1: Syntax (regex, RFC 5322)         [자체, 무료, ~99%]      │
├──────────────────────────────────────────────────────────────┤
│ L2: MX lookup + A fallback           [자체, 무료, ~98%]      │
├──────────────────────────────────────────────────────────────┤
│ L2.5: Disposable / role / freemail   [자체 OSS list, 무료]   │
├──────────────────────────────────────────────────────────────┤
│ L3: Cache lookup (Redis/PG 30~90일)  [자체, hit rate 60~80%] │
├──────────────────────────────────────────────────────────────┤
│ L4: 상용 API (MillionVerifier 등)    [miss 분만, $0.0005/건] │
├──────────────────────────────────────────────────────────────┤
│ L5: 발송 후 bounce 피드백 → cache 갱신 [자체 학습 루프]      │
└──────────────────────────────────────────────────────────────┘

비용 절감 — 캐시 hit rate 70% 가정

실전 파이프라인 의사 코드

type VerifyResult = {
  status: 'valid' | 'invalid' | 'catch_all' | 'unknown' | 'risky';
  confidence: number;          // 0..1
  reasons: string[];
};

async function verify(email: string): Promise<VerifyResult> {
  const reasons: string[] = [];

  // L1: Syntax
  const parsed = parseAddress(email);              // RFC 5321 envelope
  if (!parsed.ok) return fail('invalid', 1.0, ['syntax']);

  // L2: DNS / MX
  const mx = await resolveMx(parsed.domain);
  if (mx.nullMx) return fail('invalid', 1.0, ['null_mx']);
  if (mx.records.length === 0) {
    const a = await resolveA(parsed.domain);
    if (a.length === 0) return fail('invalid', 1.0, ['no_mx_no_a']);
  }

  // L5: Disposable
  if (await isDisposable(parsed.domain, mx.records)) {
    return { status: 'risky', confidence: 0.9, reasons: ['disposable'] };
  }

  // L3: Cache lookup (Postgres 90일)
  const cached = await db.cache.lookup(email);
  if (cached && !cached.expired) return cached;

  // L6: Role
  if (ROLE_LOCALS.has(parsed.local) && !RFC2142_REQUIRED.has(parsed.local)) {
    reasons.push('role_based');
  }

  // L4: 상용 API call (cache miss 만)
  const result = await commercialApi.verify(email, {
    senderDomain: pickWarmSenderDomain(),
    sourceIp:     pickWarmIp(),
  });

  // BIG_PROVIDER → ML 보정
  if (BIG_PROVIDER_ALWAYS_250.has(mx.providerKey)) {
    reasons.push('provider_always_250');
    return mlScore(email, { reasons, smtp: 'unreliable' });
  }

  await db.cache.upsert(email, result);
  return result;
}

린다(앱린다) 권장 구현 단계

1. L1-2 자체 — elysia-server/src/services/email-verification/ 신규. Node dns + email-validator + disposable-email-domains (매일 cron pull). 개발 1주.
2. Cache (Postgres) — email_verification_cache 테이블, UUIDv7 PK, keyset cursor, 90일 TTL. bun db:generate로 migration 추가.
3. 상용 API — MillionVerifier 시작 (가성비). enterprise tier 시 ZeroBounce 마이그레이션 옵션. BullMQ로 검증 잡 분리.
4. Bounce 학습 루프 — SES/SendGrid bounce webhook → suppression list + cache invalid 마킹. 기존 aws-ses · sendgrid skill의 suppression API 연동.
5. B2B 한국 도메인은 자체 SMTP probing optional — outbound 25 가능 별도 VPS 1대 (AWS 본 인프라 격리). 어려우면 skip.

8. 한국 · 동아시아 특화

한국 결제 친화도

전 서비스 영어 only. 한글 인터페이스는 어떤 서비스도 제공하지 않음.

9. 법적 · 윤리적 이슈

10. 실전 권고 · 결론

발송량 / 사용케이스 매트릭스

사용 시나리오별 서비스 추천

2026 검증의 본질 6가지

1. SMTP probing의 시대는 저물고 있다. Gmail/M365/Yahoo/Apple/Proton의 일관된 차단으로 글로벌 메일의 70%+가 SMTP-level 검증 불가능.
2. 레이어드 신호 + ML score가 표준. 단일 250/550보다 도메인 reputation · list source quality · historical engagement가 정확도 ↑.
3. Disposable / catch-all은 동적. 정적 list만으론 부족, MX 클러스터링 + WHOIS + ML 분류.
4. Pristine spam trap은 탐지 불가. 최선의 방어는 list source 자체 통제 (double opt-in, web form CAPTCHA, ICP 필터).
5. SPF/DKIM/DMARC 정렬은 검증의 전제조건. 정렬 안 된 sender의 verify probe는 점점 더 많이 거부됨.
6. Karpathy 원칙: 단일 라이브러리에 의존하지 말고 (overfitting), 레이어별로 confidence를 누적해 threshold 정책으로 결정.