1. 왜 지금 다시 이메일 인증인가
몇 년 전까지만 해도 SPF/DKIM/DMARC는 "메일 잘 가게 하려면 박아두는 DNS 레코드" 정도였다. 한 번 설정하고 잊는 영역. 그런데 2024년 초 Google과 Yahoo가 대량 발송자(하루 5천 통 이상)에게 DMARC 구성을 사실상 의무화하면서 상황이 바뀌었다. 이제 인증은 "안 하면 메일이 안 가는" 전제 조건이 됐다. 원문(Fastmail)에서는 이걸 웹의 HTTPS가 걸어온 길에 비유한다. 모범 사례 → 기대사항 → 인프라. 자물쇠 없는 사이트가 경고로 취급되듯, 인증 없는 메일도 점점 그렇게 돼간다.
여기에 한 겹 더 얹힌 게 AI다. 원문이 짚는 핵심은 이거다. 예전엔 사람이 의심스러운 메일을 직접 읽으며 "도메인에 글자 하나 더 붙었네", "긴급하다는 말투가 어색하네" 같은 신호를 잡아냈다. 그런데 받은편지함을 요약하고, 할 일을 뽑아내고, 답장 초안을 쓰고, 경우에 따라 사용자를 대신해 행동까지 하는 AI 어시스턴트가 표준 기능이 되면 그 휴리스틱이 사라진다. AI는 내용과 긴급성을 읽고 그대로 실행해버린다. 그래서 설득력 있는 스푸핑 메일은 받은편지함에 도달하기 전에 인증으로 막아야 한다는 게 글의 논지다.
솔직히 말하면 원문은 Fastmail의 포지셔닝성 글이라 "그래서 뭘 발표한다는 거냐"는 댓글 반응이 많았다. 나도 동의한다. 다만 인프라 엔지니어 입장에서 보면 인증 체계 자체는 여전히 우리가 직접 설정하고 운영하고 트러블슈팅해야 하는 실무 영역이고, AI 필터가 인증 결과를 핵심 입력값으로 쓰기 시작했다는 맥락은 충분히 시의성이 있다. 그 지점만 떼어내서 실무 관점으로 풀어보자.
2. SPF·DKIM·DMARC 동작 원리 — 세 개가 어떻게 맞물리나
이 셋은 따로 노는 표준이 아니라 체인으로 물려 있다. 비유하자면 이렇다.
- SPF: "이 봉투를 부친 우체국이 우리 회사 지정 우체국이 맞나?" — 발송 서버의 권한 검증
- DKIM: "봉투 안 편지에 우리 회사 봉인 도장이 찍혀 있고, 운송 중에 뜯긴 흔적이 없나?" — 메시지의 무결성 + 서명 검증
- DMARC: "SPF랑 DKIM 둘 중 하나라도 통과했고, 그게 From 도메인이랑 일치하나? 실패하면 어떻게 처리할까?" — 정책 결합 + 실패 시 처리 방침
SPF — 어느 서버가 보낼 권한이 있는가
도메인의 TXT 레코드에 발송 권한이 있는 서버 목록을 적어둔다. 수신 서버는 메일을 받을 때 실제 접속해온 IP가 이 목록에 있는지 본다.
$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"여기서 ~all(SoftFail)이냐 -all(HardFail)이냐가 운영 정책의 핵심이다. ~all은 "목록에 없는 서버에서 와도 일단 통과는 시키되 의심해", -all은 "목록에 없으면 거부해". 처음 도입할 땐 ~all로 시작하는 게 안전하다.
SPF의 가장 큰 함정은 DNS 조회 10회 제한이다. include가 중첩되면서 조회 횟수가 10을 넘으면 SPF 평가 자체가 permerror로 떨어진다. SaaS 메일 서비스 서너 개만 물려도 금방 초과한다. 이건 뒤 함정 섹션에서 에러까지 같이 본다.
DKIM — 메시지에 서명을 붙인다
발송 서버가 개인키로 메일 헤더+본문 일부에 서명을 만들어 DKIM-Signature 헤더에 넣는다. 공개키는 DNS에 올려둔다. 수신 서버는 그 공개키로 서명을 검증해서 전송 중 변조가 없었는지 확인한다.
$ dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."여기서 selector1 부분이 셀렉터(selector)다. 한 도메인이 여러 발송 서비스를 쓸 때 셀렉터로 키를 구분한다. Google은 google, SendGrid는 s1/s2 같은 식으로 자기들 셀렉터를 쓴다. 메일 원본 헤더의 DKIM-Signature에서 s= 값을 보면 어떤 셀렉터를 조회해야 하는지 나온다.
DMARC — 둘을 묶고, 실패 시 행동을 지시한다
DMARC가 추가하는 핵심 개념이 alignment(정렬)다. 단순히 SPF/DKIM이 통과했다고 끝이 아니라, 그 통과한 도메인이 사용자에게 보이는 From: 도메인과 일치해야 한다. 이게 스푸핑 방어의 진짜 핵심이다.
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=r; pct=100"읽어보면 이렇다.
p=quarantine: 실패한 메일은 격리(스팸함). 정책은none(관찰만) →quarantine→reject순으로 강화한다.rua=mailto:: 집계 리포트(aggregate report)를 받을 주소. 이게 4번 섹션의 핵심이다.adkim=s: DKIM 정렬을 strict로.r(relaxed)이면 서브도메인까지 허용한다.pct=100: 정책을 적용할 메일 비율. 롤아웃 초기엔pct=10처럼 낮춰서 점진 적용한다.
3. 실무 관점 — 트레이드오프와 흔한 함정
흔한 함정 1: SPF DNS 조회 10회 초과 (permerror)
실무에서 제일 자주 만나는 사고다. 마케팅팀이 새 메일 SaaS를 붙여달라고 해서 include를 하나 더 추가했더니, 어느 날부터 갑자기 정상 메일까지 SPF가 깨지기 시작한다. 원인은 조회 횟수 초과. DMARC 리포트나 메일 헤더의 Authentication-Results에 이런 식으로 찍힌다.
Authentication-Results: mx.google.com;
spf=permerror (google.com: permanent error in processing during
lookup of user@example.com: DNS error) smtp.mailfrom=example.compermerror는 "SPF 레코드 자체가 RFC 위반 상태라 평가 불가"라는 뜻이다. ~all이든 -all이든 평가가 무의미해진다. 해결은 (1) 안 쓰는 include 정리, (2) SPF flattening(include를 실제 IP 대역으로 펼쳐 조회 횟수를 줄임) 정도다. flattening은 SaaS 쪽 IP가 바뀌면 깨지므로 자동 갱신 도구 없이 손으로 하면 나중에 폭탄이 된다. 트레이드오프가 분명하니 도입 전 팀 내 합의가 필요하다.
흔한 함정 2: 포워딩이 SPF를 깨뜨린다
메일링 리스트나 .forward로 메일을 전달하면 발송 IP가 중간 서버로 바뀐다. 그러면 원래 도메인의 SPF에는 그 중간 서버 IP가 없으니 SPF가 실패한다. 이래서 DMARC는 SPF 또는 DKIM 둘 중 하나만 정렬+통과해도 PASS로 친다. DKIM 서명은 본문이 안 바뀌면 포워딩돼도 살아남기 때문이다. 그런데 메일링 리스트가 본문에 footer를 붙이거나 제목에 [list]를 끼워넣으면 DKIM 서명까지 깨진다. 원문이 언급한 ARC(Authenticated Received Chain) 실험이 바로 이 "복잡한 전달 경로에서 인증을 어떻게 이어붙일까" 문제를 다루려던 거다. 다만 원문 댓글에서도 ARC가 완전한 해법은 아니라는 지적이 나온다.
흔한 함정 3: DMARC를 처음부터 p=reject로 박는다
의욕 넘쳐서 처음부터 p=reject로 가면 거의 100% 사고난다. 사내에 미처 파악 못 한 발송 경로(레거시 배치 서버, 사내 모니터링 알림, 협력사가 대신 보내는 메일)가 한두 개는 꼭 있고, 그게 다 거부당해서 "왜 우리 알림 메일이 안 와요" 티켓이 폭주한다. 반드시 p=none으로 시작해 리포트로 발송원을 다 파악한 뒤 단계적으로 올려야 한다.
대안/한계 — 인증은 신원이지 의도가 아니다
원문이 솔직하게 인정하는 한계이자, 댓글에서 제일 날카롭게 파고든 지점이다. SPF/DKIM/DMARC는 "이 메일이 진짜 그 도메인에서 왔는가"는 검증하지만 "그 내용이 사기인가"는 검증하지 못한다. 댓글에 나온 실제 공격 시나리오가 인상적이다. 공격자가 PayPal·Stripe 같은 진짜 결제 플랫폼이 메일을 발송하게 만든 뒤, 회사명 필드에 "문제 발생, 이 번호로 전화하세요"를 넣는다. 그러면 진짜 PayPal에서 나가는, 모든 인증을 통과하는 정상 메일에 그 문구가 박힌다. DMARC로는 절대 못 잡는다. 인증은 사칭의 비용과 복잡성을 높일 뿐, 만능이 아니라는 걸 분명히 알고 가야 한다.
4. DMARC 리포트로 위협 모니터링하기
rua로 받는 집계 리포트는 압축된 XML이다. 메일 수신자(Google, Microsoft 등)가 "당신 도메인을 From으로 쓴 메일을 이런 IP에서 이만큼 봤고 인증 결과는 이랬다"를 하루 단위로 보내준다. 사람이 XML 원본을 읽긴 힘들어서 보통 파서나 SaaS(예: dmarcian, Postmark 무료 분석 등)를 쓴다. 구조는 대략 이렇게 생겼다.
<record>
<row>
<source_ip>203.0.113.55</source_ip>
<count>128</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
</record>이 record를 보면 모르는 IP 203.0.113.55가 우리 도메인을 From으로 128통이나 보냈는데 SPF/DKIM 둘 다 fail이다. 두 가지 가능성이다. (1) 우리가 깜빡한 정상 발송 경로 → SPF/DKIM에 추가해줘야 한다. (2) 진짜 스푸핑 시도 → 정책을 강화하면 이 IP의 메일은 막힌다. 리포트를 안 보면 이 구분이 안 된다. 그래서 p=none 관찰 기간이 중요한 거다.
로컬에서 빠르게 까보고 싶으면 받은 첨부(gzip)를 이렇게 풀어볼 수 있다.
$ gunzip -c example.com\!google.com\!1700000000.xml.gz | \
grep -E "source_ip|dkim|spf|disposition"
<source_ip>209.85.220.41</source_ip>
<dkim>pass</dkim>
<spf>pass</spf>
<disposition>none</disposition>이런 식으로 IP별 pass/fail만 빠르게 훑고, 의심스러운 IP는 따로 조사하면 된다. 양이 많아지면 결국 파서를 붙이게 되지만, 처음 감 잡을 땐 이걸로 충분하다.
5. AI 필터·어시스턴트 환경에서 인증 실패가 미치는 영향
원문의 논점을 인프라 관점으로 다시 정리하면 이렇다. 과거에 인증 실패는 "스팸함에 들어갈 확률이 좀 올라간다" 정도의 약한 신호였다. 그런데 두 가지가 동시에 바뀌고 있다.
- AI 필터가 인증 결과를 점점 더 핵심 입력값으로 쓴다. 인증이 깨진 도메인은 발송원 평판과 묶여 더 강하게 페널티를 받는다. 즉, 우리 회사 메일의 DKIM 셀렉터 키를 실수로 안 올렸다거나 SPF가 permerror면, 단순히 "일부 차단"이 아니라 도메인 평판 자체가 깎이는 방향으로 작동할 수 있다.
- AI 어시스턴트는 인증을 통과한 메일의 내용을 그대로 신뢰하고 행동(요약, 일정 등록, 답장 초안)한다. 사람이라면 걸렀을 미묘한 사칭을 그대로 실행할 위험이 있다.
결국 인프라 담당자 입장에서 시사점은 명확하다. 인증은 "메일 잘 가게 하는 옵션"이 아니라 "우리 도메인 평판을 지키는 기본 위생"이 됐다. 그리고 원문이 언급한 BIMI(검증된 발신자가 받은편지함에 자기 로고를 표시하는 표준)는 DMARC를 p=quarantine 이상으로 강화한 도메인만 쓸 수 있다. AI 생성 피싱이 내용만으로 구분하기 어려워진 시점에, 시각적 신뢰 신호를 얻으려면 인증 체계가 단단해야 한다는 뜻이다. 다만 BIMI는 VMC(검증된 마크 인증서) 비용 등 도입 장벽이 있어서, 조직 규모와 필요에 따라 판단할 영역이다(공식 요구사항은 각 메일 사업자 문서 확인 필요).
6. 정리 — 누가 언제 어떻게
한 줄 요약: SPF/DKIM/DMARC는 이제 선택이 아니라 도메인 평판과 메일 도달성의 전제 조건이고, AI가 메일을 자율 처리할수록 "내용은 못 막아도 발송원 사칭의 비용은 올린다"는 가치가 커진다. 단, 인증은 신원 검증이지 의도 검증이 아니라는 한계를 알고 써야 한다.
프로덕션 점진 롤아웃 체크리스트:
- 현재 발송 경로 전수 조사 (사내 배치, 알림 서버, 협력사 대행 발송까지)
- SPF 레코드 정리 —
include조회 횟수 10회 이내 확인, 처음엔~all - 모든 발송 서비스에 DKIM 셀렉터 설정 + DNS 공개키 확인
- DMARC를
p=none으로 배포하고rua리포트 수집 시작 - 1~2주 리포트 분석 → 누락된 정상 발송원을 SPF/DKIM에 추가
pct를 낮춰가며p=quarantine→p=reject로 단계 강화- 필요 시 BIMI 검토 (DMARC 강화 정책 선행 필요)
이건 누구에게나 필요하다. 대량 발송하는 서비스라면 Google/Yahoo 정책 때문에 이미 필수다. 사내 전용 도메인이라도 우리 도메인을 사칭한 피싱이 협력사·고객에게 날아가는 걸 막으려면 최소 p=quarantine은 가는 게 맞다. 다만 처음부터 p=reject로 박지 말고, 리포트로 발송원을 다 파악한 뒤 단계적으로. 그 인내심이 티켓 폭주와 평온한 금요일을 가른다.
참고 자료
'Tech_News' 카테고리의 다른 글
| curl 없는 컨테이너에서 살아남기: Bash /dev/tcp로 HTTP 요청 날리기 (0) | 2026.06.19 |
|---|---|
| JWT로 로그인 세션 유지하지 마라 — 5년차 인프라 엔지니어가 정리한 진짜 이유와 전환 가이드 (0) | 2026.06.18 |
| AUR 패키지 408개 감염 사태로 다시 보는 공급망 보안: maintainer 사칭부터 eBPF 루트킷까지 (0) | 2026.06.15 |
| 하드웨어 증설 없이 스캔 처리량 10배: Cloudflare가 Kafka·Postgres·API만 손봐서 해낸 스케일링 분석 (0) | 2026.06.14 |
| Claude Desktop이 채팅만 써도 1.8GB Hyper-V VM을 띄우는 이유와 인프라 엔지니어의 대응법 (0) | 2026.06.13 |
