Outlook CLI: 터미널에서 이메일 보내기

Outlook CLI로 터미널에서 이메일을 보내려면?

Outlook 또는 Microsoft 365를 한 번 연결한 후 nylas email send --to user@example.com --subject "Hello" --body "Hi" --yes로 전송합니다. Azure AD 앱 등록, MSAL 연동, SMTP 설정 없이 Outlook CLI 전송 워크플로를 사용할 수 있습니다.

이 명령어는 개발자들이 일반적으로 Graph API 앱 등록이나 SMTP 인증 설정으로 해결하는 Outlook 커맨드라인 이메일 전송 시나리오를 정확히 처리합니다.

Outlook 이메일을 프로그래밍 방식으로 보내는 문제는 Microsoft의 설정 과정에서 시작됩니다.

Outlook 이메일을 프로그래밍 방식으로 전송하려면 Microsoft 에코시스템에서 4~5단계의 설정이 필요합니다: Azure AD 애플리케이션 등록, Mail.Send API 권한 설정, 관리자 동의 획득, MSAL 인증 라이브러리 통합, 토큰 갱신 처리. 터미널이나 셸 스크립트에서 한 번 보내는 작업에 이 오버헤드는 10초짜리 작업을 45분짜리 프로젝트로 바꿉니다.

Microsoft가 권장하는 전송 경로는 Graph API /sendMail 엔드포인트입니다. Microsoft의 OAuth 2.0 문서에 따르면, 액세스 토큰은 60~90분 후 만료되며 리프레시 토큰 순환이 필요합니다.

터미널이나 셸 스크립트에서 빠르게 보내려면 설정이 너무 많습니다. smtp.office365.com의 포트 587을 통한 SMTP는 아직 작동하지만, Microsoft는 2022년 10월 Exchange Online의 Basic Auth를 폐기했습니다. 더 이상 사용자명/비밀번호를 사용할 수 없습니다.

Nylas CLI는 이 모든 것을 우회합니다. Nylas API와 통신하며, OAuth2 토큰 갱신, 프로바이더 라우팅, 연결 관리를 처리합니다. 한 번 인증하면 명령어 하나로 전송할 수 있습니다.

1. 설치

Nylas CLI는 macOS, Linux, Windows에서 30초 이내에 설치되며 Azure AD 앱 등록, Graph API 인증 정보, MSAL 라이브러리가 필요 없습니다. 바이너리는 20 MB 미만의 단일 Go 실행 파일로 설치 중 플랫폼과 아키텍처를 자동 감지합니다.

macOS 또는 Linux에서는 Homebrew로 설치합니다. Statcounter에 따르면 Outlook 데스크톱 사용자의 80% 이상이 실행하는 Windows에서는 PowerShell 원라이너를 사용합니다. 두 방법 모두 SHA-256 체크섬을 자동 검증합니다. 추가 설치 옵션은 시작하기 가이드를 참조하세요.

2. Outlook 계정 인증

인증은 단일 OAuth2 플로를 통해 Nylas CLI를 Outlook 또는 Microsoft 365 사서함에 연결하며, Graph API에서 요구하는 다단계 Azure AD 앱 등록을 대체합니다. 전체 과정은 약 2분이며, 인증 정보를 시스템 키링에 안전하게 저장하므로 매 명령마다 다시 인증할 필요가 없습니다.

dashboard-v3.nylas.com에서 애플리케이션을 생성하고 Outlook 또는 M365 사서함을 연결합니다. 그런 다음 API 키로 CLI를 설정합니다. Microsoft의 OAuth 2.0 문서에 따르면, 액세스 토큰은 60~90분 후 만료됩니다 — Nylas가 백그라운드에서 자동으로 갱신을 처리합니다.

nylas auth config
# 프롬프트에서 API 키 붙여넣기

# 연결 확인
nylas auth whoami
# => Authenticated as you@company.com (Microsoft)

인증 정보는 OS 키링(macOS Keychain, Windows Credential Manager, Linux libsecret)에 저장됩니다. 그랜트를 취소하지 않는 한 다시 인증할 필요가 없습니다.

3. 사용자 사서함, 별칭, 공유 사서함에서 전송

Microsoft 365 조직은 일반적으로 부서당 3~5가지 사서함 ID 유형을 관리합니다 — 사용자 사서함, 공유 사서함, 배포 그룹, 리소스 룸, 대신 보내기 별칭. Nylas CLI는 올바른 grant ID를 지정하여 이러한 모든 ID에서 전송합니다. 핵심 질문은 "메시지를 보낼 수 있는가?"가 아니라 "이 메시지를 어떤 사서함 ID에서 보내야 하는가?"입니다.

