DMARC 설정은 자체 도메인으로 메일을 운영할 때 필요한 기본 관리 작업입니다. 도메인을 직접 사칭하는 메일의 위험을 줄이는 데 도움이 되지만, 모든 사칭이나 스팸함 분류를 막아 주지는 않습니다. 청구서나 Gmail 수신 문제가 생겼다면 발송 환경 전체를 함께 점검해야 합니다.
사서함 하나를 운영하든 여러 고객 도메인을 관리하든 원칙은 같습니다. 업무용 메일 환경을 구성하는 중이라면 소규모 기업을 위한 업무용 이메일부터 읽고 DNS와 인증 설정을 점검하세요.
절차는 복잡하지 않지만 정책을 성급하게 적용하면 정상 메일이 차단될 수 있습니다. SPF, DKIM, 전달 경로, 외부 발송 서비스가 함께 쓰일 때 특히 주의해야 합니다. 이 글에서는 초기 레코드, 주요 태그, 정책 강화 시점과 흔한 오류를 다룹니다.
DMARC 설정이 하는 일
DMARC는 _dmarc.yourdomain.com에 TXT 레코드를 게시해 인증 요건을 충족하지 못한 메일에 대한 처리를 수신 서버에 요청합니다. 통과하려면 SPF 또는 DKIM이 성공하고, 성공한 인증에 사용된 도메인이 화면에 보이는 From 도메인과 정렬되어야 합니다.
DMARC는 SPF나 DKIM을 대체하지 않습니다. RFC 7489에 따르면 성공한 SPF나 DKIM 중 하나가 From 헤더 도메인과 정렬되면 통과할 수 있습니다. 인증 성공만으로는 충분하지 않습니다.
Google은 일반 발신자에게 SPF 또는 DKIM을 요구하며, 대량 발신자에게는 두 방식과 DMARC 등 추가 요건을 적용합니다. 해당 요건과 정렬 조건은 이메일 발신자 가이드라인에서 확인하세요.
즉, DMARC는 도메인 인증 결과와 실패 시 원하는 처리를 전달합니다. 콘텐츠의 안전성을 증명하지 않으며, 최종 수락과 필터링은 수신 측 정책에 따라 달라집니다.
처음 게시할 DNS 레코드
보통 p=none으로 시작해 발송원을 조사하고 보고서를 검토한 뒤 정책 적용을 강화합니다. 이 설정은 DMARC에 따른 제한을 요청하지 않지만 수신 측의 독립적인 필터링까지 해제하지는 않습니다. 발송 흐름을 모른 채 reject를 적용하면 비밀번호 재설정, 청구서, 문의 양식 메일에 문제가 생길 수 있습니다.
다음 예시는 호스트 _dmarc에 게시합니다. 선택 사항인 엄격한 정렬을 사용하므로 모든 환경의 기본값으로 적합한 것은 아닙니다.
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100환경에 완화된 정렬이 적합하다면 adkim=s와 aspf=s를 바꿀 수 있습니다. 다음 레코드는 앞의 예시를 대신하는 것으로, 함께 게시하지 않습니다.
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100완화된 정렬은 동일한 조직 도메인에 속한 식별자를 허용합니다. 아무 상위 도메인과 하위 도메인 관계나 허용한다는 뜻은 아닙니다. 실제 발송 도메인의 조직 도메인을 확인하세요.
TrekMail 도메인 대시보드는 레코드 존재 여부와 설정 점검에 도움이 될 수 있습니다. 필수 DNS 레코드, 도메인 추가, DNS 상태 확인을 참고하세요. 문서의 p=quarantine 예시가 아직 조사하지 않은 운영 도메인에도 적합하다는 뜻은 아닙니다. 처음에는 모니터링으로 실제 흐름을 확인하는 편이 일반적으로 적절합니다.
주요 DMARC 태그
처음에는 정책, 보고, 정렬에 집중하세요. 추가 옵션은 실제 발송원에 미치는 영향을 이해한 뒤 사용하는 것이 좋습니다.
| 태그 | 역할 | 실무상 선택 |
|---|---|---|
v | 프로토콜 버전 | DMARC1 |
p | DMARC 실패 시 요청할 처리 | none부터 시작해 필요하면 quarantine, reject 검토 |
rua | 집계 보고서 수신 주소 | 관리 담당자가 확인하는 수신처 |
adkim | DKIM 정렬 방식 | 환경에 맞는 r 또는 s |
aspf | SPF 정렬 방식 | 환경에 맞는 r 또는 s |
pct | 실패 메일에 정책을 적용하도록 요청하는 비율 | 100; 실제 적용은 수신 측에 따라 다름 |
sp | 상속되는 하위 도메인 정책 | 다른 정책이 필요할 때 설정 |
p는 원하는 처리를 명시하고 rua는 집계 보고서를 요청합니다. 보고서는 참여 수신자에 한정되며 완전한 발송원 목록이 아닙니다. 로그와 실제 발송 테스트로 보완하고, 외부 보고 주소의 DNS 승인 및 개인정보 보호 요건도 확인하세요.
pct는 RFC 7489에서 단계적인 정책 적용을 위해 설명한 옵션입니다. 다만 수신자마다 지원과 적용 방식이 다를 수 있습니다. 100을 none과 함께 사용해도 제한 정책이 되지는 않습니다. 비율은 처리 요청이지 실제 트래픽 분배를 보장하는 값이 아닙니다.
DMARC 설정 순서
SPF와 DKIM을 확인하고 모니터링 레코드를 게시한 뒤 보고서와 실제 메일을 검토하세요. 그 결과를 바탕으로 정책 강화를 판단합니다.
- 메일 호스팅, CRM, 청구 도구, 헬프데스크, 양식 플러그인, 마케팅 플랫폼 등 도메인을 사용하는 발송원을 조사합니다.
- 실제 봉투 발신자 도메인과 승인된 발송원에 맞춰 SPF를 확인합니다. 모든 서비스를 무조건 같은 레코드에 추가하지 않습니다.
- 지원되는 발송원에 DKIM을 설정하고 서명 유효성과 정렬을 테스트합니다. 전달 경로도 확인합니다.
p=none으로 초기 모니터링 레코드를 게시합니다.- 초기 점검 기준으로 2~4주 동안 보고서를 검토합니다. 드물거나 주기적인 발송은 더 긴 관찰이나 별도 테스트가 필요할 수 있습니다.
- 정상 흐름과 위험을 검토한 뒤
p=quarantine을 고려합니다. - 발송원 확인, 테스트, 복구 준비가 충분할 때
p=reject를 고려합니다.
유용한 명령줄 확인:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT dkim._domainkey.example.com +short다음 설정은 설명용 예시입니다. 실제 발송원에 필요한 SPF 승인만 사용하고, 올바른 셀렉터와 완전한 DKIM 공개 키로 교체하세요. 생략된 키 문자열은 사용할 수 없습니다.
; SPF
example.com. IN TXT "v=spf1 include:spf.trekmail.net include:_spf.google.com -all"
; DKIM
dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
; DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"처음 구성한다면 자체 도메인 이메일 만들기도 참고하세요. 다른 호스트에서 이전한다면 TrekMail의 IMAP 이전 개요에서 지원되는 사서함 데이터 복사 범위를 확인할 수 있습니다. 데이터 복사는 MX 전환이나 발신 인증 설정을 대신하지 않으며, DMARC는 발신 인증과 도메인 정렬을 평가합니다.
DMARC 통과와 실패
SPF 또는 DKIM이 성공하고 From 도메인과 정렬되면 DMARC가 통과합니다. 어느 방식도 두 조건을 함께 충족하지 못하면 실패합니다. 따라서 정렬되지 않은 인증 성공만으로는 통과할 수 없습니다.
아래 표에서 정렬 여부는 성공한 인증 방식에 대한 정렬을 뜻합니다.
| SPF | DKIM | 정렬 여부 | DMARC 결과 |
|---|---|---|---|
| Pass | Fail | 예 | Pass |
| Fail | Pass | 예 | Pass |
| Pass | Pass | 아니요 | Fail |
| Fail | Fail | 아니요 | Fail |
전달은 대표적인 사례입니다. 연결 서버가 달라지면 원래 SPF가 실패할 수 있습니다. DKIM은 서명된 데이터가 정규화 규칙에 따라 보존되고 유효한 서명이 정렬되어 있을 때 도움이 됩니다. 실제 전달 경로에서 이를 확인해야 합니다.
billing@example.com으로 보낸 메일을 고객이 Gmail로 전달합니다. 서버 경로가 달라져 SPF가 실패할 수 있지만,d=example.com의 서명이 유효하고 정렬 조건을 충족하면 DMARC는 통과할 수 있습니다.
모든 SPF 실패를 같은 문제로 취급하지 마세요. 유효하고 정렬된 DKIM이 있다면 전달 메일의 DMARC가 통과할 수 있습니다. 다만 정렬 여부를 확인하지 않은 DKIM 성공만으로 판단해서는 안 됩니다.
전달 기능을 사용한다면 이메일 전달도 읽어 보세요. SRS와 ARC는 조건에 따라 도움이 될 수 있지만 DMARC 통과나 배달을 보장하지는 않습니다.
none에서 quarantine, reject로 전환하기
단계적으로 적용하면 영향과 숨은 설정 오류를 살펴보기 쉽습니다. 정책 강화는 도메인 사칭 위험을 줄일 수 있지만 정상 메일에도 영향을 줄 수 있으며, 수신 측은 자체 판단을 유지합니다.
주요 정책 선택지는 다음과 같습니다.
p=none: DMARC 제한을 요청하지 않고 가능한 보고와 로그로 흐름을 조사합니다.p=quarantine: 의심스러운 메일로 취급하도록 요청합니다. 특정 스팸 폴더로의 이동은 보장되지 않습니다.p=reject: 거부를 요청하지만 수신 측의 예외 처리에 따라 달라질 수 있습니다.
다음 단계는 서로 대체하는 예시입니다. 정책은 하나씩 게시하며 예시 주석은 실제 TXT 값에 넣지 않습니다.
; Phase 1
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100
; Phase 2
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100
; Phase 3
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100sp=는 상속되는 하위 도메인 정책을 따로 지정합니다. RFC 7489에 따른 조직 도메인 정책 조회에서 sp가 없으면 기본 정책이 적용됩니다. 해당 하위 도메인의 자체 DMARC 레코드가 있으면 그것이 우선할 수 있으므로 실제 정책 조회 경로를 확인하세요.
흔한 DMARC 설정 오류
실제 원인은 SPF 승인 누락, 유효하지 않은 DKIM, 잘못된 DNS 호스트명, 외부 도구의 From 설정인 경우가 많습니다. 증상만 바꾸지 말고 확인된 원인을 수정하세요.
| 오류 | 가능한 결과 | 해결 방법 |
|---|---|---|
| DKIM을 테스트하지 않고 제한 정책 적용 | 다른 정렬된 인증도 없다면 전달 메일이 실패할 수 있음; none 게시 자체가 원인은 아님 | DKIM 설정 후 실제 경로 테스트 |
| 여러 SPF 레코드 사용 | SPF PermError 발생 | 한 레코드로 정리하고 평가 한도 준수 |
| 잘못된 DMARC 호스트 | 원하는 정책을 찾지 못함 | 도메인 루트가 아닌 _dmarc에 게시 |
| 너무 이른 reject 적용 | 정상 메일이 거부될 수 있음 | p=none과 대표 흐름 점검부터 시작 |
| 정렬 무시 | SPF 또는 DKIM이 성공해도 DMARC 실패 가능 | 성공한 인증 도메인을 From과 정렬 |
| 보고서 수신처 없음 | 요청한 집계 보고가 없지만 자체 로그 등은 사용 가능 | 작동하는 rua 주소 추가 |
별칭 메일이 자신의 도메인 대신 공급자 도메인으로 서명되면 DKIM이 성공해도 정렬되지 않을 수 있습니다. 다만 정렬된 SPF가 성공하면 DMARC는 통과할 수 있습니다. 도메인 이메일 별칭과 사서함 비교도 참고하세요.
TrekMail의 DNS 상태 화면은 설정 문제를 찾는 데 도움이 될 수 있습니다. 경고 세부 정보를 확인하고 실제 메일도 테스트하세요. 대시보드 상태만으로 모든 발신 인증이나 배달을 확인할 수는 없습니다.
TrekMail로 관리 작업 정리하기
호스팅, 전달 규칙, 서로 다른 세 SMTP 공급자가 섞이면 발송 흐름을 조사하기 어려워집니다. TrekMail은 도메인, 사서함, DNS 점검, 전달과 이전 작업을 한 관리 환경에 모으는 데 도움이 될 수 있습니다.
| 분산된 운영 방식 | TrekMail의 관련 기능 |
|---|---|
| 도메인별 도구의 사용자 단위 과금 | 리소스 한도 내에서 여러 도메인을 지원하는 요금제 |
| 사서함마다 나뉜 저장 공간 | 해당 요금제의 공유 저장 공간; 다른 서비스도 제공할 수 있음 |
| 수동 DNS 조사 | SPF, DKIM, DMARC 점검과 설정 안내 |
| 수동 메일 이전 | 지원 데이터와 권한 범위의 서버 측 IMAP 복사; 전환은 별도 계획 필요 |
| 전달 경로의 불명확한 인증 | 표준과 실제 테스트를 바탕으로 구성할 전달 도구 |
개인 운영자에게도 유용할 수 있지만 고객 도메인이 쉰 개라면 관리 과정의 일관성이 더 중요해집니다. 비용이나 지원 요청이 줄어드는지는 실제 운영 방식에 달려 있습니다.
여기에 소개된 Starter 시작 가격은 월 $3.50입니다. Nano는 카드 없이 무료로 이용하며 자체 SMTP를 쓰는 최대 10개 도메인을 지원하는 옵션으로 설명됩니다. 유료 요금제는 조건에 따라 관리형 SMTP와 14일 무료 체험을 제공할 수 있으며, 이 체험에는 신용카드가 필요합니다. 현재 가격, 기능과 조건은 TrekMail 요금에서 확인하세요.
최종 DMARC 설정 체크리스트
TXT 게시만으로 끝나지 않습니다. 성공하고 정렬된 인증, 발송원 조사, 가능한 보고와 로그, 통제된 정책 변경이 필요합니다. 이는 직접적인 도메인 사칭 위험을 줄이는 데 도움이 될 수 있지만 안전한 콘텐츠나 배달을 보장하지 않습니다.
- 도메인을 사용하는 모든 발송원을 확인합니다.
- 관련 봉투 도메인마다 SPF 레코드를 하나만 유지합니다. 중첩 평가를 포함해 DNS 조회를 유발하는 메커니즘과 수정자의 열 개 한도를 지킵니다.
- 지원되는 곳에 DKIM을 설정하고 테스트합니다.
- 보통 모니터링 레코드부터 게시합니다.
- 초기 기준으로 2~4주 동안 집계 보고서를 검토하고 월별, 분기별 또는 드문 흐름도 테스트합니다.
- 정상 흐름을 조사한 뒤 quarantine을 검토합니다.
- 충분한 테스트, 모니터링과 복구 계획을 갖춘 뒤 reject를 검토합니다.
일회성 체크가 아니라 지속적으로 관리할 절차입니다.
TrekMail은 요금제에 따라 여러 도메인, 공유 저장 공간, IMAP 이전과 DNS 점검을 제공할 수 있습니다. 무료 옵션과 현재 조건은 trekmail.net에서 확인하세요. 관리형 발송이 필요하면 요금제를 살펴보세요.
목표는 도메인 사칭과 정상 메일의 불필요한 거부 위험을 관리하는 것입니다. DMARC는 이를 지원하지만 다른 메일 운영 점검을 대신하지 않습니다.
