DMARC 정책 선택: none부터 reject까지

DMARC 정책은 DMARC에 실패한 메일을 어떻게 처리할지 수신자에게 요청하는 설정입니다. 도메인 위조를 줄이는 데 도움이 될 수 있지만 최종 처리는 수신 측이 결정합니다. 너무 일찍 정책을 강화하면 청구서, 지원 답변과 전달된 메일까지 영향을 받을 수 있습니다. 전체 설정은 비즈니스 이메일 가이드에서 먼저 확인하세요.

문제는 DMARC의 복잡성보다 준비 부족인 경우가 많습니다. p=none을 게시한 뒤 분석 없이 계속 유지하거나, 모든 발신 시스템을 확인하기 전에 p=reject로 바꾸면 정상 메일도 거부될 수 있습니다.

일반적인 절차는 p=none으로 발신 출처를 조사하고, 정상 메일이 정렬된 인증을 통과하는지 확인한 뒤 p=quarantine을 도입하며, 이후 p=reject를 검토하는 것입니다. 남은 실패가 모두 위조라고 단정하지 말고 원인을 확인하세요. 적절한 전환 속도는 메일 흐름과 수집한 근거에 따라 달라집니다.

DMARC 정책이란?

DMARC 정책은 From에 도메인을 사용하는 메시지가 DMARC에 실패했을 때의 처리를 요청합니다. 선택지는 none, quarantine과 reject입니다. 정상 발신자의 인증과 도메인 정렬을 확인한 뒤 정책을 선택해야 합니다.

수신 서버는 SPF와 DKIM 결과 및 각 인증에 사용된 도메인이 표시되는 From 도메인과 정렬되는지 확인합니다. 도메인 정렬만으로 충분하지 않으며 해당 인증도 통과해야 합니다.

SPF가 통과하고 정렬되어 있으면 DMARC가 통과합니다.

DKIM이 통과하고 정렬되어 있으면 DMARC가 통과합니다.

둘 중 어느 것도 통과하면서 정렬되지 않으면 DMARC가 실패하고 수신 측은 게시된 정책을 처리 판단에 반영합니다.

처음에는 어떤 DMARC 정책을 선택할까?

모든 정상 발신자의 정렬된 SPF 또는 DKIM 통과를 대표성 있는 데이터로 이미 확인한 경우가 아니라면 보통 p=none으로 시작합니다. 실제 트래픽을 조사해야 정책 적용의 영향을 평가할 수 있습니다.

시작 레코드의 예는 다음과 같습니다.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

이 모드는 자체적으로 위조 메일 차단을 요청하지 않습니다. 보고서로 정보를 얻을 수 있지만 모든 수신자가 보고서를 보내는 것은 아니며 데이터가 완전하지 않을 수 있습니다.

놓치기 쉬운 발신 출처는 다음과 같습니다.

1. 청구서를 보내는 회계 소프트웨어.
2. 채용 제안서를 보내는 인사 도구.
3. 캠페인을 보내는 CRM과 마케팅 플랫폼.
4. 주 도메인으로 답변하는 헬프데스크 도구.
5. 다음 단계에서 SPF에 영향을 주는 사용자 전달 규칙.

모니터링을 건너뛰면 실제 업무 시스템의 정상 메시지가 제한될 수 있습니다. 단순한 이론적 위험이 아닙니다.

대량 발신자에게 DMARC 게시가 요구되는 경우가 있으며 Google도 인증과 정렬 조건을 적용합니다. 해당 트래픽에 적용되는 조건을 확인하세요. DMARC 표준은 RFC 7489에 정의되어 있습니다.

none 정책을 얼마나 유지해야 할까?

none으로 몇 주간 관찰하면 초기 상황을 파악할 수 있지만 필요한 기간은 발송 주기에 달려 있습니다. 월별 또는 드문 메일 흐름도 실제 관찰 데이터에 포함되어야 합니다.

며칠만으로는 부족한 경우가 많습니다. 짧은 관찰 기간은 월별 청구서, 분기별 업데이트나 드물게 비밀번호 재설정을 보내는 오래된 앱을 자동으로 포함하지 않습니다.

다음 흐름을 확인하세요.

1. 일상적인 업무 메일.
2. 마케팅 발송.
3. 청구 주기.
4. 지원 요청 처리.
5. 전달된 메일.
6. 외부 자동화 시스템.

집계 보고서를 분석해 정상 시스템의 문제와 위조 징후를 구분하세요. 알 수 없는 출처, 보고서 누락과 전달 오류도 고려해야 합니다. 모든 실패를 바로 위조로 분류할 수는 없습니다.

예를 들어 뉴스레터 플랫폼이 자체 도메인으로 서명하고 SPF도 그 플랫폼에 대해서만 통과한다면, SPF와 DKIM 모두 From 도메인과 정렬되지 않아 DMARC가 실패할 수 있습니다. reject를 켜기보다 먼저 정렬을 수정해야 합니다.

TrekMail의 도메인 DNS 안내와 내장 검사는 설정에 도움이 될 수 있지만 모든 외부 발신 경로 검증을 대신하지는 않습니다. 도메인 추가와 필수 DNS 레코드를 참고하세요.

