발신 이메일 서버: 더 나은 이메일 도달률을 위한 가이드

중요한 캠페인 이메일을 보냅니다. 제품 업데이트, 채용 후속 조치, 기부자 공지 또는 영업 시퀀스일 수 있습니다. 전송 버튼을 누르고 진행률 표시줄이 완료되는 것을 지켜본 다음, 불확실성이 시작됩니다.

이메일이 도착했을까요? 받은 편지함에 들어갔을까요, 아니면 스팸으로 분류되었거나, 지연되었거나, 누군가 보기 전에 거부되었을까요?

이러한 불안감은 보통 이메일 문구, 제목, 또는 리스트 품질 탓으로 돌려집니다. 물론 그것들도 중요합니다. 하지만 문제가 발생하기 전까지 많은 비즈니스 사용자가 생각하지 못하는 배후의 또 다른 요소가 있습니다. 바로 발신 이메일 서버입니다.

Gmail, Outlook, Apple Mail, CRM, 웹사이트 양식 또는 메일 머지 도구를 사용하더라도 메시지는 이메일을 가져와 확인하고, 경로를 지정하고, 수신자의 메일 제공업체에 전달하는 시스템이 필요합니다. 이 설정이 잘못되면 완벽하게 작성된 이메일이라도 사라질 수 있습니다.

이 분야의 도구를 조사하기 전에 한 가지 주의할 점이 있습니다. Mail Merge for Gmail은 매우 설명적인 제품 이름이므로 Gmail용 다른 메일 머지 도구와 혼동하기 쉽습니다. 온라인에서 정보를 검토할 때는 해당 페이지가 특정 제품을 지칭하는지, 아니면 비슷한 이름을 가진 경쟁 제품을 지칭하는지 다시 한번 확인하세요.

이메일이 사라지는 이유

마케팅 관리자가 월요일 아침에 고객 공지를 보냅니다. 점심시간이 지났는데 회신이 예상보다 적습니다. 오후가 되자 몇몇 고객이 이메일을 받지 못했다고 말합니다. 누군가 스팸함을 확인합니다. 다른 사람은 반송 알림 스크린샷을 전달합니다. 갑자기 참여 문제로 보였던 것이 전달 문제로 바뀝니다.

보통 여기서 발신 이메일 서버가 등장합니다.

발신 서버는 작성한 메시지를 가져와 수신자의 메일 제공업체에 전달하는 역할을 하는 시스템입니다. 서버가 잘못 구성되었거나, 신뢰할 수 없거나, 차단되었거나, 주요 인증 신호가 누락된 경우 수신 측은 의심을 하게 됩니다. 이러한 의심은 종종 스팸 분류, 메시지 거부 또는 조용한 필터링으로 나타납니다.

혼란스러운 부분

대부분의 사용자는 “Gmail에서 보냈어” 또는 “이메일 앱에서 보냈어”가 전부라고 생각합니다. 그렇지 않습니다. 앱은 단지 프런트엔드일 뿐입니다. 실제 전달은 서버 인프라를 통해 이루어집니다.

간단히 생각하면 다음과 같습니다.

• 받은 편지함 앱은 책상입니다.
• 발신 서버는 우체국 창구입니다.
• 수신 제공업체는 메일을 수락, 검사 또는 거부할지 결정합니다.

우체국 창구에서 당신이 누구인지 증명할 수 없거나, 잘못된 경로를 사용하거나, 의심스러워 보이면 메시지는 원활하게 이동하지 않습니다.

실용적인 규칙: 이메일이 명확한 오류 없이 사라진다면 메시지를 다시 작성하는 것부터 시작하지 마세요. 전송 경로를 확인하는 것부터 시작하세요.

이것이 바로 전달 가능성 작업이 창의적인 변경이 아닌 기술적인 신뢰에서 시작되는 이유입니다. 도메인 평판, 인증 기록 및 서버 설정은 모두 제공업체가 귀하의 메일을 합법적인 비즈니스 커뮤니케이션으로 취급할지, 아니면 스푸핑(사칭)으로 취급할지에 영향을 미칩니다. 해당 신뢰 계층에 대한 유용한 입문서를 원하신다면 email sender reputation에 관한 이 가이드를 읽어볼 가치가 있습니다.

실제 의미

사람들이 “이메일 전달 가능성”을 말할 때, 보통 일련의 결정 과정을 의미합니다.

1. 수신 서버가 귀하의 발신 서버에 연결할 수 있는가?
2. 귀하의 서버가 합법적으로 보이는가?
3. 귀하의 도메인이 인증 기록과 일치하는가?
4. 콘텐츠가 수락할 만큼 안전해 보이는가?

발신 이메일 서버는 그 체인의 시작 부분에 위치합니다. 잘 설정되어 있으면 그 이후의 모든 것이 쉬워집니다. 잘못 설정되어 있으면 캠페인이 불리한 조건에서 시작됩니다.

발신 이메일 서버란 무엇인가

발신 이메일 서버를 이메일의 디지털 우체국이라고 생각하세요. Gmail, Outlook, Apple Mail 또는 다른 앱에서 메시지를 작성하지만, 해당 앱은 메시지를 더 넓은 인터넷으로 전달하기 위해 신뢰할 수 있는 전송 시스템이 필요합니다.

이 전송 시스템은 SMTP(Simple Mail Transfer Protocol, 간이 메일 전송 프로토콜)를 따릅니다. Mailtrap’s explanation of email servers에 따르면, 발신 이메일 서버는 SMTP에 의존하며, 메일 서버 간의 통신은 주로 TCP 포트 25를 통해 이루어지고, 인증된 클라이언트 제출은 TLS 암호화를 통해 보안 전송을 보장하는 포트 587 또는 포트 465를 사용합니다.

시각적으로 보면 다음과 같습니다.

5단계 여정

전송 버튼을 누른 후 발생하는 일은 다음과 같습니다.

1. 메시지 작성
   이메일 앱이 제목, 본문, 수신자 및 첨부 파일을 패키징합니다.

2. 앱이 발신 서버에 연결
   이것이 첫 번째 전달입니다. 기기나 소프트웨어가 메시지를 발신 서버에 제출합니다.

3. 서버가 기본 사항 확인
   시스템은 메시지가 올바르게 구성되었고 전송 준비가 되었는지 확인합니다.

4. 서버가 수신자의 제공업체를 찾음
   해당 도메인의 메일이 어디로 가야 하는지 조회하고 메시지를 외부로 라우팅합니다.

5. 수신 측이 메시지 평가
   수신자의 제공업체는 메시지를 수락, 필터링, 격리 또는 거부할지 결정합니다.

영상을 선호하신다면 짧은 가이드를 확인하세요.

배후에서 일어나는 두 가지 작업

전송 경로에는 기술적으로 들리지만 이해하기 쉬운 두 가지 역할이 포함됩니다.

MSA가 제출을 처리

MSA(Mail Submission Agent, 메일 제출 에이전트)는 첫 번째 검문소입니다. 사용자나 애플리케이션으로부터 메시지를 수락합니다. 이 단계에서 초기 유효성 검사가 수행됩니다. 메시지가 전달되기 전에 시스템이 형식과 첨부 파일 무결성을 확인합니다.

MSA를 우체국 창구 직원이라고 생각하면 됩니다. 소포가 메일 스트림에 들어가기 전에 라벨이 제대로 붙었는지 확인합니다.

MTA가 전달을 처리

MTA(Mail Transfer Agent, 메일 전송 에이전트)는 메시지를 수신자의 메일 시스템으로 라우팅하는 부분입니다. 다른 메일 서버와 통신하여 전달을 완료하려고 시도합니다.

이것은 창구 뒤의 배송 네트워크와 같습니다. 트럭, 경로, 전달 및 목적지 분류가 모두 여기서 이루어집니다.

발신 도메인의 SPF, DKIM 또는 DMARC 설정이 일치하지 않으면 수신 시스템이 사람이 보기 전에 메시지를 거부할 수 있습니다.

포트가 중요한 이유

많은 비기술적 사용자는 종종 막히곤 합니다. “SMTP는 포트 25를 사용한다”는 말을 듣고 항상 사용해야 하는 설정이라고 가정합니다. 실제로는 클라이언트 전송이 일반적으로 그렇게 작동하지 않습니다.

• 포트 25는 주로 서버 간 릴레이용입니다.
• 포트 587은 일반적으로 인증된 클라이언트 제출에 사용됩니다.
• 포트 465는 많은 설정에서 보안 제출에 사용됩니다.

이메일 앱, 플러그인 또는 비즈니스 소프트웨어에 발신 메일 설정을 입력하는 경우, 일반적으로 서버 릴레이 계층이 아닌 프로세스의 클라이언트 제출 부분에서 작업하는 것입니다.

발신 이메일 서버의 유형

모든 발신 이메일 서버가 같은 작업을 위해 만들어진 것은 아닙니다. 소규모 비즈니스는 보통 세 가지 선택지에 직면합니다. 이메일 제공업체의 기본 서버를 사용하거나, 자체 서버를 설정하거나, 전용 SMTP 릴레이 서비스를 통해 보내는 것입니다.

올바른 옵션은 무엇을 보내는지, 얼마나 많은 제어가 필요한지, 팀이 전달 가능성 위험을 관리할 수 있는지에 따라 다릅니다.

제공업체 서버

가장 익숙한 옵션입니다. 회사에서 Gmail이나 Microsoft 365를 사용 중이라면 이미 제공업체가 관리하는 전송 환경을 사용하고 있는 것입니다. 즉, 인프라, 보안 및 서버 유지 관리가 귀하를 대신하여 처리됩니다.

대부분의 비즈니스 사용자에게는 다음과 같은 이유로 가장 간단한 경로입니다.

• 설정이 간편함. 제공업체의 표준 SMTP 설정을 사용합니다.
• 신뢰도가 높음. 대형 제공업체는 성숙한 전송 인프라를 운영합니다.
• 유지 관리가 적음. 팀이 메일 서버를 관리할 필요가 없습니다.

이는 일반적인 비즈니스 커뮤니케이션, 개인화된 아웃리치 및 업무 계정에서 적당한 캠페인 전송에 가장 적합한 경우가 많습니다.

자체 호스팅 서버

자체 SMTP 서버를 운영하는 것은 완전한 제어가 가능한 것처럼 느껴져 매력적으로 들립니다. 실제로는 종종 전달 가능성 문제를 일으킵니다.

검증된 데이터에 따르면 주거용 IP나 구성되지 않은 VPS에서 자체 호스팅된 SMTP 릴레이는 빠르게 블랙리스트에 오르며, 80%가 기본적인 PTR 레코드 확인을 통과하지 못하는 반면, 적절한 정렬을 갖춘 인증된 타사 SMTP 서비스를 사용하면 95% 이상의 전달률을 보입니다.

수신 제공업체는 귀하가 서버를 “소유”하는지보다 서버를 신뢰하는지를 더 중요하게 생각하기 때문에 이 격차는 중요합니다.

많은 팀에서 자체 호스팅이 실패하는 이유

자체 호스팅 설정은 여러 가지 방식으로 무너질 수 있습니다.

• 낮은 평판 기록. 새 IP나 신뢰도가 낮은 IP는 자동으로 신뢰할 수 있어 보이지 않습니다.
• 역방향 DNS 및 정렬 누락. 수신 서버는 기술적 신원 확인이 일치하기를 기대합니다.
• 운영 부담. 누군가 인증, 릴레이 규칙 및 남용 방지를 모니터링해야 합니다.

자체 호스팅 SMTP 서버는 제한된 애플리케이션 이메일이나 내부용으로 여전히 작동할 수 있습니다. 특히 캠페인의 경우 사람들이 기대하는 쉬운 경로가 아닌 경우가 많습니다.

메일 서버를 소유한다고 해서 전달 가능성에 대한 제어가 보장되지는 않습니다. 수신 제공업체가 최종 신뢰 결정을 내립니다.

전용 SMTP 릴레이 서비스

세 번째 범주는 귀하를 대신하여 이메일을 안정적으로 보내기 위해 구축된 전문 서비스입니다. 이러한 도구는 인증, 평판 관리, 전달 가시성 및 정책 준수에 중점을 둡니다.

이 옵션은 팀이 표준 사서함이 지원할 수 있는 것보다 더 많은 전송 유연성이 필요하지만 메일 인프라를 처음부터 운영하고 싶지 않을 때 합리적입니다.

간단히 말해 장단점은 다음과 같습니다.

옵션	최적의 용도	주요 강점	주요 위험
제공업체 서버	일상적인 비즈니스 이메일	단순성 및 신뢰성	제공업체 전송 제한
자체 호스팅 서버	좁은 사용 사례를 가진 기술 팀	완전한 인프라 제어	평판 및 거부 위험
전용 SMTP 릴레이	대량 또는 운영 전송	관리형 전달 가능성 도구	추가적인 플랫폼 복잡성

대부분의 소규모 비즈니스가 해야 할 일

소규모 비즈니스, 스타트업, 채용 팀 또는 이벤트 주최자라면, 볼륨이나 워크플로가 전용 릴레이를 명확하게 요구하지 않는 한 이메일 제공업체와 함께 제공되는 신뢰할 수 있는 서버를 사용하는 것이 가장 안전한 기본값입니다.

이는 기술적으로는 작동하지만 실제 시나리오에서는 성능이 저조한 전송 설정을 구축하는 일반적인 함정을 피하게 해줍니다.

일반적인 구성 설정 및 예시

앱이 “발신 메일 서버 설정”을 요청할 때는 귀하의 제공업체 SMTP 서비스에 연결하는 데 필요한 세부 정보를 묻는 것입니다. 필드가 위협적으로 보일 수 있지만, 각각 명확한 목적이 있습니다.

Heimdal’s Gmail SMTP configuration guide에 따르면, Gmail과 같은 엔터프라이즈급 클라우드 SMTP 서비스는 smtp.gmail.com과 포트 465(SSL) 또는 **포트 587(TLS)**을 사용하며, 올바른 SSL/TLS 구성은 전송을 암호화하여 전달 가능성을 향상시킵니다.

각 필드의 의미

서버 이름

발신 메일 서버의 주소입니다. 앱에 이메일을 제출할 위치를 알려줍니다.

Gmail의 경우 smtp.gmail.com입니다.

포트

포트는 앱이 연결하는 데 사용하는 특정 통로입니다. 여기서 많은 설정이 잘못됩니다.

Gmail의 경우 일반적인 선택은 다음과 같습니다.

• 465 (SSL용)
• 587 (TLS용)

인증

앱이 이메일을 보내기 전에 유효한 이메일 계정으로 로그인해야 함을 의미합니다. 이는 기기나 웹사이트가 오픈 릴레이처럼 작동하는 것을 방지합니다.

SSL 또는 TLS

이러한 보안 계층은 메시지가 제출되는 동안 연결을 암호화합니다. 쉽게 말해, 전송 중 가로채기를 방지하고 전송 중 신뢰 문제를 줄이는 데 도움이 됩니다.

일반적인 발신 메일 서버 설정

제공업체	SMTP 서버	포트	SSL/TLS 필요	인증 필요
Gmail / Google Workspace	smtp.gmail.com	465 또는 587	예	예
Microsoft 365 / Outlook.com	제공업체의 공개 SMTP 서버 사용	일반적으로 제공업체 문서의 보안 제출 설정	예	예
Apple iCloud Mail	제공업체의 공개 SMTP 서버 사용	일반적으로 제공업체 문서의 보안 제출 설정	예	예

제공업체별 세부 정보는 변경될 수 있으므로, 구성 중인 사서함의 계정 문서에서 정확한 서버 이름과 허용된 제출 방법을 항상 확인하세요.

쉬운 예시

웹사이트 양식이나 데스크톱 이메일 클라이언트를 Gmail 계정에 연결한다고 가정해 보겠습니다.

일반적으로 다음과 같이 입력합니다.

• SMTP 서버: smtp.gmail.com
• 사용자 이름: 전체 Gmail 주소
• 비밀번호: 계정 보안에 따라 계정 비밀번호 또는 앱별 방법
• 포트: 587 또는 465
• 암호화: TLS 또는 SSL

앱에서 SSL과 TLS 옵션을 모두 제공하는 경우, 포트를 제공업체가 지원하는 보안 방법과 일치시키세요.

가장 흔한 실수는 서버 이름이 아닙니다. 잘못된 포트와 보안 조합을 선택하는 것입니다.

빠른 설정 확인

콘텐츠를 탓하기 전에 다음 기본 사항을 확인하세요.

• 서버가 제공업체와 일치하는가. Gmail 자격 증명을 다른 제공업체의 SMTP 호스트와 혼합하지 마세요.
• 포트가 암호화 유형과 일치하는가. 불일치는 종종 연결 실패를 유발합니다.
• 인증이 켜져 있는가. 대부분의 제공업체는 인증되지 않은 클라이언트로부터 메일을 릴레이하지 않습니다.
• 사용자 이름이 완전한가. 많은 서비스가 @ 기호 앞부분뿐만 아니라 전체 이메일 주소를 요구합니다.

이 네 가지 확인 사항은 “전송되지 않음” 문제의 놀라운 부분을 해결합니다.

더 나은 전달 가능성을 위한 전송 보안

SMTP가 배송 트럭이라면, 인증은 적재 구역에서의 신분 확인입니다. 인증 없이는 수신 제공업체가 귀하의 이메일이 합법적인지 추측해야 합니다. 그들은 추측하는 것을 좋아하지 않습니다.

이것이 바로 SPF, DKIM 및 DMARC가 중요한 이유입니다. 이들은 함께 이메일을 위한 디지털 여권 시스템처럼 작동합니다.

여권 시스템으로 생각하세요

수신 메일 제공업체는 세 가지 질문에 답하고 싶어 합니다.

1. 이 서버가 이 도메인을 대신하여 보낼 권한이 있는가?
2. 메시지가 전송 중에 변경되었는가?
3. 확인이 실패하면 어떻게 해야 하는가?

이 레코드들이 그 질문에 답하는 데 도움을 줍니다.

SPF는 반송 주소 확인입니다

SPF는 귀하의 도메인을 대신하여 보낼 권한이 있는 서버를 수신 측에 알려줍니다.

귀하의 도메인이 특정 발신자만 유효하다고 명시했는데 메시지가 다른 곳에서 온다면, 그 불일치는 의심을 불러일으킵니다. SPF는 봉투의 반송 주소가 승인된 배송 위치에 속하는지 확인하는 것과 같습니다.

DKIM은 변조 방지 씰입니다

DKIM은 메시지가 전송 중에 변경되지 않았으며 실제로 승인된 발신자로부터 왔음을 증명하는 데 도움이 되는 서명을 추가합니다.

문서의 왁스 씰과 비슷합니다. 씰이 확인되면 수신자는 메시지의 무결성을 더 자신 있게 신뢰할 수 있습니다.

DMARC는 세관의 정책입니다

DMARC는 SPF 또는 DKIM 확인이 실패할 때 수신 제공업체에 무엇을 해야 할지 알려줍니다. 이는 정책에 따라 의심스러운 메일을 모니터링, 격리 또는 거부하는 것을 의미할 수 있습니다.

이것이 시스템을 하나로 묶는 규칙 책입니다.

이러한 확인이 실제로 어떻게 작동하는지에 대한 자세한 내용은 email authentication에 관한 이 가이드를 읽어보세요.

이것이 받은 편지함 분류에 영향을 미치는 이유

인증은 단순한 보안 체크박스가 아닙니다. 직접적으로 신뢰를 형성합니다.

도메인과 전송 시스템이 적절하게 정렬되면:

• 수신 제공업체가 일관된 신원을 확인합니다.
• 스푸핑이 더 어려워집니다.
• 스팸 필터가 메시지를 의심할 이유가 줄어듭니다.

정렬되지 않으면 합법적인 캠페인조차 플래그가 지정될 수 있습니다.

사람들이 잊는 다른 두 가지 요소

전송 중 암호화

TLS는 앱과 발신 서버 간의 연결을 보호하기 때문에 중요합니다. 이것이 받은 편지함 분류를 마법처럼 보장하지는 않지만, 더 신뢰할 수 있는 전송 경로를 지원합니다.

전송 속도 및 제공업체 제한

잘 인증된 계정이라도 계정 유형에 비해 너무 공격적으로 보내면 문제가 발생할 수 있습니다. 제공업체는 정상적인 패턴을 기대합니다. 전송 행동이 갑자기 위험해 보이면 신뢰도가 떨어질 수 있습니다.

기본 Gmail 메일 머지 기능도 자체적인 처리량 제한이 있습니다. GMass’s analysis of Gmail’s built-in mail merge에 따르면, 기본 Gmail 메일 머지는 발신 용량을 **계정 전체 일일 전송 제한의 약 75%**로 제한합니다.

보안 레코드는 신원을 증명합니다. 전송 행동은 판단력을 증명합니다. 둘 다 필요합니다.

메일 머지 도구가 발신 서버를 사용하는 방법

많은 사람이 메일 머지 도구가 별도의 미스터리 서버를 통해 보낸다고 가정합니다. 많은 Gmail 기반 워크플로에서 실제로는 그렇지 않습니다.

대신, 도구는 기존 Google 계정의 전송 경로를 사용합니다. 즉, 배후의 발신 서버는 직접 관리해야 하는 낯선 독립형 서버가 아니라 이미 사용 중인 Gmail 또는 Google Workspace 계정에 연결되어 있습니다.

이는 메시지가 확립된 발신자 신원의 맥락을 유지하기 때문에 중요합니다. 비즈니스 사용자에게는 일상적인 아웃리치를 위해 사용자 지정 SMTP 설정을 처음부터 구축하는 것보다 더 나은 출발점입니다.

실질적인 이점

인사 담당자가 Google Workspace 계정에서 면접 후속 조치를 보낸다고 가정해 보겠습니다. 또는 커뮤니티 관리자가 Gmail을 통해 이벤트 알림을 보냅니다. 메일 머지 도구는 이러한 메시지를 개인화하고 정리하는 데 도움을 주지만, 신뢰 계층은 여전히 기본 계정 및 도메인 설정에서 나옵니다.

이는 상황을 단순화합니다.

• 구성할 별도의 서버가 없음
• 처음부터 구축할 추가 릴레이 평판이 없음
• 메일 인프라를 유지 관리할 필요가 없음

단점은 전송 볼륨이 Google의 규칙에 묶여 있다는 것입니다. 검증된 데이터에 따르면 Gmail 기반 메일 머지 도구의 발신 이메일 서버는 community discussion of Gmail mail merge limits에서 논의된 바와 같이 표준 개인 계정의 경우 일일 1,500명, 프리미엄 Google Workspace 계정의 경우 2,000명이라는 Google의 일일 제한을 받습니다.

