550 5.7.515 인증 미달 (Outlook.com)

문제

outlook.com·hotmail.com·live.com·msn.com 주소로 보낸 메일이 550 5.7.515 Access denied, sending domain [당신도메인] does not meet the required authentication level로 바운스됩니다. 이건 스팸 점수 판정도, 블록리스트도, 꽉 찬 메일함도 아닙니다. Microsoft가 강한 규칙을 집행하는 중입니다: 보이는 From 주소의 도메인이 SPF·DKIM·DMARC로 스스로를 인증해야 하는데, 당신 것이 그 기준을 못 넘긴 겁니다. 지금 걸린 건 아마 Microsoft가 감시하는 볼륨 임계치를 넘었거나, 원래부터 당신 도메인에 실제로 묶이지 않은 인증을 쓰는 발송 서비스에 의존해왔기 때문입니다. 중요한 구분은 통과(pass) 대 *정렬(align)*이고, 5.7.515는 전적으로 정렬에 관한 것입니다.

증상

• 바운스(NDR)에 550 5.7.515 Access denied, sending domain [도메인] does not meet the required authentication level가 뜨고, 거부한 호스트가 Microsoft 소비자 메일 서버(*.outlook.com / *.hotmail.com)입니다.
• Gmail·Yahoo, 그리고 당신 회사 메일로는 여전히 배달됩니다 — Outlook.com 소비자 주소만 거부합니다.
• 2025년 5월 5일 즈음이나 그 이후에 시작됐거나, Microsoft 소비자 사서함으로 가는 볼륨이 하루 수천 통을 넘긴 직후에 시작됐습니다.
• 서드파티 플랫폼(마케팅·CRM·트랜잭션·헬프데스크)으로 보낸 메일이 자체 서버에서 직접 보낸 메일보다 더 잘 실패합니다.

이 에러가 실제로 뜻하는 것

2025년 5월 5일, Microsoft는 소비자 사서함으로 가는 대량 발송자 — Outlook.com으로 하루 5,000통 초과를 밀어 넣는 발송자 — 에 대해 인증 요구를 집행하기 시작했습니다. Google과 Yahoo가 2024년 2월에 내놓은 것과 같은 각본을 따릅니다. 요구는 세 부분입니다: SPF 게시, DKIM 게시, DMARC 게시(최소 p=none), 그리고 메시지가 DMARC를 통과해야 합니다 — 즉 SPF나 DKIM이 5322.From 헤더(사람이 보는 주소)의 도메인과 정렬되는 도메인을 인증해야 합니다.

거의 모든 5.7.515는 그 “정렬”이라는 단어에 삽니다. SPF와 DKIM은 발송 인프라의 도메인에 대해 둘 다 통과하면서 당신 도메인에 대해서는 Microsoft에 아무것도 말해주지 않을 수 있습니다. 마케팅 플랫폼은 자기 return-path로 보내고(플랫폼에 대해 SPF 통과), 자기 DKIM 키로 서명합니다(플랫폼에 대해 DKIM 통과). 초록 체크 두 개, 그런데도 DMARC — From 도메인과 정렬되는 인증만 세는 — 는 정렬된 게 하나도 없다고 봅니다. Microsoft에게 그 메시지는 미인증이고, 5.7.515를 반환합니다. 규칙은 “어떤 인증이든 통과했나”가 아니라 “From 줄의 도메인에 대한 인증이 통과했나”입니다.

가장 흔한 원인 3가지

