애초에 이메일에 왜 이런 게 필요할까요

이메일에 관한 좀 불편한 진실부터 말씀드릴게요. 이메일은 1980년대 초에 서로를 믿는 사람들끼리 쓰는 작은 네트워크를 위해 설계됐어요. 아무 설정도 하지 않으면 누구나 [email protected]에서 보낸 척하는 메일을 보낼 수 있어요. 기본 프로토콜에는 그걸 막을 장치가 전혀 없거든요.

SPF, DKIM, DMARC는 이 문제를 해결하려고 나중에 추가된 거예요. 셋이 함께 있으면 Gmail, Outlook, Yahoo 같은 받는 쪽이 한 가지 질문에 답할 수 있어요. 이 메일이 정말 자기가 주장하는 도메인에서 온 걸까? 답이 ‘아니요’라면 그 메일은 스팸함으로 가거나 거부돼요. 반대로 내 도메인에 이 설정이 없으면, 진짜 메일이 가짜 취급을 받을 수도 있어요.

비유로 생각하면 쉬워요:

SPF는 초대 손님 명단이에요. 내 도메인으로 메일을 보내도 되는 서버 목록이죠.
DKIM은 밀랍 봉인이에요. 메일이 오는 도중에 바뀌지 않았다는 걸 증명하는 서명이죠.
DMARC는 입구 경비원에게 주는 지시서예요. 검사에 실패한 메일을 어떻게 처리할지, 그리고 누구에게 알릴지를 정해요.

SPF: 초대 손님 명단

SPF(Sender Policy Framework)는 도메인의 DNS에 게시하는 텍스트 한 줄이에요. 나를 대신해서 메일을 보내도 되는 서버와 서비스를 나열하죠. Gmail이 내 도메인에서 온 메일을 받으면 그 명단을 찾아보고, 메일을 보낸 서버가 명단에 있는지 확인해요.

흔한 SPF 레코드는 이렇게 생겼어요:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

왼쪽부터 차례로 읽어 보면:

v=spf1: “이건 SPF 레코드예요.”
include:_spf.google.com: Google Workspace는 나 대신 보내도 돼요.
include:sendgrid.net: SendGrid도 돼요(예를 들어 내 앱이 보내는 메일용).
~all: 그 밖의 건 아마도 내가 아니니까 의심해 주세요. (-all은 “절대 내가 아니니 거부해 주세요”라는 뜻이에요.)

가장 흔한 SPF 실수 두 가지: 같은 도메인에 SPF 레코드를 두 개 두는 것(반드시 한 줄로 합쳐야 해요), 그리고 서비스 하나를 빠뜨리는 거예요. 뉴스레터 도구나 고객 지원 도구가 내 도메인 이름으로 메일을 보낸다면, 그것도 명단에 넣어야 해요.

SPF 레코드 하나 안에서 할 수 있는 DNS 조회는 10번까지라는 제한도 있어요. include: 하나하나가 횟수에 들어가고, 그 안에 들어 있는 include도 마찬가지예요. 서비스를 많이 쓰다 보면 나도 모르게 한도를 넘기고, 그러면 모든 메일에서 SPF가 실패해요.

DKIM: 밀랍 봉인

SPF는 메일이 어디서 왔는지 확인해요. DKIM(DomainKeys Identified Mail)은 메일 자체가 조작되지 않았는지 확인하죠. 메일 서비스는 보내는 모든 메시지에 자기만 아는 개인 키로 서명해요. 나는 짝이 되는 공개 키를 DNS에 게시해 두고요. 받는 서버는 그 공개 키로 서명을 검증해요.

누군가 중간에 메일을 바꿨다면, 본문 단어 하나만 바꿨더라도 서명이 더는 맞지 않아요. 옛날 편지의 밀랍 봉인 같은 거예요. 봉인이 깨져 있으면 누군가 열어 봤다는 걸 알 수 있잖아요.

DKIM 레코드는 google._domainkey.yourdomain.com 같은 특별한 이름으로 게시되고, 값은 대략 이렇게 생겼어요:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1...

좋은 소식은 이걸 직접 쓸 일이 없다는 거예요. 메일 서비스가 만들어 주니까 DNS에 복사해 넣기만 하면 돼요. ._domainkey 앞에 있는 단어(여기서는 google)는 셀렉터라고 불러요. 서비스마다 하나씩, 여러 개의 키를 쓸 수 있게 해 주는 장치일 뿐이에요.

DMARC: 입구 경비원에게 주는 지시서

SPF와 DKIM은 받는 서버에게 ‘사실’을 알려 줘요. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 그 사실을 가지고 무엇을 할지 알려 주죠. 여기에 정렬(alignment)이라는 중요한 규칙도 하나 더해요. SPF나 DKIM을 통과한 도메인이, 읽는 사람이 실제로 보는 ‘보낸 사람(From)’ 줄의 도메인과 같아야 한다는 규칙이에요. 이 규칙이 없으면 사기꾼은 자기 도메인으로 SPF를 통과하면서도 보낸 사람에는 내 도메인을 보여 줄 수 있거든요.

DMARC 레코드는 _dmarc.yourdomain.com에 있고, 이렇게 생겼어요:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none: 지켜보기만 하고 아직 아무것도 막지 않아요. 처음 시작할 때 딱 좋아요.
p=quarantine: 실패한 메일을 스팸함으로 보내요.
p=reject: 실패한 메일을 완전히 거부해요. 가장 강력한 보호예요.
rua=mailto:...: 받는 쪽이 매일 요약 보고서를 보내 줄 주소예요.

