제품 팀은 Google SMTP 릴레이 서비스를 고를 때 무엇을 평가해야 하나요?

워크로드와 관리 적합성부터 확인하기

Google의 SMTP 릴레이 서비스는 smtp-relay.gmail.com을 통해 발송하는 애플리케이션, 기기, 메일 서버를 위한 Google Workspace 관리용 경로입니다. 아무나 접속하는 일반 SMTP 엔드포인트가 아니라 조직의 Workspace 및 메일 보안 경계의 일부로 평가하세요. Workspace 슈퍼 관리자 담당자, 계정에 포함된 도메인, 발신 시스템, 공용 송신 IP, 발신자 주소, 메시지 유형, 최대 및 일일 수신자 수, 첨부 파일 특성, 사고 연락처를 파악하세요. 워크로드가 트랜잭션, 내부 운영, 사용자 작성, 구독 기반 대량, 기기 생성 중 무엇인지 결정하세요. 승인, 수신 동의, 발송 제외, 감사, 평판에 대한 요구가 다르므로 이 유형들을 분리해 두세요. 하위 환경이 프로덕션 경로나 고객 주소를 사용할 수 없도록 하세요. 릴레이는 승인된 메시지를 전송할 수 있을 뿐이며, 비즈니스 이벤트가 정당한지, 수신자가 동의했는지, 이후의 애플리케이션 상태를 진행해도 되는지는 결정하지 않습니다.

IP 승인과 SMTP 인증 비교하기

Google의 현재 설정에서는 관리자가 릴레이 수신을 지정한 공용 IP 주소로 제한하거나, TLS를 통한 SMTP 인증을 요구하거나, 문서화된 설정에 따라 정책 선택지를 조합할 수 있습니다. 안정적인 IP 승인은 통제된 데이터 센터나 고정 송신 게이트웨이에 적합하지만, 변동하는 클라우드 NAT, 여러 리전, 장애 조치 서비스, 서드파티 네트워크 뒤에서는 깨지기 쉽습니다. SMTP 인증은 Workspace 계정과 발신 도메인을 식별하지만 자격 증명 수명 주기, 사용자 상태, 다단계 인증 및 정책과의 상호작용, TLS라는 필수 요건을 함께 가져옵니다. 여러 테넌트나 서로 무관한 애플리케이션에 폭넓은 자격 증명 하나를 쓰지 마세요. 각 방식마다 누가 IP나 계정을 추가할 수 있는지, 변경을 어떻게 검토하는지, 침해를 어떻게 감지하는지, 접근을 어떻게 폐기하는지, 장애 조치가 무엇을 하는지 문서화하세요. 허용하는 IP 범위는 실용적으로 가능한 한 작게 유지하고, 내부 주소를 복사하지 말고 실제 런타임의 공용 송신 주소를 확인하세요.

허용할 발신자와 도메인 ID 정의하기

관리 콘솔의 릴레이 설정은 어떤 발신자를 허용할지 제어합니다. Google은 등록된 Apps 사용자 및 소유한 도메인의 주소와 연결된 옵션, 그리고 악용 위험을 높이는 더 넓은 임의 주소 옵션을 문서화하고 있습니다. 워크로드가 충족할 수 있는 가장 좁은 옵션을 선택하세요. SMTP 엔벨로프 발신자를 보이는 From 및 Reply-To 필드와 별개로 파악하세요. Google은 발신자가 계정 도메인 밖에 있을 때 SMTP AUTH나 HELO 또는 EHLO에 제시된 도메인이 엔벨로프 발신자의 식별 방식이나 재작성에 영향을 줄 수 있다고 안내합니다. 재작성에 의존해 소유한 발신자 모델을 대체하지 마세요. 애플리케이션, 테넌트, 메시지 유형, 엔벨로프 발신자, 보이는 From 도메인, 반환 경로의 승인된 매핑을 요구하세요. Google에 연결하기 전에 임의의 사용자 제공 헤더, 개행 인젝션, 테넌트 간 From 주소를 차단하세요. 전체 설정을 약화하지 않으면서, 빈 엔벨로프 발신자를 포함해 반송 라우팅과 부재중 메시지를 테스트하세요.

전송 보안을 의도적으로 요구하기

Google의 현재 릴레이 가이드는 TLS를 사용하는 온프레미스 시스템에 대해 587 포트의 smtp-relay.gmail.com을 안내하며, SMTP 인증에 TLS가 필요하다고 설명합니다. 관리자 설정으로 발송 서버에서 오는 연결에 TLS를 요구할 수도 있습니다. 문서화된 레거시 제약에 대해 기간이 정해진 예외를 두는 경우가 아니라면 프로덕션에서는 필수 TLS를 활성화하세요. 서버 이름, 인증서 체인, 지원하는 프로토콜과 암호 정책, STARTTLS 협상, 실패 시 동작을 검증하세요. 필수 TLS 연결을 수립할 수 없으면 클라이언트는 연결을 거부해야 합니다. 조용히 평문으로 대체하면 정책이 무력화됩니다. SMTP 자격 증명은 관리형 시크릿 저장소에 보호하고, 명령줄, URL, 소스, 로그, 분석 도구, 크래시 보고서, 티켓에 넣지 마세요. 전송 구간의 TLS는 Google까지의 홉만 보호할 뿐 메시지의 전체 수명 주기나 메일함을 보호하지 않습니다. 민감한 내용에는 애플리케이션 수준의 제어, 데이터 최소화, 보존 정책, 별도의 종단 간 암호화 결정이 필요할 수 있습니다.

릴레이를 선택하기 전에 현재 할당량 모델링하기

Google의 현재 SMTP 릴레이 설정 문서에 따르면 사용자 한 명은 24시간 동안 최대 10,000통의 메시지를, 고유 수신자 10,000명 이하로 보낼 수 있으며 체험 계정에는 더 낮은 한도가 적용될 수 있습니다. 또한 SMTP 트랜잭션당 수신자 100명 제한과 추가적인 고객별, 피크 시, 일일 제어도 문서화되어 있습니다. 이를 용량 목표나 영구적인 계약이 아니라 현재 문서화된 상한으로 취급하세요. 출시 전에 계정과 워크로드에 대한 공식 페이지를 다시 확인하세요. 메시지 수만이 아니라 To, Cc, Bcc, 재시도, 팬아웃에 걸친 수신자 수를 계산하세요. 애플리케이션 수준의 속도, 동시성, 큐 대기 시간, 테넌트 공정성 제어를 Google 한도보다 낮게 설정하세요. 증가 속도와 남은 여유 용량에 대해 알림을 설정하세요. 한도에 걸렸다고 승인되지 않은 계정에 트래픽을 분산하거나, 엔벨로프 발신자를 돌려 쓰거나, 통제되지 않은 연결을 여는 방식으로 대응하지 마세요. 공유 Workspace 경계에 정기적으로 근접하는 워크로드는 목적에 맞는 전송 수단을 별도로 평가해야 할 수 있습니다.

내구성 있는 제출 워크플로 구축하기

SMTP 클라이언트는 승인된 서버 워커나 큐 뒤에 두세요. 안정적인 비즈니스 이벤트 키, 테넌트, 메시지 유형, 템플릿 리비전, 승인된 발신자와 수신자, 수신 동의 또는 필요성 근거, 발송 제외 결정, 시도 이력을 갖춘 발신 작업 하나를 저장하세요. 그 작업을 한 번만 가져와 콘텐츠를 렌더링하고 검증한 다음 구성된 Google 엔드포인트에 연결하세요. 현재 한도와 제품 정책에 따라 트랜잭션당 수신자와 메시지 크기에 상한을 두세요. 자격 증명이나 불필요한 내용은 로깅하지 않으면서 전체 SMTP 응답, 확장 상태 코드, 원격 호스트, 타임스탬프, 시도 식별자를 기록하세요. 릴레이가 DATA 트랜잭션을 수락하면 제공업체 또는 릴레이의 접수 단계로만 표시하세요. 데이터를 보낸 뒤 최종 응답을 확인하기 전에 클라이언트가 타임아웃되면 그 시도를 알 수 없음 상태로 유지하고 다시 보내기 전에 조정하세요. SMTP에는 애플리케이션 멱등성 키가 없으므로 중복 방지는 제품의 큐와 이벤트 모델이 맡아야 합니다.

모든 것을 재시도하지 말고 릴레이 오류를 분류하기

Google의 SMTP 릴레이 오류 페이지는 메일 릴레이 거부, 잘못된 릴레이 자격 증명 또는 도메인 식별, 일일 한도 초과, 일시적인 최대 한도 지연, 한 트랜잭션에 수신자가 너무 많음 같은 서로 다른 상황을 문서화합니다. 정확한 응답을 기록하고 좁은 범위의 내부 분류에 대응시키세요. 재전송하기 전에 구성, 발신 도메인, 자격 증명, IP, 트랜잭션당 수신자 오류를 바로잡으세요. 일일 한도가 소진되면 작업을 일시 중지하거나 다시 예약하세요. 재시도할 수 있는 일시적인 최대 한도 오류나 전송 오류는 지수 백오프, 지터, 시도 횟수 상한, 큐 대기 시간 제한으로 재시도하세요. 영구적인 응답은 무한히 재시도하지 마세요. 오류가 등록되지 않은 IP를 언급한다면 허용 목록을 넓히지 말고 런타임의 실제 공용 송신 주소와 올바른 Workspace 설정을 확인하세요. 발송 시스템, 구성 리비전, 발신 도메인, 상태 유형, 시간별로 개인정보를 최소화한 집계 건수를 보존하세요. 정책 변동, 자격 증명 폐기, NAT 변경, 악용의 신호일 수 있으므로 처음 보는 응답과 인증 급증에 대해 알림을 설정하세요.

