자동 전달의 DMARC 실패 원인과 점검 가이드

DMARC 실패 문의는 어려운 설정을 마쳤다고 생각한 뒤에 들어오곤 한다. SPF와 DKIM을 게시했고 DMARC 정책도 p=quarantine 또는 p=reject로 바꿨다. 그런데 정상적인 메일이 자동 전달된 뒤 보이지 않는다. 위조나 스팸이 아니라 전달 경로가 인증을 깨뜨렸을 수 있다. 정책은 처리 방식을 요청하지만 최종 수신 서버가 실제 처리를 결정한다.

자동 전달의 DMARC 실패가 어려운 이유가 여기에 있다. 정상 메일이라도 중간 경로를 거치며 전달 상황이 바뀌면 최종 수신자가 원래와 같은 신뢰 신호를 보지 못할 수 있다. SPF와 DKIM을 단순한 설정 항목으로만 이해하면 무작위 오류처럼 보인다. 경로와 인증 도메인을 비교하면 패턴을 파악하고 원인에 맞게 대응할 수 있다.

전체 구성부터 필요하다면 비즈니스 이메일 가이드를 먼저 읽는다. 자동 전달을 사용한다면 이메일 자동 전달 가이드도 함께 참고한다.

DMARC 실패의 정확한 의미

DMARC 실패는 표시 From 도메인과 정렬된 SPF 통과나 정렬된 DKIM 통과가 없었다는 뜻이다. 인증을 통과하는 것만으로는 충분하지 않다. DMARC는 인증 도메인이 선택한 정렬 방식에 따라 수신자에게 보이는 도메인과 일치하는지 확인한다.

DMARC는 SPF와 DKIM 위에서 동작한다. 기존 명세인 RFC 7489에 설명된 기본 원칙에 따르면 다음 중 어느 하나를 충족하면 DMARC를 통과한다.

SPF를 통과하고 인증 도메인이 Header From 도메인과 정렬된다.
DKIM을 통과하고 서명 도메인이 Header From 도메인과 정렬된다.

단순해 보이지만 운영자가 서로 다른 개념을 혼동하면 DMARC 실패를 잘못 해석하기 쉽다.

인증: SPF 또는 DKIM을 통과했는가?
정렬: 통과한 인증 도메인이 Header From 도메인과 정렬되는가?
전달 후 유효성: 중간 경로를 지나도 서명된 데이터가 유효하게 유지되는가?

SPF를 통과해도 DMARC 실패가 발생할 수 있다. DKIM을 통과해도 DMARC 실패가 발생할 수 있다. 통과한 모든 인증 도메인이 표시 도메인과 정렬되지 않았다면 DMARC는 실패한다.

자동 전달에서 DMARC가 자주 실패하는 이유

자동 전달은 경로를 바꾸고 때로는 콘텐츠도 바꾸기 때문에 DMARC 실패를 일으킬 수 있다. SPF는 연결 경로에 의존하고 DKIM은 서명 데이터의 무결성에 의존한다. 전달로 한 인증 경로를 잃고 메시지 수정으로 다른 경로까지 잃을 수 있다.

흔히 볼 수 있는 경로는 다음과 같다.

발신자가 sender.com에서 메일을 보낸다.
중간 사서함이나 게이트웨이가 받는다.
해당 시스템이 Gmail, Outlook 또는 다른 목적지로 자동 전달한다.

최종 수신 서버는 원래 발신 IP가 아니라 전달 서버의 IP를 SMTP 클라이언트로 본다.

이 지점에서 DMARC 실패가 시작될 수 있다.

먼저 영향을 받는 SPF

SPF는 RFC 7208에 정의되어 있다. 연결한 IP가 봉투 발신자 도메인을 대신해 보낼 수 있는지 확인한다.

전달 후 연결 IP는 원래 발신자가 아니라 전달 서버의 IP다. 원래 봉투 도메인이 그 IP를 허용하지 않으면 SPF는 실패한다. SRS로 봉투 발신자를 전달 서버의 도메인으로 바꾸면 해당 도메인의 SPF를 통과할 수 있지만 원래 From 도메인과의 DMARC 정렬이 자동으로 복구되지는 않는다.

원래 경로: sender.com이 IP A에서 발송해 SPF를 통과한다.
전달 경로: 중간 시스템이 IP B에서 보낸다. 수신자는 sender.com을 IP B와 비교하며, 허용되지 않은 IP라면 SPF가 실패한다.

이 SPF 실패만으로 DMARC 실패가 확정되지는 않는다. 유효한 정렬 DKIM이 유지되면 DMARC는 통과한다. 그래서 간접 전달 경로에서는 DKIM을 특히 꼼꼼하게 관리해야 한다.

