DMARC 레코드 예시는 SPF와 DKIM 어느 쪽도 인증 성공과 From 정렬을 함께 충족하지 못한 메일의 처리를 TXT로 요청하는 구성을 보여 줍니다. 잘못된 설정은 보호를 약화하거나 정상 메일에 영향을 줄 수 있지만 DMARC만으로 Gmail 분류를 예측할 수는 없습니다. 전체 구성은 업무용 이메일과 자체 도메인 이메일 만들기도 참고하세요.
_dmarc.yourdomain.com에 유효한 정책 하나를 게시하세요. 발송원을 모르면 보통 모니터링부터 시작해 조사와 테스트 뒤 제한 정책을 판단합니다. TrekMail의 필수 DNS 레코드 가이드는 기본 구성을 설명하며, 여기서는 적합한 DMARC 레코드 예시를 고릅니다.
DMARC 레코드 예시의 역할
DMARC 레코드 예시에는 프로토콜, 정책과 선택적인 보고 설정이 담깁니다. DMARC는 SPF와 DKIM을 대체하지 않습니다. 적어도 하나가 성공하고 보이는 From 도메인과 정렬되어야 합니다. 이는 콘텐츠 안전성의 증명은 아닙니다.
제한 정책 없이 보고를 요청하는 최소 예시:
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com각 부분의 의미:
v=DMARC1은 DMARC를 나타냅니다.p=none은 DMARC에 따른 격리나 거부를 요청하지 않습니다. 자체 필터는 계속될 수 있습니다.rua=mailto:dmarc@example.com은 참여 수신자에게 XML 집계 보고를 요청합니다.
이것이 기본이며 추가 태그는 실제 환경에 맞춰 검토합니다.
DMARC는 인증을 보이는 발신 도메인과 연결하고 정책 처리를 요청합니다. SPF와 DKIM은 도메인 인증이지 콘텐츠나 발신 의도가 안전하다는 증명은 아닙니다.
5가지 DMARC 레코드 예시
하나의 DMARC 레코드 예시가 모든 환경에 맞지는 않습니다. 다음은 모니터링, 제한 정책, 비율과 하위 도메인 설정의 대안입니다. 모두 함께 게시하지 마세요.
모니터링만 사용. 발송원과 전달 경로를 조사하며 로그와 테스트로 보완합니다.
v=DMARC1; p=none; rua=mailto:dmarc@example.com의심 메일 처리 요청. 정상 흐름 테스트 뒤 검토하며 이미 제한 정책입니다.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com실패 메일 거부 요청. 충분히 조사한 환경에서 복구 계획과 함께 검토합니다.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com단계적인 처리 요청. 실패 메일의 비율이며 수신자마다 지원과 적용이 다릅니다.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com하위 도메인 정책과 엄격한 정렬. 정확한 도메인 일치를 요구하며, 자체 하위 도메인 정책이 없을 때 관련 조직 도메인 정책이 상속됩니다.
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
| 정책 | 검토 환경 | 가능한 이점 | 위험 |
|---|---|---|---|
p=none | 발송원 조사 | DMARC 제한 요청 없음 | 사칭 제한 요청 없음; 보고는 부분적임 |
p=quarantine | 테스트한 적합한 환경 | 의심스럽게 처리하도록 요청 | 정상 앱도 영향 가능; 특정 스팸 폴더 보장 없음 |
p=reject | 충분히 검증한 운영 환경 | DMARC 실패 거부 요청 | 정상 메일 거부 가능; 수신 측 예외 가능 |
pct=25 | 근거 있는 단계별 적용 | 실패 메일 일부의 정책 처리 요청 | 전체 트래픽 비율이나 안전한 전환 보장 아님 |
adkim=s; aspf=s | 정확한 도메인 일치가 필요한 환경 | 엄격한 도메인 정렬 | 정상 외부 발송도 제외될 수 있음 |
다음 DMARC 레코드 예시는 정상 흐름 검증 뒤 고려할 수 있습니다. 모든 도메인의 가장 안전한 시작점은 아닙니다.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com즉시 거부 대신 제한 처리를 요청하지만 복구 가능성을 보장하지 않습니다.
DNS에 DMARC 레코드 예시 게시
DMARC 레코드 예시를 _dmarc의 TXT로 게시합니다. 루트 대신 _dmarc를 사용하고 정책 하나만 게시하세요. 중복 정책은 원하는 처리를 방해할 수 있습니다.
DNS 화면 예시입니다. TTL은 전파 시간의 보장이 아닙니다.
Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com그다음 확인합니다.
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comv=DMARC1으로 시작하는 정책 하나를 확인하세요. 다른 TXT와 한 레코드 안의 문자열 조각이 모두 중복 정책인 것은 아닙니다.
RFC 7489에 따르면 정책이 없거나 여러 정책이 있으면 유효한 DMARC 처리를 할 수 없습니다. 어떤 DNS 화면은 _dmarc만, 다른 화면은 전체 이름을 요구합니다. 영역 이름이 자동으로 붙는지 확인하세요.
전체 MX, SPF, DKIM과 DMARC 구성은 TrekMail의 필수 DNS 레코드를 참고하세요.
메일에 영향을 주는 예시 설정 오류
DMARC 레코드 예시를 잘못 적용하면 호스트, 중복 정책, 보고 주소, 테스트하지 않은 엄격한 정렬이나 전달 오류 해석이 문제가 될 수 있습니다.
주요 확인 사항:
- 도메인 루트에 게시. 화면 규칙에 맞게
_dmarc를 사용하며@는 아닙니다. - 여러 DMARC 정책 게시. 관련 도메인에 정책 하나를 사용합니다.
- 발송원 조사 전
p=reject적용. 잊은 CRM이나 청구 발송이 영향을 받을 수 있습니다. - DMARC가 전달을 고칠 것으로 기대. SPF가 실패할 수 있으며 DKIM은 유효하고 정렬된 서명과 정규화된 서명 데이터가 보존될 때 도움이 됩니다. 도메인 메일을 Gmail로 전달하기와 이메일 별칭 전달도 참고하세요.
- 정렬 무시. 정렬 없는 SPF 성공은 부족하지만 정렬된 DKIM이 성공하면 DMARC가 통과할 수 있습니다.
- 보고 생략.
rua가 없으면 집계를 요청하지 않지만 자체 로그는 가능합니다. 개인정보, 접근과 외부 DNS 승인을 관리하세요.
Google은 특정 발신자 유형에 요건을 적용합니다. 해당 경우 정책 누락이나 정렬 오류가 제한으로 이어질 수 있습니다. 모든 발송량에 같은 대량 요건을 적용하지 말고 발신자 가이드라인 FAQ를 확인하세요.
TrekMail에 맞는 DMARC 레코드 예시
DMARC 레코드 예시는 실제 발송 경로에 맞춰야 합니다. 관리형 SMTP도 올바른 DNS와 실제 테스트가 필요합니다. 자체 SMTP라면 실제 봉투 도메인의 SPF 승인과 DKIM 정렬을 확인합니다.
관리 방식 비교:
| 구성 | 분산된 방식 | 정리된 방식 |
|---|---|---|
| 관리형 발송 | 사서함과 SMTP를 따로 관리 | 적합한 TrekMail SMTP를 구성하고 인증 성공과 정렬 테스트 |
| 자체 SMTP | 실패 뒤 공급자 설정 조사 | TrekMail 사서함과 실제 필요한 외부 SPF·DKIM을 미리 구성 |
| 다중 도메인 | 개별 수동 변경 | 도메인별 템플릿과 검토한 보고 관리 |
TrekMail 관리형 SMTP는 관련 유료 옵션을, 자체 SMTP 사용은 외부 발송을 설명합니다. SPF가 평가되는 실제 도메인에서 공급자를 승인하세요. SPF 정렬이 안 되면 유효하고 정렬된 DKIM이 필요할 수 있습니다.
사서함과 앱의 발송 서비스는 다를 수 있습니다. SES, SendGrid나 Mailgun을 쓰는 앱이라면 유효한 DMARC 레코드 예시가 있어도 성공하고 정렬된 인증이 없으면 DMARC가 실패할 수 있습니다.
TrekMail 사용자의 실무 선택:
- 유료 요금제 조건에 맞는 관리형 SMTP를 검토합니다.
- 자체 SMTP의 SPF, DKIM과 DMARC를 함께 관리합니다.
- 도메인이 많으면 관리되는 보고 패턴을 쓰되 정책은 도메인별로 판단합니다.
제시된 Starter 시작 가격은 월 $3.50입니다. 설명된 옵션에는 유료 요금제의 14일 무료 체험과 카드 없는 무료 Nano가 있습니다. 다중 도메인, 공유 공간과 IMAP 이전은 요금제에 따라 달라지므로 현재 조건을 TrekMail 요금에서 확인하세요.
2026년 DMARC 레코드 예시 단계별 적용
2026년에도 DMARC 레코드 예시는 조사와 테스트를 바탕으로 판단합니다. 성급한 reject는 잊은 운영 흐름에 영향을 줄 수 있으며 보고가 전체 발송 목록은 아닙니다.
- 보통 모니터링부터 시작합니다.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - 초기 기준으로 7~14일 동안 보고를 검토할 수 있습니다. 청구, CRM, 지원과 전달을 로그와 테스트로 조사하며 드문 흐름은 더 긴 점검이 필요할 수 있습니다.
- 인증 오류를 수정하고 정렬을 확인합니다. 공급자를 바꾸거나 분리하기 전에 제약을 조사합니다.
- 검증 뒤 quarantine을 검토합니다.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - 조용한 보고만이 아니라 충분한 조사와 복구 계획으로 reject를 판단합니다.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
단계적 접근은 고객 도메인과 브랜드 관리에 도움이 될 수 있습니다. TrekMail은 조건에 따라 공통 환경, 여러 도메인과 공유 공간을 제공할 수 있습니다. IMAP은 지원 메시지를 복사하며 MX 전환과 앱 데이터는 따로 계획합니다.
적합한 DMARC 레코드 예시는 실제 발송원과 정책 목표에 맞습니다. 보고와 조사를 결합하고 정렬을 확인한 뒤 제한 정책을 검토하세요. 위험 관리에 도움이 되지만 배달이나 모든 사칭 방지를 보장하지 않습니다.
TrekMail은 사서함, DNS 안내와 관리형 또는 자체 SMTP를 다중 도메인 환경에 제공할 수 있습니다. 현재 기능, 한도와 비용은 trekmail.net에서 비교하세요. 실제 인증 점검은 계속 필요합니다.
