DMARC 설정 방법을 찾고 있다면 바로 p=reject로 시작하지 마세요. 보통 모니터링부터 시작해 실제 발송원의 SPF 또는 DKIM이 성공하고 정렬되는지 확인한 뒤 정책을 강화합니다. 잊고 있던 청구서, 비밀번호 재설정, SaaS 발송도 조사해야 정상 메일에 미치는 영향을 줄일 수 있습니다.
실제 환경은 단순하지 않습니다. Microsoft 365, 외부 청구 앱, 마케팅 서비스와 스캔 메일을 보내는 복합기가 같은 도메인을 사용할 수 있습니다. 발송원 하나를 놓쳐도 제한 정책이 업무에 영향을 줄 수 있습니다. 내 도메인에 이메일 설정하기와 업무용 이메일 가이드도 참고하세요.
이 글은 운영에 필요한 순서로 설명합니다. 정보를 모으고 발송원을 확인해 정렬을 수정한 뒤 정책을 판단합니다. 모니터링만으로 이후 단계의 안전성이 증명되지는 않습니다.
DMARC가 하는 일
DMARC는 From에 자체 도메인을 표시한 메일 중 인증과 정렬 조건을 충족하지 못한 메일의 처리를 DNS로 요청합니다. SPF 또는 DKIM 중 하나 이상이 성공하고 보이는 From 도메인과 정렬되어야 통과합니다.
DMARC는 Domain-based Message Authentication, Reporting, and Conformance의 약자입니다. 정책을 게시하고 관측된 발송에 대한 보고를 요청합니다. 기본 규격은 RFC 7489입니다.
설정할 때 다음 원칙을 기억하세요.
- 정렬되지 않은 SPF 성공만으로는 부족하지만, 정렬된 DKIM이 성공하면 DMARC는 통과할 수 있습니다.
- 정렬되지 않은 DKIM 성공만으로는 부족하지만, 정렬된 SPF가 성공하면 DMARC는 통과할 수 있습니다.
- SPF 또는 DKIM이 성공과 정렬을 함께 충족하면 DMARC가 통과합니다.
Google은 대량 발신자에게 SPF, DKIM과 최소 p=none 정책의 DMARC를 요구하며 관련 정렬 조건도 적용합니다. 일반 발신자에게 모든 대량 발신 요건이 그대로 적용되는 것은 아닙니다. Google 발신자 가이드라인 FAQ에서 해당 조건을 확인하세요.
DMARC 이전에 확인할 사항
발송 환경부터 점검하세요. SPF 오류, 누락된 DKIM, 공급자 도메인으로만 이루어진 인증이 문제로 드러날 수 있습니다. 테스트하지 않은 제한 정책은 정상 발송에도 영향을 줍니다.
먼저 세 가지를 확인합니다.
- SPF: 실제 봉투 도메인에 맞는 레코드를 하나만 사용하고, 중첩 평가를 포함해 DNS 조회를 유발하는 메커니즘과 수정자의 10개 한도를 지킵니다. 전체 DNS 질의 수를 뜻하지 않습니다.
- DKIM: 지원되는 발송원에 활성화하고 공급자가 지원하면 2048비트 키를 사용합니다.
- 발송원 목록: 메일 서비스, CRM, 청구, 지원, 양식, 스캐너와 마케팅 도구를 조사합니다.
TrekMail에서는 필수 DNS 레코드와 도메인 추가를 참고할 수 있습니다. DNS 검사는 누락이나 중복을 찾는 데 도움이 되지만 실제 발송 인증 테스트를 대신하지 않습니다.
청구 앱이
billing@yourdomain.com으로 보내지만 공급자 도메인으로 서명하고 공급자 return-path를 사용한다고 가정해 보세요. SPF와 DKIM은 공급자에 대해 성공해도 From 도메인과 정렬된 성공이 없어 DMARC가 실패할 수 있습니다.
이런 문제가 테스트하지 않은 정책 변경의 영향을 설명합니다. 모니터링 레코드 게시 자체가 인증 실패를 일으키는 것은 아닙니다.
단계 1: 모니터링 DMARC 레코드 게시
보통 p=none부터 시작합니다. DMARC에 따른 격리나 거부를 요청하지 않고 보고를 요청할 수 있습니다. 보고가 보장되는 것은 아니며 수신 측의 자체 필터링은 계속됩니다.
_dmarc.yourdomain.com에 다음 TXT 값을 게시합니다.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com같은 값을 존 파일로 표현하면 다음과 같습니다. 별도 레코드를 추가하는 예시가 아닙니다.
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"RFC 7489 예시를 따르는 구성입니다. XML 집계 보고를 받을 전용 주소나 관리되는 별칭을 사용하세요. 접근과 개인정보 보호를 관리하고, 외부 수신처에는 DNS 승인이 필요한지 확인하세요.
DNS 관리 위치와 관계없이 게시한 값을 확인하고 실제 발송원을 테스트하세요. 메일이 스팸으로 분류되는 문제 FAQ는 전달과 인증 오류 조사에 도움이 될 수 있습니다. 대시보드의 정상 표시만으로 모든 메일을 검증한 것은 아닙니다.
단계 2: 보고서와 발송원 조사
보고서는 발송원을 조사하는 자료지만 완전한 목록이나 정상·악성 트래픽 자동 분류기가 아닙니다. 참여 수신자의 데이터에 자체 로그와 테스트를 더하세요.
보고서에는 다음 정보가 포함될 수 있습니다.
- 관측된 발송 IP
- SPF 인증 결과
- DKIM 인증 결과
- From 정렬을 반영한 DMARC 평가
- 수신 측이 보고한 처리 결과
확인된 발송원과 아직 조사하지 않은 트래픽을 구분하세요.
정상 발송원의 오류는 수정해야 합니다. 모르는 IP도 조사해야 하지만 전달 서버나 공유 릴레이일 수 있습니다. 인증 성공이 콘텐츠의 안전성을 증명하지는 않습니다.
다음 표는 설명용이며 공급자의 모든 기본 설정을 단정하지 않습니다.
| 발송원 | SPF | DKIM | 정렬 | 의미 |
|---|---|---|---|---|
| 올바르게 구성된 Microsoft 365 또는 TrekMail 사서함 | Pass | Pass | Pass | 예시에서는 인증이 정상이며 실제 경로도 확인해야 함 |
| 도메인 설정이 맞지 않는 Mailchimp 또는 SendGrid | Pass | Pass | Fail | 인증은 성공하지만 도메인과 정렬되지 않음; 기본 설정은 다를 수 있음 |
| 유효하고 정렬된 DKIM을 유지한 전달 메일 | Fail | Pass | Pass via DKIM | 서명 데이터가 보존된 전달 경로에서 가능 |
| 알 수 없는 IP에서 온 것으로 확인된 도메인 사칭 | Fail | Fail | Fail | 정책이 위험을 줄일 수 있지만 IP나 실패만으로 사칭이 증명되지는 않음 |
도메인이 많으면 새 SaaS마다 인증과 운영 점검이 필요합니다. 다중 도메인 이메일 호스팅이 관리에 도움이 될 수 있지만 비용이나 지원 요청 감소를 보장하지 않습니다.
단계 3: 인증뿐 아니라 정렬 수정
SPF 또는 DKIM 성공만으로는 부족합니다. 성공한 인증 도메인이 From과 정확히 같거나 완화 모드에서 같은 조직 도메인을 공유해야 합니다.
RFC 7489의 완화된 정렬은 SPF 인증 또는 DKIM 서명 도메인과 RFC5322.From이 같은 조직 도메인을 갖는 것입니다. DMARC에는 정렬된 인증 성공 하나면 충분하지만 지원되는 두 방식을 함께 구성하면 유용합니다.
흔한 해결 방법은 다음과 같습니다.
- 마케팅 플랫폼: 지원하면 자체 도메인의 DKIM 서명을 구성합니다.
- 반송 처리: 지원되는 사용자 지정 return-path나 반송 도메인을 구성합니다.
- Microsoft 365: 제한 정책 전에 자체 도메인 DKIM을 활성화하고 테스트합니다.
- TrekMail 관리형 발송: 실제 구성에 필요한 SPF와 DKIM 값을 게시합니다.
실제 외부 발송 공급자의 설정을 따라야 합니다. TrekMail은 Nano의 자체 SMTP와 유료 요금제의 관리형 SMTP 등 옵션을 제공할 수 있습니다. 사서함과 발송 구성을 나누어 관리하되 기능과 한도는 요금제별로 확인하세요.
Nano는 자체 SMTP를, 유료 요금제는 관리형 SMTP를 사용하는 구성으로 소개됩니다. 제시된 시작 가격은 월 $3.50이며, 유료 요금제의 14일 무료 체험과 카드 없는 무료 Nano 옵션이 설명됩니다. 현재 가격과 체험 조건은 TrekMail 요금에서 확인하세요.
단계 4: quarantine 검토
정상 발송원을 조사한 뒤 quarantine을 검토할 수 있습니다. 이미 제한 정책이며 실패 메일을 의심스럽게 취급하도록 요청합니다. 특정 스팸 폴더, 복구 가능성이나 모든 도메인에 안전한 중간 단계를 보장하지 않습니다.
적합하다면 기존 레코드를 다음 값으로 교체합니다.
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.comreject 전에 quarantine을 고려하는 이유:
- DMARC 실패 메일의 더 엄격한 처리를 요청합니다.
- 거부보다 영향이 작을 수 있지만 정상 메일도 피해를 볼 수 있습니다.
- 모니터링과 복구 계획을 갖추고 실제 영향을 조사할 수 있습니다.
관련 발송을 평가할 만큼 관찰하세요. 몇 주는 초기 기준이 될 수 있지만 30일도 완전성을 증명하지 않습니다. 드문 발송이나 월별·분기별 작업을 별도로 테스트하세요.
WordPress 플러그인, CRM 테스트 환경, 오래된 복합기나 주기적인 공급자가 뒤늦게 발견될 수 있습니다. 조용한 보고 기간만 믿지 마세요.
단계 5: 충분히 검증한 뒤 reject 검토
p=reject는 DMARC 실패 메일의 거부를 요청합니다. 직접적인 도메인 사칭 위험을 줄일 수 있지만 모든 사칭을 막아 주거나 받은편지함 도착을 보장하지는 않습니다.
적합한 최종 정책은 기존 레코드를 대체할 수 있습니다.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.comRFC 7489는 p=reject에 따른 거부 요청을 설명합니다. 수신 측이 자체 예외를 적용할 수 있으므로 모든 실패 메일이 반드시 차단된다고 보지는 마세요.
이전에 다음을 확인하세요.
- 실제 사서함 발송 인증이 성공하고 정렬됨
- 마케팅과 트랜잭션 발송이 성공하고 정렬됨
- 단순히 조용한 몇 주가 아니라 관련 기간의 보고를 검토함
- 남은 오류를 조사하고 드문 핵심 발송을 테스트함
계속 보고서, 로그와 변경 사항을 확인하세요. DMARC는 일회성 작업이 아니라 변경 관리의 일부입니다.
메일에 영향을 주는 흔한 오류
누락된 발송원, 중복 SPF, 테스트하지 않은 DKIM과 정렬 없는 공급자 설정을 확인하세요. 모니터링 게시 자체가 인증 실패를 만들지는 않지만 성급한 제한 정책은 영향을 키울 수 있습니다.
- DKIM과 경로 테스트 전에 제한 정책 적용
- 적절한 단일 레코드 대신 여러 SPF 게시
- SPF 성공을 DMARC 성공으로 단정
- 소량 발송 공급자 누락
- DMARC가 없는 상태에서 바로
p=reject적용 - 아무도 관리하지 않는 주소로 보고 요청
전달로 SPF가 실패해도 서명된 데이터가 정규화 규칙에 따라 보존되고 DKIM이 유효하며 정렬되면 DMARC가 통과할 수 있습니다. 이메일 별칭 전달과 안전한 업무용 이메일도 참고하세요.
DMARC 설정 체크리스트
다음은 판단을 돕는 순서이며 정해진 기간 뒤 정책이 안전하다는 보장은 아닙니다.
- 도메인을 쓰는 발송원을 조사합니다.
- 관련 봉투 도메인에 평가 한도 내 유효한 SPF 하나를 사용합니다.
- 지원되는 발송원에 DKIM을 활성화하고 테스트합니다.
v=DMARC1; p=none; rua=mailto:...같은 모니터링을 게시합니다.- 보고서를 로그와 발송원 정보로 보완해 조사합니다.
- 정상 발송원의 인증 오류를 수정하고 정렬을 확인합니다.
p=quarantine과 영향을 검토합니다.- 계속 보고와 핵심 흐름을 확인합니다.
- 테스트와 복구 계획을 갖추고
p=reject를 검토합니다.
정리: 신중한 DMARC 설정
보통 p=none으로 시작해 발송원을 조사하고 인증과 정렬을 수정합니다. 이후 p=quarantine과 필요하면 p=reject를 검토하세요. 위험 관리에 도움이 되지만 배달이나 모든 사칭 방지를 보장하지 않습니다.
수십 또는 수백 도메인이라면 일관된 관리 환경이 도움이 될 수 있습니다. TrekMail은 요금제에 따라 자체 도메인, IMAP 사서함, catch-all, 전달, 이전과 자체 또는 관리형 SMTP를 제공할 수 있습니다. IMAP은 지원 메시지를 복사하며 MX 전환과 다른 앱 데이터는 별도 작업입니다. 실제 비용과 한도를 비교하세요.
운영 관점의 DMARC 설정 방법은 먼저 조사하고 정렬을 테스트한 뒤 보고서 외의 근거도 함께 살펴 정책을 판단하는 것입니다.
