SPF 및 DKIM 레코드를 확인하고, 발신 도메인이 깨끗해 보이는지 검증한 후 캠페인을 시작했습니다. 그런데 첫 번째 메시지가 시스템을 떠나기도 전에 애플리케이션에서 인증 오류가 반환됩니다. DNS 구성이 반드시 잘못된 것은 아닙니다. 발신 애플리케이션이 아웃바운드 SMTP 서버에 필요한 클라이언트 로그인에 실패했을 수 있습니다.
이러한 차이는 SMTP 인증이란 무엇인가라는 실무적인 질문에 대한 답이 됩니다. SMTP AUTH는 클라이언트, 애플리케이션 또는 사용자가 서버를 통해 메일을 제출할 권한이 있음을 증명합니다. SPF, DKIM, DMARC는 다른 신원 문제를 다룹니다. 즉, 수신 제공업체가 메시지와 연결된 도메인을 신뢰해야 하는지에 관한 문제입니다. 안정적인 전달 가능성을 확보하려면 두 계층 모두와 발송 전 세심한 목록 위생 관리가 필요합니다.
이메일 전송의 숨은 게이트키퍼
마케팅 팀은 발신자 평판, 도메인 정렬, 메시지 내용을 검토하는 데 며칠을 쓸 수 있지만, 결국 CRM이 발신 메일 서버에 인증할 수 없다는 사실을 발견할 수 있습니다. 제출 서버가 먼저 연결을 거부하기 때문에 캠페인은 수신자의 인프라에 도달하지 못합니다.
그것이 SMTP 인증의 역할입니다. SMTP 인증은 애플리케이션과 발신 메시지를 수락하는 메일 서버 사이의 게이트키퍼입니다. 클라이언트는 인증 메커니즘을 식별하고, 서버와의 교환을 완료한 다음, 메일을 제출할 권한을 받습니다. 그 권한이 없으면 올바르게 작성된 메시지와 올바르게 게시된 도메인 레코드도 아직 의미가 없습니다.
하나가 아닌 두 가지 신원 확인
이메일 전송에는 서로 다른 두 가지 질문이 포함됩니다.
- 이 클라이언트가 이 서버를 통해 메일을 제출할 수 있는가?
- 수신자가 이 메시지에 표시된 발신자 신원을 신뢰해야 하는가?
SMTP AUTH는 첫 번째 질문에 답합니다. SPF, DKIM, DMARC는 두 번째 질문에 답합니다. CRM에 유효한 자격 증명이 있어도 정렬된 인증 레코드가 없는 도메인에서 발송할 수 있습니다. 반대로 도메인이 강력한 레코드를 게시했더라도 애플리케이션이 만료된 비밀번호, 비활성화된 방식 또는 해당 계정의 릴레이를 거부하는 서버를 사용할 수 있습니다.
운영 규칙: 발송 경로를 순서대로 디버깅하세요. 먼저 클라이언트가 보안 인증 제출 세션을 설정할 수 있는지 확인합니다. 그런 다음 도메인 수준의 인증과 수신자 측 정책을 확인합니다.
SMTP AUTH의 표준은 RFC 4954이며, SASL을 기반으로 구축된 서비스 확장으로 SMTP 인증을 공식화했습니다. 이를 통해 서버는 지원되는 메커니즘을 알리고, 클라이언트는 SMTP의 핵심 메시지 전송 명령을 변경하지 않고 그중 하나를 선택할 수 있습니다. 이 설계는 오늘날에도 기업용 메일 시스템과 발송 플랫폼에서 인증된 제출을 뒷받침합니다.
마케터가 이 실패를 겪는 이유
이 오류는 카피나 타기팅을 변경한 뒤가 아니라, 인프라를 변경한 후에 나타나는 경우가 많습니다. 제공업체가 레거시 인증 방식을 비활성화할 수 있습니다. 관리자가 계정의 SMTP AUTH를 꺼둘 수 있습니다. 보안 정책에서 암호화된 제출을 요구할 수 있습니다. 방화벽이 서버 간 트래픽은 허용하면서 마케팅 애플리케이션이 사용하는 포트는 차단할 수 있습니다.
따라서 “비밀번호는 정확하다”는 말만으로는 충분한 진단이 되지 않습니다. 서버는 인증 방식, 연결 보안, 계정의 릴레이 권한 또는 발송 클라이언트의 설정을 거부할 수 있습니다. SMTP AUTH를 입력란이 아니라 프로토콜 수준의 제어 기능으로 다루세요.
SMTP AUTH 핸드셰이크 이해하기
SMTP AUTH는 협상된 교환 과정입니다. 클라이언트는 사용자 이름을 보내고 서버가 받아 주기를 기다리는 방식으로 동작하지 않습니다. 서버가 먼저 지원하는 항목을 식별하면, 클라이언트가 호환되는 메커니즘을 선택하고 인증 시퀀스를 시작합니다.
프로토콜 시퀀스
교환은 일반적으로 다음 순서로 진행됩니다.
- 클라이언트가 연결을 엽니다. 인증된 제출의 경우, 애플리케이션은 일반적으로 지정된 제출 서비스를 통해 연결하고 자격 증명이 노출되기 전에 전송 보안을 협상합니다.
- 클라이언트가 EHLO를 보냅니다. 이 확장 인사말은 클라이언트가 이해하는 SMTP 기능을 서버에 알립니다.
- 서버가 기능을 알립니다. 응답에는 지원되는 SASL 메커니즘을 나열하는
250-AUTH줄이 포함될 수 있습니다. 클라이언트는 서버가 제공하는 메커니즘 중 하나를 선택해야 합니다. - 클라이언트가 AUTH를 보냅니다. 이 명령은 RFC 4954의 AUTH 명령 사양에 정의된 대로 선택한 메커니즘을 첫 번째 매개변수로 사용합니다.
- 양측이 교환을 완료합니다. 메커니즘에 따라 서버가 챌린지를 보내고 클라이언트가 필요한 인증 데이터로 응답할 수 있습니다. 교환 중 자격 증명을 표현하기 위해 Base64 인코딩을 사용할 수 있지만, 인코딩은 암호화가 아닙니다. TLS가 세션을 보호해야 합니다.
- 서버가 세션을 수락하거나 거부합니다. 인증이 성공하면 일반적으로
235가 반환됩니다. 시도가 실패하면 일반적으로535가 반환되지만, 진단 세부 정보는 제공업체마다 다릅니다.
중요한 점은 클라이언트가 메시지 봉투와 콘텐츠를 제출하기 전에 SMTP AUTH가 수행된다는 것입니다. 인증이 완료되면 애플리케이션은 서버의 릴레이 및 정책 제어에 따라 MAIL FROM, RCPT TO, DATA와 같은 명령을 진행할 수 있습니다.
응답이 알려 주는 내용
AUTH 기능이 누락되었다면 클라이언트가 잘못된 서비스에 연결했거나, 지원되지 않는 포트를 사용했거나, 인증된 제출을 제공하지 않는 서버에 접속했음을 나타낼 수 있습니다. 535 응답은 잘못된 자격 증명, 차단된 계정, 비활성화된 인증 방식 또는 제공업체가 레거시 로그인 동작을 거부한 결과일 수 있습니다.
애플리케이션 로그에는 비밀번호와 토큰을 기록하지 않으면서 서버의 응답 코드와 협상된 보안 상태를 저장해야 합니다. 수락되었지만 이후 필터링된 메시지를 조사할 때는 수신 시스템이 기록한 인증 결과를 확인하기 위해 이메일 헤더를 무료로 분석할 수도 있습니다.
SMTP AUTH는 계정 보안을 대체하지 않습니다. 사서함 또는 서비스 계정에서 다중 인증을 사용하는 경우, 일반 비밀번호가 작동할 것이라고 가정하지 말고 제공업체가 지원하는 흐름을 확인해야 합니다. Finchum Fixes IT의 2FA 가이드는 두 번째 인증 요소가 로그인 모델을 바꾸는 이유를 이해하는 데 유용한 배경 정보를 제공합니다.
이러한 시스템에 공급되는 수신자 데이터를 정리하는 팀이라면, BillionVerify는 한 가지 문제를 해결하기 위해 구축된 전문 이메일 verification 서비스입니다. 즉, 잘못된 이메일 데이터는 기업에 비용을 초래합니다. 이는 주소 목록의 품질을 다루는 것이지 SMTP 로그인 자체를 다루는 것은 아닙니다.
SMTP 인증과 발신자 인증 비교
가장 이해하기 쉬운 비유는 직원 배지와 회사 레터헤드의 차이입니다.
SMTP AUTH는 배지입니다. 이 배지는 발신 메일 서버에 해당 클라이언트 또는 계정이 메시지를 제출할 권한이 있음을 알립니다. SPF, DKIM, DMARC는 레터헤드와 인증 표시입니다. 이들은 수신 제공업체가 메시지가 수신자에게 표시된 도메인을 실제로 나타내는지 평가하는 데 도움을 줍니다.
배지 확인에 성공했다고 해서 의심스러운 레터헤드가 신뢰할 수 있게 되는 것은 아닙니다. 마찬가지로 정교하게 구성된 도메인 레코드가 애플리케이션에 서버의 메일 큐에 메시지를 주입할 권한을 부여하는 것도 아닙니다.
| 기능 | 클라이언트 제출(SMTP AUTH) | 도메인 검증(SPF/DKIM/DMARC) |
|---|---|---|
| 주요 질문 | 이 클라이언트가 메일을 제출할 수 있는가? | 수신자가 이 도메인 ID를 신뢰해야 하는가? |
| 작동 위치 | 발신 클라이언트와 발신 서버 사이 | 메시지, DNS 레코드, 수신 제공업체 사이 |
| 주요 구성 요소 | EHLO, 공지된 AUTH 메커니즘, SASL 교환, 릴레이 권한 | SPF 인증, DKIM 서명 검증, DMARC 정렬 및 정책 |
| 일반적인 실패 | 인증 거부, 비활성화된 계정, 지원되지 않는 방식 | 스푸핑 실패, 정렬 불일치, 정책 기반 필터링 |
| 성공의 효과 | 서버가 후속 전송을 위해 메시지를 수락할 수 있음 | 수신자가 필터링 결정에 도메인 ID 신호를 사용할 수 있음 |
각 계층이 입증하는 것
SPF는 도메인에 지정된 발신 IP 주소를 인증합니다. DKIM은 암호화 서명을 첨부하여 수신 시스템이 서명된 메시지 콘텐츠와 도메인 서명이 유효한지 확인할 수 있도록 합니다. DMARC는 이러한 결과를 수신자에게 표시되는 From 도메인과 연결하고, 정렬에 실패한 메시지를 처리하는 정책을 제공합니다. 이러한 차이점은 이 SPF, DKIM, DMARC 비교에 명확하게 요약되어 있습니다.
SMTP AUTH는 이러한 도메인 지침을 게시하지 않습니다. 또한 수신자가 메시지를 받은편지함에 넣을 것이라고 보장하지도 않습니다. SMTP AUTH는 발신 서비스가 해당 클라이언트를 권한이 있는 제출자로 수락했다는 사실만 확립합니다.
게시와 시행은 다릅니다
레코드를 보유하는 것과 정책을 시행하는 것의 차이는 운영 측면에서 중요합니다. DMARC Guard의 이메일 인증 연구에 따르면, 550만 개 도메인을 대상으로 한 2026년 측정에서 SPF 게시율은 56.0%, DMARC는 30.4%, DKIM은 **22.7%**였습니다. 같은 출처의 상위 10,000개 도메인 대상 별도 벤치마크에서는 SPF 게시율이 84.5%, DMARC 게시율이 76.6%, 격리 또는 거부 정책을 통한 DMARC 시행률이 **54.0%**에 달했습니다.
실질적인 교훈은 간단합니다. 도메인이 구성된 것처럼 보여도 여전히 모니터링 전용 모드로 운영될 수 있습니다. DMARC 검사 도구를 사용해 정책과 정렬 상태를 확인하되, SMTP 자격 증명은 별도로 문제를 해결하세요. 어느 도구도 다른 도구를 대신할 수 없습니다.
안전한 제출을 위한 포트 및 프로토콜
자격 증명은 보호되지 않은 클라이언트 제출 세션을 통해 전송되어서는 안 됩니다. 따라서 SMTP AUTH는 전송 암호화 및 메시지 제출을 위한 포트와 함께 사용해야 하며, 제한 없는 릴레이 경로와 함께 사용해서는 안 됩니다.
표준으로 정의된 제출 포트는 587이며, 일반적으로 STARTTLS와 함께 사용됩니다. 자세한 내용은 이 SMTP 인증 포트 개요에서 확인할 수 있습니다. 클라이언트는 SMTP 세션을 설정하고, 서버의 기능을 확인한 뒤, TLS 업그레이드를 요청하고, 보호된 연결 내부에서 인증을 수행합니다.
올바른 엔드포인트 선택
포트 25는 주로 서버 간 릴레이와 관련됩니다. 사용자 자격 증명을 사용해 애플리케이션, CRM 또는 마케팅 플랫폼에서 메일을 제출할 때 일반적으로 선택하는 포트는 아닙니다. 개방형 릴레이 악용과 손상된 호스트로 인해 제한 없는 아웃바운드 SMTP가 보안 문제가 되었기 때문에 많은 네트워크에서 포트 25를 제한합니다.
포트 465는 암시적 TLS를 사용하므로 연결이 시작되는 순간부터 암호화됩니다. 일부 provider와 애플리케이션은 여전히 이 포트를 요구하지만, 구성은 서버의 요구 사항과 일치해야 합니다. 암시적 TLS 엔드포인트에서 STARTTLS를 가정하거나, 서버가 일반 텍스트 인사말 후 업그레이드를 기대하는데 암시적 TLS를 가정하는 클라이언트는 인증 전에 실패합니다.
| 연결 유형 | 일반적인 역할 | 보안 요구 사항 |
|---|---|---|
| 포트 25 | 서버 간 릴레이 | 일반적인 인증된 클라이언트 제출 경로가 아님 |
| 포트 587 | 메시지 제출 | SMTP AUTH 전에 일반적으로 STARTTLS 협상 |
| 포트 465 | 필요한 경우의 제출 | 연결 시점부터 암시적 TLS 시작 |
노출을 방지하는 구성 점검
자격 증명을 테스트하기 전에 애플리케이션의 엔드포인트, 포트, 암호화 모드 및 인증 메커니즘이 provider의 문서와 일치하는지 확인하세요. 포트에 연결할 수 있어도 TLS 협상은 여전히 실패할 수 있습니다. 마찬가지로 서버가 AUTH를 광고하더라도 릴레이 권한이나 테넌트 정책으로 인해 제출이 금지되면 계정을 거부할 수 있습니다.
MX 레코드 확인 도구는 도메인의 메일 수신을 담당하는 메일 서버를 식별하는 데 도움이 되지만, MX 데이터가 아웃바운드 provider가 제공한 제출 엔드포인트를 대신할 수는 없습니다. 수신 인프라와 인증된 발신 인프라는 서로 다른 서비스일 수 있습니다.
보안 경계: TLS를 비활성화하여 인증 실패를 “해결”하려 하지 마세요. 그렇게 하면 자격 증명과 메시지 트래픽이 노출될 수 있으며, 근본적인 호환성 또는 정책 문제는 해결되지 않은 채 남습니다.
대용량 시스템에서는 API가 빈번한 SMTP 세션을 유지하는 것보다 운영 측면에서 더 간단할 수 있지만, 애플리케이션이 이미 SMTP를 지원하고 provider가 안정적인 제출 서비스를 제공한다면 SMTP도 여전히 유용합니다. 선택은 습관이 아니라 통합 요구 사항, 관찰 가능성 및 보안 제어를 따라야 합니다.
레거시 Auth 사용 중단의 영향
비밀번호가 변경되지 않았더라도 메일 발송 워크플로가 인증에 실패할 수 있습니다. 제공업체들은 사용자 이름과 비밀번호를 직접 전송하는 Basic Authentication을 OAuth 및 기타 권한 부여 흐름으로 대체하고 있습니다. 이러한 흐름을 사용하면 관리자가 토큰, 범위, 동의 및 취소를 제어할 수 있습니다.
Microsoft의 발표된 계획에 따르면 Basic Authentication 동작은 2026년 12월까지 변경 없이 유지될 예정입니다. 그 이후에는 기존 테넌트에서 기본적으로 비활성화될 예정이며, 이후 생성되는 새 테넌트는 지원되는 방식으로 OAuth를 사용하게 될 것으로 예상됩니다. Microsoft는 2027년 하반기에 최종 제거 일정을 발표할 계획입니다. 이러한 예상 일정은 Microsoft Exchange Online SMTP AUTH 사용 중단 일정에 나와 있습니다.
유효한 비밀번호도 계속 실패하는 이유
제공업체는 비밀번호를 확인하기 전에 인증 방식을 거부할 수 있습니다. 테넌트 관리자가 해당 사서함의 SMTP AUTH를 비활성화했을 수도 있으며, 애플리케이션이 LOGIN 또는 PLAIN만 제공하는 반면 서비스는 토큰 기반 흐름을 요구할 수도 있습니다. 따라서 한 사서함에서 로그인 테스트가 성공했다고 해서 모든 메일 발송 통합이 계속 작동한다는 의미는 아닙니다.
Microsoft의 이전 안내에서는 이 SMTP AUTH 마이그레이션 가이드에 보고된 것처럼 영향을 받는 Basic Authentication 경로에 대해 2026년 3월 1일부터 단계적인 거부가 시작되고 2026년 4월 30일까지 완전히 종료될 것이라고 설명했습니다. 제공업체의 일정과 테넌트 정책은 변경될 수 있으므로, 과거의 구현 날짜를 보장으로 간주하지 말고 각 환경의 현재 상태를 확인해야 합니다.
실용적인 마이그레이션 계획
CRM 워크플로, 결제 애플리케이션, 모니터링 도구, 양식 및 스크립트를 포함하여 테넌트를 통해 메일을 제출하는 모든 시스템을 목록화합니다. 각 시스템에 대해 계정, 엔드포인트, 포트, 암호화 모드, 인증 메커니즘 및 담당자를 기록합니다. OAuth를 지원하는 통합과 교체가 필요하거나 승인된 앱 비밀번호 방식을 사용해야 하는 통합을 구분합니다.
프로덕션 순서를 변경하기 전에 통제된 환경에서 새 흐름을 테스트합니다. 토큰 만료, 동의 요구 사항, 오류 처리 및 액세스 취소를 확인합니다. 또한 인증이 성공한 후에도 워크플로가 제공업체의 응답을 올바르게 처리하는지 확인합니다. OAuth를 지원하지 않는 커넥터는 저장된 비밀번호가 여전히 유효하더라도 캠페인 중에 실패할 수 있습니다.
로그인 그 이상의 전송 가능성 확인
발신 서버에 인증하면 제출 권한이 입증됩니다. 하지만 수신자 사서함이 존재하는지, 수신자 도메인이 해당 주소로 메일을 수락하는지, 또는 메시지가 필터링을 피할 수 있는지는 입증하지 못합니다.
발송 전 검증 파이프라인은 MX 조회로 시작합니다. MX 레코드는 도메인의 메일 수신을 담당하는 메일 서버를 식별하며, 이메일 검증 작동 방식 개요에서 설명하듯 MX 레코드가 없는 도메인은 메일을 수신할 수 없습니다. 그런 다음 검증 서비스는 SMTP 대화를 사용해 수신자 서버를 조회하고 해당 주소가 전송 가능한 것으로 보이는지 평가할 수 있습니다.
검증 파이프라인이 실제로 확인하는 항목
서비스는 유용한 정보를 얻기 위해 캠페인 메시지를 전송할 필요가 없습니다. 수신자 도메인의 MX 호스트를 식별하고, SMTP 세션을 열어 서버가 지정된 수신자를 수락할지 물을 수 있습니다. 일부 서버는 도메인의 모든 주소로 메일을 수락하므로 긍정적인 응답이 항상 명확한 것은 아닙니다.
여기서 catch-all 감지가 중요합니다. 검증기는 동일한 MX 호스트로 두 번째 테스트 주소를 전송합니다. 서버가 무작위 주소도 수락하면, 이 catch-all 감지 워크플로에서 설명하듯 해당 도메인은 원래 사서함의 존재를 입증하는 대신 catch-all로 분류됩니다.
유용한 구분: “서버에서 수락됨”과 “특정 사서함으로 확인됨”은 항상 같은 결과가 아닙니다.
따라서 검증은 단순한 유효 또는 무효 전환이 아니라 위험 분류 시스템으로 사용할 때 가장 효과적입니다. 마케팅 운영팀은 캠페인으로 인해 하드 반송이 발생하기 전에 전송 가능성이 높은 주소를 알 수 없음, catch-all, 일회용, 역할 기반 또는 기타 위험한 레코드와 분리할 수 있습니다.
BillionVerify 전송 가능성 검사기는 팀이 주소 및 발송 경로 확인을 위해 평가하는 도구 중 하나로 이러한 발송 전 검토에 포함될 수 있습니다. 운영 목표는 로그인 성공보다 광범위합니다. 잘못된 수신자를 줄이고, 발신자 평판을 보호하며, 캠페인에 더 깔끔한 오디언스를 제공하는 것입니다.
복원력 있는 발송 인프라 구축
복원력 있는 발송 시스템은 인증을 단일 체크박스가 아닌 계층형 제어로 다룹니다. 클라이언트는 아웃바운드 서비스에 안전하게 인증해야 합니다. 사용자에게 표시되는 발신자 도메인은 정렬된 신원 검사를 통과해야 합니다. 수신자 데이터는 캠페인에서 방지 가능한 반송이 발생하지 않을 만큼 최신 상태여야 합니다.
인프라 감사부터 시작하기
애플리케이션에서 수신자까지 이어지는 전체 경로를 매핑하세요. 각 발송 워크플로에 대해 제출 제공업체, 인증 방식, 암호화 요구 사항, 계정 소유자 및 대체 동작을 문서화하세요. 이 목록을 작성하면 아직도 비밀번호나 오래된 SMTP 설정에 의존하는 방치된 통합이 드러나는 경우가 많습니다.
그런 다음 장애 모드를 의도적으로 테스트하세요.
- 제출 실패: 클라이언트가 의도한 엔드포인트에 도달하고, TLS를 협상하며, 예상되는 AUTH 기능을 확인하고, 성공적인 인증 응답을 받는지 확인하세요.
- 도메인 실패: From 주소에 표시된 도메인의 SPF 인증, DKIM 서명 및 DMARC 정렬을 검증하세요.
- 데이터 실패: 새 주소와 가져온 주소가 캠페인이나 영업 시퀀스에 들어가기 전에 검증하세요.
- 평판 실패: IP 평판 검사 도구를 사용하여 반송, 불만, 차단 목록 신호 및 수락 동작의 갑작스러운 변화를 모니터링하세요.
RFC 4954 표준은 프로토콜의 기반을 제공하지만, 표준 준수만으로 운영상의 복원력이 보장되지는 않습니다. 제공업체는 테넌트 규칙을 적용하거나, 메커니즘을 비활성화하거나, 인증 요구 사항을 변경할 수 있습니다.
위생 관리를 워크플로의 일부로 만들기
목록이 커지거나 캠페인이 예약될 때까지 기다리지 마세요. 가입, 가져오기, CRM 동기화 시점과 주요 발송 전에 검증을 추가하세요. 실시간 검사는 명백히 위험한 주소가 데이터베이스에 들어오는 것을 막을 수 있으며, 대량 검토는 영업 및 마케팅 팀이 축적한 오래된 레코드를 식별할 수 있습니다.
최상의 워크플로는 결과와 그 이유도 함께 보존합니다. “catch-all이므로 알 수 없음”은 “메일박스가 거부함” 또는 “도메인에 수신 서버가 없음”과 다르게 처리해야 합니다. 세분화를 통해 팀은 모든 불확실한 레코드를 안전하다고 간주하는 대신 주소를 제외할지, 검토할지, 신중하게 테스트할지 결정할 수 있습니다.
계층형 프로그램에는 소유권도 필요합니다. 인프라 팀은 OAuth 마이그레이션과 TLS 정책을 관리해야 합니다. 마케팅 운영팀은 발송 도메인 정렬 및 제외 규칙을 유지 관리해야 합니다. 데이터 팀은 검증 상태 처리 방식을 정의해야 합니다. 명확한 소유권이 없으면 각 그룹은 다른 팀이 발송 경로를 보호하고 있다고 생각하게 됩니다.
이 동영상에서는 관련 인프라 개념을 시각적으로 설명합니다.
핵심 교훈은 실용적입니다. SMTP AUTH는 메시지를 아웃바운드 대기열에 넣는 반면, 도메인 인증과 수신자 검증은 더 넓은 전송 시스템이 해당 메시지를 신뢰할 이유가 있는지를 결정합니다. 모니터링에서는 이러한 제어를 분리하되, 운영 프로세스에서는 서로 연결하세요.
BillionVerify는 수신자 데이터가 캠페인, 워크플로 및 아웃바운드 시퀀스에 도달하기 전에 확인할 수 있도록 이메일 검증을 제공합니다. 이를 사용하여 사전 발송 프로세스에서 SMTP 수준의 검증, MX 및 catch-all 신호, 전송 가능성 검토를 연결한 다음, BillionVerify를 방문하여 팀에 적합한 워크플로인지 평가하세요.