AgentMail. Cloudflare Email Service. Resend의 에이전트 SDK. 이번 달 Product Hunt에 올라온 모든 AI SDR 스타트업들. 그들의 피치는 항상 동일합니다: "API 호출 한 번이면 당신의 에이전트에게 편지함이 생깁니다."

멋지군요. 저는 그들이 모두 서 있는 기반을 측정해 보았습니다.

MX 레코드(MX records)를 보유한 671,693개의 도메인. SPF를 보유한 634,220개. DMARC를 보유한 468,749개. 2026-07-25 스냅샷 기준, Tranco top-1M에 대한 일일 forward-DNS 스캔 결과입니다.

당신의 오후를 망쳐놓을 숫자가 여기 있습니다:

지난달 인터넷에는 9,173개의 순수 신규 DMARC 도메인이 추가되었습니다. 하지만 DMARC 강제 적용(enforcement) 비율은 0.42%포인트 하락했습니다.

다시 읽어보세요. 더 많은 사람들이 DMARC를 게시했지만, 인터넷의 보호를 받는 범위는 줄어들었습니다. 그 신규 레코드 중 4개 중 3개는 p=none 태그였습니다.

이것은 채택(adoption)이 아닙니다. 채택이라는 가면을 쓴 희석(dilution)일 뿐입니다.

첫 번째 타격: 모든 DMARC 레코드의 4분의 1은 하중을 지탱하는 '무(無)'입니다

DMARC를 게시한 468,749개의 도메인을 레코드가 실제로 수행하는 역할에 따라 분류해 보겠습니다:

그 세 번째 행은 현재 제가 인터넷에서 가장 좋아하는 부분입니다.

117,384개의 도메인이 p=none 설정과 작동하는 집계 보고서(aggregate report) 주소 없이 DMARC 레코드를 게시하고 있습니다. 이는 아무것도 차단하지 않습니다. 아무것도 보고하지 않습니다. 오직 컴플라이언스(compliance) 체크박스를 초록색으로 만들기 위한 목적으로만 존재하는 TXT 레코드일 뿐입니다.

v=DMARC1; p=none;

순수한 연극을 보여주는 20글자입니다. 누군가는 이에 대해 비용을 청구했을 것입니다. (이것은 말 그대로 인터넷에서 가장 흔한 단일 DMARC 레코드입니다. 58,997개의 도메인이 정확히 이 문자열을 사용하고 있습니다.)

그리고 관점을 "비활성(inert)"에서 "맹목적(blind)"인 상태로 넓혀보면 상황은 더 우스워집니다:

DMARC를 게시하는 모든 도메인의 35.51% — 즉 166,442개 — 는 작동하는 rua= 주소를 가지고 있지 않습니다.

166,442개의 도메인이 이메일 인증 정책을 게시했지만 텔레메트리(telemetry)를 연결 해제했습니다. 그중 일부는 p=reject 상태입니다. 생각해 보세요. 이들은 적극적으로 메일을 반송하면서도 누가 보내는지 알지 못합니다. 만약 파트너 통합에 내일 문제가 생기면, 세 주 후에 화난 전화 통화로 그것을 알게 될 것입니다.

여러분은 지표(metrics) 엔드포인트가 삭제된 서비스를 출시하지 않을 것입니다. 하지만 웹의 3분의 1이 바로 그런 방식으로 이메일 정책을 운영하고 있습니다.

핵심 문제 #2: 보안은 당신이 얼마나 유명한지에 달려 있다

Tranco 순위 티어별 DMARC 적용 현황:

인터넷의 머리 부분은 '꼬리' 부분보다 3.8배 더 방어되어 있습니다.

여러분은 읽었던 모든

뼈아픈 사실 #4: 도메인 4개 중 1개는 SPF 허용 목록(allowlist)에 낯선 존재가 포함되어 있습니다

저는 634,220개의 SPF 게시 도메인 전체에서 모든 SPF include: / redirect= 대상을 추출하였고, 이를 ESP(Email Service Provider), SaaS 발신자 및 보안 게이트웨이(security gateways)의 공개 사전와 대조했습니다.

분류 커버리지(Classification coverage): include 대상의 **82.66%**입니다. 이는 공개 사전로 이름을 식별할 수 없는 고유한 include 대상이 80,991개나 남아 있음을 의미합니다. 도메인별 관점은 더 심각합니다. include:를 통해 위임(delegate)하는 도메인 중 완전히 분류되는 도메인은 72.37%에 불과합니다. 즉, 도메인 4개 중 1개 이상은 발신 허용 목록(sending allowlist)에 식별할 수 없는 항목을 최소 하나 이상 포함하고 있습니다.

이 부분이 실제로 여러분을 두렵게 만들어야 하는 지점이며, 이것이 100% 에이전트(agent) 이야기입니다.

