가이드인증

SPF와 DKIM은 통과하는데 DMARC가 실패할 때

두 검사 모두 pass인데 DMARC는 fail이라고 합니다. 원인은 From 주소와 일치하지 않는 도메인입니다. 테스트 이메일 한 통이면 어느 도메인인지 알 수 있고, 해결책은 메일을 보내는 쪽의 설정 하나입니다.

2026년 10월 5일 업데이트읽는 데 9분

핵심 요약

DMARC는 SPF나 DKIM이 From 주소의 도메인에 대해 통과해야만 통과합니다. 제공업체의 도메인에 대한 통과는 인정되지 않습니다.
발송한 메시지를 Gmail에서 Show original(원본 보기)로 열고 Authentication-Results 헤더의 smtp.mailfrom, header.i, header.from을 비교하세요.
DKIM부터 고치세요. 나를 대신해 메일을 보내는 모든 서비스에서 내 도메인으로 서명하도록 켭니다. DKIM 서명은 전달되어도 유지되지만 SPF는 그렇지 않습니다.
하위 도메인은 기본적으로 충분히 가까운 것으로 인정됩니다. DMARC 레코드에 adkim=s나 aspf=s가 있으면 인정되지 않습니다.
워밍업은 정렬을 고쳐 주지 않습니다. 워밍업 이메일은 내 메일함을 통해 발송되므로 메일함과 함께 실패합니다.

DMARC는 SPF와 DKIM이 통과했는지를 묻지 않습니다. 둘 중 하나가 From 주소의 도메인에 대해 통과했는지를 묻습니다. SPF는 제공업체의 반송 도메인에 대해 통과하고 DKIM은 제공업체의 서명 도메인에 대해 통과했다면, 두 줄 모두 “pass”라고 나오는데도 DMARC는 “fail”이라고 합니다. 해결은 발송 측에서 합니다. 내 도메인으로 서명하게 하거나, 내 도메인의 반송 주소를 쓰게 하세요. 둘 중 하나면 충분합니다.

이렇게 일치하는 것을 정렬(alignment)이라고 부릅니다. DMARC에서 DNS 검사 도구가 볼 수 없는 부분입니다. 내 메일이 정렬되어 있는지는 실제로 발송된 메시지에서만 드러납니다. 이 글은 그런 메시지를 읽는 방법을 보여 줍니다.

모든 이메일에는 도메인 세 개가 따라다닙니다

이메일에는 내 도메인이 최대 세 곳에 들어갑니다. 검사마다 보는 곳이 다릅니다.

부두 위에 나란히 놓인 봉투 문양의 남색 깃발, 황동 꼬리표가 달린 우편 자루, 밀랍으로 봉인한 편지. 봉인에는 깃발과 같은 문양이 찍혀 있고 꼬리표에는 없다 — 깃발은 From 줄, 우편 자루의 꼬리표는 Return-Path, 밀랍 봉인은 DKIM 서명입니다. DMARC는 꼬리표나 봉인이 깃발과 일치하기를 원합니다.

위치	다른 이름	누가 보는가
받는 사람에게 보이는 From 줄	헤더 From, `header.from`	DMARC. 나머지 둘을 재는 기준입니다.
Return-Path	봉투 발신자(envelope sender), MAIL FROM, 반송 주소, `smtp.mailfrom`	SPF. 발송 서버가 이 도메인을 써도 되는지 확인합니다.
DKIM-Signature 헤더의 `d=` 값	서명 도메인, `header.d` 또는 `header.i`	DKIM. 이 도메인의 서명이 유효한지 확인합니다.

SPF(RFC 7208)와 DKIM(RFC 6376)은 각각 좁은 질문 하나에 답하며, 어느 질문에도 From 줄은 등장하지 않습니다. 뉴스레터 서비스는 자기 반송 도메인으로 SPF를 통과하고 자기 키로 서명할 수 있고, 그래도 메시지는 내가 보낸 것이라고 주장할 수 있습니다. DMARC가 그 틈을 메웁니다. 2026년 5월부터 DMARC 표준인 RFC 9989는 결과 뒤에 있는 도메인이 From 도메인과 일치할 때만 그 결과를 인정하며, DKIM에 대해서는 그 이유를 한 문장으로 밝힙니다.

메시지에는 어떤 도메인의 유효한 서명이든, 심지어 악의적인 행위자가 쓰는 도메인의 서명도 붙을 수 있으므로, DMARC는 DKIM으로 인증된 식별자에 식별자 정렬을 적용하도록 요구한다.

