Defaults.Exposed › 수정 › Guides

Outlook이 이메일을 거부함: 550 5.7.515, 550 5.7.509, compauth=fail 설명 및 수정 (2026)

게시일 2026-07-08

기준일: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인에 대한 집계 센서스 데이터. 등급 산정 방식을 참고하세요.

두 가지 다른 Microsoft 시스템이 메일을 거부합니다. 소비자 Outlook.com은 인증에 실패하는 대량 발송자를 거부하고(550 5.7.515, 2025년 5월부터 시행), Exchange Online은 귀사의 DMARC reject 정책을 준수하여 거부합니다(550 5.7.509). Defaults.Exposed의 261,086,232 도메인 센서스에 따르면, spf.protection.outlook.com을 승인한 10,205,070 도메인 중 85.0%가 엄격한 SPF를 갖고 있지만 DMARC를 집행하는 곳은 21.7%뿐입니다.

대부분의 “Outlook이 내 이메일을 거부한다” 문제는 실제로 거부가 아닙니다 — 헤더에 compauth=fail이 있는 채로 정크에 조용히 분류됩니다. 이 가이드는 Microsoft 코드를 해독하고, Authentication-Results 헤더를 읽는 방법을 보여주고, 수정 방법을 순서대로 안내합니다: SPF 확인, 커스텀 도메인 DKIM 활성화, DMARC 게시 및 집행, 재테스트.

실제로 어떤 Microsoft 오류가 발생한 건가요?

Microsoft는 두 개의 별도 수신 서비스를 운영하며, 각각 다른 이유로 거부합니다. 증상을 먼저 맞춰보세요 — 잘못된 진단은 하루를 낭비합니다.

정확한 NDR 문구는 변경될 수 있으므로, 라이브 바운스에 대해 인용하는 문자열을 확인하세요.

550 5.7.515는 무엇을 의미하나요?

이것은 Microsoft 365 테넌트 오류가 아닌 소비자 Outlook.com/Hotmail 요구 사항입니다. 2025년 5월부터 소비자 Outlook 주소로 하루 5,000건 이상을 발송하는 발송자는 SPF를 통과하고, DKIM을 통과하고, From 도메인과 정렬된 DMARC 레코드(최소 p=none)를 게시해야 합니다. 이 기준을 충족하지 못하면 소비자 Outlook이 다음과 같이 거부합니다:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

이것이 아닌 것 두 가지: 2026년 의무가 아닙니다(메일이 갑자기 거부되기 시작했다면 규칙이 아닌 발송량이나 DNS가 변경된 것입니다), 그리고 수신자의 M365 테넌트 설정에 관한 것이 아닙니다. 수정 방법은 아래 인증 단계입니다 — 하루 5,000건을 넘는 캠페인 날도 해당됩니다.

550 5.7.509는 무엇을 의미하나요?

이것은 비즈니스 테넌트의 Exchange Online Protection에서 오며, 귀사의 DMARC 정책이 준수되고 있음을 의미합니다:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

주의 깊게 읽으세요 — Microsoft가 까다롭게 구는 것이 아닙니다. 귀사 도메인이 p=reject를 게시하고, 이 메시지가 DMARC에서 실패했으며, 수신자가 정확히 귀사가 요청한 대로 한 것입니다. 거부된 메일이 합법적이라면, 일부 발송 소스(뉴스레터 도구, CRM, 스캔-이메일 기기)가 정렬된 방식으로 인증되지 않은 것입니다. 정책을 약화하지 마세요; 해당 소스에 정렬된 SPF 또는 DKIM을 제공하세요 — DMARC 수정 및 p=none에서 p=reject로를 참고하세요.

Outlook이 메일을 거부하지 않고 compauth=fail로 정크로 분류하는 이유는?

대부분의 Microsoft 전달성 문제는 바운스를 생성하지 않습니다. 메시지는 수신되고, 점수가 매겨지고, 정크에 파일됩니다 — 유일한 증거는 Authentication-Results 헤더입니다. 수신자의 사서함(또는 귀사 outlook.com 테스트 사서함)에서 메시지를 열고, 메시지 소스 보기를 선택하고, 다음 줄을 찾으세요:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth는 Microsoft의 복합 인증 판정입니다: 도메인이 DMARC 레코드를 게시하지 않더라도 Microsoft는 암묵적인 DMARC 유사 검사를 적용합니다. 일반적으로 보이는 값:

• compauth=fail reason=000 — 메시지가 명시적 인증에서 실패함: 귀사 도메인의 DMARC 정책이 quarantine/reject이고 메시지가 실패했습니다.
• compauth=fail reason=001 — 메시지가 암묵적 인증에서 실패함: 귀사 도메인이 인증 레코드를 게시하지 않거나 충분하지 않으며, 메시지가 귀사에서 온 것처럼 보이지 않습니다. “DKIM/DMARC를 설정한 적이 없다”는 전형적인 신호.
• compauth=fail reason=6xx — 암묵적 인증 실패 변형; 601은 발신 도메인이 조직의 수락 도메인 중 하나임(내부 스푸핑, 자신에게 발송)을 의미합니다.

교훈: Microsoft에서는 NDR뿐 아니라 헤더를 읽으세요. 같은 줄의 spf=, dkim=, dmarc= 판정이 수정해야 할 다리를 정확히 알려줍니다.

Outlook 거부 및 정크 분류를 어떻게 수정하나요?

1. 먼저 무료 검사를 실행하세요. DNS를 건드리기 전에 SPF, DKIM, DMARC를 한 번에 등급으로 표시하고 어느 다리가 실패하는지 보여줍니다.
2. SPF를 확인하세요 — Microsoft 365에서는 보통 이미 정상입니다. 표준 레코드는 v=spf1 include:spf.protection.outlook.com -all이며, M365 설정 시 추가됩니다: spf.protection.outlook.com을 승인하는 10,205,070 도메인 중 85.0%가 이미 엄격한 -all로 끝납니다(기준: 2026-06-29). 주의할 점: 수신자는 From 헤더가 아닌 Return-Path(RFC5321.MailFrom) 도메인에 대해 SPF를 평가합니다 — 따라서 뉴스레터 도구가 귀사 것에 아무것도 하지 않으면서 자체 바운스 도메인에서 SPF를 통과할 수 있습니다. 이것이 3단계와 4단계가 더 중요한 이유입니다.
3. 커스텀 도메인에 DKIM을 활성화하세요 — 두 개의 셀렉터 CNAME. M365는 커스텀 도메인 서명을 활성화하기 전까지 정렬되지 않은 onmicrosoft.com 기본값으로 서명합니다: 테넌트 키를 가리키는 selector1._domainkey 및 selector2._domainkey CNAME을 게시한 다음 Defender 포털에서 서명을 활성화하세요. 전체 클릭 경로: Microsoft 365에서 DKIM 설정. DKIM이 “통과”를 보여주지만 DMARC가 여전히 실패한다면, 기본 서명 함정에 있는 것입니다.
4. DMARC를 게시한 다음 집행하세요. v=DMARC1; p=none; rua=mailto:...로 시작하여 보고서를 받고, 드러나는 모든 합법적인 발송 소스를 수정한 다음, p=quarantine 및 p=reject로 단계적으로 강화하세요 — 단계적 경로는 DMARC 수정에 있습니다. 이것은 대부분의 Microsoft 조직이 건너뛰는 단계입니다: M365 발송 도메인 중 DMARC를 집행하는 곳은 21.7%뿐입니다.
5. 헤더를 읽어 재테스트하세요. 소비자 outlook.com 사서함으로 발송하고, 메시지 소스를 열고, spf=pass, dkim=pass, dmarc=pass, compauth=pass를 확인하세요.
6. 대량 발송자: 소비자 Outlook 기준을 충족하세요. 하루 5,000건 이상이라면 유효하고 모니터링되는 From/reply-to, 작동하는 구독 취소, 깨끗한 목록도 필요합니다 — 인증이 5.7.515를 해결하고, 불만 비율이 S3140/S3150 IP 차단에서 벗어나게 합니다. IP 차단이 이미 발생한 경우, SPF/DKIM/DMARC 수정이 차단을 해제하지 않습니다: Microsoft 발송자 지원을 통해 차단 해제를 요청하고, 인증을 다시 차단되지 않을 이유로 처리하세요.

