본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 21. 16:42

AI 이메일 보안 분석 수정 — 6개 기업에서 실제 격차 발견

요약

이전의 AI 기업 이메일 보안 분석 오류를 바로잡기 위해 SPF, DMARC, DKIM을 결합한 점수 모델로 재분석을 수행했습니다. 분석 결과, Anthropic을 포함한 39개 기업 중 30개 기업이 적절한 인증 메커니즘을 통해 스푸핑으로부터 잘 보호되고 있음을 확인했습니다.

핵심 포인트

  • SPF softfail 단독으로는 스푸핑 위험을 확정할 수 없으며, DMARC와 DKIM의 정렬 상태가 핵심임
  • DMARC는 SPF 또는 DKIM 중 하나만 정렬되어도 통과되므로 결합된 보안 계층을 고려해야 함
  • 재분석 결과 Anthropic, OpenAI, Apple 등 주요 기술 기업 대부분이 교과서적으로 올바른 보안 설정을 갖춤
  • 6개 기업에서만 실제 보안 격차가 발견되었으며, 대다수 기업은 DMARC reject/quarantine 정책을 통해 보호됨

어제 저는 39개 AI 기업 중 26개 기업이 SPF softfail을 사용하여 이메일이 스푸핑(spoofing)될 수 있다고 주장하는 분석 내용을 게시했습니다. 한 독자(@privacyfish)는 이것이 오해의 소지가 있다고 지적했습니다. 도메인에 DMARC 강제 적용(enforcement)과 DKIM 정렬(alignment)이 작동하고 있다면, SPF ~all 자체만으로는 항상 "도메인이 편지함으로 스푸핑될 수 있음"을 의미하지는 않습니다. 그들의 말이 맞습니다. SPF는 하나의 계층일 뿐입니다. 도메인의 실제 스푸핑 가능성은 SPF, DMARC, 그리고 DKIM이 어떻게 함께 작동하느냐에 달려 있습니다. 또한 DMARC는 메시지가 통과하기 위해 SPF 또는 DKIM 중 하나만 정렬되어 있으면 됩니다. 그래서 저는 결합 점수 모델(combined scoring model)을 사용하여 분석을 다시 수행했습니다.

이메일 인증이 실제로 작동하는 방식

계층역할단독 작동 시
SPF승인된 발신 IP 목록을 나열함Softfail (~all) = "플래그를 표시하지만 전달함"
DMARC인증 실패 시 수신자에게 수행할 작업을 지시함p=reject = 강력한 강제 적용
DKIM이메일이 정품임을 증명하는 암호화 서명메시지 무결성 검증

제가 놓친 결정적인 지점은 다음과 같습니다: SPF 또는 DKIM 중 하나가 From 도메인과 정렬되면 DMARC를 통과한다는 것입니다. SPF softfail + DMARC reject + DKIM이 적용된 도메인은 잘 보호되고 있는 상태입니다. 왜냐하면 SPF가 softfail되더라도, 정렬된 DKIM이 DMARC 검사를 통과하게 만들기 때문입니다. 그리고 만약 둘 다 실패한다면, DMARC reject가 수신자에게 메시지를 폐기하도록 지시합니다. 제 원래 분석이 했던 것처럼 SPF만 확인하는 것은 전체 그림을 놓치는 것입니다.

수정된 결과: 30개 보호됨, 3개 부분적 보호, 6개 격차 발견

세 가지 계층을 모두 사용하여 재스캔한 39개 AI/기술 기업 중:

잘 보호됨 (30개 기업)
이 기업들은 DMARC 강제 적용(reject 또는 quarantine)과 더불어 최소 하나 이상의 정렬된 인증 메커니즘(aligned authentication mechanism)을 갖추고 있습니다:

기업SPFDMARCDKIM
Anthropicsoftfailrejectgoogle
OpenAIhardfailrejectgoogle
Applesoftfailquarantineselector1
Microsofthardfailrejectselector2
Cloudflarehardfailrejectk1
Stripesoftfailrejectgoogle
DeepSeekhardfailquarantinedefault
(+ Cohere, Mistral, Midjourney, Perplexity, Databricks, Snowflake, Cursor, Vercel, Replit을 포함한 23개 기업)

어제 취약하다고 강조했던 Anthropic은 사실 교과서적으로 올바르게 설정되어 있습니다. Softfail SPF + reject DMARC + DKIM 정렬 = 스푸핑(spoofed)된 이메일이 거부됨.

부분적으로 확인됨 (3개 기업)

