ARC(Authenticated Received Chain)란?

ARC(Authenticated Received Chain)는 메시지의 원래 SPF, DKIM, DMARC 결과를 기록하고, 메시지가 메일링 리스트나 포워더 같은 중간 서버를 거치는 동안 그 결과를 함께 전달하는 이메일 인증 프로토콜이에요. 최종 수신 서버는 중간 단계에서 메시지가 수정되기 전에 어떻게 인증되었는지 신뢰할 수 있는 방식으로 확인할 수 있어서, 정상적으로 전달된 메일이 거부되지 않아요.

정의

Authenticated Received Chain은 2019년 7월에 발표된 RFC 8617에 정의된 이메일 인증 표준이에요. 메시지가 발신자에게서 수신자에게 바로 전달되지 않고 중간 서버를 거쳐 중계될 때 SPF와 DKIM이 제대로 작동하지 않는 오랜 약점을 해결하기 위해 만들어졌어요.

수신자에게 이메일을 바로 보내면 보통 SPF와 DKIM 검사가 성공하고 DMARC도 통과해요. 문제는 메시지가 중간에 제3자를 거칠 때 생겨요. 메일링 리스트, 메일을 자동 전달하는 계정, 보안 게이트웨이는 메시지를 변경하는 경우가 많아요. 제목을 다시 쓰거나, 바닥글을 추가하거나, 다른 IP 주소에서 메시지를 중계할 수 있죠. 이런 변경은 원래의 DKIM 서명을 깨뜨리고 SPF 결과를 무효로 만들어, 메시지가 완전히 정상인데도 DMARC가 실패할 수 있어요.

ARC는 Google을 비롯한 대형 메일 사업자의 엔지니어들이 참여한 업계 그룹이 바로 이런 상황을 수신자가 알아볼 수 있도록 설계했어요. 수신자는 마지막 단계에서 보이는 깨진 인증 결과만으로 판단하지 않고, ARC 체인을 읽어 중간 서버가 손대기 전에 메시지가 올바르게 인증되었다는 사실을 알 수 있어요.

작동 방식

ARC는 참여하는 각 중간 서버가 메시지를 다음으로 전달하기 전에 ARC 세트라고 부르는 암호화 서명된 기록을 추가하는 방식으로 작동해요. 각 ARC 세트는 세 개의 헤더 필드로 구성되고, 체인을 순서대로 읽을 수 있도록 인스턴스 번호를 가지고 있어요.

첫 번째 필드는 ARC-Authentication-Results예요. 중간 서버가 메시지를 받은 시점에 확인한 SPF, DKIM, DMARC 결과의 스냅샷을 담고 있어요. 사실상 해당 단계에서의 인증 판정을 고정해 둔 사본이에요.

두 번째 필드는 ARC-Message-Signature예요. DKIM 서명과 비슷하게 작동해요. 체인의 해당 시점에 존재하는 메시지 헤더와 본문에 대한 암호화 서명으로, 기록된 인증 결과를 실제 콘텐츠와 묶어 줘요.

세 번째 필드는 ARC-Seal이에요. 현재 세트뿐 아니라 이전 ARC 헤더 체인 전체를 대상으로 하는 서명이에요. 이 씰에는 cv라고 쓰는 체인 검증 태그가 있어 지금까지의 체인 상태를 알려 줘요. none은 첫 번째 단계라는 뜻이고, pass는 이전의 모든 ARC 세트가 올바르게 검증되었다는 뜻이며, fail은 체인의 어딘가를 검증할 수 없었다는 뜻이에요.

메시지가 ARC를 지원하는 여러 서버를 거치면서 인스턴스 번호는 단계마다 늘어나요. 메시지를 검증하는 수신 서버는 ARC 세트를 순서대로 읽고, 빠진 항목이 없는지 확인하고, 각 씰이 이전 항목을 유효하다고 보고하는지 점검한 뒤, 가장 최근의 메시지 서명을 검증해요. 체인이 온전하면 수신 서버는 맨 처음 단계에서 기록된 인증 결과를 신뢰할 수 있어요.

이메일 도달률에 중요한 이유

포워딩과 메일링 리스트는 어디에나 있고, ARC가 없으면 이것들이 정상적인 메일을 조용히 거부당하게 만들기 때문에 ARC가 중요해요. 업무 메일을 개인 계정으로 전달하는 직원, 모든 메시지에 바닥글을 붙이는 토론 리스트, 수신 메일을 스캔하는 외부 보안 장비는 모두 메시지가 진짜인지와는 상관없이 DKIM이나 SPF를 깨뜨려요.