DKIM이 인증 경로를 유지할 수 있다

RFC 6376에 정의된 DKIM은 선택한 헤더와 본문에 서명한다. 어느 IP가 전달하는지를 검사하지 않으므로 SPF가 실패해도 DMARC 통과 경로를 제공할 수 있다.

다만 다음 조건이 모두 필요하다.

전달 후에도 서명이 유효하다.
d= 도메인이 표시 From 도메인과 정렬된다.

어느 조건이든 빠지고 다른 정렬 인증 경로도 없다면 DMARC 실패가 발생할 수 있다.

전달 시스템의 다음 수정은 서명을 깨뜨릴 수 있다.

제목에 [EXTERNAL] 추가
면책 문구나 법적 고지 푸터 추가
MIME 경계 재작성
줄바꿈 또는 공백 변경

일부 변경은 relaxed DKIM 정규화에서 허용되지만 다른 변경은 그렇지 않다. 영향은 서명된 필드와 실제 수정 내용에 달려 있다. 따라서 전달된 메일의 DMARC 실패가 위조를 증명하지는 않는다. 정상 메일을 구현 과정에서 바꿨는지 먼저 확인한다.

자동 전달 없이도 발생하는 도메인 정렬 문제

DMARC 실패에 자동 전달이 꼭 필요한 것은 아니다. SaaS 발신 서비스가 회사 도메인 대신 자체 도메인으로 인증해도 발생할 수 있다. 메일은 정상이지만 정렬된 SPF나 DKIM이 없으면 DMARC는 실패한다.

운영에서 자주 놓치는 설정 문제다.

예를 들면 다음과 같다.

From: billing@yourcompany.com
Return-Path: bounce.vendor-mail.com
DKIM: d=vendor-mail.com

SPF는 vendor-mail.com에 대해 통과할 수 있고 DKIM도 vendor-mail.com에 대해 통과할 수 있다. 그래도 DMARC 실패가 나타난다. 어느 인증 도메인도 yourcompany.com과 정렬되지 않기 때문이다.

이 경우 사용자 도메인 인증을 구성한다. ESP가 자체 도메인만이 아니라 회사 도메인과 정렬되는 유효한 DKIM으로 서명하도록 설정하는 편이 좋다. 정렬된 봉투 도메인의 SPF 통과도 DMARC 경로가 될 수 있지만 자동 전달로 SPF를 잃을 수 있으므로 DKIM을 함께 점검한다.

별칭에 크게 의존하는 구성을 재검토한다면 도메인 이메일 별칭과 사서함 비교를 읽는다. 불명확한 경로는 인증 문제를 진단하기 어렵게 만든다.

헤더로 DMARC 실패 진단하기

많은 DMARC 실패는 추측보다 헤더를 읽는 편이 빠르게 진단 방향을 알려준다. 신뢰하는 수신 서버가 추가한 Authentication-Results부터 확인한다. 같은 이름의 임의 헤더를 그대로 믿지 말고 SPF, DKIM, 정렬에 사용하는 도메인을 비교한다.

수신자에게 전체 헤더를 요청하고 다음과 같은 결과를 찾는다.

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

SPF는 실패했지만 DKIM과 DMARC는 통과했다. 자동 전달이 원인일 수 있으나 이 결과만으로 경로를 확정할 수는 없다. 이 검사에서는 DMARC 문제가 없으며 다른 전달 문제는 별도로 평가한다.

다음 결과는 추가 확인이 필요하다.

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

자동 전달에 따른 DMARC 실패일 수 있다. 경로 변경이 SPF 실패를 설명할 수 있지만 DKIM은 콘텐츠 수정, 유효하지 않은 서명, 키 게시 오류나 원래 인증 상태까지 확인한다. 헤더만으로 다른 원인을 배제하지 않는다.

헤더 결과	흔한 의미	조치
`spf=fail`, `dkim=pass`, `dmarc=pass`	정상 자동 전달에서도 나타날 수 있음	이 결과의 DMARC 수정은 불필요하며 모니터링 유지
`spf=fail`, `dkim=fail`, `dmarc=fail`	전달과 콘텐츠 수정 또는 잘못된 DKIM 가능성	서명, 키, 정규화, 중간 수정 확인
`dkim=pass`지만 `d=` 도메인이 정렬되지 않음	ESP나 릴레이의 정렬 문제 가능성	사용자 도메인 DKIM 구성 및 SPF 경로 확인
`spf=permerror`	복잡하거나 중복되거나 잘못된 SPF 가능성	문법과 불필요한 include 정리, 적절한 하위 도메인 사용, flattening 유지 관리
`arc=pass`	ARC 체인이 검증됨; 신뢰 여부는 수신자가 별도 판단	중간 시스템과 최종 수신 판단을 함께 평가