왜 많은 Microsoft 365 도메인이 여전히 실패하나요?

첫 번째 단계만 자동으로 해주기 때문입니다. spf.protection.outlook.com을 승인하는 10,205,070 도메인 중 85.0%가 엄격한 SPF를 갖고 있습니다 — M365가 설정 시 제공하는 레코드 — 하지만 Defaults.Exposed의 261,086,232 도메인 센서스에 따르면 DMARC를 집행하는 곳은 21.7%뿐입니다. M365는 기본으로 엄격한 SPF를 제공하지만, 대부분의 테넌트는 거기서 멈춥니다 — compauth가 잡도록 만들어진 정확한 집단입니다(그래도 전체 등급 도메인 중 DMARC 집행률 10.59%보다는 앞서 있음). 전체 공급업체 비교: 이메일 공급업체 SPF 순위표.

자주 묻는 질문

550 5.7.515는 Microsoft 365 오류인가요? 아니오. 소비자 Outlook.com/Hotmail에서 오며 2025년 5월부터 시행되는, 하루 5,000건 이상 발송자를 대상으로 합니다. 비즈니스 Exchange Online 거부는 다른 코드를 사용합니다 — 가장 일반적으로 550 5.7.509(귀사의 DMARC reject 정책) 또는 5.7.511(차단된 발송자).

550 5.7.509가 발생했지만 메일이 합법적이었습니다 — p=reject를 삭제해야 하나요? 아니오 — 정책이 인증되지 않은 소스를 잡은 것이며, 이것이 올바르게 작동하는 것입니다. 헤더나 DMARC 보고서에서 소스를 찾아 정렬된 DKIM(또는 정렬된 SPF)을 제공하세요. p=none으로 약화하면 모든 사람에게 정확한 도메인 스푸핑이 다시 가능해집니다.

compauth=fail은 누군가 우리를 스푸핑하고 있다는 의미인가요? 반드시 그런 것은 아닙니다. reason=001은 보통 귀사 자신의 메일이 귀사에서 온 것임을 증명하지 못한다는 의미입니다 — 정렬된 DKIM 없음, DMARC 없음. M365 발송 10,205,070 도메인 중 DMARC를 집행하는 곳은 21.7%뿐이며(기준: 2026-06-29), Microsoft는 나머지 모두에 암묵적 검사를 적용하고, 인증되지 않은 합법적인 메일도 실패합니다.

하루 5,000건 미만을 발송합니다 — 무시해도 되나요? 550 5.7.515는 피할 수 있지만, 정크 폴더는 피할 수 없습니다: compauth는 모든 발송량에 적용됩니다. Gmail도 같은 방식을 적용합니다 — Gmail 550 5.7.26 가이드를 참고하세요. 수정은 무료입니다; 장벽은 비용이 아닌 인식입니다.

보고서를 담당자에게 전달하세요

다른 사람을 위해 이메일을 수정하는 경우 — 고객, 상사, 인보이스가 거부되던 회사 — 증거로 작업을 마무리하세요. DNS가 안정된 후 무료 검사를 다시 실행하고 등급 보고서를 전달하세요. 비즈니스 오너가 읽을 수 있는 일반 언어로 SPF, DKIM, DMARC가 초록색으로 표시되며, 다음에 사이버 보험 갱신이나 고객 보안 설문지에서 이메일 인증 여부를 물을 때 필요한 결과물입니다. 수정된 것은 좋고, 증명 가능하게 수정된 것이 보수를 받게 하고 그들을 보호합니다.

도메인을 무료로 확인하세요

Microsoft가 어떤 다리에서 실패하는지 확인하세요 — SPF, DKIM, DMARC — 비공개로, 소유자만.

도메인 확인하기 → · DMARC 수정 → · DKIM은 통과하지만 DMARC는 실패 → · 등급 산정 방식 → · 집계 데이터만 사용. 데이터는 EU 내에서 저장 및 처리됩니다.