사실 이 보고서가 숨은 보물이에요. 내 도메인으로 메일을 보내는 모든 서버를 보여 주거든요. 깜빡 잊고 있던 서비스는 물론, 나를 사칭하려는 사람까지요.

단계별로 설정해 봐요

예를 들어 내가 myshop.com을 갖고 있고, 메일함은 Google Workspace를, 주문 확인 메일은 SendGrid나 Mailgun 같은 서비스를 쓴다고 해 볼게요. 저라면 이 순서로 할 거예요:

내 도메인 이름으로 메일을 보내는 걸 전부 적어 보세요: 메일함 서비스, 웹사이트나 앱, 뉴스레터 도구, 고객 지원 도구, 청구서 프로그램 등이요. 사람들이 흔히 건너뛰는 단계인데, 나중에 생기는 문제 대부분이 여기서 시작돼요.
SPF 레코드를 하나 만드세요. DNS에(myshop.com의 TXT 레코드로) 모든 서비스를 넣고 마지막은 ~all로 끝내요.
각 서비스에서 DKIM을 켜세요. 서비스마다 DNS에 복사할 레코드를 줘요. 그다음 그 서비스에서 ‘확인’이나 ‘인증 시작’을 누르세요.
p=none으로 DMARC 레코드를 추가하세요. 보고서 받을 주소도 넣어서 _dmarc.myshop.com에 추가해요.
1~2주 기다린 다음 보고서를 읽어 보세요. 정상적인 메일인데 실패하는 게 있다면 고쳐 주세요.
진짜 메일이 전부 통과한다는 확신이 들면 정책을 강화하세요. p=quarantine으로, 나중에는 p=reject로요.

DNS 변경 사항이 모든 곳에 반영되기까지는 몇 분에서 몇 시간이 걸릴 수 있어요. 레코드를 추가하자마자 검사가 실패해도, 뭔가를 바꾸기 전에 조금만 기다려 보세요.

받은 메일에서 확인하는 방법

따로 도구는 필요 없어요. 메일 앱이 이미 결과를 보여 주고 있거든요:

Gmail: 메일을 열고 점 세 개를 누른 다음 원본 보기를 선택하세요. 맨 위에 SPF: PASS, DKIM: PASS, DMARC: PASS 같은 줄이 보여요.
Outlook: 메시지를 열고 보기 → 메시지 세부 정보 보기(또는 메시지 원본)를 선택한 뒤 Authentication-Results 헤더를 찾으세요.
Apple Mail: 보기 → 메시지 → 모든 헤더를 선택하세요.

실제 헤더는 이런 모습이에요:

Authentication-Results: mx.google.com; dkim=pass header.d=myshop.com; spf=pass smtp.mailfrom=myshop.com; dmarc=pass (p=QUARANTINE) header.from=myshop.com

세 개 모두 통과했고 도메인도 일치해요. 이 메일은 진짜예요. fail이 보이거나 도메인이 화면에 보이는 보낸 사람과 다르다면 조심하세요. 그건 제가 피싱 메일 구별하는 법에서 다룬 경고 신호 중 하나예요.

내 도메인을 설정하는 중이라면, 임시 메일함과 Gmail 주소로 메일을 보내 보고 Gmail 쪽 헤더를 확인하는 게 빠른 테스트 방법이에요. 2분이면 끝나고, 바깥에서 내 메일이 어떻게 보이는지 정확히 알 수 있어요.

자주 생기는 문제와 빠른 해결법

“SPF: softfail” 또는 “neutral”: 메일을 보낸 서버가 SPF 레코드에 없어요. 그 서비스가 안내하는 include:를 추가하세요.
“SPF permerror”: 보통 SPF 레코드가 두 개 있거나 조회가 10번을 넘은 경우예요. 레코드를 하나로 합치고 더 이상 안 쓰는 서비스는 지우세요.
템플릿을 수정한 뒤 “DKIM: fail”: 서명된 다음에 무언가가 메일을 다시 썼어요(일부 전달 서비스나 메일 꼬리말 기능이 이래요). 직접 보내서 다시 테스트해 보세요.
SPF는 통과하는데 DMARC가 실패해요: 정렬 문제예요. SPF가 통과한 건 내 도메인이 아니라 발송 서비스의 도메인이에요. 그 서비스에서 내 도메인으로 DKIM을 켜거나, 사용자 지정 Return-Path 도메인을 설정하세요.
모두 통과하는데도 스팸함으로 가요: 인증은 내가 누구인지를 증명할 뿐, 사람들이 내 메일을 원한다는 걸 증명하진 않아요. 내용, 발송 평판, 스팸 신고 비율도 중요해요. 이 부분은 앱 이메일이 스팸함에 들어가는 이유에서 더 자세히 써 뒀어요.

정말 세 가지 다 필요할까요?

네, 필요해요. 2024년부터 Gmail과 Yahoo는 메일을 대량으로 보내는 발신자에게 SPF, DKIM, DMARC 레코드를 모두 요구하고 있어요. 소규모 발신자도 세 가지를 다 갖추면 메일이 훨씬 잘 도착해요. 무엇보다 p=reject로 설정한 DMARC야말로 사기꾼이 내 이름으로 내 고객에게 가짜 메일을 보내는 걸 막아 줘요.

설정은 반나절이면 충분해요. 그다음부터는 매일 조용히 내 도메인을 지켜 줘요. 도메인이 있는데 계속 미뤄 왔다면, 지금이 바로 그때예요. 오늘은 p=none으로 시작하세요. 강화는 나중에 해도 돼요.

Blog

SPF, DKIM, DMARC 쉽게 이해하기 (예시 포함)