기술 · 출처 기반 답변

Authenticated Received Chain(ARC)란? 개념과 동작 방식

Authenticated Received Chain(ARC)은 중간 메일 서버가 SPF, DKIM, DMARC 검사 결과에 서명할 수 있게 해 주는 이메일 인증 표준입니다. 이메일이 전달(포워딩)되는 과정에서 원래의 SPF 또는 DKIM 서명이 깨지더라도, 최종 수신 서버가 원래의 인증 상태를 신뢰할 수 있습니다.

ARC의 동작 원리

ARC는 이메일이 중간 서버를 거칠 때 세 가지 전용 헤더를 추가하는 방식으로 동작합니다. ARC-Seal은 ARC-Authentication-Results를 포함하는 ARC-Message-Seal에 대한 디지털 서명을 제공합니다. 이 체인은 각 홉(hop)에서의 인증 상태를 검증 가능한 기록으로 남깁니다. 메시지가 전달되면 다음 서버는 ARC 체인을 검증해, 전달자가 엔벨로프나 헤더를 수정하기 전에는 메시지가 정상이었음을 확인할 수 있습니다.

이메일 발신자에게 중요한 이유

사용자나 메일링 리스트가 이메일을 자주 전달하는 발신자에게 ARC는 매우 중요합니다. ARC가 없으면 전달자가 발신자 주소를 바꾸거나 메시지 본문을 수정하는 경우가 많아 SPF와 DKIM이 실패합니다. 발신자가 엄격한 DMARC reject 정책을 사용한다면 이렇게 정상적으로 전달된 이메일도 차단됩니다. ARC는 신뢰할 수 있는 중간 서버가 이미 메시지를 검증한 경우, 최종 수신자가 DMARC 실패를 무시할 수 있는 방법을 제공합니다.

운영 시 참고 사항과 흔한 실수

흔한 실수는 ARC가 DKIM이나 SPF를 대체한다고 생각하는 것입니다. ARC는 이러한 프로토콜에 의존하는 보조 계층입니다. 중간 서버가 ARC를 지원하고 최종 수신 서버가 ARC 서명 주체를 신뢰할 때만 동작합니다. 전달 시나리오에서 ARC에 의존하기 전에, SendHQ 무료 도구(https://sendhq.cc/tools)로 기본 DKIM 및 SPF 레코드가 올바르게 설정되어 있는지 먼저 확인하세요.

구체적인 구현 예시

사용자가 회사 이메일을 개인 Gmail 계정으로 전달하는 경우를 생각해 보세요. 회사 서버는 DKIM으로 메일에 서명합니다. 전달 서버는 메일을 받아 DKIM을 검증하고 ARC 실(seal)을 추가합니다. Gmail이 메일을 받으면 전달 서버가 허가된 발신자가 아니므로 원래의 SPF는 실패합니다. 하지만 Gmail은 신뢰할 수 있는 전달자가 추가한 ARC 실을 확인하고 ARC 헤더에 저장된 원래의 DKIM 결과를 검증한 뒤, 메일을 거부하지 않고 전달합니다.

ARC와 DMARC의 상호작용

ARC는 DMARC의 안전망 역할을 합니다. DMARC가 메시지의 현재 상태를 평가하는 반면, ARC는 인증의 이력을 기록으로 제공합니다. 현재 DMARC 검사는 실패했지만 신뢰할 수 있는 출처에서 온 유효한 ARC 체인이 있으면, 수신 메일 전송 에이전트(MTA)는 DMARC 정책을 무시하고 메시지를 수락할 수 있어 스팸 필터의 오탐이 줄어듭니다.

팀에서 자주 묻는 질문

ARC가 DMARC를 대체하나요?

아니요. ARC는 DMARC를 대체하지 않습니다. ARC는 인증 결과를 보존하는 방법을 제공하며, 덕분에 메시지가 전달된 뒤에도 DMARC를 더 정확하게 평가할 수 있습니다.

ARC는 누가 구현해야 하나요?

ARC는 주로 메일링 리스트 관리자, 전달 서비스, 기업용 이메일 게이트웨이 같은 메일 중개 서비스가 구현합니다.

ARC가 모든 스팸을 막아 주나요?

아니요. ARC는 정상적으로 전달된 메일이 스팸으로 분류되는 것을 막기 위한 것이며, 스팸 자체를 차단하기 위한 것이 아닙니다. ARC는 서명 주체와 수신자 사이의 신뢰에 의존합니다.

모든 이메일 제공업체가 ARC를 지원하나요?

Gmail과 Microsoft 365 등 대부분의 주요 제공업체는 ARC를 지원하지만, 규모가 작은 메일 서버와 레거시 시스템에서는 도입 정도가 다릅니다.

1차 출처

더 알아보기

이메일 DKIM SPF DMARCDMARC 확인이메일 전달성이메일 도메인 검증