개인 Outlook 사서함에서 보내려면 grant ID 없이 명령을 실행합니다 — CLI가 기본 인증된 사서함을 사용합니다. 공유 사서함이나 부서 ID에서 보내려면 공유 사서함의 grant ID를 첫 번째 인자로 전달합니다. 각 그랜트는 Exchange Online의 정확히 하나의 사서함 ID에 매핑됩니다.

# 자신의 Outlook 사서함에서 전송
nylas email send \
  --to "colleague@company.com" \
  --subject "Q2 planning doc" \
  --body "Hi — the planning doc is ready for review." \
  --yes

# 공유 사서함 그랜트에서 전송
nylas email send <shared-mailbox-grant-id> \
  --to "vendor@partner.com" \
  --subject "PO #4521" \
  --body "Purchase order 4521 is ready for review." \
  --yes

send-as 또는 공유 사서함 권한이 없으면, 명령 구문이 올바르더라도 Microsoft 365가 403 오류를 반환하고 전송을 거부합니다. Microsoft의 Exchange Online 권한 문서에 따르면, 공유 사서함 위임 변경이 전파되는 데 최대 60분이 걸릴 수 있습니다. 이 오류는 CLI 문제가 아니라 Exchange Online 정책 문제입니다.

4. 배포 목록, 별칭, 팀 큐

Microsoft 365 배포 목록과 M365 그룹은 서버 측에서 모든 구성원 사서함으로 확장되므로, 단일 nylas email send 명령으로 클라이언트 측 주소 확인 없이 수백 명의 수신자에게 도달할 수 있습니다. 500명 이상의 직원을 둔 기업은 일반적으로 부서, 프로젝트 팀, 규정 준수 라우팅을 위해 20~50개의 배포 목록을 유지합니다. Nylas CLI는 --to 플래그에 목록 주소를 지정하여 개별 주소로 보내는 것과 동일한 방식으로 이러한 목록에 전송합니다.

아래 예시는 두 가지 일반적인 패턴입니다: 엔지니어링 배포 목록으로 브로드캐스트, CC로 법무팀에 계약 업데이트를 라우팅하면서 규정 준수 BCC를 포함하는 패턴. --bcc 플래그는 규정 준수 또는 저널링 주소를 보이는 수신자 목록에서 숨기며, 이는 금융 및 의료와 같은 규제 산업에서 자주 요구되는 사항입니다.

# 배포 목록으로 전송
nylas email send \
  --to "engineering-all@company.com" \
  --subject "Deployment window tonight" \
  --body "Production deploy starts at 22:00 UTC. Freeze all PRs by 21:00." \
  --yes

# 규정 준수 또는 아카이브 수신자 포함
nylas email send \
  --to "contracts@company.com" \
  --cc "legal@company.com" \
  --bcc "compliance@company.com" \
  --subject "Contract update" \
  --body "Updated terms are ready for review in the contract system." \
  --yes

5. HTML 본문과 비즈니스 워크플로 이메일

Outlook 비즈니스 이메일은 인보이스, 승인, 작업 명세서, 조달 업데이트를 자주 전달합니다. 현재 CLI 전송 명령은 --body를 통해 HTML을 수신하고, --template-id를 통해 호스팅된 템플릿을 지원하며, 파일 전달은 별도로 유지합니다: 문서 시스템에 파일을 게시하고 링크를 보내거나, MIME 첨부가 필요할 때 Nylas API/SDK를 사용합니다.

Outlook의 렌더링 엔진은 Microsoft Word의 HTML 파서를 통해 HTML을 처리하므로, 일부 CSS 속성이 Gmail이나 Apple Mail과 다르게 렌더링됩니다. 자동화된 HTML 본문은 작게 유지하고, 중요한 스타일을 인라인으로 처리하며, 테넌트 레벨의 DLP 및 전송 규칙이 전송 완료 후 최종 메시지를 검사하도록 합니다.

nylas email send \
  --to "client@example.com" \
  --subject "Invoice #1042" \
  --body "<h1>Invoice #1042</h1><p>Amount due: <strong>$2,400.00</strong></p><p>Payment link: <a href='https://pay.example.com/1042'>pay.example.com/1042</a></p>" \
  --yes

6. 예약 전송 및 Microsoft 365 제한 준수