SPF도 마찬가지입니다. 누구나 자기가 가진 도메인에 SPF 레코드를 게시할 수 있기 때문입니다. 그래서 규칙은 이렇습니다. SPF가 통과하고 동시에 그 도메인이 정렬되거나, DKIM이 통과하고 동시에 그 도메인이 정렬되면 DMARC가 통과합니다.

실제 메시지 한 통에서 불일치 찾기

실제 메일을 보내는 방식 그대로 보낸 이메일 한 통과, 그것을 받을 Gmail 주소가 필요합니다.

문제가 되는 메일함이나 도구에서, 내가 열어 볼 수 있는 Gmail 주소로 메시지를 보냅니다.
컴퓨터의 Gmail에서 그 메시지를 엽니다. Reply(답장) 옆의 More(더보기)를 클릭한 다음 Show original(원본 보기)을 클릭합니다. Google은 같은 절차를 전체 헤더로 이메일 추적하기에서 설명합니다.
Authentication-Results 헤더를 찾습니다. 수신 서버가 검사 결과를 적어 두는 헤더입니다(RFC 8601). 세 값을 비교하세요. smtp.mailfrom= 뒤의 도메인, header.i=@ 뒤의 도메인(일부 수신 서버는 header.d=라고 씁니다), 그리고 header.from= 뒤의 도메인입니다. 이메일 헤더 읽는 법에서 이 줄을 단계별로 살펴봅니다.

다음은 SPF와 DKIM은 통과하고 DMARC는 실패하는 메시지의 전형적인 모습입니다. 헤더는 줄였고 예시 도메인을 썼습니다.

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

아래에서부터 읽으세요. From 도메인은 example.com입니다. SPF는 통과했지만 send.vendor-mail.example에 대한 통과입니다. DKIM도 통과했지만 서명은 vendor-mail.example의 것입니다. 어느 쪽도 example.com이 아니므로 From 줄의 이름을 보증하는 것은 아무것도 없습니다.

서비스가 내 도메인으로 서명하도록 설정한 뒤에는 같은 메시지가 이렇게 보입니다.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF는 여전히 서비스 업체를 가리킵니다. 괜찮습니다. 이제 DKIM이 일치하고, DMARC에는 정렬된 통과 하나면 됩니다.

얼마나 가까워야 하나: 완화와 엄격

두 도메인이 똑같을 필요는 없습니다. 기본값은 완화된(relaxed) 정렬입니다. 둘이 같은 등록 도메인에 속하기만 하면 되며, 표준은 이를 조직 도메인(organizational domain)이라고 부릅니다. 엄격한(strict) 정렬은 정확히 일치할 것을 요구합니다. DMARC 레코드에서 DKIM은 adkim 태그로, SPF는 aspf 태그로 선택합니다.

SPF 또는 DKIM이 통과한 도메인	From 도메인	완화(기본값)	엄격
`example.com`	`example.com`	정렬됨	정렬됨
`mail.example.com`	`example.com`	정렬됨	정렬 안 됨
`example.com`	`news.example.com`	정렬됨	정렬 안 됨
`vendor-mail.example`	`example.com`	정렬 안 됨	정렬 안 됨

표준은 “거의 모든 도메인 소유자가 완화된 정렬로 자신의 필요를 충족하기에 충분하다고 판단했다”고 적고 있습니다. 그래도 내 레코드는 확인해 보세요. Google의 DMARC 설정 페이지 맨 위에 있는 예시 레코드는 adkim=s; aspf=s로 끝나므로, 거기서 복사한 레코드는 엄격한 정렬입니다. 내 레코드에 이 두 태그가 있고 어떤 도구가 하위 도메인에서 발송한다면 태그를 지우세요. Google도 그 페이지에서 엄격한 정렬 때문에 “연결된 하위 도메인의 메시지가 거부되거나 스팸으로 분류될 수 있다”고 경고합니다.

불일치가 주로 생기는 곳

자체 서버에서 발송하는 서비스

뉴스레터 플랫폼, CRM, 청구서 도구, 헬프데스크는 내 메일을 자기 인프라에서 보냅니다. 내 도메인을 연결하기 전까지는 보통 자기 도메인의 반송 주소를 쓰고 자기 키로 서명합니다. Amazon의 문서는 여기서 SPF 정렬이 드문 이유를 분명히 말합니다. Return-Path는 “제공업체(SES)가 자신이 소유한 주소를 사용해 추적하는 반송과 불만 신고에 쓰인다”는 것입니다(Amazon SES). 이를 고치는 설정은 서비스마다 이름이 다르며, 결국 내 쪽에 DNS 레코드 몇 개를 추가하는 일로 끝납니다.

