회사가 주문 확인 메일을 mail.example.com에서, 뉴스레터를 marketing.example.com에서 보낸다면, 이 주소들은 메인 도메인의 하위 도메인입니다. 메인 도메인을 이메일 스푸핑으로부터 보호하기 위해 DMARC를 켜면 하위 도메인도 보통 함께 보호됩니다. 하위 도메인이 메인 도메인의 정책을 자동으로 따르기 때문입니다. 그런데 DMARCeye의 Q1 2026 데이터셋에서 DMARC를 완전히 켜 둔 도메인 13개 중 1개꼴로 작은 설정 오류가 있어서 메인 도메인은 잠겨 있는데 하위 도메인은 노출된 상태로 남아 있습니다.
이 글은 DMARCeye Q1 2026 산업 보고서의 하위 도메인 정책 결과를 풀어서 설명합니다. 전체 보고서와 방법론은 아래에 있습니다.
DMARC 레코드는 DNS에 들어가는 짧은 텍스트 한 줄로, 이메일 수신 서버에 여러분의 도메인을 사칭하는 메일을 어떻게 처리해야 할지 알려 줍니다. 핵심 설정은 p= 태그로, 메인 도메인의 정책을 정합니다. 정책 단계는 세 가지입니다.
p=none은 수신 서버가 모니터링과 보고는 하되 모든 메일을 그대로 전달한다는 뜻입니다 (아직 보호 없음).p=quarantine은 인증에 실패한 메일을 스팸함으로 보낸다는 뜻입니다.p=reject는 인증에 실패한 메일을 아예 차단한다는 뜻입니다.sp= 태그는 같은 개념을 하위 도메인에 적용한 것입니다. 위와 동일한 세 가지 값을 가집니다. sp=를 따로 설정하지 않으면 하위 도메인은 p=가 무엇이든 그대로 따라갑니다. 그래서 메인 도메인이 p=reject이고 sp=를 설정하지 않았다면, 모든 하위 도메인(mail.example.com, support.example.com, 그 외 어떤 것이든)도 p=reject가 됩니다. 이는 표준 사양이 의도한 대로 동작하는 것입니다 (RFC 7489 §6.3 참조).
하위 도메인을 메인 도메인과 다르게 처리하고 싶을 때만 sp=를 명시적으로 설정합니다. 가장 흔한 이유는 두 가지입니다. 하위 도메인이 메인 도메인과 다른 벤더로 메일을 보내거나, 하위 도메인을 메인 도메인보다 빠르게 (또는 느리게) 시행 단계로 올리고 싶을 때입니다.
DMARCeye Q1 2026 모니터링 표본의 수천 개 도메인에서 sp=의 분포는 메인 p= 정책에 크게 좌우됩니다.
세 가지 패턴이 눈에 띕니다.
sp=를 아예 설정하지 않습니다. p=none 도메인의 86.67%, p=quarantine의 78.59%, p=reject의 65.15%가 레코드에서 sp=를 완전히 빼 둡니다. 위에서 다룬 대로 이는 기본 동작이며, 하위 도메인은 메인 도메인의 정책을 자동으로 따라갑니다.p=reject 도메인 중 6.62%가 sp=none으로, 또 다른 0.94%가 sp=quarantine으로 설정되어 있습니다. 합치면 시행 정책에 도달한 도메인의 7.56%가 메인 도메인은 엄격하게 보호하면서 하위 도메인은 느슨하거나 보호하지 않는 상태입니다.sp=를 쓰는 곳은 거의 없습니다. p=none 도메인 중 단 0.42%만 sp=reject를 설정해 두었습니다. 이는 영리한 패턴인데 (메인 도메인은 모니터링 모드로 두면서 데이터를 모으는 동안 하위 도메인의 사칭 메일은 곧바로 차단), 거의 활용되지 않고 있습니다.sp=를 명시적으로 설정하는 것이 옳은 두 가지 상황이 있습니다.
하위 도메인이 다른 이메일 제공자를 쓰는 경우. marketing.example.com이 한 도구로(예를 들어 뉴스레터 플랫폼) 발송하고 메인 도메인은 다른 도구로(예를 들어 트랜잭션 메일 제공자) 발송한다면, 둘은 인증 설정이 서로 다릅니다. 특히 새 제공자를 도입하는 동안에는 한쪽에 더 엄격한 DMARC 정책을 두고 싶을 수 있습니다. sp=를 설정하면 메인 도메인을 건드리지 않고 하위 도메인에 별도의 정책을 줄 수 있습니다.
메인 도메인보다 하위 도메인을 먼저 보호하고 싶은 경우. 메일을 많이 보내는 도메인이거나 사칭의 표적이 되기 쉬운 도메인이라면, 보고서를 몇 주 동안 지켜본 뒤에 본격적인 시행을 하고 싶어집니다. 이런 경우라면 메인 도메인은 p=none(모니터링 전용)으로 두고 sp=reject를 설정해 하위 도메인을 곧바로 보호하는 것이 합리적입니다. 하위 도메인은 보통 정상 발송자가 더 적고 설정이 더 명확하기 때문에 먼저 시행 단계에 올리기에 더 안전한 경우가 많습니다. Q1 데이터에서는 p=none 도메인의 0.42%가 이 패턴을 사용합니다.
주의해야 할 실수는 그 반대입니다. 메인 도메인은 엄격한 정책(p=reject)인데 하위 도메인은 느슨하거나 없는 경우(sp=none 또는 sp=quarantine)입니다. 이유는 보통 다음 중 하나입니다.
sp=를 느슨하게 풀어 버린 경우입니다.sp=none으로 설정해 뒀고, 이후 다시 돌아와 조이지 않은 경우입니다.sp=를 p=에 맞춰 두었는데, 나중에 누군가 어떤 이유로 수동으로 약화시킨 경우입니다.어느 경우든 결과는 같습니다. 메인 도메인은 완전히 보호되지만, 모든 하위 도메인은 시행 없이 사칭 메일을 받아들입니다. 여러분의 DMARC 레코드를 살펴보는 사람이라면 누구든 이 빈틈을 곧바로 알아챕니다.
당사의 Q1 2026 데이터셋에서 시행 정책 도메인의 7.56%가 이 설정 상태입니다. 시행 단계에 와 있다면, 이것이 DMARC 레코드에서 가장 먼저 점검해야 할 항목입니다.
짚고 넘어갈 짧은 질문 세 가지가 있습니다.
p=reject를 향해 단계적으로 올라가게 됩니다. 레코드에서 sp=를 빼 두는 것이 기본값이며, 대부분의 회사에 이 방식이 잘 맞습니다. 하위 도메인은 메인 정책을 자동으로 따릅니다.sp= 설정을 고려하세요.sp=를 명시적으로 설정하세요. 하위 도메인을 메인 도메인보다 느슨하게 두고 싶은 경우는 거의 없으니, 그 대신 sp=를 p=에 맞추거나 아예 비워 두세요.DNS에 이미 sp=가 선언되어 있다면 p=보다 약하지 않은지 다시 한 번 확인해야 합니다. p=reject에 sp=none을 결합한 형태가 바로 주의해야 할 잘못된 설정입니다. 아직 DMARC 모니터링을 설정해 두지 않았다면, DMARCeye의 무료 플랜이 도메인 1개를 다루며 여러분의 레코드가 정확히 어떻게 생겼는지를 보여 줍니다. 설정해 둔 sp= 값이 있다면 그것까지 함께 보입니다. 지금 도메인이 어떤 상태인지 바로 확인하려면 아래에서 조회해 보세요.
DMARCbis는 2026년에 발표될 예정인 DMARC 표준의 다음 업데이트입니다. sp=가 작동하는 방식 자체는 바뀌지 않습니다. 설정하지 않으면 하위 도메인은 여전히 메인 정책을 그대로 물려받습니다.
대신 np=라는 새 태그가 추가됩니다. 이 태그는 실제로 존재하지 않는 하위 도메인에 적용할 정책을 통제합니다. 지금은 스패머가 madeup.example.com(여러분이 만들지 않은 하위 도메인)을 사칭해 메일을 보내면, 수신 서버는 메인 도메인의 정책으로 되돌아가 처리합니다. np=가 도입되면 이러한 가짜 하위 도메인에만 더 엄격한 정책을 따로 적용할 수 있게 됩니다. DMARCbis가 확정된 뒤 하위 도메인 보호를 더 강하게 가져가고 싶다면 이 태그를 눈여겨봐 두세요.
대부분의 도메인은 sp=를 레코드에서 빼 두는 것이 옳은 선택입니다. 기본 동작이 하위 도메인을 자동으로 보호해 줍니다.
예외는 분명히 있지만 그 범위는 제한적입니다. 하위 도메인이 메인 도메인과 다른 이메일 제공자를 쓸 때, 또는 메인 도메인보다 하위 도메인을 더 빠르게 보호하고 싶을 때입니다. 두 경우 모두 sp=를 의도를 가지고, 그리고 정확하게 설정해야 합니다.
DMARC 레코드가 p=reject인데 sp=가 그보다 약한 어떤 값이라면, 이것이 바로 그 잘못된 설정입니다. 다른 무엇보다 먼저 이것부터 고치세요. DMARCeye는 모니터링 중인 모든 도메인의 sp= 설정을 추적하며, 무료 플랜은 도메인 1개를 다룹니다.