이메일 인증은 어떻게 작동할까? SPF·DKIM·DMARC 한눈에 이해하기

01보낸 사람 주소가 곧 신분증은 아닙니다

우편 봉투에 회사 이름을 적는다고 그 회사가 보낸 편지가 되는 것은 아닙니다. 이메일도 마찬가지입니다. 화면에 표시되는 이름과 주소만으로 실제 발신자를 확인할 수는 없습니다.

여기서 주소를 두 가지로 나눠 보면 이해하기 쉽습니다. 하나는 메일 앱에 보이는 From입니다. 다른 하나는 서버끼리 메일을 주고받을 때 사용하는 MAIL FROM입니다. 배달 실패 안내를 돌려보내는 데 쓰이며, 받은 메일에서는 보통 Return-Path 헤더에서 확인합니다.

주소가 다르다는 이유만으로 주소 도용이라고 판단할 수는 없습니다. 뉴스레터 서비스가 회사 대신 메일을 보내는 경우도 있기 때문입니다. 어떤 도메인으로 인증에 성공했는지, 그 도메인이 From과 맞는지를 함께 봐야 합니다. Microsoft의 발신 주소 설명 ↗

02메일 한 통은 이런 확인을 거칩니다

회사는 먼저 DNS에 메일 인증 정보를 공개합니다. DNS는 도메인의 정보를 찾아보는 인터넷 주소록이라고 생각하면 됩니다. 여기에 허용한 발신 서버, 서명 확인용 공개키, 인증 실패 시 처리 방침을 적어 둡니다.

수신 서버는 메일을 받으며 이 정보를 조회합니다. SPF와 DKIM을 검사하고, 그 결과가 화면에 보이는 From 도메인과 연결되는지 DMARC로 확인합니다.

검사가 끝나면 수신 서버가 DMARC 정책과 자체 보안 기준을 함께 적용합니다. 따라서 인증이 통과해도 스팸으로 분류될 수 있습니다. 반대로 DMARC가 실패해도 수신 측 예외 정책에 따라 처리 결과가 달라질 수 있습니다. DMARC 표준의 동작 설명 ↗

03SPF는 발신 서버를 확인합니다

SPF는 도메인 관리자가 공개한 발신 서버 허용 목록입니다. 회사가 Google Workspace로 메일을 보낸다면 Google의 발송 서버를 허용하는 정보를 DNS에 넣습니다.

여기서 중요한 점은 SPF가 일반적으로 MAIL FROM 도메인을 기준으로 검사한다는 것입니다. 화면에 보이는 From을 직접 보증하지는 않습니다. 공격자가 자기 도메인에 SPF를 설정한 뒤 From만 회사 주소로 바꾸면, SPF 자체는 통과할 수도 있습니다.

메일 전달에도 주의해야 합니다. 다른 서버를 거쳐 전달되면 최종 수신 서버가 보는 발신 IP가 달라집니다. 그 서버가 원래 도메인의 허용 목록에 없다면, 정상 메일이어도 SPF가 실패할 수 있습니다. SPF 표준 ↗

04DKIM은 메일에 붙은 전자서명을 확인합니다

DKIM은 발송 서버가 메일에 전자서명을 붙이는 방식입니다. 발신 측이 보관하는 개인키로 서명하고, 수신 측은 DNS에 공개된 공개키로 그 서명을 확인합니다.

서명에는 d=example.com처럼 서명 도메인이 들어 있습니다. s=google 같은 selector는 어느 공개키를 찾아야 하는지 알려주는 이름입니다.

DKIM은 메일 내용을 암호화하는 기능이 아닙니다. 또 “재무팀의 특정 직원이 직접 보냈다”거나 “첨부파일이 안전하다”는 뜻도 아닙니다. 어느 도메인의 서명이 유효한지 확인하는 기술입니다. DKIM 표준 ↗

05DMARC는 인증 결과를 보낸 사람 주소와 연결합니다

SPF는 발신 서버를, DKIM은 전자서명을 확인합니다. 하지만 그 인증이 회사와 무관한 도메인의 것이라면 회사 주소를 신뢰할 근거가 되지 않습니다.

DMARC는 인증에 성공한 도메인이 From 도메인과 맞는지를 추가로 확인합니다. 이 관계를 도메인 정렬, 또는 alignment라고 부릅니다.

기본 설정인 완화 모드(r)에서는 example.com과 mail.example.com처럼 같은 조직 도메인에 속하면 정렬된 것으로 봅니다. 엄격 모드(s)는 도메인이 완전히 같아야 합니다. 이름이 비슷한 별도 도메인은 여기에 해당하지 않습니다.

