DMARC 정렬 이해와 인증 오류 점검 가이드

DMARC 정렬은 SPF, DKIM과 DMARC를 게시한 뒤에도 놓치기 쉽습니다. 메일이 스팸으로 분류되거나 거부된다면 정렬을 확인하되 다른 원인도 조사해야 합니다. 전체 환경은 업무용 이메일 가이드도 참고하세요.

인증 성공만으로는 부족합니다. 성공한 SPF 또는 DKIM 도메인이 보이는 From과 정렬되어야 합니다. 어느 방식도 성공과 정렬을 함께 충족하지 못하면 DMARC가 실패하지만 사칭의 증명은 아닙니다. 외부 서비스, CRM, 지원 도구, 전달과 불완전한 설정도 원인이 될 수 있습니다.

이 글은 정렬의 원리, SPF의 한계, 관련 헤더와 실제 발송·전달 경로를 점검하는 방법을 설명합니다.

DMARC 정렬이란?

SPF 또는 DKIM으로 인증한 도메인을 보이는 From과 비교합니다. SPF가 성공하고 정렬되거나 DKIM이 성공하고 정렬되면 DMARC가 통과합니다. 하나의 정렬된 성공이면 충분하며 그런 성공이 없으면 실패합니다.

RFC 7489의 규칙입니다. DMARC는 자체 인증을 대신 수행하지 않고 성공한 인증을 수신자가 보는 도메인과 연결합니다.

확인 대상:

검사	수신 측 확인 사항	DMARC 정렬 조건
SPF	봉투 발신자 / Return-Path 도메인의 IP 승인	Return-Path 도메인과 From 정렬
DKIM	유효한 서명의 d= 도메인	d= 도메인과 From 정렬
DMARC	인증 및 정책 평가	위 방식 중 하나 이상이 성공하고 정렬됨

SPF나 DKIM 성공만으로는 부족하며 성공한 방식의 정렬이 필요합니다.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

SPF 성공에도 정렬이 안 되는 이유

Return-Path가 공급자 도메인이면 IP가 승인되어 SPF가 성공해도 자체 From과 정렬되지 않을 수 있습니다. SendGrid, Mailchimp, HubSpot이나 Shopify 구성에서 가능하지만 정렬된 DKIM이 성공하면 DMARC는 통과할 수 있습니다.

공급자는 반송 처리, 발송 제외 목록과 추적을 운영하므로 일부 구성에서 자신의 Return-Path를 사용합니다.

보이는 From: billing@example.com
Return-Path: bounces+123@sendgrid.net

sendgrid.net의 IP 승인으로 SPF는 성공할 수 있습니다. 하지만 sendgrid.net은 example.com과 정렬되지 않습니다.

SPF 정렬에는 지원되는 사용자 지정 반송 도메인이나 Return-Path가 필요합니다. 링크 브랜딩과 추적 도메인이 자동으로 같은 기능인 것은 아니므로 실제 봉투 발신자를 확인하세요.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

공급자 활성화와 테스트 뒤 봉투 도메인이 bounces.example.com이면 완화 모드에서 example.com과 정렬됩니다. CNAME 게시만으로 사용이 활성화되었다고 볼 수는 없습니다.

전달에서는 연결 서버가 바뀌어 원래 SPF가 실패할 수 있습니다. 도메인 메일을 Gmail로 전달하기와 이메일 별칭 전달도 참고하세요. 직접 경로의 SPF가 성공하고 정렬되면 충분할 수 있지만 다른 경로는 별도 테스트가 필요합니다.

DKIM 정렬이 중요한 이유

DKIM은 전달 경로에서도 유효하고 정렬된 서명과 정규화 규칙에 따른 서명 데이터가 유지될 때 도움이 됩니다. 모든 전달이 이를 보존하는 것은 아닙니다.

그래서 정렬된 DKIM을 구성하는 것이 좋지만 정렬된 SPF가 성공하면 DMARC 규격상 DKIM이 반드시 필요한 것은 아닙니다. 공급자 서명만으로 자체 도메인의 정렬을 충족하지는 않습니다.

보이는 From: newsletter@example.com
DKIM 서명: d=mailchimpapp.net

DKIM이 성공해도 정렬되지 않을 수 있습니다. 성공하고 정렬된 SPF도 없을 때 DMARC가 실패합니다.

실제 발송 서비스에서 도메인 인증을 활성화하세요. 필요한 DKIM 레코드를 게시한 뒤 공급자가 올바른 서명을 활성화했는지 확인합니다.

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

활성 구성은 d=example.com이나 d=mail.example.com처럼 정렬 가능한 서명을 사용할 수 있습니다. SPF가 실패해도 서명이 유효하고 선택한 정렬 조건을 충족하면 DMARC를 지원합니다.

Google은 대량 발신자에게 관련 인증과 SPF 또는 DKIM을 통한 From 정렬을 요구합니다. 해당 유형의 요건과 실제 결과를 확인하세요. 정렬 오류만으로 모든 제한이나 스팸 분류를 예측할 수는 없습니다.

완화된 정렬과 엄격한 정렬

완화 모드는 같은 조직 도메인을, 엄격 모드는 정확히 같은 도메인을 요구합니다. 기본은 완화 모드지만 실제 발송원과 관리 요건에 맞춰 선택해야 합니다.

