Brevo SMTP: 설정, 옵션, 문제 해결 가이드

Brevo SMTP는 애플리케이션의 발신 메일을 웹 호스트의 로컬 메일 에이전트에서 떼어 내, 모든 메시지를 인증하고 기록하고 리포팅하는 인프라 위로 옮겨 줍니다. 설정은 간단합니다. 호스트 이름 하나, 포트 하나, 자격 증명 두 개면 됩니다. 잘못 설정하는 것도 그만큼 간단하고, 실패 양상은 조용합니다. 이 가이드는 설정값과 자격 증명 모델, 실제로 메일이 도착하게 만드는 DNS 작업, 그리고 어느 한 조각이라도 잘못되었을 때 만나게 되는 오류를 다룹니다. 아직 제공업체를 고르는 단계라면 SMTP 이메일 서비스 가이드가 시장 전반을 먼저 비교해 줍니다.

Brevo SMTP란

Brevo는 Brevo SMTP를 자사의 SMTP 릴레이 서비스로 설명합니다. 애플리케이션이나 웹사이트, 메일 서버가 인증된 연결로 메시지를 릴레이에 넘기면, Brevo가 라우팅과 재시도, 평판, 리포팅을 책임집니다. 릴레이로 보낸 메일의 통계는 캠페인 통계와 나란히 표시되며, 하드 바운스가 발생하면 해당 연락처는 자동으로 차단 목록에 들어갑니다.

이 릴레이는 트랜잭션 메시지를 위해 만들어졌습니다. 비밀번호 재설정, 영수증, 주문 확인, 계정 알림 같은 것들입니다. 그것과 마케팅 메일의 경계가 아직 뚜렷하지 않다면 트랜잭션 이메일이란 무엇인가에서 다룹니다.

SMTP인가 REST API인가

두 경로 모두 같은 플랫폼에 도달합니다. 실무적인 구분은 다음과 같습니다.

한 가지 명확한 한계가 있습니다. Brevo 개발자 문서는 SMTP 릴레이가 일괄 발송을 지원하지 않는다고 명시하며, 일괄 작업은 API 엔드포인트로 안내합니다.

SMTP 자격 증명 만들기

Brevo의 SMTP 인증은 이미 가지고 있는 다른 자격 증명과 혼동하기 쉬운 두 값을 사용합니다.

SMTP 로그인 찾기

SMTP 로그인은 Brevo 계정 이메일 주소가 아닙니다. Settings의 SMTP and API 페이지의 Login 필드에 표시되는 별도의 식별자이며, 형식은 [email protected] 입니다.

여기서 두 가지 규칙이 따라옵니다. 둘 다 Brevo의 문제 해결 문서에 나오는 내용입니다. 사용자 이름 필드에 smtp-relay.brevo.com 을 넣지 마십시오. 그것은 릴레이 호스트이지 로그인이 아닙니다. 그리고 SMTP 로그인을 From 헤더에 넣지 마십시오. 그 값은 발신자를 식별하는 것이 아니라 사용자를 인증하는 값입니다.

SMTP 키 생성하기

비밀번호는 SMTP 키입니다. 계정 비밀번호도 아니고 API 키도 아닙니다.

1. 계정 드롭다운을 열고 Settings를 선택한 뒤 SMTP and API로 이동합니다.
2. SMTP 탭에서 Generate a new SMTP key를 클릭합니다.
3. 그 키를 사용할 연동의 이름을 따서 키 이름을 정합니다.
4. 종류를 고릅니다. Standard는 권장되는 64자 키이고, Short는 긴 비밀번호를 처리하지 못하는 클라이언트를 위한 15자 키입니다.
5. 만료 기간을 7일에서 1년 사이로 설정하거나 만료 없음을 선택합니다.
6. Generate를 클릭한 뒤 전체 키를 즉시 복사합니다.

전체 키는 한 번만 표시되고, 이후에는 마지막 몇 자리만 보입니다. 분실하면 대체 키를 생성하고 설정을 갱신해야 합니다.

연결 설정

클라이언트나 라이브러리에 입력할 값은 다음과 같습니다.

포트 선택하기

