DMARC 실패 이해와 원인 조사 체크리스트

DMARC fail은 성공하고 From과 정렬된 인증이 없다는 뜻입니다. p=reject는 거부를, p=quarantine은 의심스러운 처리를 요청합니다. 수신 측 예외가 가능하며 특정 스팸 폴더로 이동한다는 보장은 없습니다. 구성과 다른 배달 원인도 조사하세요. 전체 환경은 소규모 기업의 업무용 이메일을 참고하세요.

정렬 오류, 전달 후 SPF 실패, 누락되거나 유효하지 않은 DKIM, SPF 평가 오류가 반복됩니다. 신뢰하는 수신 헤더를 읽고 도메인을 비교해 확인된 원인을 수정하세요.

이 글은 진단 표, 조사 절차와 설정 예시를 제공합니다. 하나의 DNS 변경으로 모든 실패가 해결되지는 않습니다.

DMARC fail의 정확한 의미

SPF와 DKIM 어느 쪽도 인증 성공과 보이는 From 정렬을 함께 충족하지 못한 상태입니다. 정렬 없는 개별 인증 성공만으로는 부족합니다.

SPF 또는 DKIM이 성공하고 동시에 RFC5322 From과 정렬되어야 통과합니다. RFC 7489의 규칙이며 콘텐츠의 안전성을 증명하지는 않습니다.

상황	SPF	DKIM	DMARC	의미	확인 사항
두 인증 모두 실패	Fail	Fail	Fail	구성 오류, 경로 변경 또는 승인되지 않은 발송 가능	발송원, IP, DNS와 서명 조사
정렬 문제	Pass, unaligned	Pass, unaligned	Fail	인증이 From 도메인과 정렬되지 않음	적절한 return-path와 도메인 DKIM 구성 테스트
전달 메일	Fail	Pass, aligned	Pass	서명이 보존된 경로에서 가능	유효하고 정렬된 DKIM과 실제 경로 확인
전달과 메시지 변경	Fail	Fail	Fail	목록이나 릴레이 변경이 원인일 수 있음	조사; ARC는 수신 측 판단을 돕지만 DMARC 인증 성공을 만들지는 않음
SPF PermError	PermError	Fail or none	Fail	평가 한도나 구성 오류 가능	평가를 확인하고 적합한 실제 봉투 도메인 분리 검토

단계 1: 정렬부터 확인

공급자가 자신의 도메인을 인증했어도 귀사의 From과 정렬되지 않을 수 있습니다. 성공 여부만이 아니라 인증 도메인을 확인하세요.

예시:

Header From: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

spf=pass와 dkim=pass가 있어도 vendor.net이 yourdomain.com과 정렬되지 않고 다른 정렬된 성공도 없다면 DMARC가 실패합니다.

마케팅, CRM, 지원과 보조 SMTP의 도메인 인증, 사용자 지정 Return-Path·반송 도메인과 DKIM을 확인하세요. 링크 브랜딩이나 추적 도메인이 자동으로 봉투 도메인을 바꾸지는 않습니다.

설명용 DNS 예시입니다. 실제 공급자 값으로 구성하고 활성화와 테스트까지 진행하세요.

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

TrekMail은 도메인 구성 정보를 정리하는 데 도움이 될 수 있습니다. 도메인 추가와 필수 DNS 레코드를 참고하세요. 실제 봉투 도메인에 SPF 하나를 사용하고 모든 서비스를 무조건 같은 레코드에 넣지는 마세요.

단계 2: 수신 헤더 조사

메시지 원본에서 Authentication-Results, Return-Path와 DKIM d=를 찾습니다. 신뢰하는 수신 인프라가 추가한 결과만 사용하고 임의의 첨부 헤더는 신뢰하지 마세요.

조사 순서:

보이는 From 도메인 확인
SPF 결과 확인
SPF가 평가한 봉투 도메인 확인
DKIM 결과 확인
평가한 유효한 서명의 d= 확인
설정한 모드에 따라 From과 비교

