사칭 메일, Gmail 경고나 공급자의 DNS 요청을 받은 뒤 DMARC 레코드 만들기를 시작하는 경우가 많습니다. 메일마다 SPF와 DKIM 결과가 다르다면 조사해야 합니다. 환경을 구성하는 중이라면 업무용 이메일 가이드에서 도메인, 사서함과 DNS를 함께 살펴보세요.
레코드가 존재한다고 올바르게 작동하는 것은 아닙니다. 잘못된 호스트, 부적절한 정책, 사용할 수 없는 보고 주소나 정렬 누락이 문제가 될 수 있습니다. DMARC만으로 모든 사칭이나 스팸함 분류를 막을 수는 없습니다.
이 글은 DMARC 레코드 생성, 주요 태그, _dmarc.yourdomain.com에 게시할 값과 모니터링에서 제한 정책으로 전환하는 판단을 다룹니다.
DMARC 레코드에 게시하는 내용
_dmarc.yourdomain.com에 v=DMARC1으로 시작하고 p=none, p=quarantine 또는 p=reject 같은 유효한 정책을 포함한 TXT를 게시합니다. SPF와 DKIM 어느 쪽도 성공과 From 정렬을 함께 충족하지 못한 메일의 처리를 요청합니다.
최소한의 유효한 예시:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;DMARC 제한을 요청하지 않는 정책입니다. 집계 보고를 요청하지 않으며 수신 측의 자체 필터링은 계속됩니다. 보고를 수집하는 전체 구성은 아닙니다.
보고를 포함한 예시:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100충분히 조사한 뒤 기존 정책을 다음과 같이 교체할 수 있습니다.
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100RFC 7489에 따르면 v는 첫 번째여야 하며 p는 필수입니다. 잘못된 값은 원하는 정책으로 사용되지 않을 수 있습니다. 세부 규칙은 RFC 7489를 참고하세요.
DNS의 어느 위치에 게시하나요?
도메인 루트가 아니라 _dmarc에 게시합니다. example.com의 조회 대상은 _dmarc.example.com입니다. 다른 이름이면 원하는 정책을 찾지 못합니다.
@에 값을 넣지 마세요. _dmarc.example.com 전체를 입력할지 _dmarc만 입력할지는 DNS 관리 화면에 따라 다릅니다. 영역 이름을 자동으로 붙이는지 확인하세요.
게시 후 관리 화면 밖에서도 확인합니다.
dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.comv=DMARC1으로 시작하는 DMARC 정책 레코드가 하나여야 합니다. 다른 TXT가 모두 충돌하는 것은 아니며, 한 레코드 안의 여러 문자열 조각은 하나의 값으로 연결됩니다.
TrekMail에서는 실제 구성에 필요한 값을 확인할 수 있습니다. 도메인 추가, 필수 DNS 레코드, DNS 상태 확인을 참고하세요. 대시보드 검사는 모든 발송 경로의 실제 테스트를 대신하지 않습니다.
DMARC 레코드의 주요 태그
v, p와 필요에 맞는 rua부터 구성하세요. 정렬 태그와 추가 옵션은 영향을 이해한 뒤 사용합니다.
| 태그 | 필수 여부 | 역할 | 실무 조언 |
|---|---|---|---|
v | 예 | 버전 | DMARC1이며 맨 앞에 위치 |
p | 예 | 실패 시 요청 정책 | 보통 none부터 시작해 quarantine과 reject 검토 |
rua | 아니요 | 집계 보고 수신처 | 관리되는 주소와 자체 로그 사용 |
ruf | 아니요 | 실패 보고 수신처 | 선택 사항이며 지원이 제한적이고 개인정보에 민감함 |
adkim | 아니요 | DKIM 정렬 | 기본값은 r; 실제 도메인 구조 확인 |
aspf | 아니요 | SPF 정렬 | 기본 r, 근거가 있는 경우 s |
pct | 아니요 | 실패 메일에 정책을 요청하는 비율 | 100도 모든 메일이나 수신자의 처리를 보장하지 않음 |
sp | 아니요 | 상속되는 하위 도메인 정책 | 적용 가능한 자체 레코드 없이 조직 도메인 정책을 조회할 때 관련됨 |
p=none만 있고 rua가 없는 레코드도 유효할 수 있지만 집계 보고를 요청하지 않습니다. 자체 로그와 테스트는 계속 사용할 수 있습니다. 보고는 접근·개인정보 관리가 필요하며 외부 수신처에는 DNS 승인이 필요할 수 있습니다.
정책 선택 방법
발송 흐름을 아직 다 조사하지 않았다면 보통 p=none으로 시작합니다. 오류 수정과 테스트 뒤 p=quarantine을 검토하세요. 모르는 트래픽과 드문 정상 발송까지 충분히 조사한 뒤 p=reject를 고려합니다.
| 정책 | 요청하는 처리 | 검토 시점 | 위험 |
|---|---|---|---|
p=none | DMARC 제한 요청 없음 | 초기 조사 | 실패 메일 제한을 요청하지 않음; 자체 필터는 계속됨 |
p=quarantine | 의심스럽게 취급하도록 요청 | 조사 뒤 적합한 경우 | 정상 예외 메일도 영향 가능; 특정 폴더나 복구 보장 없음 |
p=reject | 거부 요청 | 충분히 검증한 환경 | 잘못 구성한 정상 메일이 거부될 수 있음; 수신 측 예외 가능 |
Google은 대량 발신자에게 SPF, DKIM과 관련 From 정렬 요건을 적용합니다. DMARC에는 정렬된 인증 성공 하나면 충분합니다. 미래 요건을 단정하지 말고 Google 발신자 가이드라인 FAQ에서 해당 발신자 유형의 요건을 확인하세요.
DMARC를 체크 항목으로만 보지 마세요. CRM이 귀사 도메인을 From에 표시하면서 공급자의 서명과 반송 도메인을 쓰면 인증이 활성화되어 있어도 정렬된 성공이 없어 DMARC가 실패할 수 있습니다.
DMARC 레코드 생성 순서
발송원을 조사하고 모니터링 정책을 게시한 뒤 보고서, 로그와 실제 테스트로 제한 정책을 판단합니다. 조용한 보고 기간만으로 모든 흐름을 검증했다고 볼 수 없습니다.
- Google Workspace, Microsoft 365, 지원, CRM, 양식, 청구와 뉴스레터 발송을 조사합니다.
- 실제 발송원의 유효한 SPF와 테스트한 DKIM을 확인합니다. DMARC는 이를 대체하지 않습니다.
dmarc@yourdomain.com같은 관리 주소나 적합한 보고 서비스를 구성합니다.- 보통
p=none부터 게시합니다. - 수신한 집계를 자체 로그와 발송원 정보로 보완합니다.
- 해당 서비스의 인증 오류와 From 정렬을 수정합니다.
- 모니터링과 복구 계획을 갖추고
p=quarantine을 검토합니다. - 드문 핵심 발송도 테스트한 뒤
p=reject를 검토합니다.
2026년 환경에서 참고할 설명용 모니터링 예시:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100전달이 필요하면 도메인 이메일을 Gmail로 전달하기를 읽어 보세요. 원래 SPF가 실패할 수 있으며 DKIM은 서명이 유효하고 정렬되며 정규화된 서명 데이터가 보존될 때 도움이 됩니다. ARC는 수신 측 판단에 쓰일 수 있지만 DMARC 실패를 인증 성공으로 바꾸지는 않습니다.
흔한 생성 오류
호스트명, 중복 정책, 보고 주소와 기본 인증을 확인하세요. 관리 환경 밖에서도 조회합니다.
반복되는 문제는 다음과 같습니다.
1. _dmarc 대신 루트에 게시.@에서는 원하는 DMARC 정책을 찾지 못합니다.
2. 여러 DMARC 정책 레코드 사용.
RFC 7489는 여러 정책 레코드가 처리를 중단시킨다고 설명합니다. 한 레코드 안의 문자열 조각과는 다릅니다.
3. 처음부터 p=reject 적용.
잊고 있던 서비스의 복구, 청구나 지원 답장이 거부될 수 있습니다.
4. 사용할 수 없는 주소를 rua로 지정.
보고 수신이 막힐 수 있습니다. 보고가 없다고 수신자가 반드시 보냈다고 볼 수도 없습니다.
5. DMARC가 전달을 고칠 것으로 기대.
성공하고 정렬된 SPF 또는 DKIM이 필요합니다. 실제 경로에서 유효하고 정렬된 DKIM이 유지되는지 테스트하세요.
주문 확인, 지원과 마케팅이 서로 다른 세 SMTP 서비스를 사용합니다. 점검 없이
p=reject를 게시하면 하나는 통과하고 둘은 실패해 고객 메일이 거부될 수 있습니다. 실제 영향에는 수신 측 처리도 관계됩니다.
처음 구성한다면 자체 도메인 이메일 만들기에서 주변 DNS와 사서함 작업도 확인하세요.
여러 도메인의 DMARC 관리
스프레드시트와 오래된 지원 기록의 값만으로 관리하면 혼동이 생길 수 있습니다. 공통 대시보드와 도메인별 설정은 조사를 정리하는 데 도움이 되지만 DNS와 실제 발송을 계속 검증해야 합니다.
| 분산된 방식 | TrekMail의 관련 기능 |
|---|---|
| 등록기관마다 로그인해 현재 값 확인 | 여러 도메인을 같은 환경에서 관리 |
| 수동 TXT 비교 | DNS 차이 조사 지원; 전파 완료 보장은 아님 |
| 인증을 여러 도구에서 따로 관리 | SPF, DKIM, DMARC 설정 안내를 한곳에서 확인 |
| 일부 서비스의 사용자별 과금 | 요금제 한도 내 다중 도메인; 제시된 시작 가격 월 $3.50 |
TrekMail은 조건에 따라 여러 도메인, 공유 저장 공간, IMAP 사서함, 이전, catch-all, 전달과 자체 또는 관리형 SMTP를 제공할 수 있습니다. Nano는 자체 SMTP로 최대 10개 도메인을 지원하는 무료 옵션으로, 유료 시작 가격은 월 $3.50로 소개됩니다. 현재 기능과 조건은 TrekMail 요금에서 확인하세요.
일관된 환경은 다섯 공급자와 스무 브라우저 탭에 흩어진 조사를 정리하는 데 도움이 될 수 있습니다. 모든 발송의 인증이나 구체적인 절약을 증명하지는 않습니다.
제한 정책 전 최종 점검
정상 발송원에 성공하고 정렬된 인증이 있는지, 보고 주소가 관리되는지, _dmarc에 유효한 정책 하나가 게시되는지 확인하세요. DMARC는 잘못된 SPF나 DKIM을 대신 고치지 않습니다.
다시 확인할 항목:
- DMARC 정책 레코드 하나만 사용
- DNS 화면 규칙에 맞는
_dmarc호스트 v=DMARC1; p=...로 시작하는 값- 승인과 개인정보를 관리한 실제
rua수신처 - 관련 봉투 도메인마다 SPF 하나; 중첩 평가를 포함한 DNS 조회를 유발하는 SPF 메커니즘과 수정자의 한도 준수
- 지원되는 발송원의 DKIM 구성과 실제 테스트
- 외부 조회에서 예상한 정책 확인
- 발송원과 관련 경로를 충분히 검증하지 않았다면 보통
none부터 시작
TrekMail은 도메인, IMAP 사서함, DNS 상태, SMTP 선택과 이전을 같은 관리 환경에 제공할 수 있습니다. IMAP은 지원 메시지를 복사하며 MX 전환과 앱 데이터는 별도 작업입니다. trekmail.net에서 현재 기능을 확인하고 변경 후에도 메일을 점검하세요.