Brevo는 587을 기본값으로 권장합니다. 465 포트는 SSL 기반 SMTP용으로 지정되었다가 이후 폐기되었지만 여전히 널리 지원되며, 첫 명령 이전에 연결이 암호화되어야 할 때 적합합니다. 2525 포트는 IETF나 IANA에 등록된 포트가 아니지만 대부분의 ISP와 클라우드 제공업체가 허용하므로, 587이 막혔을 때의 비상구가 됩니다.

암호화 필드에서 많이들 걸립니다. Brevo는 465를 쓰는 경우가 아니면 비워 두라고 안내합니다. 그렇다고 연결이 암호화되지 않는다는 뜻은 아닙니다. 587과 2525에서는 서버가 STARTTLS 를 광고하고, 제대로 만들어진 클라이언트라면 인증 전에 연결을 업그레이드합니다. 이 안내의 의미는 587에 연결하면서 “SSL”을 선택하지 말라는 것입니다. 포트와 암호화가 어긋나면 자격 증명이 올바르더라도 인증이 실패합니다.

코드를 쓰기 전에 연결부터 테스트하십시오

애플리케이션 코드를 디버깅하기 전에 릴레이가 응답하는지, TLS가 협상되는지 먼저 확인하십시오.

openssl s_client -starttls smtp -crlf -connect smtp-relay.brevo.com:587

핸드셰이크에 성공하면 서버의 250 기능 목록으로 끝나며, 여기에는 STARTTLS 와 PLAIN, LOGIN 을 나열하는 AUTH 줄이 포함되어야 합니다. 배너 자체가 없다면 자격 증명 문제가 아니라 네트워크 문제입니다.

발신 도메인 인증하기

사람들이 건너뛰는 단계이자, 메일이 도착할지를 결정하는 단계입니다. 2024년 2월 1일부터 Gmail과 Yahoo의 발신자 요구사항에 따라 도메인 인증은 의무가 되었고, Brevo는 Microsoft가 2025년 5월 5일에 유사한 기준을 발표했다고 안내합니다. 인증되지 않은 메일은 어떤 릴레이로 보내든 필터링되거나 거부됩니다.

Brevo가 요구하는 레코드

Brevo 안에서 도메인 제공업체에 로그인하면 이 레코드를 자동으로 추가할 수 있고, 값을 직접 복사해 DNS 존에 넣어도 됩니다. 어떤 DKIM 형태가 주어지는지는 계정에 따라 다릅니다. CNAME 두 개 방식은 기본적으로 2048비트 키를, 단일 TXT 방식은 1024비트 키를 사용합니다.

SPF 레코드가 없는 이유

Brevo의 FAQ는 분명합니다. 도메인 인증에 SPF와 MX 레코드는 필요하지 않으며, 전용 IP를 설정할 때만 제공됩니다. 공유 인프라에서는 Brevo가 반송 경로를 관리하므로, DKIM과 소유권 확인이 인증을 담당합니다. SPF include를 요구하던 제공업체에서 옮겨 오는 경우라도 없는 include를 지어내지 마십시오. 불필요한 include는 조회 횟수 제한 문제만 유발합니다.

DMARC는 여전히 중요하며, Brevo는 바로 쓸 수 있는 시작 레코드를 공개합니다.

v=DMARC1; p=none; rua=mailto:[email protected]

p=none 으로 시작해 배달에 위험을 주지 않으면서 집계 리포트를 받고, 정상적인 발신 소스가 모두 정렬되면 quarantine과 reject로 강화하십시오. 이메일 도달률 가이드가 그 단계별 진행을 다룹니다.

발신자 검증

모든 From 주소는 검증된 발신자이거나 인증된 도메인에 속해 있어야 합니다. 새 발신자는 해당 주소로 전송되는 6자리 코드로 검증하지만, 인증된 도메인의 발신자는 그 단계를 건너뜁니다. 도메인을 먼저 인증하는 이유가 여기에 있습니다. 무료 메일 도메인은 인증할 수 없으므로 gmail.com 이나 outlook.com 의 From 주소는 거부되거나 필터링됩니다.

연동 실습

WordPress

WordPress는 발신 메일을 wp_mail 에 넘기고, 이 함수는 호스트가 제공하는 수단을 호출합니다. 이를 Brevo로 보내려면 플러그인이 필요합니다.

1. 관리자 사이드바에서 Plugins로 이동한 뒤 Add New Plugin을 선택합니다.
2. Brevo를 검색해 “Newsletter, SMTP, Email marketing and Subscribe forms by Brevo”를 설치하고 활성화합니다.
3. Brevo로 이동한 뒤 Home에서 활성화 필드에 Brevo API key v3를 입력합니다. 이 단계에서 API 키를 쓰는 이유는 플러그인이 연락처 동기화도 하기 때문입니다. Login을 클릭합니다.
4. Transactional emails에서 Yes를 선택합니다.
5. 기존 발신자를 고르거나 새로 만듭니다. 모든 WordPress 이메일이 그 발신자 이름과 주소를 사용합니다.
6. 주소를 입력하고 Send email을 클릭해 테스트를 발송합니다.

흔한 오류는 두 가지입니다. Brevo SMTP 계정이 활성화되지 않아 트랜잭션 이메일을 사용할 수 없다는 메시지는 Brevo 지원팀이 플랫폼을 켜 주어야 한다는 뜻입니다. 다른 프로세스가 wp_mail 을 선언해 SMTP를 사용할 수 없다는 메시지는 경쟁하는 SMTP 플러그인이 있다는 뜻이므로, 다른 플러그인을 하나씩 비활성화해 보십시오.

서버 사이드 애플리케이션

Brevo의 공식 Node.js 예제는 nodemailer와 위의 설정값을 사용합니다.

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp-relay.brevo.com",
  port: 587,
  secure: false, // 465 포트는 true, 그 외 포트는 false
  auth: {
    user: process.env.BREVO_SMTP_LOGIN, // [email protected]
    pass: process.env.BREVO_SMTP_KEY,
  },
});

async function sendOrderConfirmation() {
  const info = await transporter.sendMail({
    from: '"Acme Support" <[email protected]>',
    to: "[email protected]",
    subject: "Your order is confirmed",
    text: "Order 10482 is confirmed and ships within two business days.",
  });
  console.log("Message sent:", info.messageId);
}

sendOrderConfirmation().catch(console.error);

587 포트에서 secure: false 로 둔 점에 유의하십시오. 이 플래그는 암묵적 TLS를 제어할 뿐 연결의 암호화 여부를 결정하지 않습니다. nodemailer는 여전히 STARTTLS 를 실행합니다. 465일 때만 true 로 설정하십시오.

표준 라이브러리를 사용하는 Python 예제입니다.

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "Acme Support <[email protected]>"
msg["To"] = "[email protected]"
msg["Subject"] = "Your order is confirmed"
msg.set_content("Order 10482 is confirmed and ships within two business days.")

with smtplib.SMTP("smtp-relay.brevo.com", 587, timeout=20) as server:
    server.starttls(context=ssl.create_default_context())
    server.login(BREVO_SMTP_LOGIN, BREVO_SMTP_KEY)
    server.send_message(msg)

두 예제 모두 환경 변수에서 자격 증명을 읽습니다. 다음 절의 주제가 바로 그것입니다.

키 보안과 교체

Brevo는 SMTP 키를 비밀번호로 취급합니다. 운영 원칙은 문자 그대로 따를 만한 가치가 있습니다.

• 연동당 키 하나. 각 키에 그것을 사용하는 시스템의 이름을 붙이면, 유출이나 폐기 시 정확히 하나만 무효화할 수 있습니다.
• 키를 절대 커밋하지 마십시오. 환경 변수, 시크릿 매니저, 또는 플랫폼의 설정 저장소를 사용하십시오. 소스 관리, 추적되는 .env 파일, 화면 캡처는 안 됩니다.
• 무중단으로 교체하십시오. 대체 키를 생성하고 배포한 뒤 발송을 확인하고, 그다음에 기존 키를 삭제하십시오. 삭제는 되돌릴 수 없으며, 사용 중인 키를 삭제하면 트랜잭션 발송이 즉시 중단됩니다.
• 연동을 잠시 멈출 때는 삭제 대신 비활성화하십시오. 키는 나중에 다시 활성화할 수 있습니다.
• 만료를 염두에 두십시오. 키에는 7일에서 1년 사이의 만료를 설정할 수 있고, Brevo는 90일간 사용되지 않은 키를 만료시킵니다.

더 강한 경계가 필요하다면 Brevo가 알 수 없는 IP 주소의 요청을 차단하도록 설정할 수 있습니다. 허용 목록은 API 키와 SMTP 키가 공유하므로, 허용한 항목은 양쪽 모두에 적용됩니다. 컨테이너나 클라우드 워크로드에서는 주의하십시오. 아웃바운드 주소가 예상한 인스턴스 IP가 아니라 NAT 게이트웨이일 수 있고, 이를 잘못 지정하면 525 5.7.1 Unauthorized IP address 거부가 발생합니다.

스토어와 CRM, 지원 데스크와 함께 Brevo를 운영하는 팀은 결국 여러 개의 키와 발신자, 도메인을 동시에 관리하게 됩니다. Tajo는 그 설정을 네 개의 대시보드가 아니라 한곳에 모아 둡니다.

발송 제한과 스로틀링

SMTP 발송은 요금제의 이메일 크레딧을 소진합니다. 무료 요금제에서는 하루 300통이며, 제한은 매일 초기화되고 사용하지 않은 발송량은 이월되지 않습니다. 제한에 도달하면 Brevo는 추가로 최대 1,000통을 재시도 대기열에 보관하고 그 이상은 배달하지 않습니다. 유료 요금제는 일일 상한을 없애며, Brevo 요금제 가이드에서 등급별 내용을 정리했습니다.

크레딧이 완전히 소진되면 SMTP로 제출된 메시지는 폐기되지 않고 일시 정지되어 대기열에 쌓입니다. 이 대기 물량은 Transactional에서 Real time, Usage and plan으로 들어가 Email queue 섹션에서 확인할 수 있습니다.

Brevo가 공개하는 엄격한 요청 제한은 릴레이가 아니라 REST API에 대한 것입니다. 일반 등급에서 POST /v3/smtp/email 은 초당 1,000회를 허용하며, 제한을 초과하면 429 Too Many Requests 가 반환됩니다. API 경로는 속도를 조절할 수 있도록 요청 제한 헤더도 반환하지만 릴레이는 그렇지 않습니다.

반송과 불만 모니터링

릴레이로 보낸 메일은 Transactional의 Statistics와 Logs 페이지에서 확인할 수 있습니다. 대응이 필요한 이벤트는 다음과 같습니다.

• 하드 바운스. 주소가 유효하지 않으며, Brevo가 해당 연락처를 자동으로 차단 목록에 넣습니다.
• 차단됨. 수신자가 이전에 불만을 제기했거나 수신을 거부했거나 하드 바운스가 발생했거나 수동으로 차단된 경우입니다.
• 지연과 소프트 바운스. 수신 측이 연결은 받아들였지만 메시지를 미루거나 거부한 경우입니다. 특정 사업자에게서 지연이 반복된다면 코드 문제가 아니라 평판 문제 신호입니다.

로그를 폴링하는 방식은 확장되지 않습니다. Brevo는 배달, 반송, 오픈, 불만 이벤트를 실시간으로 엔드포인트에 전달하는 트랜잭션 웹훅을 지원하며, 이것이 자체 억제 데이터를 최신 상태로 유지하는 방법입니다.

주시해야 할 수치는 스팸 신고율입니다. Gmail과 Yahoo, Microsoft는 발신자에게 0.3% 미만을 요구하며, Brevo는 Gmail Postmaster Tools로 이를 모니터링할 것을 권장합니다. 기준을 넘긴 뒤 회복하는 데는 애초에 넘지 않는 것보다 훨씬 오랜 시간이 걸립니다.

문제 해결

535 5.7.8 Authentication failed

사용자 이름이나 비밀번호를 검증할 수 없다는 뜻입니다. 가능성이 높은 순서로 정리하면 다음과 같습니다.

• [email protected] 형식의 SMTP 로그인 대신 계정 이메일 주소를 사용했습니다.
• 사용자 이름 필드에 smtp-relay.brevo.com 을 붙여 넣었습니다. Brevo도 이를 가장 흔한 원인 중 하나로 꼽습니다.
• SMTP 키 대신 API 키를 사용했습니다.
• 복사와 붙여넣기 과정에서 키 끝에 공백이나 줄바꿈이 들어갔습니다.
• 암호화 설정이 포트와 맞지 않습니다.
• 보안 경고 이후 키가 무효화되었습니다. 이 경우 새 키를 생성하십시오.