모든 에이전트 기반 이메일 제품은 동일한 방식으로 사용자를 온보딩합니다: "저희의 include:를 귀하의 SPF에 추가하기만 하면 끝납니다.""
여러분은 그것을 붙여넣습니다. 그러면 CRM, 티켓팅 도구, 마케팅 자동화, 전자 서명 벤더, 그리고 더 이상 관리자 권한을 가진 사람이 없는 2021년에 방치된 웨비나 플랫폼으로부터 이미 존재하던 11개의 항목 위에 차곡차곡 쌓이게 됩니다.

include:는 단순한 설정 줄이 아닙니다. 그것은 당신을 대신하여 메일을 보낼 수 있도록 부여된 상시 권한입니다. 영구적으로 말이죠. 만료 기한도 없습니다. 감사 로그(audit log)도 없습니다. "이 include는 400일 동안 사용되지 않았습니다"라고 알려주는 대시보드도, 그 어디에도, 그 누구도 제공하지 않습니다.

또한 SPF는 DNS 조회(DNS lookups) 횟수를 10회로 엄격히 제한합니다. 이를 초과하면 전체 레코드가 성능 저하가 아닌, 아예 **실패(fails)**합니다. 이는 대부분의 팀이 자신의 SPF가 예산을 초과했다는 사실을 발견하는 방식이, 정당한 메일이 도착하지 않는데 그 이유를 아무도 모르는 방식이라는 것을 의미합니다. 왜냐하면 — 뼈아픈 사실 #1에서 보았듯이 — rua=가 연결되어 있지 않았기 때문입니다.

왜 에이전트는 이를 "기술 부채"에서 "장애"로 바꾸는가

인간 SDR(Sales Development Representative)은 천천히 업무를 늘려갑니다. 화요일과 목요일에 쓰는 글이 다릅니다. 지루해하기도 하고, 아프기도 하며, 유급 휴가(PTO)를 쓰기도 합니다. 이러한 모든 우연한 노이즈(noise)가 발신자 평판(sender reputation)이 조정되는 기준이 됩니다.

에이전트 군단(agent fleet)은 이 중 그 어떤 것도 하지 않습니다:

• 볼륨 집중 (Volume concentration). 10명 분량의 작업 결과물이 단 하나의 도메인, 하나의 인증 경로(auth path), 하나의 평판 버킷(reputation bucket)을 통해 나갑니다.
• 콘텐츠 수렴 (Content convergence). 하나의 모델, 하나의 시스템 프롬프트 (system prompt), 하나의 목소리. 필터들은 정확히 그 지점에 클러스터링(cluster)됩니다.
• 가속 속도 (Ramp velocity). 평판은 분기(quarters)에 걸쳐 쌓입니다. 하지만 에이전트는 배포하는 그날 오후에 바로 제로에서 풀 스로틀(full throttle)로 달려나갑니다.

p=none 설정에, rua=가 없고, 감사되지 않은 12개의 include: 권한 부여가 포함된 도메인에 이 상황을 결합한다면, 당신은 아웃바운드 채널(outbound channel)을 구축한 것이 아닙니다. 당신은 연기 감지기를 제거한 채, 당신의 도메인에 불을 지르는 매우 빠른 방법을 만든 것입니다.

인프라 벤더(infrastructure vendors)들은 이 사실을 알고 있습니다. 그래서 우수한 벤더들은 이제 SPF/DKIM/DMARC를 자동으로 구성하고 도메인을 워밍업(warm domains)해 줍니다. 하지만 그들의 자동 구성(auto-config) 역시 p=none을 작성합니다. 왜냐하면 p=none은 고객의 온보딩(onboarding)을 절대 방해하지 않기 때문입니다. 모든 이의 인센티브(incentives)는 겉모습(sticker)을 향하고 있습니다.

그것이 바로 당신의 -0.42 pp(퍼센트 포인트)입니다.

네 가지 명령. 이 탭을 닫기 전에 실행하세요.

# 1. 강제(enforce)하고 있습니까, 아니면 겉치레(sticker)뿐입니까?
dig +short TXT _dmarc.example.com

...

그다음 30초간의 분류(triage):

1. 항상 rua=가 최우선입니다. 정책(policy)을 건드리기 전에요. 볼 수 없는 것은 강제할 수 없습니다. 작동하는 보고서가 동반된 p=none은 정직한 엔지니어링적 입장입니다. 보고서가 없는 p=none은 스스로에게 하는 거짓말입니다.
2. 2주 동안 보고서를 읽으세요. 벤더가 요약한 보고서가 아닌, 실제 보고서를 읽어야 합니다.
3. 그다음 단계를 높이세요. none → quarantine → reject. 몇 달이 아니라 몇 주 안에 하세요. 당신은 이미 늦었습니다.
4. 이번 분기에 include: 하나를 삭제하세요. 무엇이든 상관없습니다. 매우 두려울 것입니다. 그 두려움이 바로 발견(finding)입니다.
5. 에이전트에게 전용 서브도메인(subdomain)을 부여하세요. agent.yourdomain.com, 별도의 DKIM 키, 별도의 평판. 에이전트가 타버릴 때 — 만약이 아니라 '언제' — 그 불길은 당신이 에이전트를 위해 만들어 놓은 방 안에만 머물 것입니다.