Microsoft 365의 예약 이메일 전송은 지금 메시지를 작성하고 특정 미래 시간에 전송되도록 할 수 있어, 다른 시간대의 수신자에게 연락하거나 업무 외 시간에 후속 메시지를 대기시키는 데 유용합니다. Microsoft 365는 대부분의 플랜에서 분당 30개 메시지, 하루 10,000명의 수신자 제한을 적용하므로, 대량 또는 자동화된 전송 루프는 임시 차단을 방지하기 위해 의도적인 속도 조절이 필요합니다.

--schedule 플래그는 "tomorrow 9am"이나 "next Monday 2pm EST"와 같은 자연어 시간 표현을 수신합니다. 대량 전송 루프의 경우, 전송 사이에 2초 대기를 추가하면 Microsoft의 분당 30개 메시지 한도를 충분히 지키며 최대 24시간 지속되는 임시 전송 차단을 방지할 수 있습니다.

# 후속 메시지 예약
nylas email send \
  --to "client@example.com" \
  --subject "Follow-up" \
  --body "Checking in on the proposal." \
  --schedule "tomorrow 9am" \
  --yes

# 사서함 자동화 루프에 속도 제한 적용
while read -r recipient; do
  nylas email send --to "$recipient" --subject "Status update" --body "See attached notes." --yes
  sleep 2
done < recipients.txt

7. 스크립팅 및 감사 추적을 위한 JSON 출력

nylas email send 명령에 --json을 추가하면 메시지 ID, grant ID, thread ID, 타임스탬프, 발신자/수신자 주소를 포함한 전체 메시지 객체를 구조화된 JSON으로 반환합니다. 이 출력은 전송 이벤트 로깅, 다운스트림 큐 프로세서에 메시지 ID 전달, 정확한 타임스탬프가 포함된 전송 시도 증명이 필요한 규정 준수 감사 추적에 유용합니다.

JSON 응답은 일반적으로 메시지당 400~600바이트이며 Nylas API 메시지 스키마를 따릅니다. jq를 통해 출력을 파이핑하면 특정 필드를 추출할 수 있습니다 — 추적을 위한 메시지 ID, 대화 스레딩을 위한 thread ID, 감사 로그를 위한 날짜.

nylas email send \
  --to "user@example.com" \
  --subject "Test" \
  --body "Hello." \
  --json --yes

{
  "id": "a1b2c3d4e5f6g7h8",
  "grant_id": "d3f4a5b6-c7d8-9e0f-a1b2-c3d4e5f6g7h8",
  "thread_id": "x9y8z7w6v5u4t3s2",
  "subject": "Test",
  "from": [{"name": "Dev User", "email": "dev@company.com"}],
  "to": [{"name": "", "email": "user@example.com"}],
  "date": "2026-03-28T10:30:00-04:00",
  "object": "message"
}

셸 스크립트에서 jq를 사용하여 JSON 출력에서 메시지 ID를 캡처하고 다운스트림 처리에 사용할 수 있습니다 — 전송 상태 확인, 감사 CSV에 추가, 티켓 시스템에 전달. .id 필드는 Nylas API에서 메시지에 매핑되는 고유한 16자 문자열입니다.

# 전송 후 메시지 ID 캡처
msg_id=$(nylas email send \
  --to "user@example.com" \
  --subject "Automated" \
  --body "This is automated." \
  --json --yes | jq -r '.id')

echo "Sent message: $msg_id"

Graph API vs. Nylas CLI

Microsoft Graph API로 단일 Outlook 이메일을 보내려면 Azure AD 앱 등록, MSAL 토큰 획득, 토큰 갱신 처리, 실제 POST 요청을 포함하여 50~100줄의 Python 또는 Node.js 코드가 필요합니다. Nylas CLI는 이를 코드 0줄, Azure 포털 설정 없이 1개의 명령으로 줄입니다. 아래 비교표는 두 접근 방식의 각 단계를 분석합니다.

Outlook 관련 팁

Microsoft 365에는 Gmail이나 Yahoo 같은 소비자 이메일 프로바이더에 없는 테넌트 레벨 정책, 규정 준수 기능, 사서함 유형이 있습니다. 다음 팁은 수신 확인, 민감도 레이블, 공유 사서함, 속도 제한, 전송 규칙 등 CLI에서 전송된 이메일이 처리되는 방식에 영향을 미치는 Outlook 고유의 동작을 다룹니다.

수신 확인