자동 전달의 DMARC 실패를 줄이는 방법

수신자가 메일을 전달하지 못하게 할 수는 없다. 전달을 고려해 유효한 정렬 DKIM, 관리 가능한 SPF, 서명 데이터를 최대한 보존하는 경로를 구성하면 DMARC 실패를 줄이는 데 도움이 된다. 모든 중간 시스템이나 수신자의 처리까지 보장할 수는 없다.

1. 모든 발신 흐름에서 DKIM을 관리한다

정상 메일이 전달 후에도 인증을 유지하도록 하려면 모든 발신 흐름에 서명한다. 뉴스레터나 지원뿐 아니라 청구, 앱 알림과 다른 서비스도 확인한다. DKIM은 중요한 경로지만 직접 발송은 정렬된 SPF로도 DMARC를 통과할 수 있다.

서명 도메인은 표시 From 도메인과 정렬되어야 한다. From이 yourdomain.com이면 yourdomain.com이나 선택한 모드에서 정렬되는 하위 도메인으로 서명한다. relaxed 정렬은 조직 도메인을 기준으로 하며 strict 정렬은 정확한 도메인 일치가 필요하다.

TrekMail에서는 필수 DNS 레코드부터 확인한다. DNS 상태 경고를 조사한 뒤 복잡한 전달 경로를 테스트한다. 상태 표시의 색만으로 실제 전달을 증명하지는 못한다.

2. 적절한 relaxed DKIM 정규화를 사용한다

simple 정규화는 일부 작은 형식 변경에도 민감하다. relaxed 정규화는 허용되는 헤더 및 공백 정규화를 흡수해 일부 DMARC 실패를 피하는 데 도움이 된다. 콘텐츠 변경을 전반적으로 안전하게 만들지는 않는다.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; h=from:to:subject:date:message-id; ...

본문에 푸터를 추가하면 여전히 서명이 깨질 수 있다. relaxed는 규칙이 정규화하는 변경만 처리하므로 실제 중간 경로에서 테스트한다.

3. 외부 공급자의 도메인 정렬을 확인한다

CRM, 헬프데스크나 뉴스레터 도구가 d=vendor.com으로 서명한다면 다른 유효한 정렬 DKIM이나 SPF 통과 경로가 있는지 확인한다. 그런 경로가 없으면 자동 전달 전에도 DMARC 실패가 발생할 수 있다. 적절한 사용자 도메인 인증을 설정한다. 사용자 return-path와 DKIM은 역할이 다르며 DMARC가 항상 둘 다 요구하지는 않는다. 다만 SPF에만 의존하면 전달에서 문제가 생길 수 있다.

4. SPF를 평가 제한 안에 유지한다

SPF는 자동 전달뿐 아니라 오래된 서비스와 중첩 include가 쌓여도 실패할 수 있다. RFC 7208은 평가 과정에서 DNS 조회를 일으키는 메커니즘과 수정자를 10개로 제한하며 관련 중첩 경로도 포함한다. 이 제한을 넘으면 permerror가 발생해 SPF가 DMARC 통과 경로가 될 수 없다.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

Google, Microsoft, Mailgun, SendGrid, Zendesk와 오래된 호스트가 한 레코드에 있다면 실제 사용 중인 서비스를 파악한다. 필요 없는 항목을 없애고 적절한 경우 하위 도메인을 사용한다. flattening은 공급자 IP 변경에 따른 유지 관리가 필요할 수 있다.

5. SRS와 ARC의 역할과 한계를 이해한다

SRS는 봉투 발신자를 바꾸어 전달 서버 도메인의 SPF 통과를 가능하게 하지만 원래 From 도메인과의 정렬을 자동으로 복구하지 않는다. ARC는 앞선 단계의 인증 결과를 검증 가능한 체인에 담을 수 있다. 최종 수신자가 중간 시스템을 신뢰하면 이를 판단에 참고할 수 있다. 둘 다 올바른 DKIM을 대신하거나 DMARC 통과와 전달을 보장하지 않는다.

Google의 현재 지침은 직접 메일과 전달 메일을 구분하고 전달 서비스의 ARC 사용을 권고한다. 그렇다고 전달에서 DMARC 정렬의 기술적 조건이 없어지는 것은 아니다. 2025년과 2026년에도 간접 전달은 중요한 점검 대상이므로 공급자의 최신 적용 범위를 확인한다.

