DMARC 설명: 이메일을 보호하고 DNS에 DMARC 레코드를 추가하는 방법

이메일 신뢰도는 고객 소통부터 주문 확인에 이르기까지 모든 것에 영향을 미칩니다. 적절한 인증이 없으면 정상적인 이메일조차 스팸으로 분류되거나 차단될 수 있습니다. DMARC는 스푸핑으로부터 도메인을 보호하고 이메일 전송률을 향상시키는 데 도움을 줍니다. DMARC는 이메일 서버에 전송 실패 메시지를 처리하는 방법에 대한 명확한 지침을 제공합니다. 이제 DMARC를 올바르게 설정하는 것은 선택 사항이 아니라 필수 사항입니다.

핵심 요약

• DMARC는 이메일 스푸핑 및 사칭으로부터 도메인을 보호합니다
• 이는 SPF 및 DKIM과 함께 작동하여 발신자의 진위 여부를 확인합니다
• DMARC 레코드는 DNS에서 _dmarc 호스트 이름 아래의 TXT 레코드로 존재합니다
• 모니터링 정책부터 시작하면 배송 문제를 방지하는 데 도움이 됩니다
• 이메일을 전송하지 않는 도메인이라도 DMARC 레코드를 게시해야 합니다
• DMARC 설정을 올바르게 하면 받은 편지함 수신 위치와 이메일 신뢰도가 향상됩니다

DMARC란 무엇이며 왜 존재하는가?

DMARC는 도메인 기반 메시지 인증 보고 및 적합성(Domain-Based Message Authentication Reporting and Conformance)의 약자입니다. 간단히 말해, DMARC는 수신 이메일 서버에 사용자의 도메인에서 온 것처럼 보이는 이메일을 어떻게 처리해야 하는지 알려주는 일련의 지침입니다.

DMARC 이전에는 이메일 인증이 주로 SPF와 DKIM에 의존했습니다. 이러한 시스템은 서버가 해당 도메인에 대한 이메일 전송 권한이 있는지 확인하고 메시지 내용이 변경되지 않았는지 검증합니다. 유용하기는 하지만, 이러한 시스템은 수신 서버에 문제가 발생했을 때 어떤 조치를 취해야 하는지 알려주지는 않습니다.

이러한 허점 때문에 공격자들은 발신자 주소를 위조하여 도메인을 악용할 수 있었습니다. 공격자들은 승인되지 않은 서버에서 이메일을 발송함으로써 신뢰할 수 있는 브랜드에서 온 것처럼 위장할 수 있었습니다. DMARC는 이러한 허점을 해결합니다.

DMARC는 인증에 실패한 이메일을 수신 서버가 어떻게 처리해야 하는지를 명확히 정의함으로써 투명성을 높입니다. 서버는 DMARC를 통해 메시지를 전달할지, 스팸으로 분류할지, 아니면 완전히 차단할지 결정합니다. 따라서 DMARC는 단순한 기술 설정이 아니라 이메일 신뢰의 핵심 요소입니다.

DMARC는 이메일 인증에 어떻게 활용될까요?

SPF와 DKIM은 신원 확인 절차라고 생각하시면 됩니다. DMARC는 최종 결정을 내리는 역할을 합니다. DMARC는 이러한 확인 결과를 검토하고 사용자의 지침에 따라 정책을 시행합니다. DMARC가 없으면 이메일 제공업체는 의심스러운 메시지를 어떻게 처리해야 할지 추측해야 합니다. 하지만 DMARC를 사용하면 제공업체는 사용자의 규칙을 따르게 됩니다.

DMARC는 어떻게 작동할까요?

이메일이 전송되면 수신자에게 도달하기 전에 여러 서버를 거칩니다. 그 과정에서 수신 서버는 이메일의 진위 여부를 확인하기 위해 여러 가지 사항을 검사합니다.

먼저 SPF는 발신 서버가 해당 도메인에 대한 이메일 발송 권한을 가지고 있는지 확인합니다. 다음으로 DKIM은 메시지가 손상되지 않았으며 승인된 발신자가 서명했는지 확인합니다.

여부를 평가합니다 정렬. 정렬이란 발신 주소에 사용된 도메인이 SPF 및 DKIM에서 검증한 도메인과 일치하는지 여부를 의미합니다. 정렬에 실패하면 DMARC 적용이 시작됩니다.

DMARC 정책에 따라 수신 서버는 메시지를 허용하거나, 스팸으로 분류하거나, 완전히 차단합니다. 이 과정은 사용자 개입 없이 백그라운드에서 자동으로 처리됩니다.

DMARC가 실제로 어떻게 작동하는지 보여주는 간단한 실생활 예시

누군가가 귀사의 청구 담당자를 사칭하여 가짜 이메일을 보낸다고 가정해 보세요. 발신자 주소는 바꾸지만, 승인되지 않은 서버에서 메시지를 보냅니다. SPF 차단도 실패하고, DKIM 인증도 실패합니다. DMARC는 이를 감지하고 귀사의 정책을 적용합니다. 만약 귀사의 정책이 거부된다면, 해당 이메일은 수신함에 도달하지 못합니다. 공격은 시작도 전에 차단되는 것입니다.

DMARC 레코드란 무엇인가요?

DMARC 레코드는 DMARC 정책이 저장되는 곳입니다. 도메인의 DNS 서버에 TXT 레코드 형식으로 저장됩니다. DNS는 인터넷에 도메인 작동 방식을 알려주는 일종의 설명서와 같습니다.

이라는 특정 이름으로 저장됩니다 dmarc.yourdomain.com. 이렇게 하면 수신 서버에서 해당 레코드를 쉽게 찾고 읽을 수 있습니다.

DMARC는 특별한 DNS 레코드 유형이 아니라는 점을 이해하는 것이 중요합니다. DMARC는 단순히 TXT 레코드 내에 저장된 텍스트입니다. 따라서 모든 주요 DNS 제공업체와 호환됩니다.

DMARC 정책 옵션 이해하기

DMARC 정책은 인증 실패 시 발생하는 상황을 정의합니다. 적절한 정책을 선택하는 것은 이메일 설정에 대한 확신도에 따라 달라집니다.

정책 없음

이 정책은 수신 서버가 전송 실패 이메일에 대해 아무런 조치를 취하지 않도록 합니다. 메시지는 여전히 전달되지만 보고서는 생성됩니다. 이는 모니터링에 이상적입니다. 전송 문제 발생 위험 없이 누가 도메인을 대신하여 이메일을 보내는지 확인할 수 있습니다.

정책 격리

이 정책은 서버가 전송 실패 이메일을 의심스러운 것으로 간주하도록 지시합니다. 대부분의 제공업체는 이러한 이메일을 스팸 폴더로 보냅니다. 격리는 모니터링과 완전한 정책 시행 사이의 전환 단계로 자주 사용됩니다.

정책 거부

이것은 가장 엄격한 옵션입니다. DMARC 검사에 실패한 이메일은 즉시 거부되어 수신자에게 도달하지 않습니다. 설정이 검증되면 이 정책은 스푸핑 및 사칭으로부터 가장 강력한 보호를 제공합니다.

DMARC 레코드의 주요 구성 요소 설명

DMARC 레코드는 세미콜론으로 구분된 태그와 값으로 구성됩니다. 각 부분은 특정 역할을 수행합니다.

버전 태그 v

이는 서버에 레코드가 사용하는 DMARC 버전을 알려줍니다. 현재는 항상 DMARC1입니다.

정책 태그 p

이 설정은 인증 실패 시 수행할 작업을 정의합니다. 유효한 값은 none, quarantine 또는 reject입니다.

신고 태그 rua

이 설정은 DMARC 집계 보고서를 보낼 위치를 지정합니다. 보고서는 일반적으로 전용 사서함이나 제3자 모니터링 서비스로 전송됩니다.

선택적 정렬 및 보고 태그

ADKIM 및 ASPF와 같은 태그는 정렬 규칙의 엄격도를 제어합니다. FO 및 PCT와 같은 태그는 보고 동작 및 적용 비율을 조정합니다. 이러한 태그는 선택 사항이며 설정이 안정화됨에 따라 나중에 추가할 수 있습니다.

DMARC 보고서란 무엇이며 왜 중요한가

DMARC 보고서는 도메인이 이메일에서 어떻게 사용되는지 파악할 수 있도록 도와줍니다. 어떤 서버가 이메일을 전송하는지, 인증 검사는 어떻게 수행되는지, 그리고 메시지가 DMARC 검사를 통과하는지 실패하는지 등을 보여줍니다.

이러한 보고서는 일반적으로 XML 파일 형식으로 전송되며 처음에는 내용이 방대해 보일 수 있습니다. इसीलिए 많은 기업에서 보고 도구를 사용하여 이러한 보고서를 읽기 쉬운 대시보드로 변환합니다.

종합 보고서 vs. 분석 보고서

종합 보고서는 시간 경과에 따른 요약 데이터를 제공합니다. 포렌식 보고서는 개별 실패 메시지에 대한 자세한 정보를 제공합니다. 두 보고서 모두 잘못된 구성 및 악용 시도를 식별하는 데 도움이 됩니다.

모든 도메인에 DMARC 레코드가 필요한가요?

네. 이메일을 전혀 보내지 않는 도메인이라도 DMARC 레코드를 등록해야 합니다. DMARC 레코드가 없으면 공격자가 해당 도메인 이름을 피싱 이메일을 쉽게 유포할 수 있습니다.

이메일을 발송하지 않는 도메인의 경우, 거부 정책을 통해 승인되지 않은 모든 이메일을 차단할 수 있습니다. 이를 통해 브랜드 이미지를 이메일을 직접 사용하지 않더라도

DMARC 레코드를 단계별로 생성하는 방법

DMARC 설정은 체계적인 방식으로 진행할 때 가장 효과적입니다. 명확한 방향성 없이 엄격한 정책을 바로 적용하면 정상적인 이메일 전송에 문제가 발생할 수 있습니다. 다음 단계는 안전하고 확실하게 DMARC 레코드를 구축하는 데 도움이 됩니다.

1단계: DMARC 레코드가 이미 존재하는지 확인합니다

새로운 항목을 추가하기 전에 도메인에 DMARC 레코드가 이미 존재하는지 확인해야 합니다. 도메인에는 DMARC 레코드가 하나만 있을 수 있습니다. 두 번째 레코드를 추가하면 유효성 검사 오류가 발생합니다.

온라인 DMARC 조회 도구를 사용하여 이를 확인할 수 있습니다. 레코드가 존재하는 경우, 무턱대고 교체하지 말고 신중하게 검토하십시오.

2단계: 정책 전략을 결정하세요

DMARC를 처음 사용하는 경우 모니터링 방식부터 시작하세요. 정책을 '없음'으로 설정하면 이메일 전송에 영향을 주지 않고 보고서를 수집할 수 있습니다.

정상적인 이메일이 인증을 통과하는 것을 확인한 후에는 격리 단계로 넘어가고 최종적으로 차단할 수 있습니다. 이러한 단계적 접근 방식을 통해 실제 이메일을 차단할 위험을 줄일 수 있습니다.

3단계: 보고용 이메일 주소를 선택하세요

DMARC 보고서는 귀하의 기록에 등록된 이메일 주소로 전송됩니다. 해당 주소는 적극적으로 모니터링하거나 보고 서비스에 연결해야 합니다.

개인 사서함 사용은 피하십시오. 보고서는 빈번하게 발생하며 전문적인 내용이 포함될 수 있습니다. 많은 조직에서는 전용 사서함을 만들거나 제3자 DMARC 보고 서비스 제공업체를 이용합니다.

4단계: DMARC 레코드 값 준비

기본 DMARC 레코드에는 버전, 정책 및 보고 주소가 포함됩니다. 이러한 간단한 구조만으로도 안전하게 모니터링을 시작하고 가시성을 확보할 수 있습니다.

DNS에 DMARC 레코드를 추가하는 방법

DMARC 레코드가 준비되면 다음 단계는 해당 레코드를 도메인의 DNS에 추가하는 것입니다. DNS 설정은 도메인 레코드를 관리하는 담당자가 관리합니다.

DNS가 관리되는 위치

DNS는 도메인 설정 방식에 따라 여러 곳에서 관리될 수 있습니다. 일반적인 관리 위치로는 도메인 등록 기관, 웹 호스팅 제공업체 또는 CDN이 와 같은 Cloudflare.

DNS 관리 주체가 어디인지 확실하지 않다면 도메인의 네임서버를 확인해 보세요. 네임서버에는 일반적으로 DNS를 담당하는 공급업체가 표시됩니다.

DMARC TXT 레코드 추가

DNS 관리자에서 새 TXT 레코드를 생성하세요.

• 레코드 이름은 dmarc 또는 dmarc.yourdomain.com 제공업체에 따라
• 값 필드에는 전체 DMARC 정책 텍스트가 포함되어야 합니다.
• TTL은 일반적으로 자동으로 설정해 두면 됩니다.

레코드를 입력한 후에는 저장하십시오. DNS 변경 사항은 즉시 적용되지 않으므로 시간이 걸릴 수 있습니다.

