550 5.7.509: Microsoft DMARC 거부 바운스 해결

Problem

Microsoft 365나 Outlook 수신자에게 보낸 메일이 550 5.7.509와 함께 “Access denied, sending domain [당신-도메인] does not pass DMARC verification and has a DMARC policy of reject.” 같은 문구로 바운스됩니다. 아무것도 전달되지 않았습니다. 스팸 점수나 평판 하락이 아니고 — 모두를 헷갈리게 하는 반전은, 거부하는 서버가 자기 규칙이 아니라 당신의 규칙을 집행하고 있다는 점입니다. 당신의 From 도메인이 DMARC p=reject를 게시했고, 이 메시지는 DMARC를 통과 못 했으며, Microsoft는 당신 정책이 모든 수신자에게 시킨 그대로 했습니다: 거부.

그래서 5.7.509는 묘하게 정직한 에러입니다. 필터를 뚫으라는 게 아닙니다. 당신 도메인에서 왔다고 주장하는 메시지가 그걸 증명하지 못했고, 당신은 이미 세상에 정확히 그런 메일을 거부하라고 지시해 뒀다는 걸 알려주는 겁니다. 그래서 실제 경우는 둘뿐이고, 진단 전부가 어느 쪽인지 고르는 일입니다: 메일이 정당하게 당신 것이지만 DMARC 정렬이 안 됐거나, 메일이 스푸핑이고 거부가 설계대로 작동한 것.

Symptoms

• 바운스/NDR에 550 5.7.509가 실리고 DMARC와 policy of reject를 명시적으로 지목합니다.
• 특정 발송 스트림 — 보통 한 벤더나 앱(CRM, 뉴스레터 도구, 티켓 시스템) — 에 영향을 주고, 주 제공자에서 직접 보낸 메일은 여전히 도착합니다.
• 당신 쪽 변화 없이 갑자기 시작될 수 있습니다. 수신자가 조용히 격리하던 데서 p=reject를 존중하기 시작했기 때문입니다.
• 잘 구성된 경로로 보낸 같은 도메인 메일은 멀쩡하고, 실패하는 경로가 정렬 안 된 그 경로입니다.
• 수신자가 Microsoft(Microsoft 365 / Exchange Online / outlook.com)라는 점이 이 코드를 Microsoft의 DMARC 처리에 묶어 줍니다.

550 5.7.509가 실제로 뜻하는 것

DMARC는 기존 두 검사 — SPF와 DKIM — 를 사람이 실제로 보는 From 헤더의 도메인에 묶고, 둘 다 정렬 안 될 때 무엇을 할지 게시된 정책을 더합니다. ‘정렬(alignment)‘이 핵심입니다: SPF 통과는 SPF가 인증한 도메인이 당신 From과 맞을 때만 DMARC에 유효하고, DKIM 서명은 서명 도메인(d=)이 당신 From과 맞을 때만 유효합니다. 메시지는 그중 하나라도 정렬되면 DMARC를 통과합니다. 어느 쪽도 안 되면 DMARC 실패이고, 수신자는 당신 DMARC 레코드의 p= 태그가 말하는 대로 적용합니다: none, quarantine, reject.

550 5.7.509는 Microsoft가 p=reject를 적용하는 겁니다. 수신측은 수신 테넌트의 안티피싱 정책 — HonorDmarcPolicy 컨트롤 — 이 다스리지만, 현대 기본값은 발신자가 무시당하던 시절과 달리 발신자의 명시된 정책을 존중합니다. 그래서 코드는 정확합니다: DMARC가 실패했고 그리고 당신 도메인이 거부를 요청했다는 뜻. 아무것도 재발급하지 않고, 수신측에서 화이트리스트하지 않고, 스팸 설정을 바꿔도 이건 안 움직입니다. 정상 메일에서 5.7.509를 푸는 유일한 것은 그 발송 스트림이 정렬된 SPF나 DKIM 통과를 만들게 하는 겁니다.

이 점이 이웃 코드들과도 갈립니다. 5.7.1은 DMARC 의미가 없는 옛 일반 정책 거부입니다. 5.7.26은 Gmail의 ‘다중 인증 검사 실패’ 대량 발신자 규칙 — 같은 발상, 다른 수신자와 규칙서입니다. 5.7.515는 Outlook.com의 소비자 대량 발신자 기준으로 별도 집행 트랙입니다. 그리고 5.7.520은 인증이 아예 아니고 — Microsoft가 외부 자동 전달을 막는 겁니다. 5.7.509는 “당신이 게시한 DMARC reject 정책이 이 메시지를 잡았다”를 뜻하는 유일한 코드입니다.

주요 원인