전달 사서함이 많다면 플랫폼 기능과 실제 경로를 평가한다. 현재 안내상 TrekMail은 사서함 전달과 DNS 구성을 지원한다. 자체 SMTP 사용 문서에서 정렬 책임을 확인하고 선택한 조합을 테스트한다.

여러 도메인을 관리하는 기존 방식과 새로운 방식

DMARC 실패에 도구를 계속 추가하면 어느 시스템이 무엇을 서명하는지 불명확해질 수 있다. 더 나은 방식은 사서함 호스팅, 발신, DNS 상태를 구분해 문제를 보이게 만드는 것이다. 다음 비교는 운영 선택지이며 요금 방식마다 반드시 생기는 단점은 아니다.

기존 방식	새 방식
사용자별 요금 때문에 복잡한 별칭과 전달에 의존할 수 있음	정액 다중 도메인 모델에서 조건에 맞는 실제 사서함 구성 가능
모든 서비스가 들어간 거대한 SPF	정리된 DNS, 적은 include, 필요한 하위 도메인
ESP가 공급자 도메인으로만 서명	모든 정상 발신 흐름에 적절한 정렬 인증 경로 구성
사용자 불만 뒤에야 문제 발견	DNS 점검으로 구성 문제를 더 일찍 확인할 수 있음
수동 내보내기와 추측에 의존한 사서함 이동	IMAP으로 수동 복사 작업을 줄일 수 있지만 DNS와 인증은 별도 확인

이것이 TrekMail의 실무적인 접근이다. 현재 조건에 따라 여러 도메인의 사서함을 한곳에서 호스팅하고 저장 공간을 공유하며 관리형 SMTP나 자체 공급자를 선택할 수 있다. 운영 모델은 다중 도메인 이메일 호스팅, 사서함 이동은 imapsync를 참고한다.

DMARC 실패 문의가 들어왔을 때

DMARC 실패 문의가 들어왔다고 바로 정책을 reject에서 none으로 되돌리지 않는다. 자동 전달, 잘못된 DKIM, 정렬 실패 중 무엇이 원인인지 먼저 확인한다. 정상 발신자를 파악하고 복구를 테스트하며 필요한 정책 변경은 모니터링과 롤백 계획을 두고 진행한다.

수신자에게 전체 헤더를 요청한다.
연결 IP가 알려진 전달 시스템이어서 SPF가 실패했는지 확인한다.
DKIM 통과 또는 실패 여부와 서명한 d= 도메인을 확인한다.
서명 도메인이 표시 From 도메인과 정렬되는지 확인한다.
신뢰하는 중간 시스템을 지났다면 arc=pass와 체인을 평가한다.
SPF의 과도한 DNS 조회와 오래된 include를 점검한다.

TrekMail에서는 도메인 추가로 레코드를 검토하고, 명확한 반송 없이 메일이 누락된다면 이메일이 수신되지 않을 때를 참고한다. DMARC 보고서도 보완 자료지만 모든 수신자의 데이터를 포함하지는 않는다.

결론: DMARC 실패는 경로와 구성의 점검 대상이다

반복되는 DMARC 실패가 이메일을 고칠 수 없다는 뜻은 아니다. SPF 의존도가 높거나 DKIM이 정렬되지 않거나 유효하지 않을 수 있고 중간 시스템이 메일을 수정할 수도 있다. 다만 조사 없이 위조나 무단 발신을 배제하지는 않는다.

대응은 기본을 정리하는 일이다. 정렬 인증을 구성하고 DKIM 유효성을 유지하며 SPF를 관리하고 자동 전달을 테스트한다. 이런 점검을 지속적인 운영에 포함한다.

현재 안내상 TrekMail은 정액 다중 도메인 호스팅, 공유 저장 공간, IMAP 마이그레이션, catch-all과 유연한 발신을 요금제 조건 안에서 제공한다. IMAP은 사서함 데이터를 옮길 뿐 DNS, 앱, 평판을 옮기거나 무중단을 보장하지 않는다. 유료 요금제는 현재 연간 결제 기준 월 $3.50부터이며 14일 무료 체험이 적용될 수 있다. Nano는 조건에 따라 카드 없이 무료다. 최신 요금이나 TrekMail을 확인한다.

요약하면 자동 전달을 사용한다면 DMARC 실패를 예외로 넘기지 말고 테스트 계획에 넣는다. 검증한 경로와 명확한 책임은 메일 운영을 더 안정적으로 만들 수 있지만 전달을 보장하지는 않는다.