
read receipts
자신에게 전달한 이메일이 스팸으로 간 이유
당신 잘못이 아닙니다. SPF 때문입니다. 이메일 제공자가 설명해주지 않는 메커니즘이 여기 있습니다.
오래된 계정에서 새 계정으로 자동 전달을 설정하면, 일부 메일이 조용히 스팸으로 사라질 것입니다. 제공자가 고장 난 것이 아니라, 전달 과정에서 메시지를 보내는 사람은 바꾸지만 암호화된 증명은 바꾸지 않기 때문입니다. SPF는 잘못된 서버를 검증하고, DMARC 판정이 실패로 바뀌며, 자신이 자신에게 보낸 합법적인 이메일이 격리됩니다. 해결 방법의 이름은 ARC이고, 2019년에 RFC 8617로 정의되었습니다.
전달이 내 메일을 SPF 실패하게 만드는 이유는?
SPF가 메시지를 중계한 마지막 서버를 검증하기 때문이고, 전달은 그 서버를 바꾸기 때문입니다. SPF(Sender Policy Framework)는 어떤 IP 주소가 도메인을 위해 메일을 보낼 수 있는지 나열하는 DNS 레코드입니다. bank.com이 영수증을 보내면, 받는 서버는 이렇게 검증합니다. 이것이 bank.com이 인증한 IP에서 도착했나? 예. 통과.
이제 그 영수증을 Gmail에서 새 주소로 전달합니다. Google의 서버가 이를 중계합니다. 최종 받는 서버는 SPF를 검증하고 묻습니다. Google이 bank.com을 위해 메일을 보낼 권한이 있나? 없습니다. SPF 실패. Google의 Workspace 문서에는 이것이 명확하게 나와 있습니다. 전달된 메시지가 SPF를 실패하는 이유는 전달 서버가 원래 도메인의 SPF 레코드에 없기 때문입니다. 아무것도 스푸핑되지 않았습니다. 검증이 단지 잘못된 홉을 보고 있을 뿐입니다.
그렇다면 왜 그것이 스팸으로 보내질까요?
DMARC 때문입니다. SPF 실패만으로는 예전에는 견딜 수 있었습니다. DMARC가 그것을 판정으로 바꿨습니다. DMARC는 SPF와 DKIM을 함께 묶고 받는 쪽에 둘 다 실패할 때 어떻게 할지 지시합니다. 아무것도 하지 않거나, 격리하거나, 거부하는 것입니다. 2024년까지 대형 발신자는 선택의 여지가 없었습니다. Google과 Yahoo가 하루에 5,000개 이상의 메시지를 자신의 사용자에게 보내는 모든 사람에게 DMARC를 의무화하기 시작했습니다.
다른 기둥인 DKIM은 메시지에 내장된 서명입니다. 이론상 콘텐츠에 서명하고 경로에는 서명하지 않기 때문에 전달을 견딥니다. 실제로 메시지에 건드리는 모든 것이 그것을 부수합니다. 메일링 리스트가 "구독 중입니다. 구독 취소는 여기" 바닥글을 추가하거나, 서버가 제목 줄을 다시 쓰거나, 줄이 줄바꿈되는 방식이 바뀌어도 서명이 더 이상 일치하지 않고, DKIM도 실패합니다. 이제 두 기둥이 모두 내려가고, DMARC가 실패를 말하며, 당신 자신의 영수증이 정크 폴더에 있습니다.
ARC란 무엇이고 실제로 이것을 고칠까요?
ARC(Authenticated Received Chain, RFC 8617)는 정직한 전달자가 메일이 건드리기 전에 인증을 통과했다고 증명할 수 있게 합니다. 전달 서버는 메시지에 봉인된 기록으로 "이것이 나에게 도착했을 때, SPF와 DKIM이 유효했습니다. 당신이 검증할 수 없는 구간에 대해서는 나의 말을 믿으세요"라고 표시합니다. 최종 받는 쪽이 그 전달자를 믿으면, DMARC 실패를 무시하고 전달할 수 있습니다.
함정은 "믿으면"에 있습니다. ARC는 비밀번호가 아닙니다. 평판 시스템입니다. 받는 쪽은 ARC 봉인자가 알려진 잘 행동하는 운영자인지 평가합니다. Google은 ARC 헤더에 표시를 하고 신뢰하는 발신자로부터 그것을 준수하고 있고, 이것이 Gmail-to-Gmail 전달은 보통 생존하지만 어떤 낡은 대학 중계를 통한 전달은 그렇지 않은 이유입니다.
자신이 전달을 직접 운영한다면 두 가지 구체적인 조치가 도움이 됩니다. 호스트가 이를 지원한다면 Server-Side Redirect / SRS 스타일 재작성을 사용하세요. 이것은 발신자 봉투를 다시 써서 SPF 검증이 원래 도메인이 아닌 당신의 전달자에 대해 작동하도록 합니다. 그리고 둘 다 ARC를 지원하는 제공자 간의 전달을 선호합니다. 계정을 통합하고 있고 목적지가 인증 혼란을 처리하기를 원한다면, 그것이 정확히 AI 이메일 플랫폼이 흡수하도록 만들어진 종류의 배관입니다.
언제 제공자를 탓하는 것을 멈춰야 할까요?
패턴이 "전달된 메일만 실패"일 때, 제공자는 올바르게 자신의 일을 하고 있습니다. 프로토콜이 문제입니다. 다음이 단서입니다. 누락된 메시지의 헤더를 열고 Authentication-Results 줄을 찾습니다. spf=fail이 원래 발신자가 아닌 전달자에 속하는 발신 IP와 함께 보이면, 그것은 SPF가 잘못된 홉을 검증하고 있는 것입니다. dkim=fail이 리스트나 메시지를 편집하는 중계를 통해 간 메일에 나타나면, 그것은 손상된 서명이지 위조가 아닙니다.
불편한 진실은 이메일 인증이 누군가 거짓말을 할 것이라고 가정하지 않은 시스템 위에 수십 년에 걸쳐 층층이 덧붙여졌다는 것입니다. SPF는 2006년에, DKIM은 2007년에, DMARC는 2015년에, ARC는 2019년에 왔습니다. 각각이 마지막 것이 열어놓은 구멍을 패치했습니다. 전달은 네 가지가 모두 서로 비비는 이음매이고, 당신의 받은편지함은 그 마찰을 느끼는 곳입니다.
출처
- IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
- Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
- Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold