제품 팀은 Cloudflare 이메일 라우팅을 어떻게 안전하게 구현해야 하나요?

수신 작업과 소유권 경계를 정의하세요

먼저 수신 작업을 정확히 적어 두세요. 어떤 도메인과 로컬 파트가 메일을 받을지, 각 대상 주소의 소유자는 누구인지, 메시지를 전달할지 코드로 처리할지 폐기할지, 운영 증거를 얼마나 오래 보관할 수 있는지를 정합니다. Cloudflare Email Routing은 수신 라우팅 계층입니다. 그 자체로 지원 티켓을 만들거나, 발신자 ID를 확립하거나, 전달된 메일이 사람에게 도달했음을 증명하거나, 대상 주소의 메일함 도달을 보장하지 않습니다. 이러한 후속 애플리케이션 상태는 분리해서 관리하세요. DNS, 라우팅 규칙, Worker 코드, 대상 주소 검증, 보안 사고, 롤백에 대한 운영 담당자를 지정하세요. 첫 롤아웃에서는 catch-all 대신 support@나 invoices@ 같은 전용 별칭을 사용하세요. 라우트를 좁게 잡으면 의도치 않은 수집이 줄고, 테스트 결과를 해석하기 쉬워지며, 잘못된 대상 주소나 Worker 분기의 영향이 제한됩니다.

DNS를 맹목적인 설치 단계로 취급하지 말고 도메인을 온보딩하세요

Cloudflare의 최신 Email Service 문서에 따르면 Email Routing을 사용하려면 도메인이 Cloudflare DNS를 사용해야 합니다. 온보딩 과정에서 수신 라우팅용 MX 레코드와, 제품이 설명하는 SPF 및 DKIM 관련 TXT 레코드가 추가될 수 있습니다. 적용하기 전에 제안된 레코드를 정확히 검토하세요. 먼저 기존 MX, SPF, DKIM, DMARC, 메일함, 전달 서비스, 검증 토큰, 서브도메인 위임을 목록으로 정리하세요. MX 레코드를 바꾸면 새 수신 SMTP 세션이 향하는 곳이 바뀌므로, 점검 시간을 조율하고 이전 값을 롤백 기록으로 보존하세요. 하나의 소유자 이름에 SPF TXT 레코드를 여러 개 만들지 마세요. 변경 후에는 권한 있는 리졸버와 공개 리졸버를 조회한 다음, 대상 주소와 관련 없는 계정에서 전달을 테스트하세요. DNS 전파 예상 시간은 모든 발신자가 이제 같은 응답을 본다는 증거가 아니며, 대시보드가 녹색이라고 해서 종단 간 전달이 증명되지도 않습니다.

활성 라우트를 만들기 전에 대상 주소를 검증하세요

Cloudflare는 대상 주소를 계정 수준 리소스로 설명하며, 라우팅 규칙에서 사용하려면 먼저 검증해야 합니다. 검증 단계는 중요한 남용 방지 경계입니다. 그 시점에 메일함을 통제하고 있음을 보여 주지만, 지속적인 업무상 승인이나 올바른 팀 소속을 증명하지는 않습니다. 요청 담당자, 목적, 검증 날짜, 검토 날짜를 자체 시스템에 기록하세요. 직원의 개인 주소보다는 팀이 관리하는 대상 주소를 사용하세요. 퇴사한 사용자의 대상 주소는 즉시 제거하되, Cloudflare 문서에 따르면 대상 주소를 삭제하면 그 주소를 사용하는 라우트가 비활성화되므로 삭제 전에 어떤 규칙이 해당 주소에 의존하는지 확인하세요. 검증 이메일은 보안에 민감한 것으로 취급하고, 신뢰할 수 없는 자동화에 자동 클릭하거나 전달하지 마세요. 대시보드에서는 한 명의 운영자가 규칙을 저장할 수 있더라도, 프로덕션 변경은 일반적인 인프라 프로세스에 따라 다른 사람의 검토를 거치게 하세요.

명시적 규칙을 만들고 우선순위를 이해하세요

라우팅 규칙은 이메일 패턴을 검증된 대상 주소 또는 Worker와 짝짓습니다. Cloudflare는 이메일로 보내기, Worker로 보내기, 폐기(drop)의 세 가지 동작을 문서화하고 있습니다. 가장 구체적인 로컬 파트 라우트를 먼저 만들고, 변경 기록에 담당자를 명시하며, 패턴마다 의도한 규칙이 하나뿐인지 확인하세요. 문서에는 여러 규칙이 같은 패턴을 사용하면 목록에서 가장 먼저 나오는 규칙만 수신 메일을 처리한다고 경고되어 있습니다. 화면에 보이는 순서를 비공식적인 업무 규칙으로 삼지 말고 모호성을 없애세요. 삭제는 의도적으로 전달하지 않는 것이므로 폐기 규칙은 근거를 좁게 잡으세요. catch-all은 개인정보, 스팸 물량, 오타, 저장에 미치는 영향을 나열해 본 뒤에만 활성화하세요. catch-all은 아무도 만들려고 하지 않았던 주소까지 수집할 수 있으므로, 개인 메일함을 조용히 물려받게 두지 말고 전용 대상 주소 또는 Worker 정책, 알림, 빠른 비활성화 경로를 마련해야 합니다.

서브어드레싱을 의도적으로 사용하세요

Cloudflare는 RFC 5233에 부합하는 선택적 플러스 주소 지정을 문서화하고 있습니다. 이를 활성화하면 user+detail@example.com 같은 주소로 온 메일이 기본 user@example.com 규칙과 일치할 수 있으며, Worker와 로그에 노출되는 메시지 수신자에는 detail이 그대로 보존됩니다. 이는 라우팅 태그, 테스트 식별자, 워크플로별 별칭에 활용할 수 있지만, detail은 발신자가 통제하는 텍스트입니다. 인증된 테넌트 ID, 권한 부여, 비밀로 취급하지 마세요. 데이터베이스 키, 메트릭 차원, 큐 이름으로 사용하기 전에 정규화하고 길이에 상한을 두세요. Cloudflare는 전체 서브어드레스에 대한 명시적 규칙이 기본 규칙보다 우선한다고도 문서화하고 있습니다. 나중에 추가한 구체적인 규칙이 기존 워크플로를 조용히 바꾸지 않도록 명시적 규칙과 대체 규칙의 경우를 모두 테스트하세요. 플러스 태그는 헤더, 로그, 전달된 메시지, 지원 내보내기, 분석에 나타날 수 있으므로 개인 정보나 기밀 데이터를 넣지 마세요.

실제로 처리가 필요할 때만 Worker를 선택하세요

주소 하나를 검증된 메일함 하나로 보내기만 하면 되는 경우에는 직접 전달을 사용하세요. 통제된 분기, 메시지 검사, 저장, 거부, 답장, 여러 곳으로의 전달이 필요할 때 Worker로 라우팅하세요. Cloudflare의 이메일 핸들러는 엔벨로프 발신자와 수신자, 헤더, 원본 MIME 스트림, 크기, 그리고 전달, 답장, 거부를 위한 메서드를 제공합니다. 핸들러는 작게 유지하세요. 먼저 수신자 정책을 검증하고, 메시지와 파싱의 상한을 적용하고, 가능하면 시간 제한이 있는 큐를 통해 외부 호출을 수행하고, 모든 오류에 대한 결과를 정의하세요. 헤더, 제목, 표시 이름, 첨부 파일, 링크, MIME 경계는 모두 공격자가 통제할 수 있습니다. 기본적으로 원본 본문이나 전체 주소를 로그에 남기지 마세요. 내용을 저장해야 한다면 암호화하고, 테넌트와 작업 단위로 접근을 제한하고, 삭제 방침을 정의하고, 동기 라우팅 경로 밖에서 첨부 파일을 검사하세요. 파싱 예외가 의도하지 않은 전달이나 답장으로 이어져서는 안 됩니다.

명시적인 결정 경로를 하나 구현하세요

안전한 핸들러는 부수 효과를 수행하기 전에 승인된 동작을 먼저 계산해야 합니다. 예를 들어 정확한 엔벨로프 수신자를 구성된 워크플로에 매핑하고, 알 수 없는 수신자는 거부하고, 상한이 있는 메타데이터 레코드를 큐에 넣은 다음, 구성에서 선택한 검증된 대상 주소로만 전달하세요. 메시지 헤더, 제목, 플러스 태그, 본문에서 대상 주소를 받아들이지 마세요. 여러 대상 주소로 전달할 때는 Cloudflare의 한도 문서에 따라 Worker가 검증된 대상 주소마다 forward를 한 번씩 호출해야 합니다. 부분 성공을 허용할 수 있는지 정하고 각 시도를 따로 기록하세요. 로그에는 수신자 내용 대신 안정적인 내부 상관 식별자를 사용하세요. 핸들러가 답장할 수 있다면 Cloudflare의 최신 답장 제약을 따르고 루프 방지를 추가하세요. 자동 답장은 사람 팀의 확인 응답이 아닙니다. 애플리케이션에 내구성 있는 접수가 필요하다면, 자동 응답을 보내기 전에 티켓이나 이벤트를 저장하고, 작업이 생성되었다고 약속하지 말고 모호한 실패를 대조하세요.

전달과 답장을 증거 범위가 정해진 결과로 취급하세요