서비스	도메인을 연결하기 전	찾아야 할 설정
Twilio SendGrid	메일이 “via sendgrid.net”으로 발송된 것으로 표시됩니다.	Domain authentication(도메인 인증): 반송용 하위 도메인과 DKIM 키 두 개를 위한 CNAME 레코드.
Amazon SES	Return-Path가 `amazonses.com`의 하위 도메인입니다.	서명에는 Easy DKIM, SPF에는 custom MAIL FROM domain(사용자 지정 MAIL FROM 도메인).
Mailchimp	도메인이 확인(verified)되었지만 인증(authenticated)되지는 않았습니다.	Email domain authentication(이메일 도메인 인증): DKIM용 CNAME 레코드 두 개.

이는 2026년 10월 기준으로 각 업체가 직접 설명한 내용입니다. 다른 서비스도 비슷한 방식으로 작동합니다. 해당 서비스의 도움말에서 “authenticate domain”, “custom DKIM”, “branded sending domain”을 검색해 보세요.

메일 제공업체가 자기 도메인으로 서명하거나 아예 서명하지 않는 경우

자기 도메인의 메일함이라면 Return-Path는 보통 내 주소이므로, SPF 레코드에 제공업체가 들어 있기만 하면 SPF는 정렬됩니다. smtp.mailfrom= 뒤의 값을 보면 알 수 있습니다. 스위치를 켜야 하는 쪽은 DKIM입니다.

Google Workspace. 내 도메인에 DKIM을 켜기 전까지 Google은 자기 도메인 가운데 하나로 서명해 왔습니다. Google 도움말 페이지의 이전 버전에는 그 경우 Gmail이 “다음 기본 DKIM 도메인 키로 서명합니다: d=*.gappssmtp.com”이라고 적혀 있었습니다. 현재 페이지는 그 도메인을 더 이상 밝히지 않으므로 내 헤더를 직접 확인하세요. header.i가 gappssmtp.com으로 끝나면 내 키가 활성화되지 않은 것입니다. 관리 콘솔의 Apps, Google Workspace, Gmail, Authenticate email(이메일 인증)에서 키를 생성하고, 표시되는 TXT 레코드를 추가한 다음 Start authentication(인증 시작)을 클릭하세요(DKIM 설정).
Microsoft 365. 2026년 8월에 업데이트된 Microsoft 문서는 이렇게 밝힙니다. “현재 사용자 지정 도메인에서 나가는 메일에는 DKIM 서명이 이루어지지 않습니다.” CNAME 레코드 두 개를 게시하고 Defender 포털에서 서명을 켜야 합니다(사용자 지정 도메인의 이메일에 DKIM을 사용하는 방법).

DKIM 키를 위해 추가하는 레코드는 항상 _domainkey 아래에, 제공업체가 정한 이름으로 놓입니다. Google Workspace에서는 다음과 같습니다. 키는 줄였습니다.

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

내 메일함에 연결해 그 메일함을 통해 발송하는 도구는 자기 서명을 덧붙이지 않습니다. 그런 도구에서 나간 메일은 내가 직접 쓴 메일과 똑같이 보이므로, 고칠 곳은 도구가 아니라 메일 제공업체입니다.

메시지가 전달된 경우

수신자가 내 메일을 자동으로 전달하면, 메일은 내 SPF 레코드에 없는 서버에서 도착합니다. SPF는 실패하거나 전달한 쪽의 도메인에 대해 통과합니다. DKIM 서명은 아무도 메시지를 바꾸지 않는 한 그 과정에서도 유지됩니다. 푸터나 제목 태그를 덧붙이는 메일링 리스트는 서명도 깨뜨립니다. 내 쪽에서는 이를 고칠 수 없습니다. Google의 발신자 FAQ는 Gmail의 경우 “전달된 메시지나 메일링 리스트 메시지에는 DMARC 정렬이 요구되지 않는다”고 말합니다. SPF에만 기대지 말고 DKIM을 정렬해 두어야 하는 이유가 여기에 있습니다.

봉인된 편지가 한 우편선에서 다른 우편선으로 건네진다. 배마다 자기 우편 자루와 꼬리표가 있고, 편지의 밀랍 봉인은 깨지지 않았다 — 전달되면 우편 자루와 꼬리표가 바뀝니다. 편지의 봉인은 그대로 남습니다.