흔히 저지르는 서식 오류를 피하는 방법

DMARC 관련 문제는 대부분 사소한 형식 오류로 인해 발생합니다. 예를 들어, _dmarc 대신 루트 기호를 사용하면 레코드 유효성 검사가 실패할 수 있습니다. 또한, 공백을 추가하거나 세미콜론을 누락하는 경우에도 유효성 검사가 실패할 수 있습니다.

저장하기 전에 철자와 문장 구조를 다시 한번 확인하세요.

DMARC가 작동하기 시작하는 데 걸리는 시간

DMARC는 즉시 활성화되지 않습니다. DNS 변경 사항이 인터넷 전체에 전파되는 데 시간이 걸립니다. 일반적으로 몇 분 정도 소요되지만, 제공업체에 따라 최대 48시간까지 걸릴 수 있습니다.

이 기간 동안 일부 서버는 새 레코드를 수신하지만 다른 서버는 수신하지 못할 수 있습니다. 이는 정상적인 동작이며 시간이 지나면 자동으로 해결됩니다.

DMARC 레코드가 제대로 작동하는지 확인하는 방법

배포 후에는 DMARC 레코드가 활성화되어 있고 읽을 수 있는지 확인해야 합니다. 온라인 DMARC 조회 도구를 사용하면 즉시 확인할 수 있습니다.

유효한 기록에는 정책, 보고 주소 및 정렬 설정이 표시됩니다. 오류가 발생하는 경우 일반적으로 수정해야 할 사항을 설명하는 명확한 메시지가 포함됩니다.

테스트 이메일을 보내고 DMARC 보고서를 검토하여 정상 작동 여부를 확인할 수도 있습니다.

일반적인 DMARC 오류 및 해결 방법

아주 작은 실수라도 DMARC 오류를 일으킬 수 있습니다. 흔히 발생하는 문제를 이해하면 문제를 더 빠르게 해결할 수 있습니다.

DMARC 레코드를 찾을 수 없습니다

이는 일반적으로 레코드 이름이 잘못되었거나 레코드가 아직 전파되지 않았음을 의미합니다. 호스트 이름을 확인하고 추가 문제 해결을 진행하기 전에 기다리십시오.

DMARC 정렬 실패

타사 이메일 서비스를 적절한 설정 없이

정상적인 이메일이 스팸으로 분류되는 경우

이는 엄격한 정책을 너무 일찍 적용했을 때 자주 발생합니다. 보고서를 검토하는 동안 모니터링 정책으로 되돌리면 이메일 손실을 방지할 수 있습니다.

DMARC 레코드 중복 오류

도메인당 하나의 DMARC 레코드만 허용됩니다. 중복된 레코드를 제거하고 하나의 통합된 정책을 유지하십시오.

DMARC 및 WordPress 이메일 전달률

워드프레스 웹사이트는 이메일을 매우 중요하게 생각합니다. 문의 양식, 비밀번호 재설정, 주문 확인, 알림 등 모든 기능은 안정적인 이메일 전달에 달려 있습니다.

DMARC를 사용하지 않으면 WordPress 이메일이 의심스러운 메일로 분류될 가능성이 높아집니다. 특히 기본 서버 설정을 사용하여 이메일을 보낼 때 이러한 현상이 두드러집니다.

DMARC는 적절한 SMTP 설정 및 인증된 발송 서비스와 함께 사용할 때 최상의 효과를 발휘합니다. 이 두 가지를 함께 사용하면 수신함 도달률과 신뢰도가 크게 향상됩니다.

결론: DMARC가 더 이상 선택 사항이 아닌 이유

DMARC는 더 이상 단순한 보안 업그레이드가 아닙니다. 이메일 신뢰를 위한 기본 요구 사항입니다. 이메일 제공업체는 DMARC를 기대하고, 고객은 DMARC에 의존하며, 공격자들은 DMARC가 없는 도메인을 적극적으로 악용합니다.

모니터링부터 시작하면 위험 부담 없이 가시성을 확보할 수 있습니다. 점진적으로 더욱 강력한 정책을 시행하면 브랜드 보호는 물론 이메일 전송률 향상에도 도움이 됩니다.

도메인에서 이메일을 전송하든 안 하든, DMARC 레코드를 게시하는 것은 온라인 보안을 강화하기 위해 취할 수 있는 가장 간단하고 효과적인 조치 중 하나입니다.

DMARC 관련 자주 묻는 질문