기업SPFDMARCDKIM 발견 여부?
Googlesoftfailreject표준 셀렉터(selectors)에 없음. 거의 확실하게 커스텀 DKIM 셀렉터를 사용 중임 — 그들이 프로토콜을 만들어냄
Metaredirectreject표준 셀렉터에 없음. Proofpoint를 사용하며, 커스텀 셀렉터를 사용할 가능성이 높음
Notionsoftfailquarantine표준 셀렉터에 없음. SPF 정렬을 통해 DMARC 강제 적용 활성화

중요한 주의 사항: DKIM 셀렉터는 도메인 소유자가 선택하는 임의의 문자열입니다. 제 스캐너는 9개의 일반적인 셀렉터(google, selector1, selector2, default, k1, s1, s2, dkim, mail)를 확인합니다. Google과 Meta는 거의 확실하게 제가 확인하지 않은 셀렉터를 사용하여 DKIM 서명을 합니다. 이 기업들은 강력한 DMARC 강제 적용을 갖추고 있으며 실질적인 위험에 처해 있지 않습니다.

인증 격차 (6개 기업) 이 기업들은 DMARC 강제 적용 (enforcement)이 없습니다. 즉, 이들의 DNS 정책은 수신자에게 인증 실패 시 메시지를 거부하도록 지시하지 않습니다.

| 기업 | SPF | DMARC | DKIM | 격차 |
| :--- | :--- | :--- | :--- | : |
| Nvidia | softfail | missing | yes | DKIM이 있음에도 DMARC 정책이 전혀 없음 |
| xAI | softfail | p=none | no | 모니터링 전용 DMARC, DKIM 없음, 중국 이메일 인프라 |
| Stability AI | softfail | p=none | yes | DKIM은 있으나 실패 시 DMARC가 강제 적용하지 않음 |
| Hugging Face | softfail | p=none | yes | 위와 동일 — DKIM은 존재하지만 DMARC는 모니터링 전용임 |
| Inflection AI | softfail | missing | yes | DMARC가 전혀 없음 |
| Qdrant | softfail | p=none | no | 어떤 계층에서도 강제 적용되지 않음 |

p=none은 도메인 소유자가 DMARC 실패 보고서를 수집하고는 있지만, 수신자에게 실패에 따른 조치를 요구하지는 않음을 의미합니다. 이는 DMARC를 배포할 때 거치는 표준적인 첫 단계로, 강제 적용하기 전에 모니터링을 수행하는 것이지만, 일부 기업들은 무기한 모니터링 모드에 머물러 있습니다. 이것이 이 기업들의 이메일이 활발하게 스푸핑 (spoofing)되고 있다는 뜻은 아닙니다. 단지 이들의 DNS 설정이 수신 메일 서버에 스푸핑된 메시지를 거부하도록 지시하지 않는다는 의미입니다. 실제로 스푸핑이 성공할지 여부는 수신 서버 자체의 정책에 달려 있습니다.

Nvidia가 가장 눈에 띄는 격차를 보입니다. 시가총액 3조 달러 규모의 기업이 DKIM은 설정되어 있으나 DMARC 정책은 전혀 없습니다. 프로세스를 시작했지만 완료하지 않은 것입니다.

어제와 무엇이 달라졌나요?

| 지표 | SPF 전용 분석 | 통합 분석 |
| :--- | :--- | : |
| 격차가 있는 기업 수 | 26개 (67%) | 6개 (15%) |
| 오탐 (False alarms) | — | 20개 기업이 위험한 것으로 잘못 분류됨 |
| 확인된 계층 | SPF만 확인 | SPF + DMARC + DKIM |

기존 분석은 기술적으로는 정확했습니다. 26개 기업이 SPF softfail을 사용하는 것은 사실입니다. 하지만 대부분이 DMARC 강제 적용에 의해 보호받고 있기 때문에 실질적으로는 오해의 소지가 있었습니다.

직접 도메인을 확인해 보세요
세 가지 계층을 모두 가중치로 두어 통합된 스푸핑 가능성 위험 점수를 보여주도록 대화형 체크 도구를 업데이트했습니다. 도메인을 입력하면 SPF 정책 + DMARC 강제 적용 + DKIM 존재 여부 + 종합적인 평가를 확인할 수 있습니다. 데이터는 DomainIntel을 통해 공개 DNS 레코드에서 실시간으로 가져옵니다. 모든 주장은 dig 명령어로 독립적으로 검증 가능합니다. 원문 기사에 대한 @privacyfish의 댓글로 인해 이번 수정이 이루어졌습니다.

2026년 5월 21일 수집된 데이터.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0