핵심 요약

메일 머지 도구는 전송을 더 효율적이고, 더 개인화되고, 추적하기 쉽게 만들 수 있습니다. 하지만 기본 원칙을 없애지는 않습니다. 결과는 여전히 계정의 평판, 인증 설정의 품질, 그리고 전송 볼륨이 제공업체가 예상하는 범위 내에 있는지에 달려 있습니다.

전송 문제 해결을 위한 체크리스트

전송이 중단되면 일반적인 접근 방식은 바로 이메일을 다시 작성하는 것입니다. 보통은 잘못된 첫 번째 움직임입니다. 증상에서 시작하여 서버 수준의 원인과 일치시키세요.

연결이 거부되는 경우

가장 먼저 확인할 것은 포트입니다.

검증된 데이터에 따르면 포트 25와 587의 혼동은 비기술적 사용자의 발신 SMTP 실패의 60%를 유발합니다. 포트 25는 종종 ISP에 의해 차단되는 반면, STARTTLS를 사용하는 포트 587은 현대 ESP에서 인증된 제출을 위해 요구되기 때문입니다.

다음 빠른 체크리스트를 시도하세요.

• 포트 설정 확인. 앱이 클라이언트 제출에 포트 25를 사용 중이라면 제공업체가 지원하는 경우 587로 전환하세요.
• 포트에 보안 일치. 해당 포트에서 제공업체가 예상하는 암호화 방법을 사용하세요.
• 릴레이가 아닌 제출을 구성 중인지 확인. 대부분의 비즈니스 앱은 인증된 제출 설정이 필요합니다.

인증이 실패하는 경우

이는 보통 앱이 계정을 통해 보낼 권한이 있음을 증명하지 못했음을 의미합니다.

다음 항목을 살펴보세요.

• 사용자 이름 확인. 제공업체가 요구하는 경우 전체 이메일 주소를 사용하세요.
• 비밀번호 방법 재확인. 일부 제공업체는 특정 앱 로그인 흐름을 요구합니다.
• 인증이 활성화되었는지 확인. 앱에 SMTP 인증 체크박스가 있다면 보통 켜져 있어야 합니다.

메시지가 스팸으로 거부되는 경우

거부된 메시지는 종종 문구뿐만 아니라 신뢰 신호를 가리킵니다.

다음 순서를 사용하세요.

1. SPF, DKIM 및 DMARC 정렬 확인
2. From 도메인이 전송 설정과 일치하는지 확인
3. 최근 전송 행동 검토

스팸 분류가 반복적인 문제가 되었다면, how to prevent email from going to spam에 관한 이 가이드가 실용적인 다음 단계입니다.

전송 제한에 도달한 경우

이는 서버 버그가 아닙니다. 보통 제공업체 정책 제한입니다.

그 시점에서 귀하의 옵션은 기술적인 것이 아니라 운영적인 것입니다.

• 일일 볼륨 줄이기
• 승인된 비즈니스 워크플로 전반으로 전송 분할
• 사용 사례에 맞는 도구 및 플랫폼 선택

팀이 더 큰 캠페인을 위해 전용 플랫폼이 더 적합할지 결정 중이라면, compare top email marketing platforms를 통해 장단점을 파악하는 데 도움이 될 수 있습니다.

이메일 문구가 아닌 전송 경로에서 시작하세요. 대부분의 전달 실패는 구성에 단서를 남깁니다.

---

SMTP 인프라를 직접 관리하지 않고 기존 Google 계정을 통해 개인화된 캠페인을 보내고 싶다면, Mail Merge for Gmail이 해당 워크플로를 위해 구축되었습니다. 팀은 Google Sheets 데이터를 사용하여 Gmail에서 맞춤형 아웃리치를 보내고, 열람 및 클릭을 추적하고, 수신 거부를 관리하며, 팀이 이미 사용하는 스프레드시트 내에서 보고서를 계속 확인할 수 있습니다.