DMARC 통과 조건과 별개로, 발신 환경에는 SPF와 DKIM을 모두 설정하는 것이 좋습니다. 전달 과정이나 발송 서비스 구성에 따라 둘 중 하나가 실패할 수 있고, 대량 발송 서비스의 요구사항도 따로 확인해야 하기 때문입니다. Microsoft의 DMARC·정렬 설명 ↗

06네 가지 메일을 비교해 보세요

아래에서 발송 상황을 바꿔 보세요. PASS라는 글자만 보는 것과 어떤 도메인으로 통과했는지 보는 것의 차이를 확인할 수 있습니다.

외부 뉴스레터는 SPF 도메인이 달라도 회사 도메인으로 DKIM이 통과하면 DMARC를 통과합니다. 반면 주소 도용 예시는 SPF와 DKIM이 모두 PASS여도 회사 도메인과 연결되지 않아 실패합니다.

07실패한 메일은 정책으로, 운영 상태는 리포트로 확인합니다

DMARC에는 도메인 소유자가 수신 서버에 요청하는 처리 방침도 있습니다. DNS 레코드의 p= 값으로 정합니다.

수신 서버는 자체 정책에 따라 최종 처리합니다. p=none이라고 모든 메일을 받는 것도, p=reject라고 모든 종류의 사칭을 차단하는 것도 아닙니다. DMARC 정책 표준 ↗

RUA는 “누가 어떤 인증 결과로 보냈는지” 보여줍니다

DMARC 레코드의 rua=에는 집계 리포트를 받을 주소를 적습니다. 리포트를 제공하는 수신 서버는 자신이 관찰한 발신 IP, 메일 건수, 인증 결과 등을 모아 보냅니다.

실패한 200통을 전부 주소 도용으로 세면 안 됩니다. 정상 뉴스레터의 설정 오류가 섞여 있을 수 있습니다. 실제 발송 서비스 목록과 대조해 원인을 분류해야 합니다.

RUA는 전체 발송 로그나 실시간 경보가 아닙니다. 보고하는 수신자가 관찰한 범위의 집계이며, 메일 원문이나 최종 받은편지함 도착 여부를 알려주는 자료도 아닙니다. DMARC 집계 리포트 표준 ↗

08설정은 발신처 목록을 만드는 데서 시작합니다

회사 메일만 떠올리기 쉽지만, 홈페이지 문의 답장이나 주문 알림, 비밀번호 재설정 메일도 회사 주소로 발송됩니다. 먼저 회사 이름으로 메일을 보내는 서비스를 적어 보세요.

1. 발신처를 모읍니다

   직원용 메일, 뉴스레터, CRM, 고객지원, 자동 알림을 확인합니다. 관리 담당자도 함께 적어 둡니다.

2. 서비스별 SPF와 DKIM을 설정합니다

   서비스의 공식 발급값을 DNS에 등록합니다. DKIM은 메일 서비스에서 서명도 활성화해야 합니다.

3. DMARC 관찰과 리포트 수신을 시작합니다

   정상 메일의 인증과 도메인 정렬을 확인하고 누락된 발신처를 찾습니다.

4. 문제를 정리한 뒤 정책을 강화합니다

   월말 청구서처럼 드물게 보내는 메일까지 확인합니다. 이후에도 서비스가 추가되면 다시 점검합니다.

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

09인증이 통과해도 확인해야 할 것은 남습니다

이메일 인증은 회사 도메인의 무단 사용을 줄이는 데 도움이 됩니다. 다만 다음 상황은 별도로 대응해야 합니다.

• 회사와 닮은 다른 주소공격자가 자기 도메인으로 인증을 설정할 수 있습니다. 표시 이름뿐 아니라 실제 주소를 확인해야 합니다.
• 탈취된 정상 계정회사의 정상 발송 경로를 쓰면 인증도 통과할 수 있습니다. 계정 보안과 로그인 모니터링이 필요합니다.
• 메일 내용과 송금 요청인증은 링크·첨부파일의 안전성이나 계좌 변경의 정당성을 보장하지 않습니다. 중요한 요청은 기존 연락처로 따로 확인합니다.

Google Workspace나 Microsoft 365를 쓰더라도 회사 도메인의 인증 상태는 확인해야 합니다. 회사 대신 보내는 서비스까지 살펴봐야 실제 발신 환경을 알 수 있습니다. DMARC의 보호 범위 ↗