전달은 왜 DMARC에 영향을 줄까?

전달 서버는 원래 서버가 아니므로 원래 봉투 발신자에 대한 SPF가 실패할 수 있습니다. 정렬된 DKIM이 통과하면 DMARC는 유지될 수 있습니다. 따라서 정책 강화 전에 전달 과정에서 서명이 유지되는지 확인하세요.

숙련된 관리자도 발신자 식별자의 차이를 놓칠 수 있습니다.

사용자가 보는 From과 반송 처리용 봉투 발신자는 다릅니다. SPF는 봉투 발신자 도메인에 대한 발신 IP 허용 여부를 확인합니다. DMARC는 통과한 SPF의 도메인이 From과 정렬되는지도 확인합니다.

전달하면 발신 IP가 바뀌어 원래 SPF 허용 범위를 벗어날 수 있습니다. DKIM은 서명된 헤더와 본문이 검증에 영향을 주는 방식으로 바뀌지 않으면 유지될 수 있습니다.

따라서 다음은 동시에 성립할 수 있습니다.

1. 전달 후 SPF가 실패합니다.
2. 정렬된 DKIM이 통과하므로 DMARC는 통과합니다.

정책 적용 전에 중요한 전달 흐름을 테스트하세요. 정상 발신자의 정렬된 DKIM과 중간 처리를 확인해야 합니다. Gmail 전달은 도메인 이메일을 Gmail로 전달하기, 일반적인 문제는 이메일 전달을 참고하세요.

ARC는 중간 시스템과 메일링 리스트를 거치는 인증 정보를 전달합니다. 그 정보를 신뢰하고 활용할지는 수신자가 결정하며 자체 정렬 설정을 대체하지는 않습니다. RFC 8617에 설명되어 있습니다.

quarantine으로 언제 전환할까?

대표성 있는 보고서와 테스트에서 정상 발신자의 정렬된 SPF 또는 DKIM 통과를 확인한 뒤 quarantine을 검토하세요. 실패한 메일을 의심스럽게 처리하도록 요청하지만 수신자는 다르게 처리할 수 있습니다. 안전을 보장하는 중간 단계는 아닙니다.

레코드 예시는 다음과 같습니다.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

놓친 정상 발신자의 메일이 스팸함에 나타나 문제가 드러날 수 있습니다. 그러나 이것만을 점검 수단으로 삼지 마세요. 처리 방식은 다양하고 사용자가 모두 신고하지도 않습니다.

문제가 생기면 다음과 같이 대응합니다.

1. 사용자가 메일 누락을 신고합니다.
2. 발신자와 정렬을 조사합니다.
3. SPF, DKIM 또는 둘 다 수정합니다.
4. reject 전환 전에 다시 테스트합니다.

일부 팀은 pct=25나 pct=50으로 점진 적용합니다. 하지만 수신자마다 지원과 적용 방식이 달라 정확한 트래픽 분배나 안전을 보장하지 않습니다. 100%에 quarantine을 적용하는 경우에도 충분한 검토가 필요합니다.

TrekMail 관리형 SMTP에서는 도메인 DKIM 설정과 실제 결과를 확인하세요. 전달된 메일은 SPF가 실패해도 정렬된 DKIM이 통과할 수 있습니다. 메일이 스팸함으로 들어가는 문제를 참고하세요.

reject로 언제 전환할까?

정상 발신 경로를 검증하고 남은 실패 원인을 충분히 조사한 뒤 reject를 검토하세요. DMARC 실패 메일의 거부를 요청하는 정책이며 수신 측은 자체 정책이나 상황에 따라 이를 재정의할 수 있습니다.

레코드 예시는 다음과 같습니다.

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

많은 도메인에서 충분한 준비 후 고려할 수 있는 목표입니다.

가능한 이점은 다음과 같습니다.

1. 정책을 따르는 수신자에서 직접적인 도메인 위조 제한.
2. 도메인을 악용하는 일부 피싱과 업무 이메일 사기 억제.
3. 인증 실패 메일의 원하는 처리 방식을 수신자에게 명확히 전달.
4. 완전한 보호를 보장하지 않으면서 도메인 및 브랜드 보호에 기여.

Google은 인증되지 않거나 정렬되지 않은 메일의 거부와 속도 제한을 설명합니다. DMARC 관련 4.7.31, 정렬 관련 4.7.32와 Gmail 반송의 5.7.26 같은 코드가 나타날 수 있습니다. 전체 오류 메시지와 Google 이메일 발신자 지침 FAQ를 함께 확인하세요.

주의할 점이 있습니다. 오래된 업무 도구의 청구서가 정렬된 인증을 통과하지 못하면 reject 정책 아래에서 거부될 수 있습니다. 테스트, 모니터링과 복구 계획을 준비하세요.

DNS에는 어떤 DMARC 레코드를 게시할까?

정책은 _dmarc.yourdomain.com의 TXT 레코드로 게시합니다. 도메인마다 DMARC 정책 레코드는 하나만 두세요. 여러 정책 레코드는 정책 발견을 무효화할 수 있습니다.

