중요 알림: Google과 Yahoo는 2024년 4월부터 DMARC를 요구할 예정입니다.
자세히 보기
PowerDMARC

DMARC 정책 설명: 없음, 격리 및 거부

마이탐 알 라와티
정책 D마크

정책 D마크

읽기 시간: 9 분

이메일 인증은 사이버 보안에서 중요한 관행이 되었습니다. 이는 실제 유명 조직을 사칭하는 공격이 증가했기 때문입니다. 에 따르면 포브스에 따르면 사이버 범죄와 관련된 비용은 2025년까지 연간 10조 5,000억 달러에 달할 것으로 예상됩니다.

그렇기 때문에 다음과 같은 이메일 인증 프로토콜을 채택해야 합니다. DMARC 과 같은 이메일 인증 프로토콜의 도입이 중요한 이유입니다. 도메인 기반 메시지 인증, 보고 및 적합성(DMARC)은 이메일 발신자의 DNS(도메인 이름 시스템)에 텍스트 레코드로 배치할 수 있습니다. DMARC가 활성화되면 이메일의 유효성 검사 및 보안이 시작됩니다. DMARC 정책은 피싱, 이메일 스푸핑, 랜섬웨어 공격을 방지하고 이메일 전송률을 향상시킬 수 있는 강력한 기능을 가지고 있습니다.

DMARC 정책은 이메일 수신자에게 인증에 실패한 메시지를 처리하는 방법을 알려줍니다. 이 정책은 세 가지 가능한 조치를 지정할 수 있습니다:

DMARC 정책을 "거부"로 설정하면 도메인 남용, 브랜드 사칭, 피싱 및 스푸핑 공격의 위험을 최소화할 수 있습니다.

DMARC로 이메일 보호

이메일은 쉽게 위조될 수 있기 때문에 진짜와 가짜를 구분하기 어렵습니다. 그래서 DMARC가 필요합니다. DMARC는 메시지를 통과시키기 전에 발신자의 신원을 확인하는 이메일 보안 체크포인트와 같습니다. 실제로 Verizon 보고서에 따르면 에 따르면 전체 데이터 유출 사고의 30% 이상이 피싱 공격의 결과이며, 이는 DMARC와 같은 강력한 보호 기능의 필요성을 강조합니다. DMARC를 사용하면 스푸핑 시도를 차단하고 받은 편지함을 사기성 이메일로부터 안전하게 지킬 수 있습니다.

에 따르면 RFC 7489 에 따르면 DMARC에는 이메일 발신자가 인증에 대한 기본 설정을 할 수 있는 고유한 기능이 있습니다. 이 기능을 활성화하면 이메일 처리 및 잠재적인 도메인 남용에 대한 보고서도 받을 수 있습니다. 따라서 도메인 유효성 검사 측면에서 DMARC는 정말 돋보입니다.

DMARC의 설정 프로세스를 시작하려면 몇 가지 DNS를 변경하고 프로토콜에 대한 DNS TXT 레코드를 포함해야 합니다. 그러나 이 프로토콜을 수동으로 구현하는 것은 기술 전문가가 아닌 사용자에게는 상당히 복잡할 수 있습니다. 심지어 외부 CISO를 고용하여 비즈니스를 위해 관리할 경우 상당한 비용이 발생할 수도 있습니다. 따라서 PowerDMARC의 DMARC 분석기는 손쉬운 대안이 될 수 있습니다. DMARC 정책 설정을 자동화하여 시간과 비용을 모두 절약할 수 있습니다.

 


구글과 야후의 새로운 이메일 발신자 요건이 발표된 후 PowerDMARC를 찾았습니다. PowerDMARC는 순식간에 DMARC 정책을 모니터링할 수 있게 해줬어요! 그 덕분에 더 나은 보호를 위해 느리지만 확실하게 강제 정책으로 전환할 수 있었습니다." 라고 중소기업 소유주 레이첼 R.이 보고했습니다.

DMARC 정책이란 무엇인가요?

DMARC 정책은 특수 TXT 레코드로 설정할 수 있는 DNS 수준 지침 집합입니다. 이 정책은 인증에 실패한 이메일을 처리하는 방법을 수신 메일 서버에 알려줍니다. 이메일이 DMARC 유효성 검사에 실패할 경우 메일 서버가 취해야 할 조치를 지정하는 DMARC 레코드의 "p" 태그로 표시됩니다. 

DMARC 정책은 실제로 브랜드를 사칭하는 이메일을 얼마나 엄격하게 처리할지 결정하는 데 도움이 될 수 있습니다. 도메인의 경비원이라고 생각하세요. 경비원은 사용자의 ID에 따라 사용자가 건물(이 경우 수신자의 받은 편지함)에 들어갈 수 있는지 여부를 결정합니다. 경비원은 사용자의 출입을 막거나(거부), 추가 검토를 위해 특별한 장소로 보내거나(격리), 그냥 들여보낼 수도 있습니다(허용하지 않음).

DMARC 정책을 p=거부로 설정하면 스푸핑, 피싱 및 도메인 이름 남용을 방지하여 브랜드를 사칭하려는 악의적인 공격자에게 '침입 금지' 신호와 같은 역할을 할 수 있습니다.

3가지 유형의 DMARC 정책: p=거부, p=없음, p=격리

이메일 도메인 소유자가 설정하려는 적용 수준에 따라 없음, 격리, 거부의 세 가지 기본 DMARC 정책 유형이 있습니다. 이러한 정책 옵션 간의 주요 차이점은 메일 발신자가 DNS 레코드에 정의한 지정된 정책을 준수할 때 수신 메일 전송 에이전트가 취하는 조치에 따라 결정됩니다. 

다음은 3가지 DMARC 정책 유형에 대한 간략한 개요와 자세한 설명입니다:

1. DMARC 없음 정책

DMARC 정책 없음(p=none)은 수신자 측에서 아무런 동작을 트리거하지 않는 편안한 모드입니다. 이 정책은 이메일 활동을 모니터링하는 데 사용할 수 있습니다. 사이버 공격에 대한 보호 수준은 제공하지 않습니다.

없음 정책 구현 사용 사례

예: v=DMARC1; p=none; rua= mailto:(이메일 주소);

2. DMARC 격리 정책

p=격리를 사용하면 도메인 소유자가 수신자에게 나중에 검토할 수 있도록 이메일을 스팸 폴더로 롤백하라는 메시지를 표시할 수 있으므로 일정 수준의 보호 기능을 제공합니다.DMARC가 실패하는 경우.

격리 정책 구현 사용 사례

예: v=DMARC1; p=검역소; rua=mailto:(이메일 주소);

3. DMARC 거부 정책

마지막으로 DMARC 거부 정책(p=reject)은 적용 정책입니다. 이 정책은 DMARC 인증에 실패한 메시지가 거부되도록 합니다. DMARC 거부는 사용자가 승인하지 않은 이메일을 삭제하여 최대한의 적용을 제공합니다.

정책 구현 사용 사례 거부

예: v=DMARC1; p=reject; rua= mailto:(이메일 주소);

DMARC 정책 시행의 이점

도메인에 엄격한 DMARC 정책을 설정하면 얻을 수 있는 이점에 대해 자세히 알아보세요:

1. 피싱 및 BEC에 대한 직접적인 보호

DMARC 거부 시 ( DMARC 적용)에서 인증되지 않은 출처에서 발신된 이메일은 삭제됩니다. 이렇게 하면 사기성 이메일이 수신자의 받은 편지함에 도달하는 것을 방지할 수 있습니다. 따라서 피싱 공격, 스푸핑, BEC 및 CEO 사기로부터 직접적으로 보호할 수 있습니다.

이는 특히 중요합니다: 

2. 악성 소프트웨어에 대한 첫 번째 방어선

랜섬웨어와 멀웨어는 종종 사칭된 도메인 이름으로 전송된 가짜 이메일을 통해 확산됩니다. 이러한 악성코드는 침투하여 운영 체제를 완전히 장악할 수 있습니다. 거부 시 DMARC 정책을 사용하면 인증되지 않은 이메일이 고객의 받은 편지함에서 차단됩니다. 이렇게 하면 고객이 유해한 첨부파일을 클릭하는 것을 자동으로 방지할 수 있습니다. 또한 랜섬웨어나 멀웨어가 시스템에 무의식적으로 다운로드될 가능성도 최소화합니다. 여기서 DMARC 정책은 이러한 공격에 대한 기본 방어선 역할을 합니다. 

3. 이메일 채널 모니터링하기

단순히 메시지 트랜잭션과 발신 소스를 모니터링하려는 경우 p=none의 DMARC로 충분합니다. 하지만 이렇게 해도 사이버 공격으로부터 사용자를 보호할 수는 없습니다.

4. 배달 전에 의심스러운 이메일 검토하기

승인되지 않은 이메일을 완전히 차단하고 싶지 않다면 격리할 수 있습니다. 격리 DMARC 정책을 활용하여 의심스러운 메시지를 수락하기 전에 검토하기만 하면 됩니다. 이렇게 하면 이메일이 받은 편지함 대신 격리 폴더에 보관됩니다.

가장 적합한 DMARC 정책 유형은 무엇이며 그 이유는 무엇인가요?

이메일 보안 노력을 극대화하고 Gmail의 파란색 체크 표시 기능을 사용하려면 DMARC 거부가 최상의 DMARC 정책입니다.. p=거부로 설정하면 도메인 소유자가 고객의 받은 편지함에서 승인되지 않은 메시지를 적극적으로 차단하기 때문입니다. DMARC 정책은 사이버 공격에 대한 높은 수준의 보호 기능을 제공합니다. 여기에는 직접 도메인 스푸핑, 피싱 및 기타 형태의 사칭 위협이 포함됩니다. 따라서 효과적인 피싱 방지 정책으로도 활용할 수 있습니다.

DMARC 적용 시 다음을 구현할 수도 있습니다. BIMI. BIMI를 사용하면 Gmail과 Yahoo 받은 편지함의 이메일에 파란색 체크 표시를 활성화할 수 있는데, 아주 멋진 기능입니다!

일반적인 DMARC 정책 오해 바로잡기