릴레이 접근을 넘어 발신자 인증하기

Google 릴레이를 사용할 권한이 있다고 해서 수신자에게 보이는 발신자 인증이 되는 것은 아닙니다. 엔벨로프 ID의 실제 발송 경로를 승인하는 SPF 정책을 게시하고, 조직이 통제하며 DMARC 정렬이 되는 도메인으로 DKIM 서명을 구성하고, 보이는 From 도메인에 대해 검토를 마친 DMARC 정책을 게시하세요. 통제된 외부 메일함에서 수신된 원본 메시지를 검증하세요. SPF 결과와 도메인, DKIM 결과, d= 도메인과 셀렉터, 보이는 From 도메인, 정렬, DMARC 결과를 기록하세요. 기술적으로 유효한 제공업체나 Workspace 서명도 사용자 지정 From 도메인과는 정렬되지 않을 수 있습니다. 전달(forwarding)도 SPF 증거를 바꿀 수 있습니다. 테스트 하나를 통과시키려고 두 번째 SPF 레코드를 추가하거나 조직 전체의 DMARC를 약화하지 마세요. DNS 및 메일 관리자와 조율하고, 이전 레코드를 보존하고, 권한 있는 응답과 재귀 응답을 테스트하고, ID 변경은 한 번에 하나씩 적용하세요.

관측성과 검증된 종료 경로 요구하기

가능한 곳에서는 Google 관리자 이메일 로그 검색과 릴레이 측 로그를 사용하되, 결정의 기준 시스템은 제품이 소유한 발신 원장으로 유지하세요. 메시지 유형과 발신 도메인별로 큐 대기 시간, 접수, 일시적 및 영구적 응답, 한도 사용량, 반송 및 스팸 신고 신호, 인증, 지연 시간을 모니터링하세요. 접근을 제한하고 일상적인 지표에는 전체 주소나 내용을 넣지 마세요. 소스 IP 변경, 자격 증명 교체, TLS 실패, 관리자 설정 비활성화, 사용자 정지, 한도 소진, 수신자 팬아웃, DNS 변경, 제공업체 장애를 테스트하세요. 내구성 있는 작업을 잃지 않고 영향을 받는 그룹을 일시 중지할 수 있는 롤백을 정의하세요. 마이그레이션에 대비해 제공업체 고유의 SMTP 필드를 하나의 어댑터에 격리하고, 비즈니스 이벤트 키, 발송 제외 상태, 발신자 승인, 시도 이력을 보존하세요. 두 번째 릴레이가 영구적인 정책 거부나 수신자 거부를 우회하는 자동 경로가 되어서는 안 됩니다. 호환성은 호스트 이름을 바꾸는 것만이 아니라 필드 수준과 오류 수준의 테스트가 필요합니다.

SendHQ의 활용 방식

SendHQ는 검증된 도메인 발송, 수신 이메일, 호스팅 템플릿, 전달 이벤트, 발송 제외, 웹 대시보드를 갖춘 예상되는 제품 커뮤니케이션을 위한 워크스페이스 단위 이메일 API입니다. 현재 문서와 제어된 테스트로 Google Workspace SMTP 릴레이와 계정 및 테넌트 경계, 자격 증명과 교체, 허용 발신자 적용, 엔벨로프 및 표시 ID, TLS 실패, 수신자 제한, 일시적 및 영구 응답, 모호한 결과, 발송 제외, 이벤트 재조회, 마이그레이션을 비교하세요.

자주 묻는 질문

출처

• Google을 통해 발신 SMTP 릴레이 메시지 라우팅하기 — Google Workspace
• SMTP 릴레이 서비스 오류 메시지 — Google Workspace
• RFC 3207: TLS 기반 보안 SMTP를 위한 SMTP 서비스 확장 — RFC Editor
• RFC 7208: 발신자 정책 프레임워크(Sender Policy Framework) — RFC Editor
• RFC 6376: DKIM(DomainKeys Identified Mail) 서명 — RFC Editor
• RFC 7489: 도메인 기반 메시지 인증, 보고 및 준수(DMARC) — RFC Editor
• RFC 5321: 단순 메일 전송 프로토콜(SMTP) — RFC Editor