1. 도메인에 정렬 안 된 서드파티 발신자 — 압도적으로 흔합니다. 마케팅·지원·청구 플랫폼이 당신 ‘으로서’ 보내지만 자기 return-path로 SPF를 통과하고 자기 도메인으로 DKIM을 서명합니다. 둘 다 인증되지만 어느 쪽도 당신 From과 정렬 안 됨 → DMARC 실패 → p=reject가 바운스. 해결은 그 벤더가 DKIM을 당신 도메인으로 서명하게 하거나(보통 그들이 주는 CNAME) SPF가 맞도록 Return-Path를 정렬하는 겁니다.
2. 전달로 깨진 SPF 단독 설정 — 스트림이 SPF 정렬에만 의존하는데 메일이 전달되면, 전달 홉이 봉투 발신자를 바꿔 SPF가 더는 정렬 안 됩니다(또는 아예 실패). 기댈 정렬된 DKIM 서명이 없으면 전달 뒤 DMARC가 실패합니다. DKIM 정렬이 지속 가능한 해결책입니다 — 유효한 DKIM 서명은 본문이 안 바뀌면 전달을 견딥니다.
3. 진짜 스푸핑 — 설계대로 작동 — 그 실패 경로로 당신이 실제로 안 보낸다면, 5.7.509는 DMARC가 제 일을 하는 겁니다: 누군가 당신 도메인을 위조했고 당신의 p=reject가 Microsoft 사서함에서 막은 것. 메시지에 ‘고칠’ 건 없고, 올바른 대응은 출처가 당신 것이 아님을 확인하고 그 거부를 성공한 방어로 여기는 겁니다.

DechoNet으로 진단

• 이메일 / DMARC 진단은 당신 도메인의 게시된 SPF·DKIM·DMARC 레코드를 DNS에서 읽습니다 — 거부를 일으키는 실제 p= 값과, SPF·DKIM이 애초에 당신 From과 정렬되도록 설정됐는지까지. 당신이 어떤 정책을 약속했고 정렬된 경로가 존재하기는 하는지 알려줍니다.
• 이메일 헤더 분석이 나머지 절반입니다: 바운스된 메시지(또는 전달된 사본)의 헤더를 붙여 넣고 Authentication-Results 줄을 읽어 어느 검사가 통과·정렬·실패했는지 정확히 보세요. ‘SPF는 통과했지만 정렬 안 됨’과 ‘DKIM이 서명된 적 없음’을 가르는 게 해결을 결정합니다.
• DNS 조회는 벤더가 추가하라고 한 TXT 레코드(DKIM 셀렉터 CNAME, SPF include)가 실제로 살아 해석되는지 확인합니다 — 누락·오타 레코드는 ‘설정됐다’는 스트림이 여전히 정렬 안 되는 흔한 이유입니다.

해결 체크리스트

• 메시지가 정당하게 당신 것인지 확인하세요. 그 경로로 안 보낸다면 5.7.509는 당신 DMARC 정책이 스푸핑을 막는 것 — 고칠 것 없이 제대로 작동 중입니다.
• 바운스된 메시지의 Authentication-Results를 읽으세요. SPF·DKIM이 통과했는지, 그리고 별개로 어느 쪽이든 당신 From과 정렬됐는지 확정하세요. 정렬 없는 통과가 전형적인 5.7.509 원인입니다.
• 실패하는 서드파티 스트림은 벤더와 함께 DKIM을 당신 도메인으로 서명 설정하세요(그들이 주는 CNAME/셀렉터). 정렬된 DKIM이 가장 확실하고 전달을 견딥니다.
• 가능한 곳에서 SPF를 정렬하세요 — 당신 도메인의 Return-Path/bounce 도메인을 써서 SPF 인증 도메인이 당신 From과 맞게 하세요.
• 외부 이메일 / DMARC 진단으로 게시된 레코드가 해석되고 정렬된 방법이 이제 하나라도 존재하는지 확인한 뒤, 다시 보내 바운스가 사라졌는지 확인하세요.
• DMARC 정책 완화(p=quarantine·p=none)는 정렬을 고치는 동안의 임시·의도적 조치로만 — 해결책이 아닙니다. 바운스를 멈추려고 정책을 약화하면 그걸 게시한 목적인 보호도 약해집니다.

언제 에스컬레이션할까

• 실패 메일이 서드파티 플랫폼을 거친다면, 그 플랫폼과 DNS 관리자에게 에스컬레이션하세요: 그들이 당신 도메인에 대해 도메인 정렬 DKIM과/또는 정렬된 Return-Path를 켜야 합니다. Microsoft 수신자는 이걸 못 고칩니다 — 그들은 당신이 게시한 정책을 존중할 뿐입니다.
• 메일이 전달 이후에만 깨지면, 전달 운영자에게 에스컬레이션하거나 그 스트림을 SPF가 아니라 정렬된 DKIM에 의존하도록 옮기세요. SPF는 대부분의 전달을 못 견디고, Microsoft 수신측 변경으로는 정렬이 복구되지 않습니다.
• 출처가 당신 것이 아님을 확인했다면 구할 전달은 없지만 — 그 패턴을 정보로 다루세요: 당신이 안 보낸 메일에 대한 반복된 5.7.509 거부는 무언가가 당신 도메인을 스푸핑하고 있고 당신의 p=reject가 그걸 잡고 있다는 신호입니다.