설명용 실패 헤더:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

다음처럼 해석합니다.

SPF는 sendgrid.net 아래의 반송 도메인에 대해 성공합니다. sendgrid.net의 header.i만으로 서명 도메인을 증명할 수는 없으므로 d=를 확인하세요. From은 yourdomain.com입니다. 여기서 DMARC 실패는 정렬된 인증 성공이 없음을 뜻합니다.

트랜잭션, 마케팅, 지원과 별칭은 경로가 다를 수 있으므로 각각 확인하세요. 내 도메인에 이메일 설정하기도 참고합니다.

단계 3: 전달을 별도로 조사

전달은 연결 IP를 바꾸어 원래 SPF가 실패할 수 있습니다. 유효하고 정렬된 DKIM과 정규화된 서명 데이터가 보존되면 DMARC는 통과할 수 있습니다.

Google Groups, Outlook이나 학교 전달 경로의 SPF 실패만으로 판단하지 마세요. DKIM이 유효하고 정렬되면 통과할 수 있으므로 실제 경로를 테스트합니다.

RFC 7960은 원래 봉투 발신자를 유지하는 경우와 바꾸는 경우를 설명합니다. 유지하면 SPF가 실패할 수 있고 SRS 등으로 바꿔도 원래 From 정렬이 자동으로 생기지는 않습니다. RFC 7960을 참고하세요.

임의의 SPF 승인을 더하는 것이 일반 해결책은 아닙니다. 다음을 검토하세요.

지원 발송원에 DKIM을 구성하고 테스트합니다.
조직 도메인의 완화 정렬을 검토하며 명확한 필요가 있을 때 엄격 모드를 선택합니다.
서명을 깨는 목록 변경을 조사합니다. ARC는 수신 측 예외에 도움이 될 수 있지만 DMARC 성공을 보장하지 않습니다.

이메일 전달과 도메인 이메일을 Gmail로 전달하기도 읽어 보세요. TrekMail은 요금제에 따라 전달과 관리형 SMTP를 제공할 수 있지만 모든 경로를 확인해야 합니다.

단계 4: SPF PermError 조사

SPF PermError는 중첩 평가를 포함해 DNS 조회를 유발하는 메커니즘과 수정자의 열 개 한도나 잘못된 설정에서 발생할 수 있습니다. 전체 DNS 패킷 수를 뜻하지 않습니다. 유효하고 정렬된 DKIM이 성공하면 DMARC는 통과할 수 있습니다.

확장된 SPF 예시:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all

보이는 목록만으로 유효성을 판단하지 마세요. 중첩 include와 redirect를 실제 평가 경로에서 확인해야 합니다.

게시한 값을 조회합니다.

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

조회만으로 PermError를 증명할 수는 없습니다. 육 개월 동안 쓰지 않은 공급자도 실제 흐름이 남아 있지 않은지 확인한 뒤 제거합니다. 적합하다면 분리를 검토합니다.

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

별도 SPF 예산은 활성 공급자 구성에서 실제 사용하는 봉투 도메인에 적용됩니다. 하위 도메인 DNS 게시만으로 발송 경로가 바뀌지 않습니다. 변경 뒤 승인과 From 정렬을 테스트하세요.

TrekMail의 DNS 상태 확인은 중복 SPF와 레코드 점검을 다룹니다.

단계 5: 악용 가능성 조사

모든 DMARC 실패에 DNS 수정이 필요한 것은 아닙니다. 승인되지 않은 발송일 수도 정상 경로의 오류일 수도 있으므로 실패를 사칭으로 단정하지 마세요.

알 수 없는 IP의 SPF·DKIM 실패는 조사 대상이며 무조건 허용하거나 차단할 근거는 아닙니다. 발송원, 릴레이와 전달을 확인하세요. p=quarantine과 p=reject는 실패 시 처리를 요청하지만 수신 측 판단이 가능합니다.

증거를 바탕으로 판단합니다.