DMARC 정책에 대한 몇 가지 일반적인 오해가 있습니다. 이 중 일부는 메일 전송에 끔찍한 결과를 초래할 수 있습니다. 이러한 오해가 무엇인지, 그리고 그 뒤에 숨겨진 진실은 무엇인지 알아보세요:

1. 스푸핑을 방지할 수 없는 DMARC 없음

DMARC 없음은 "아무 조치도 취하지 않는" 정책이며 사이버 공격으로부터 도메인을 보호할 수 없습니다. 공격자는 종종 도메인을 가장하기 위해 p=none 정책을 악용합니다. 

지난 몇 년 동안 여러 도메인 소유자가 DMARC를 구현했음에도 불구하고 어떻게 스푸핑을 당하고 있는지 설명하면서 PowerDMARC에 문의해 왔습니다. 추가 검토 결과, 전문가들이 확인한 결과 대부분의 도메인 소유자가 DMARC 정책을 "없음"으로 설정한 것으로 나타났습니다. 

2. p=none인 경우 DMARC 보고서를 수신하지 않습니다.

p=none인 경우에도 발신자의 유효한 이메일 주소를 지정하기만 하면 매일 DMARC 보고서를 계속 받을 수 있습니다. 

3. DMARC "격리"는 중요하지 않습니다.

종종 간과하는 경우가 많지만 DMARC의 격리 정책은 과도기에 매우 유용합니다. 도메인 소유자는 이를 배포하여 활동 금지에서 최대 시행으로 원활하게 전환할 수 있습니다.

4. DMARC 거부로 인한 전송 가능성 저하

DMARC 거부 상태에서도 정상적인 이메일이 원활하게 전달되도록 할 수 있습니다. 발신자의 활동을 모니터링하고 분석하면 도움이 될 수 있습니다. 또한 인증 결과를 검토하여 실패를 더 빨리 감지해야 합니다.

DMARC 정책 오류 문제 해결

다음은 발생할 수 있는 몇 가지 일반적인 DMARC 정책 오류입니다: 

구문 오류

프로토콜이 올바르게 작동하는지 확인하기 위해 레코드를 설정하는 동안 구문 오류에 주의해야 합니다.

구성 오류

DMARC 정책을 구성하는 동안 발생하는 오류는 일반적으로 발생하며 다음과 같이 DMARC 검사기 도구를 사용하여 방지할 수 있습니다.

DMARC sp 정책

DMARC 거부 정책을 구성하지만 하위 도메인 정책은 하위 도메인 정책 을 설정하지 않으면 규정 준수를 달성할 수 없습니다. 이는 아웃바운드 이메일에 대한 정책 재정의 때문입니다.

"DMARC 정책이 사용되지 않음" 오류

보고서에서 이 오류 메시지가 표시되면 DNS에 DMARC 도메인 정책이 누락되었거나 "없음"으로 설정된 것을 가리킵니다. 레코드를 편집하여 p=거부/격리를 통합하면 문제가 해결됩니다. 

DMARC 정책을 업데이트, 적용 및 최적화하는 더 안전한 방법

PowerDMARC의 DMARC 분석기 플랫폼은 DMARC 프로토콜을 손쉽게 설정할 수 있도록 도와줍니다. 클라우드 네이티브 인터페이스를 사용하여 몇 번의 버튼 클릭만으로 레코드를 모니터링하고 최적화할 수 있습니다. 주요 이점을 살펴보세요:

문의하기 에 문의하여 DMARC 정책을 구현하고 결과를 쉽게 모니터링하세요!

DMARC 정책 FAQ

내 이메일이 DMARC를 준수하는지 어떻게 알 수 있나요? 

PowerDMARC 고객은 대시보드 요약을 확인하여 규정 준수 여부를 쉽게 평가할 수 있습니다. 또한 다음을 통해 현재 보안 상태를 분석할 수도 있습니다. PowerAnalyzer.

DMARC 정책을 수정하려면 어떻게 해야 하나요? 

DNS 관리로 들어가서 정책을 수동으로 수정할 수 있습니다. 들어가면 DMARC TXT 레코드를 편집해야 합니다. 보다 간단한 해결책은 한 번의 클릭으로 정책을 변경할 수 있는 호스팅 솔루션을 사용하는 것입니다. 

기본 DMARC 정책은 무엇인가요?

DMARC 생성기 도구를 사용하여 정책을 추가하는 경우 기본 모드로 "없음"이 지정됩니다. 수동으로 구현하는 경우 "p=" 필드에 정책을 정의해야 합니다. 그렇지 않으면 기록이 유효하지 않은 것으로 간주됩니다. 

콘텐츠 및 사실 확인 검토 프로세스

이 콘텐츠는 사이버 보안 전문가가 작성했습니다. 기술적 정확성과 관련성을 보장하기 위해 사내 보안팀의 세심한 검토를 거쳤습니다. 모든 사실은 공식 IETF 문서와 대조하여 확인되었습니다. 정보를 뒷받침하는 보고서 및 통계에 대한 참조도 언급되어 있습니다.

 

마이탐 알 라와티의 최신 글 (전체 보기)
모바일 버전 종료