1. From 도메인에 정렬된 인증이 없음 - 압도적으로 흔한 경우. 자기 바운스 도메인으로 SPF를 통과하고 자기 도메인으로 DKIM 서명하는 서드파티 서비스로 보냅니다. 어느 것도 당신 From 주소와 정렬 안 되니 DMARC가 검증할 게 없고 Outlook.com이 거부합니다. 해법은 브랜드 인증입니다: 당신 도메인을 쓰는 커스텀 DKIM 서명(대개 벤더가 주는 CNAME)과/또는 SPF가 당신 도메인 기준으로 평가되도록 커스텀 return-path.
2. DMARC 레코드가 아예 없음 - SPF와 DKIM이 완벽해도 From 도메인이 DMARC 레코드를 게시하지 않으면 Microsoft가 정렬을 평가할 정책이 없고, 대량 발송자는 요구를 못 넘깁니다. 정렬된 SPF나 DKIM을 갖춘 p=none 레코드면 규칙을 충족합니다 — 볼륨이 있으면 DMARC 게시는 선택이 아닙니다.
3. 실제 발송 경로의 DKIM이 깨졌거나 없음 - 주 메일 흐름은 인증했는데 한 발송자를 빠뜨린 경우: 인보이스 플랫폼, 알림 서비스, 자회사. 그 경로가 키 없이 또는 깨진 셀렉터로 서명해 그것만 DMARC에 실패하고, 그 소스의 메일만 5.7.515를 받고 나머지는 배달됩니다.

DechoNet으로 진단

• 이메일 점검은 Microsoft가 집행하는 세 레코드 — SPF·DKIM·DMARC — 를 당신 From 도메인에 대해 한 번에, 바깥에서, 수신 서버와 같은 방식으로 읽습니다. 각 레코드가 존재하고 문법이 유효한지, DMARC가 게시됐는지, 당신 설정이 정렬된 인증을 만들어낼 수 있는지조차 보여줍니다. 도메인에 DMARC 레코드가 없거나 SPF/DKIM이 당신 도메인에 묶인 것 없이 서드파티만 가리킨다면, 그게 바로 눈앞의 5.7.515입니다 — Microsoft나 발송 벤더에 티켓을 넣기 전에.

해결 체크리스트

• Microsoft가 지목한 정확한 From 도메인을 NDR에서 읽으세요. 해법은 그 도메인 — 보이는 From의 도메인, 서버 호스트명이나 return-path가 아니라 — 에 적용됩니다.
• 그 도메인에 세 레코드가 모두 있는지 확인: SPF 레코드, 메일이 실제로 서명하는 셀렉터의 DKIM 키, 그리고 DMARC 레코드(p=none이면 요구는 충족하나, p=reject가 진짜 목표).
• 통과가 아니라 정렬을 고치세요. 모든 발송 서비스에서 당신 도메인으로 DKIM 서명(벤더의 브랜드 DKIM / CNAME 설정)을 켜거나, SPF가 당신 도메인을 인증하도록 커스텀 return-path를 쓰세요. 정렬된 식별자 최소 하나가 DMARC를 통과해야 합니다.
• 당신 도메인으로 보내는 모든 소스를 목록화하세요 — 마케팅·CRM·청구·트랜잭션·지원, 그리고 아무도 문서화 안 한 그 스크립트 하나 — 각각이 정렬된 인증을 만드는지 확인. 5.7.515는 흔히 잊어버린 그 한 발송자에서 옵니다.
• 변경 후 Outlook.com 주소로 테스트 발송하고 수신 메시지의 Authentication-Results 헤더를 읽으세요: 아무 통과가 아니라 당신 도메인에 대한 spf=pass 또는 dkim=pass를 동반한 dmarc=pass를 원합니다.

에스컬레이션 시점

• 당신 도메인이 유효하고 정렬된 SPF/DKIM/DMARC를 게시하는데도 여전히 5.7.515로 바운스된다면, 발송 플랫폼으로 가져가세요: 그들이 실제 아웃바운드 메시지에 당신의 브랜드 인증을 적용하지 않는 것일 수 있고, 그건 그쪽 설정 문제입니다.
• 한 벤더를 통한 메일만 실패하고 직접 메일은 배달되면, 그 벤더 경로가 정렬 안 된 것입니다. 실패한 Authentication-Results를 넘기고 당신 도메인용 DKIM 서명을 켜달라고 요청하세요.
• 전부 정렬되고 통과하는데도 Microsoft가 거부하면 Microsoft 발송자 지원 채널을 쓰세요 — 단 이메일 점검이 세 레코드가 깨끗하다고 보인 뒤에. 실제로는 당신 DNS에 있는 문제를 에스컬레이션하지 않도록.