525 5.7.1 Unauthorized IP address

IP 차단이 활성화되어 있고 연결한 주소가 허용되지 않았다는 뜻입니다. 해당 주소를 추가하시되, 애플리케이션이 NAT 뒤나 컨테이너 플랫폼에서 동작한다면 실제 송출 주소부터 확인하십시오.

응답도 배너도 없음

TCP 연결은 열리는데 서버가 220 인사말을 전혀 보내지 않는다면 인증을 시작할 수 없으며, 문제는 네트워크의 이쪽 편에 있습니다. 기업 방화벽이 연결은 허용하고 SMTP 트래픽만 조용히 버리는 경우가 있습니다. AWS와 Azure, Google Cloud는 신규 계정에서 기본적으로 아웃바운드 SMTP를 제한합니다. 제한 해제를 요청하거나 2525 포트로 전환하십시오.

450, 플랫폼 미활성화

SMTP 계정이 아직 활성화되지 않았거나 발송 플랫폼이 현재 비활성화되어 있다는 오류입니다. 신규 계정에서는 트랜잭션 발송에 Brevo 지원팀의 별도 활성화 절차가 필요합니다. 기존 계정에서는 대개 정지 상태를 뜻하며, 보호되지 않은 폼이 봇 가입에 노출되었거나 계정에 침해 정황이 나타난 경우입니다.

발신자 거부

세 가지를 확인하십시오. 도메인이 인증되어 있는지, 발신자가 검증되었는지, 그리고 From 헤더가 SMTP 로그인이 아닌지입니다.

메일은 수신되지만 스팸함으로 감

다음 순서로 점검하십시오. 발신 도메인이 인증되어 있고 DKIM 서명이 이루어지는지 확인합니다. From 도메인이 무료 메일 제공업체가 아니라 자사 도메인인지 확인합니다. Postmaster Tools에서 불만율을 0.3% 기준과 비교합니다. 콘텐츠는 이 점검이 모두 깨끗해진 뒤에 살펴보십시오. 콘텐츠가 첫 번째 원인인 경우는 거의 없습니다.

전용 IP

전용 IP는 볼륨이 높고 일정할 때만 도움이 됩니다. 의미 있는 발송을 시작하기 전에 워밍업이 필요하며, 헤더에서 mailed by와 반송 경로 도메인으로 표시될 발송용 서브도메인도 필요합니다. Brevo가 SPF와 MX 레코드를 제공하는 것은 이 구성 하나뿐이며, 해당 서브도메인에 대한 A, CNAME, DKIM, DMARC 레코드도 함께 제공됩니다.

주의할 점이 두 가지 있습니다. 마케팅 이메일용으로 설정된 전용 IP는 트랜잭션 메시지를 발송하지 않고 대기열에 쌓아 두므로, 설정을 바꾸거나 두 번째 IP를 구매해야 합니다. 그리고 트랜잭션과 마케팅 라우팅을 분리하려면 서로 다른 발신자를 가진 최소 두 개의 IP 풀이 필요합니다. 그래야 마케팅 메일의 낮은 참여도가 영수증과 비밀번호 재설정 메일을 끌어내리지 않습니다.

처음부터 제대로 하기

도메인을 인증하고, 이름을 붙인 SMTP 키를 만들고, smtp-relay.brevo.com 에 587로 연결한 뒤, 대시보드의 버튼이 아니라 실제 코드 경로를 통해 테스트를 발송하십시오. 이후에 생기는 문제는 거의 전부 다음 세 가지 중 하나로 귀결됩니다.

• 사용자 이름이나 비밀번호 필드에 잘못된 자격 증명이 들어간 경우.
• 포트와 암호화 설정이 서로 어긋난 경우.
• 발신 도메인이 애초에 인증되지 않은 경우.

이 세 가지를 제대로 해 두면 릴레이는 배경으로 사라집니다. 트랜잭션 인프라는 원래 그래야 합니다.