Worker 메서드 호출이 성공했다는 것은 플랫폼 작업에 대한 증거이지 최종 사용자 결과가 아닙니다. SMTP는 시스템 간 전송을 정의하며, 이후의 필터링, 전달, 격리, 메일함 규칙, 사람의 열람은 그 구간 밖에 있습니다. Cloudflare가 수신함, Worker 호출됨, 동작 시도됨, 대상 서버가 수락함, 지연 또는 실패함, 애플리케이션 레코드 생성됨 같은 상태를 별도로 모델링하세요. 이를 모두 전달됨으로 표시하지 마세요. 규칙 ID, Worker 리비전, 동작, 타임스탬프, 상관 식별자, 대략적인 결과를 담은 구조화되고 개인정보를 최소화한 로그를 유지하세요. 전체 주소나 내용은 문서화된 운영상의 필요가 있는 곳에만 저장하세요. 호출 실패, 크기 거부, 비정상적인 catch-all 물량, 반복되는 발신자 패턴, 대상 주소 실패, 갑작스러운 트래픽 변화에 대해 알림을 설정하세요. 통제된 테스트 메시지를 지속적으로 샘플링하되, 실제 고객 콘텐츠를 관측용 픽스처로 사용하지 마세요.

현재 플랫폼 한도와 실패 모드를 준수하세요

Cloudflare는 현재 Email Routing 한도로 도메인당 라우팅 규칙 200개, 계정당 대상 주소 200개, 수신 메시지 크기 25 MiB, 그리고 Worker로 라우팅되는 메시지에 대한 표준 Workers CPU 및 메모리 한도를 문서화하고 있습니다. 이 값들은 영구적인 상수가 아니라 현재의 제공업체 문서로 취급하세요. 계획 단계에서 실제 한도 페이지를 읽고, 상한에 이르기 훨씬 전에 알림을 설정하세요. 큰 MIME 메시지는 부주의하게 디코딩하면 플랫폼의 원본 크기 상한보다 작아도 메모리나 CPU를 소진할 수 있습니다. 불필요한 콘텐츠는 스트리밍하거나 거부하고, 첨부 파일 수에 상한을 두고, 비용이 큰 파싱은 상한이 있는 비동기 작업 뒤에 두세요. Cloudflare의 라우팅 문서에 따르면 Worker 이름을 바꾸면 라우팅 바인딩이 깨질 수 있으므로, 배포 검증에 라우트 점검을 포함하세요. 실패한 호출은 Workers 로그에서 확인할 수 있어야 하지만, 로그만으로는 재처리(replay)가 이루어지지 않습니다. 발신자가 SMTP로 재시도해야 하는지, 운영자가 애플리케이션 작업을 안전하게 재처리할 수 있는지, 후속 레코드의 중복을 어떻게 방지할지 정하세요.

롤아웃과 롤백을 하나의 변경으로 테스트하세요

먼저 스테이징 또는 위험이 낮은 라우트를 만드세요. 검증된 대상 주소와 다른 계정에서 통제된 메시지를 보내되, 일반 텍스트, 멀티파트 콘텐츠, 예상되는 첨부 파일, 플러스 주소 지정, 알 수 없는 로컬 파트, 안전한 한도 내의 의도적으로 잘못된 입력을 다루세요. DNS 응답, 대시보드 구성, Worker 리비전, 전달 결과, 후속 레코드, 개인정보 동작을 검증하세요. 그런 다음 부정적인 경로를 테스트하세요. 검증되지 않은 대상 주소, 비활성화된 규칙, Worker 예외, 크기 초과 메시지, 반복 전달, 그리고 그렇지 않았다면 catch-all로 빠졌을 규칙이 여기에 해당합니다. 단계마다 예상되는 증거를 기록하세요. 트래픽을 늘리기 전에 규칙 비활성화, 필요한 경우 이전 MX 레코드 복원, Worker 분리, 지연되거나 거부된 메일에 대한 안내를 미리 연습하세요. 원인을 알 수 없는 라우팅 유실, 테넌트 간 노출, 콘텐츠 유출, 예기치 않은 답장, 상한 없는 저장, 지속적인 Worker 실패가 있으면 롤백하세요. 메시지 내용은 필요 이상으로 오래 보관하지 않으면서 구성 스냅샷과 테스트 결과는 보존하세요.

SendHQ의 활용 방식

SendHQ는 수신 이메일을 지원합니다. 이 가이드는 Cloudflare Email Routing을 다루며, 각 서비스의 설정과 제한은 해당 문서를 따르세요.

자주 묻는 질문

출처

• 이메일 라우팅하기 — Cloudflare
• 이메일 라우팅 규칙과 주소 — Cloudflare
• 라우팅된 이메일을 위한 Workers API — Cloudflare
• Cloudflare Email Service 한도 — Cloudflare
• RFC 5321: 단순 메일 전송 프로토콜(SMTP) — RFC Editor
• RFC 5233: Sieve 이메일 필터링: 서브어드레스 확장 — RFC Editor