모르는 IP와 공급자를 목록, 로그와 테스트로 조사합니다.
정상 메일의 실제 공급자와 도메인 인증을 확인합니다.
지원되지만 누락된 DKIM을 활성화하고 테스트합니다.
도구 교체나 하위 도메인 이동 전에 제약을 조사하고 실제 봉투 도메인과 정렬을 테스트합니다.

해당 제한 정책이 적용되면 의도와 관계없이 자체 오류도 영향을 받습니다. 수신 측 예외는 가능합니다. Google 발신자 인증 가이드를 참고하세요.

발송원별 흔한 패턴

시스템 유형은 조사 방향을 잡는 단서이며 원인을 확정하지는 않습니다.

발송원	가능한 원인	확인과 수정
마케팅 플랫폼	정렬되지 않은 DKIM이나 반송 도메인	DKIM과 사용자 지정 Return-Path 활성화 및 테스트
지원 또는 CRM	공급자 인증 도메인	도메인 인증 완료와 점검
사서함 전달	릴레이 뒤 SPF 실패	유효하고 정렬된 DKIM과 서명 데이터 보존 확인
메일링 리스트	경로와 메시지 변경	조사; ARC는 수신 측 판단에 도움 가능
소규모 기업의 혼합 구성	SPF 평가나 불완전한 DNS	발송원을 조사하고 실제 봉투 도메인 분리 검토
다중 도메인 대행사	일관되지 않은 구성	도메인별 설정과 테스트 표준화

여러 도메인의 DMARC 실패 관리

고객마다 Google Workspace, cPanel, SendGrid나 Gmail 전달을 쓰면 각자의 현재 구성을 확인해야 합니다. 불명확한 DNS는 반복 조사에 부담을 더합니다.

공통 환경이 도메인 상태, 전달, SMTP와 인증을 정리하는 데 도움이 될 수 있습니다. 대시보드가 모든 실제 결과의 증명은 아닙니다.

제시된 TrekMail 유료 시작 가격은 월 $3.50이며 14일 무료 체험과 자체 SMTP를 쓰는 무료 옵션이 설명됩니다. 자체 도메인, IMAP 사서함, catch-all, 전달, IMAP 이전, API와 설정 안내는 현재 요금제 조건에 따라 다릅니다. IMAP은 지원 메시지를 복사하며 MX와 앱 데이터는 별도 작업입니다.

고객 도메인이 많다면 다중 도메인 이메일 호스팅을 읽고 운영 과정과 실제 비용을 비교하세요.

짧은 조사 체크리스트

구체적인 메시지에서 신뢰하는 결과를 확인하고 인증 도메인을 From과 비교한 뒤 확인된 문제를 수정합니다.

메시지의 신뢰하는 Authentication-Results 확인
SPF 결과와 봉투 도메인 확인
DKIM 결과와 유효한 d= 도메인 확인
Header From과 비교
성공한 방식이 정렬되지 않으면 정렬 수정
전달의 유효하고 정렬된 DKIM과 서명 데이터 보존 테스트
SPF 평가와 실제 봉투 도메인 분리 조사
모르는 발송원을 로그와 테스트로 조사하며 실패만으로 사칭 단정 금지

구체적인 순서로 근거 있는 변경을 선택하세요.

결론: 확인한 원인을 수정하기

DMARC fail은 정렬 오류, 전달에서 보존되지 않은 유효한 DKIM, SPF PermError나 승인되지 않은 발송에서 생길 수 있습니다. 실패만으로 악용이나 배달 결과를 확정하지는 못합니다.

임의의 레코드 대신 조사한 원인을 수정하세요. TrekMail은 요금제에 따라 공유 공간, 다중 도메인, Nano의 자체 SMTP, 관리형 SMTP와 IMAP 이전을 제공할 수 있습니다. TrekMail이나 https://trekmail.net/pricing에서 현재 기능과 요금을 확인하고 드문 정상 발송도 계속 테스트하세요.