Outlook은 Disposition-Notification-To 헤더를 통한 수신 확인 요청을 지원합니다. Nylas CLI를 통해 보내면, 수신자의 Outlook 클라이언트가 설정에 따라 수신 확인을 보낼지 묻는 메시지를 표시할 수 있습니다. Microsoft 문서에 따르면, 수신자가 수신 확인 요청을 거부할 수 있으므로 자동화된 워크플로에서 배달 확인 용도로 의존하지 마세요.

민감도 레이블

M365 민감도 레이블(기밀, 내부용 등)은 Microsoft Information Protection에 의해 테넌트 레벨에서 적용됩니다. Nylas CLI를 통해 보내는 메시지는 테넌트의 기본 레이블 정책을 따릅니다. 조직에서 특정 레이블이 필요한 경우, Exchange 관리자가 전송 클라이언트에 관계없이 모든 아웃바운드 이메일에 적용되는 자동 레이블 규칙을 설정할 수 있습니다.

공유 사서함 전송

공유 사서함에서 보내려면 OAuth 플로를 통해 별도의 그랜트로 연결합니다. 각 공유 사서함은 자체 grant ID를 가지며, 전송 시 해당 ID를 참조합니다. 공유 사서함을 연결하는 사용자 계정은 Exchange Online에서 전체 액세스 또는 대신 보내기 권한이 있어야 합니다 — 위임 변경이 전파되는 데 최대 60분이 걸릴 수 있습니다.

# 공유 사서함 연결
nylas auth login
# 공유 사서함의 OAuth 플로 진행

# 공유 사서함의 grant ID를 사용하여 전송
nylas email send <shared-mailbox-grant-id> \
  --to "vendor@partner.com" \
  --subject "PO #4521" \
  --body "Purchase order 4521 is ready for review."

Outlook 전송 제한

Microsoft 365는 대부분의 플랜에서 하루 10,000명의 수신자, 분당 30개 메시지 제한을 적용합니다. Microsoft의 Exchange Online 제한 문서에 따르면, 이 한도를 초과하면 임시 차단이 발생합니다. 대량 전송 시 스크립트에서 메시지 사이에 sleep 2를 추가하세요.

전송 규칙, 저널링, 대신 보내기 정책

Microsoft 365 메일 플로는 수신자에게 도달하기 전에 메시지를 처리하는 테넌트 전체 Exchange Online 규칙에 의해 형성됩니다. 전송 규칙은 발신자, 수신자, 제목, 콘텐츠 패턴에 따라 메시지를 리디렉션, 차단, 수정할 수 있습니다. 저널링은 모든 이메일을 규정 준수 사서함으로 복사합니다. DLP 정책은 100개 이상의 내장 민감한 정보 유형에 대해 첨부 파일과 본문 콘텐츠를 검사합니다. Microsoft의 메일 플로 규칙 문서에 따르면, 전송 규칙은 우선순위 순서로 평가되며 첫 번째 일치하는 규칙이 추가 처리를 중단할 수 있습니다.

두 사서함 간에 Outlook 전송이 다르게 동작하는 경우, 원인은 보통 CLI 명령 구문이 아니라 사서함 정책 또는 테넌트 라우팅 정책입니다.

공유 사서함 및 팀 큐 워크플로

Microsoft 365 조직은 조달, 지원, 채용, 임원 운영에 공유 사서함을 사용합니다. Microsoft의 공유 사서함 문서에 따르면, 50 GB 미만의 사서함은 별도 라이선스가 필요하지 않습니다. Nylas CLI를 통해 support@company.com이나 ap@company.com에서 전송하려면 공유 사서함을 별도의 그랜트로 연결하고 전송 명령에서 해당 grant ID를 지정합니다.

다음 단계

터미널에서 Outlook 이메일을 보낼 수 있게 되면, Outlook 수신함 읽기 및 필터링, 캘린더 이벤트 관리, AI 에이전트를 사서함에 연결하거나, 다른 프로바이더로 전환하는 등 워크플로를 확장할 수 있습니다 — Nylas CLI는 동일한 명령 구문으로 6개 프로바이더를 지원합니다.

• 터미널에서 이메일 보내기 — Linux, macOS, Windows를 아우르는 크로스 프로바이더 가이드
• 터미널에서 Outlook 이메일 목록 조회 — Outlook 수신함 읽기, 검색, 필터링
• CLI로 Outlook 캘린더 관리 — 이벤트 생성, 가용성 확인, 미팅 예약
• MCP를 통해 AI 에이전트에 이메일 액세스 부여 — Claude, Cursor, VS Code를 Outlook 수신함에 연결
• 전체 명령어 레퍼런스 — 모든 플래그와 서브커맨드 문서