SPF, DKIM, DMARC가 모두 중요한 이유

기업에 중요한 이유

이메일에는 발신자가 누구인지 확인하는 기능이 기본으로 없습니다. 이 레코드가 없으면 누구나 귀사 도메인을 From 줄에 넣을 수 있어, 가짜 청구서가 경리팀에서 보낸 것처럼 도착할 수 있습니다.

반대의 경우도 생깁니다. 대형 제공업체는 인증되지 않은 메일을 불신하므로 정상적인 답장이 스팸함으로 들어갑니다. Google과 Yahoo는 2024년부터 대량 발송자에게 인증을 요구하고 있습니다.

각각이 더하는 것

• SPF: 귀사 도메인 대신 발송할 수 있는 서버를 나열합니다.
• DKIM: 각 메시지에 서명하여 어느 도메인이 서명했는지, 그리고 전송 중 아무것도 변경되지 않았음을 증명합니다.
• DMARC: From 주소의 도메인에 대해 SPF 또는 DKIM이 통과했는지 확인하고, 둘 다 통과하지 못했을 때 수신자가 어떻게 처리할지 알려 주며, 보고서를 보내 줍니다.

하나만으로는 충분하지 않습니다. SPF와 DKIM은 수신자가 보는 도메인과 다른 도메인에 대해서도 통과할 수 있고, 어느 쪽도 수신자에게 무엇을 차단하라고 요청하지 않습니다. DMARC는 둘 중 하나가 작동해야 하는데, SPF는 전달된 메일에서 실패하므로 DKIM이 보완책이 됩니다.

흔한 실수

• SPF 레코드 두 개: 새 서비스를 위해 두 번째 레코드를 추가하면 모든 메일에서 SPF가 실패합니다.
• 아무도 추가하지 않은 발송처: 마케팅 플랫폼이나 청구 시스템이 귀사 도메인으로 발송하지만 SPF 항목이나 DKIM 키를 받은 적이 없습니다.
• DMARC를 계속 none으로 둠: 정책이 바뀌지 않아 위조 메일이 계속 전달됩니다.
• 바로 reject로 이동: 보고서를 읽기 전에 강제 적용하면 위조 메일과 함께 귀사의 정상 메일도 차단됩니다.

설정 순서

1. 모든 발송처를 나열합니다: 메일 제공업체와 귀사 도메인으로 이메일을 보내는 각 서비스.
2. SPF 레코드를 하나만 게시하여 모두를 포함합니다.
3. 모든 발송 서비스에서 DKIM을 켭니다.
4. 보고서 주소와 함께 DMARC를 none으로 게시하고 보고서를 읽습니다.
5. 귀사의 서비스만 나타나면 quarantine으로, 그다음 reject로 올립니다.

세 가지 모두 DNS에 있습니다. 나머지 설정은 업무용 이메일 가이드에서 다룹니다.

KawaConnect의 이메일 인증 지원 방식

Microsoft 365를 설정, 마이그레이션, 관리할 때 SPF, DKIM, DMARC 레코드는 메일을 라우팅하는 MX 레코드와 함께 작업에 포함됩니다. 저희가 호스팅하는 웹사이트에서 메일을 보내는 문의 양식도 같은 레코드에 추가합니다.

자세히 보기

• Wikipedia의 Email authentication이메일의 출처를 확인하는 데 쓰이는 방법들의 개요.
• Cloudflare의 DMARC, DKIM, SPF세 가지 레코드에 대한 해설.
• dmarc.org의 DMARC 개요표준 자체 사이트에서 설명하는 DMARC가 SPF와 DKIM을 바탕으로 하는 방식.
• Google 이메일 발신자 가이드라인Gmail이 발신자에게 요구하는 인증.
• Microsoft 365의 이메일 인증Microsoft 365에서 세 가지 모두를 다루는 Microsoft의 가이드.