데이터에 대하여, 누군가 댓글로 물어볼 것이기에

완전한 공개를 합니다. 여러분 중 절반은 제 작업 내용을 검증하려 할 것이고, 저는 여러분이 성공하기를 바라기 때문입니다:

• 데이터 소스는 일일 OpenINTEL forward-DNS Tranco 스냅샷 (University of Twente)입니다. 데이터 이용 약관에 따라, 분석 후에는 이들의 집계 데이터(aggregates)를 재사용하고 원본 parquet 파일은 삭제합니다. 위 모든 수치에 적용된 스냅샷 날짜는 2026-07-25입니다.
• "Top-1M"은 분모가 아닙니다. 측정된 리스트에는 1,087,498개의 에이펙스 이름(apex names, 2026-07-24 파티션)이 포함되어 있었습니다. 그중 671,693개가 MX 레코드를 게시했습니다. 누구라도 여러분에게 깔끔하게 "상위 100만 개 중 x%"라고 말한다면, 그는 존재하지 않는 숫자로 나누기를 하고 있는 것입니다.
• 데이터 이력에는 2022-08-11에 경계선(seam)이 존재합니다. 이 시점에 기반 리스트가 Alexa에서 Tranco로 전환되었습니다. 모집단이 다르고 규모도 다릅니다. 이 경계선을 기준으로 절대값을 비교할 수 없으며, 저는 비교할 수 있는 척하지 않을 것입니다.
• MX 분류에는 328개의 정규 표현식(regex) 패턴이 사용됩니다. 일치하지 않는 호스트는 "기타(other)"로 조용히 분류되는 대신 공개적으로 게시됩니다. 일치하지 않는 상위 100개 리스트는 모든 스냅샷과 함께 제공되며, 독자의 수정 사항은 다음 날 실행 결과에 반영됩니다.
• 기록된 알려진 사각지대(blind spots): MX의 CNAME 체인은 풀림(unrolled) 처리되지 않습니다(Microsoft 365 고객의 일부가 "unknown"으로 나타남). 평탄화된(flattened) SPF는 ESP를 원시 IP 범위 뒤에 숨기므로, 위에 제시된 모든 ESP 점유율은 상한선이 아닌 하한선입니다. DKIM 가시성은 잘 알려진 셀렉터(selectors)로 제한됩니다. 만약 여기의 수치가 틀릴 수 있다면, 그 방향은 바로 이 지점이며, 이를 명시합니다.

수치, 방법론, 변경 이력 및 도메인별 조회: check.live-direct-marketing.online/email-stats. CC BY 4.0, JSON API, llms.txt, 2016년까지 거슬러 올라가는 210개의 아카이브된 스냅샷. 마음껏 분석하십시오.

저를 잠 못 들게 하는 부분

우리는 이번 주, 자율 소프트웨어가 우리를 대신해 행동할 수 있도록 프로토콜을 표준화하고 있습니다. 작업(Tasks). 장기 실행 작업(Long-running jobs). 에이전트가 에이전트에게 메일을 보내는 것들 말입니다.

그 밑바닥에는 SPF가 자리 잡고 있습니다. 이는 2003년 시대의 메커니즘으로, 그 보안 모델은 _아무도 감사하지 않고 아무도 완전히 식별할 수 없는 TXT 레코드 내의 문자열 목록_에 불과합니다. 또한 DMARC 위에 올라타 있는데, DMARC 채택자의 4분의 1은 말 그대로 아무런 동작도 하지 않도록 설정해 두었습니다. SPF에 의존하는 항목들의 그래프는 수직 상승하고 있는 반면, SPF 자체는 매달 점점 더 약해지고 있습니다.

우리는 암반 위에 건물을 짓고 있는 것이 아닙니다. 우리는 지난달에 측정 가능한 수준으로 약해진 바닥 위에서 매우 빠르게 건물을 짓고 있으며, 화재 경보기는 166,442개의 도메인이 입력조차 하지 않은 rua= 주소일 뿐입니다.

지금 바로, 다음 스탠드업 미팅(standup) 전까지 본인의 도메인에 대해 dig 명령어를 실행해 보세요.

분명 무언가를 발견하게 될 것입니다.

데이터: OpenINTEL Tranco snapshot 2026-07-25, MX 레코드가 있는 n=671,693개 도메인. 방법론에 동의하지 않으십니까? 좋습니다 — 이미 공개되었으며, 저는 인용되는 것보다 교정받는 것을 선호합니다.