DMARC의 aspf와 adkim이 각각 SPF와 DKIM을 제어합니다.

모드	정렬 기준	영향
완화	`mail.example.com`과 `example.com` 정렬	같은 조직 도메인 허용
엄격	정확히 같은 도메인만 허용	정상 하위 도메인도 정렬되지 않을 수 있음

예시:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

엄격 모드에서는 mail.example.com 서명이 From의 example.com과 정렬되지 않습니다. 이는 모드의 조건이며 악성 메일이라는 증거는 아닙니다.

명확한 필요와 충분한 발송원 관리가 있을 때 엄격 모드를 검토하세요. 그 외에는 완화 모드를 검토하되 핵심 경로를 테스트합니다.

DMARC 정렬 문제 조사

수신된 Authentication-Results, DKIM d=, SPF smtp.mailfrom과 header.from의 dmarc를 확인하세요. 신뢰하는 수신 인프라가 추가한 결과만 사용하고 메시지에 포함된 임의의 헤더는 신뢰하지 않습니다.

이 결과는 오류 조사에 도움이 됩니다. 다음 header.i만으로 DKIM 서명 도메인을 증명할 수는 없습니다. DMARC는 평가한 서명의 d=를 사용합니다.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

확인 순서:

header.from에서 보이는 도메인을 확인합니다.
smtp.mailfrom이 정렬되지 않은 공급자 도메인이면 SPF 정렬을 충족하지 않습니다.
header.i가 DMARC 기준인 것은 아닙니다. 유효한 서명의 d=를 확인합니다.
성공한 인증 어느 것도 정렬되지 않으면 SPF와 DKIM이 각각 성공해도 DMARC가 실패합니다.

DNS도 확인합니다.

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

전달에서만 발생하는 SPF 실패는 경로 특성일 수 있습니다. DKIM이 유효하고 정렬되면 DMARC를 지원할 수 있지만 단순 DKIM 성공이나 DNS만으로 실제 메일을 판단해서는 안 됩니다.

새 도메인 구성은 TrekMail의 도메인 설정 가이드와 자체 도메인 이메일 만들기를 참고하세요. 적절한 SPF 하나를 사용하고 DKIM과 DMARC를 테스트합니다. 기존 MX 등은 실제 사용을 확인한 뒤 제거하세요.

흔한 정렬 실패 패턴

외부 발송, 전달, 다른 하위 도메인과 중복·오래된 설정을 조사합니다. 패턴은 단서이며 검증을 대신하지 않습니다.

반복되는 상황:

공급자 반송 도메인: SPF 성공만으로 정렬되지 않지만 DKIM이 DMARC를 지원할 수 있음
공급자 서명: DKIM 성공만으로 정렬되지 않지만 SPF가 DMARC를 지원할 수 있음
전달: SPF가 실패할 수 있으며 유효하고 정렬된 DKIM이 유지되면 도움됨
의도하지 않은 엄격 모드: 다른 하위 도메인이 정렬되지 않음
이전 DNS: 실제 경로와 서명을 확인해야 하며 DNS만으로 잘못된 서명 서비스가 활성화되지는 않음

4.7.32 등 Gmail의 From 정렬 관련 응답이 있다면 실제 인증 결과와 해당 요건을 조사하세요. Google 이메일 발신자 가이드라인을 참고합니다.

TrekMail로 DMARC 정렬 관리

TrekMail은 사서함, DNS 상태와 발송 선택을 한 환경에 모으는 데 도움이 될 수 있습니다. 다섯 대시보드의 조사를 정리하더라도 발송원 확인과 테스트는 필요합니다.

운영 방식 비교:

분산된 관리와 통합된 관리

분산된 방식	TrekMail의 관련 기능
사서함, 발송과 DNS를 따로 추적	도메인, 사서함, 발송 선택과 DNS 검사를 공동 관리
공급자 지침을 개별 수집	누락되거나 다른 레코드를 찾는 설정 도움
전달 영향과 민원을 따로 조사	정렬된 DKIM과 테스트한 경로를 일관된 절차로 관리

유료 요금제 조건에 따라 관리형 SMTP를 사용할 수 있습니다. 자체 SMTP는 SES, SendGrid, Mailgun 등 실제 공급자의 요건에 맞춰 연결합니다. 어느 방식이든 적절한 DNS와 실제 정렬된 인증 성공이 필요하며 정상 표시만으로 충분하지 않습니다.

참고 문서:

메일이 스팸으로 분류되는 문제는 전달 결과를 설명합니다. IMAP & SMTP 설정은 클라이언트 구성을 다룹니다. 클라이언트 로그인 성공이 발신 메일의 DMARC 성공은 아닙니다.

제시된 Starter 시작 가격은 월 $3.50입니다. 설명된 유료 요금제의 무료 체험은 14일이며 시작하려면 신용카드가 필요합니다. Nano는 자체 SMTP, 최대 10개 도메인과 5 GB 공유 공간을 갖춘 무료 옵션으로 소개됩니다. 현재 기능, 가격과 조건은 TrekMail 요금에서 확인하세요. IMAP 이전은 지원 메시지를 복사하며 MX나 모든 앱 데이터를 자동 전환하지 않습니다.