다음은 서로 대체하는 예시입니다. 모두 함께 게시하지 마세요.

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

TrekMail 도메인 구성에는 MX, SPF, DKIM과 DMARC가 포함될 수 있습니다. 아래는 형식 예시이며 모든 발신 경로에 적용되지 않습니다. quarantine 예시는 모니터링 없이 바로 제한하라는 뜻이 아닙니다.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

SPF를 중복 게시하지 말고 실제 DKIM 값을 사용하며 변경 시 기존 MX를 검토하세요. 자체 발신 제공업체를 사용한다면 해당 업체의 SPF와 DKIM 안내를 따라야 합니다. TrekMail SPF include가 모든 BYO 경로에 적용되는 것은 아닙니다. 자체 SMTP (BYO)를 참고하세요.

자주 하는 DMARC 정책 실수

p=none을 분석 없이 계속 유지하기, 너무 이른 정책 강화, SPF에만 의존하기와 하위 도메인 누락이 흔한 문제입니다. 보호 효과가 제한되거나 정상 메일에 영향을 줄 수 있습니다.

다음을 주의하세요.

1. none을 유지하면서 보고서나 정책 전환을 검토하지 않기. 이 정책은 차단을 요청하지 않습니다.
2. SPF가 정상으로 보인다고 DKIM 정렬을 건너뛰기. 전달 경로에서 문제가 드러날 수 있습니다.
3. 하위 도메인을 잊기. sp=로 상속되는 하위 도메인 정책을 지정할 수 있습니다.
4. SPF 제한 무시하기. 평가 중 DNS 조회를 유발하는 항목이 10개를 초과하면 PermError가 발생할 수 있으며 단순 DNS 패킷 개수와는 다릅니다.
5. 도메인으로 보내는 플랫폼의 서명 방식을 검증하지 않고 신뢰하기.

하위 도메인 정책 예시는 다음과 같습니다.

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

주 도메인에는 reject를, 이 정책을 상속하는 하위 도메인에는 none을 요청합니다. 특정 테스트 하위 도메인 하나에만 적용되는 것은 아니며, 하위 도메인의 명시적인 정책 레코드가 우선할 수 있습니다.

TrekMail을 활용한 정책 준비

TrekMail은 도메인 관리, DNS 검사와 발신 구성을 통합하는 데 도움이 될 수 있습니다. 다중 도메인 대시보드와 공유 저장 공간은 분산 관리를 줄일 수 있지만 모든 외부 발신자를 자동으로 조사하거나 DMARC 위험을 제거하지는 않습니다.

여기서 소개하는 유료 요금제는 Starter 월 $3.50부터이며 관리형 SMTP를 포함합니다. Nano는 자체 SMTP를 사용하는 무료 옵션으로 설명됩니다. 현재 가격, 한도와 기능은 확인하세요. TrekMail은 IMAP 사서함을 제공하며 자체 도메인, 캐치올, 전달, 마이그레이션과 API는 요금제에 따라 이용할 수 있습니다.

DMARC에서 어려운 부분은 TXT 게시 자체보다 도메인으로 발신할 수 있는 시스템을 관리하는 일입니다.

구성에 따라 TrekMail에서 다음을 할 수 있습니다.

1. 여러 도메인을 한 대시보드에서 관리합니다.
2. 사용 시작 전에 필수 DNS 레코드를 검사합니다.
3. 지원되는 유료 요금제의 관리형 SMTP 또는 Nano의 자체 SES/SendGrid를 사용합니다.
4. 사서함 호스팅과 발신 제공업체 선택을 분리합니다.
5. 원본 접근 권한과 지원 범위 안에서 IMAP 마이그레이션으로 기존 메일을 가져옵니다.

전체 설정은 자체 도메인에 이메일 설정하기, 여러 브랜드나 고객 도메인의 운영은 다중 도메인 이메일 호스팅을 참고하세요.

결론: 근거에 따른 단계적 전환

일반적인 경로는 none으로 시작해 인증과 정렬을 수정하고 quarantine을 검토한 뒤 reject를 고려하는 것입니다. DMARC는 한 번 설정하면 끝나는 항목이 아니라 유지 관리와 근거 있는 판단이 필요합니다.

간단히 정리하면 다음과 같습니다.

1. p=none으로 예를 들어 2주에서 4주간 초기 조사하되 발송 주기에 따라 늘립니다.
2. 모든 정상 발신자가 정렬된 SPF를 통과하고 가능하면 DKIM도 통과하도록 설정합니다.
3. 정상 메일 흐름과 위험을 평가한 뒤 p=quarantine을 적용합니다.
4. 남은 실패를 조사하고 부작용을 충분히 줄인 뒤 p=reject를 검토합니다.

이 접근은 정상 메일의 위험을 관리하면서 직접적인 도메인 위조를 줄이는 데 도움이 될 수 있지만 전달이나 완전한 보호를 보장하지는 않습니다. TrekMail 문서와 현재 기능 및 가격 조건은 https://trekmail.net/pricing에서 확인하세요.