도메인 소유자가 p=reject 같은 엄격한 DMARC 정책을 게시하면, 이렇게 깨진 인증 결과 때문에 전달된 사본은 보통 폐기돼요. 수신자는 기다리던 메시지를 끝내 받지 못하고, 겉으로는 원인을 알 수 없는 전송 실패처럼 보이죠. ARC는 최종 수신자가 더 나은 판단을 내릴 수 있도록 맥락을 제공해요. 신뢰할 수 있는 중간 서버가 수정하기 전에 메시지가 올바르게 인증되었다는 사실이 ARC 체인에 나타나면, 수신자는 정직한 전달 메일에 엄격한 정책을 적용하는 대신 메시지를 전달하기로 결정할 수 있어요.

ARC가 하는 일과 하지 않는 일을 정확히 구분하는 것이 중요해요. ARC는 DMARC를 무시하지 않으며, 전달을 보장하지도 않아요. ARC는 하나의 신호예요. 수신자는 여전히 특정 ARC 체인을 얼마나 신뢰할지 스스로 결정하고, 그 신뢰는 체인에 서명한 중간 서버의 평판에 달려 있어요. ARC는 흔하면서도 골치 아픈 오탐 거부의 원인을 없애, 정상적인 메일이 받은편지함에 도착할 가능성을 높여 줄 뿐이에요.

VeriMails의 처리 방식

VeriMails는 이메일 검증 서비스이기 때문에 도달률의 다른, 그리고 상호 보완적인 부분에 집중해요. ARC가 이미 중간 서버를 거쳐 전송 중인 메시지를 보호한다면, VeriMails는 보내기 버튼을 누르기 전에 리스트의 주소가 실제로 존재하고 메일을 받을 수 있는지 확인해요.

VeriMails는 확인하는 모든 주소에 대해 구문 검증, MX 레코드 조회, DNS 확인, 수신 메일 서버와의 실시간 SMTP 핸드셰이크, 캐치올 감지, 일회용 주소 감지, 역할 기반 주소 감지를 실행해요. 이 조합으로 주소가 캠페인에 들어가기 전에 발송 가능한지 알 수 있고, 캠페인 판단에 쓸 수 있는 명확한 도달 가능성 분류도 함께 받아요.

두 방식은 서로를 강화해요. ARC와 SPF, DKIM, DMARC로 이루어진 더 넓은 인증 체계는 메일이 진짜임을 증명해 발신 평판을 보호해요. VeriMails는 유효하지 않거나 위험한 주소를 리스트에서 걸러 내 반송과 스팸 신고를 줄임으로써, 반대 방향에서 같은 평판을 보호해요. VeriMails REST API로 주소를 하나씩 검증하거나 CSV 파일을 업로드해 일괄로 검증할 수 있고, 모든 신규 계정은 만료되지 않는 무료 크레딧 100개로 시작해요. 신용카드는 필요 없어요.

자주 묻는 질문

아니요. ARC는 보완 수단이지 대체 수단이 아니에요. SPF, DKIM, DMARC는 평소처럼 그대로 실행돼요. ARC는 메시지가 SPF나 DKIM을 깨뜨리는 중간 서버를 거치는 특정 상황에서만 가치를 더해요. 메시지가 수정되기 전에 확인된 인증 결과를 기록해, 최종 수신자가 그 이전 결과를 고려할 수 있게 해 줘요. 이메일 인증의 기반은 여전히 SPF, DKIM, DMARC예요.
대부분의 발신자는 ARC를 직접 설정하지 않아요. ARC 서명은 전송 중에 메일을 수정하는 메일링 리스트, 포워더, 보안 게이트웨이 같은 중간 서버의 몫이에요. 이런 서비스를 운영한다면 ARC 키를 게시하고 메시지에 서명해야 해요. 일반 발신자라면 SPF, DKIM, DMARC만 올바르게 설정하면 되고, ARC 처리는 이를 지원하는 수신 제공업체에서 자동으로 이루어져요.
ARC는 각 단계마다 세 개의 헤더 필드를 추가해요. ARC-Authentication-Results는 해당 단계에서 확인된 SPF, DKIM, DMARC 결과를 기록하고, ARC-Message-Signature는 메시지에 대한 DKIM과 비슷한 서명이며, ARC-Seal은 이전 ARC 헤더 체인에 대한 서명이에요. 각 세트에는 인스턴스 번호가 있어 검증자가 단계를 순서대로 읽고 체인이 온전한지 확인할 수 있어요.
ARC는 2019년 7월에 발표된 RFC 8617에 정의되어 있으며, 정식 Internet Standard가 아닌 Experimental 상태로 발표되었어요. 실험적 지위에도 불구하고 Google과 Microsoft를 비롯한 주요 메일박스 제공업체가 구현해 전달된 메일을 평가할 때 사용하고 있어요. 사양이 표준 트랙으로 승격되지는 않았지만, 실제로 배포되어 작동하는 프로토콜이에요.

VeriMails 무료로 써 보기

가입하면 무료 크레딧 100개를 드려요. 신용카드는 필요 없어요. 오늘 바로 이메일 검증을 시작해 보세요.

무료로 시작하기
신용카드 없이 시작할 수 있어요. 크레딧은 만료되지 않아요.