내 메일이 아닌 경우

DMARC 보고서에 한 번도 써 본 적 없는 서버의 실패가 보인다면, 누군가 내 주소로 메일을 보내고 있을 수 있습니다. 그런 메시지는 실패하는 것이 맞습니다. 고칠 것은 없으며, 나중에 정책을 더 엄격하게 올려야 할 근거가 됩니다.

DKIM을 먼저, 그다음 SPF를 고치세요

둘 중 어느 쪽이든 통과를 얻을 수 있습니다. 그래도 갖춰 두기에 더 좋은 쪽은 DKIM입니다. 메시지와 함께 이동하기 때문입니다. M3AAWG의 권장 모범 사례는 이를 규칙으로 적습니다. “나가는 모든 메일에 RFC5322.From 헤더의 도메인과 정렬되는 DKIM 키로 서명하라.” RFC 9989는 둘 다 사용할 것을 권장합니다.

내 도메인으로 발송하는 것을 전부 적으세요. 메일함, 뉴스레터 도구, CRM, 청구서, 웹사이트의 문의 양식입니다. 잊은 것은 DMARC 보고서가 알려 줍니다.
하나씩 테스트하세요. 위의 헤더 확인 방법을 쓰고, 두 도메인 중 어느 것이 내 것이 아닌지 적어 두세요.
내 도메인으로 서명하도록 켜세요. header.i에 다른 이름이 보이는 곳마다 켜고, 서비스가 알려 주는 레코드를 게시합니다. DNS 호스팅 업체가 지원한다면 2048비트 키를 선택하세요. Gmail은 최소 1024비트를 요구하고 2048비트를 권장합니다.
사용자 지정 반송 도메인을 설정하세요. 서비스가 제공한다면 bounce.example.com 같은 하위 도메인에 설정합니다. 그러면 SPF도 정렬됩니다.
테스트 메일을 다시 보내 dmarc=pass가 나오는지 확인하세요. DNS 변경에는 시간이 걸릴 수 있습니다. Google은 새 DKIM 키가 작동하기까지 최대 48시간이 걸릴 수 있다고 안내합니다.

내 레코드에 서비스 업체를 추가하는 방법은 통하지 않습니다. Return-Path가 업체의 도메인에 있다면 내 SPF 레코드에 업체용 include:를 넣어도 아무것도 달라지지 않습니다. SPF는 내 도메인이 아니라 그 도메인의 레코드를 조회하기 때문입니다. DMARC 레코드에 신뢰하는 제3자를 나열할 수도 없습니다. 표준은 그런 용도로 “일반적으로 받아들여지는 메커니즘이 없다”고 말합니다.

헤더에 dmarc=pass가 보이는데도 메시지가 스팸함에 들어간다면 원인은 더 이상 인증이 아닙니다. SPF, DKIM, DMARC를 통과했는데도 이메일이 스팸함에 들어갈 때에서 이어서 다룹니다.

정책이 p=none인 동안 DMARC 실패가 치르는 대가

p=none은 실패가 나도 아무 조치를 하지 말라고 수신 측에 요청하는 것이므로, 내 정책 때문에 거부되는 메일은 없습니다. 그래도 두 가지 면에서 불리하게 작용합니다.

대량 발송자 규칙. Gmail, Yahoo, Outlook.com은 대량 발송자에게 정렬된 메일을 요구하며, Gmail과 Outlook.com에서는 하루 5,000통부터가 대량 발송자입니다. Google의 발신자 FAQ는 From 헤더가 “인증된 SPF 또는 DKIM 조직 도메인 어느 쪽과도 정렬되지 않은” 메일에 대한 일시적 오류 4.7.32를 싣고, 그 결과로 “일시적 또는 영구적 실패 코드, 또는 스팸함 분류”를 듭니다.
다음 단계를 막습니다. p=quarantine이나 p=reject로 옮기는 순간, 정렬되지 않은 내 메시지는 모두 스팸으로 처리되거나 거부되어야 하는 대상이 됩니다. Gmail에서 반송 메시지는 “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”이고 오류 코드는 5.7.26입니다(DMARC 문제 해결).

DMARC 레코드가 아예 없다면 추가해야 할 레코드부터 시작하세요. 그 레코드는 모든 발송 서비스의 정렬을 한꺼번에 보여 주는 보고서도 켜 줍니다.

여기서 워밍업이 할 수 있는 일과 할 수 없는 일

워밍업은 정렬을 고쳐 주지 않습니다. WarmupBay는 내 메일함에 연결해 그 메일함에서 발송하므로, 워밍업 이메일은 내가 직접 쓰는 메일과 똑같이 내 제공업체가 발송하고 서명합니다. 내 메일함이 DMARC에 실패하면 워밍업 이메일도 함께 실패합니다. 레코드를 먼저 고치세요.

WarmupBay는 그 앞 단계와 뒤 단계를 돕습니다. 메일함을 연결하면 도메인의 SPF, DKIM, DMARC를 점검하고, 72시간 후에도 레코드가 없으면 워밍업을 중지합니다. 레코드가 갖춰지면 내 메일함이 공동 풀의 다른 메일함들과 하루에 이메일 몇 통을 주고받고, 대시보드는 그 이메일이 받은편지함, Gmail 탭, 스팸함 중 어디에 도착했는지를 Google과 그 밖의 제공업체로 나누어 보여 줍니다. 뉴스레터 도구나 CRM에서 나가는 메일은 테스트하지 않습니다. 그런 메일은 내 메일함을 거치지 않기 때문입니다. Microsoft 365나 Outlook.com 메일함은 아직 연결할 수 없습니다. 하루 10통의 워밍업 이메일까지 무료입니다. 헤더에 dmarc=pass가 보이면 메일함을 연결하세요.

자주 묻는 질문

SPF는 통과하고 정렬도 되는데 DKIM은 정렬되지 않습니다. 이것으로 충분한가요?

DMARC에는 충분합니다. 정렬된 통과가 하나만 있으면 됩니다. 다만 수신자가 내 메일을 전달하면 SPF가 더 이상 맞지 않으므로 그때는 충분하지 않습니다. Google도 발신자 FAQ에서 SPF와 DKIM 모두의 정렬이 요건이 될 가능성이 높다고 쓰고 있으니, 어쨌든 내 도메인에 DKIM을 설정해 두세요.

왜 어떤 수신자에게는 DMARC가 실패하고 다른 수신자에게는 통과하나요?

메일이 서로 다른 경로로, 또는 서로 다른 발송 서비스에서 도착하기 때문입니다. 다른 메일함으로 전달하는 수신자나 메일링 리스트는 SPF가 보는 내용을, 때로는 DKIM이 보는 내용까지 바꿉니다. 여러 발송 서비스 가운데 하나가 아직 설정되지 않았을 수도 있습니다. 집계 보고서는 결과를 발송 서버별로 나열하므로 어느 경우인지 알 수 있습니다.

Reply-To 주소도 DMARC에 영향을 주나요?

아니요. DMARC는 From 헤더의 도메인만 사용합니다. Reply-To 주소, 표시 이름, Sender 헤더는 검사 대상이 아닙니다.

헤더를 열지 않고 정렬 문제를 확인하려면 어떻게 하나요?

DMARC 집계 보고서에서 볼 수 있습니다. 각 레코드에는 dkim과 spf 결과가 담긴 policy_evaluated 블록이 있고, 이 결과는 정렬 검사를 거친 뒤의 결과입니다. 그 아래 auth_results 블록은 원래 결과와 그 결과가 어느 도메인에 대한 것이었는지를 보여 줍니다. 원래 결과는 pass인데 평가 결과가 fail이라면 바로 이 글에서 다루는 경우입니다. DMARC 레코드에 rua 주소를 추가하면 보고서를 받을 수 있습니다.

헤더에 dkim=fail 또는 dkim=neutral이라고 나옵니다. 같은 문제인가요?

아니요. 그 경우는 서명 자체가 검증되지 않은 것으로, 다른 종류의 오류입니다. body hash did not verify라는 문구가 있다면 Google의 문제 해결 페이지가 원인을 알려 줍니다. 서명된 뒤에 메시지가 바뀐 것이며, 예를 들어 푸터를 덧붙이는 게이트웨이가 그럴 수 있습니다. 정렬 문제는 서명은 유효한데 다른 도메인의 것인 경우를 말합니다.

나를 대신해 메일을 보내는 서비스마다 DKIM 키가 따로 필요한가요?

실제로는 그렇습니다. 각 서비스는 자기 키로 서명하고, 그 키를 내 도메인의 _domainkey 아래에 자기만의 선택기(selector) 이름으로 게시합니다. 그래서 여러 키가 충돌 없이 나란히 놓입니다. 도메인 하나에 레코드를 하나만 둘 수 있는 SPF와는 다릅니다.