Use a subdomain, not your main domain

Before you copy anything, pick a sending subdomain like mail.yourbiz.com or send.yourbiz.com. Never use your bare apex domain (yourbiz.com) for cold or bulk sending. Here is why:

• Your sending reputation is scored per domain. One bad campaign on your apex tanks your team inbox too.
• Most enterprise inboxes auto trust senders that follow the subdomain convention.
• You can isolate marketing, transactional and cold outreach onto separate subdomains and keep them from cross contaminating.

You will need DNS access (Cloudflare, GoDaddy, Namecheap, Route53, whatever you use) to add the subdomain plus 4 records. Inflowave shows you the exact records to paste, no copying from this guide required.

Gmail (free personal account)

Best for testing or very low volume. Hard capped at 500 recipients per day. Not suitable for cold outreach at scale.

Where to find your Gmail App Password

1. Open myaccount.google.com and sign in.
2. Left sidebar, click Security.
3. Under "How you sign in to Google", confirm 2-Step Verification is ON. App passwords only exist after you enable 2FA.
4. Search for "App passwords" in the search bar at the top, or visit myaccount.google.com/apppasswords directly.
5. Type a name like "Inflowave" and click Create.
6. Google shows a 16-digit passcode. Copy it (no spaces). This is your SMTP password.

Note (2026 changes): Google now recommends "Sign in with Google" over App Passwords for new integrations, but App Passwords still work for SMTP and Inflowave fully supports them.

Auto-revoke: Any time you change or reset your Google Account password, all of your App Passwords are revoked automatically. You will need to regenerate them and update Inflowave.

If "App passwords" does not appear, one of the following is true: 2-Step Verification is set up only with a security key, your account has Advanced Protection enabled, or you are in a Workspace tenant whose admin disabled App Passwords. The first two cases require switching 2FA to include a phone-based factor; the third requires the Workspace admin to enable App Passwords or use the Workspace SMTP Relay path below.

Google Workspace (business)

For volumes above 500/day, or any business email on your own domain. Two paths: the user level SMTP (same as personal Gmail with an App Password) or the SMTP Relay service (best for bulk).

Where to enable SMTP Relay

1. Sign in to the admin console at admin.google.com as a Workspace super admin.
2. Top-left menu: Apps → Google Workspace → Gmail → Routing.
3. Scroll to SMTP relay service (it's a section, not a sidebar item) and click Configure.
4. Name the configuration (e.g. "Inflowave relay").
5. Under Allowed senders, pick one of:
   • "Only registered Apps users in my domains" (strictest, recommended)
   • "Only addresses in my domains"
   • "Any addresses (not recommended)" - only if you need to send from external addresses
6. Under Authentication, check Require SMTP Authentication (so Inflowave authenticates with App Password) and/or Only accept mail from the specified IP addresses (if you have a static egress IP).
7. Under Encryption, check Require TLS encryption.
8. Click Save. Allow up to 24 hours for the relay config to propagate, though it usually takes effect in minutes.

SMTP Relay daily limits (official): 10,000 messages per user per 24h, 100 recipients per single SMTP transaction, 4.6M recipients per organization per 24h, max 319,444 recipients per rolling 10-minute window. Hitting these triggers a soft block that resets at midnight Pacific time.

If "Less secure app access" is mentioned anywhere in a tutorial, that tutorial is out of date - Google removed the feature in 2022. App Passwords or OAuth only in 2026.

Sub-host gotcha: If you misspell smtp-relay.gmail.com as smtp.gmail.com in Inflowave, the connection still authenticates against the user-level path and caps you at 2,000/day silently. Double-check the host before saving.

Outlook.com / Hotmail (free)

Covers @outlook.com, @hotmail.com, @live.com, and @msn.com personal Microsoft accounts. Microsoft requires Modern Auth (OAuth2) by default; App Passwords are the supported workaround for any SMTP client that does not implement OAuth - that includes Inflowave's SMTP path.

Step 1 - Enable POP/SMTP access on your mailbox

As of 2024, Microsoft disables POP and IMAP access by default on new Outlook.com accounts. SMTP send via App Password works only after you toggle this on. Most people miss this step and waste time chasing a 535 auth error that the App Password did not cause.

1. Sign in at outlook.live.com.
2. Top-right gear icon, then View all Outlook settings at the bottom of the panel.
3. Left rail, Mail → Sync email.
4. Under "POP and IMAP", set Let devices and apps use POP to Yes.
5. Click Save.

Step 2 - Confirm 2-Step Verification is on

App Passwords only exist on Microsoft accounts with two-step verification enabled. If you have not turned it on yet, do so at account.microsoft.com/security → Two-step verification → Set up two-step verification. Microsoft will not show the App Passwords menu until 2FA is active.

Step 3 - Generate the App Password

1. Visit account.microsoft.com/security, sign in.
2. Click Advanced security options.
3. Scroll to the App passwords section.
4. Click Create a new app password.
5. Microsoft shows a long random password. Copy it (one-time view, no spaces) and paste into Inflowave.

Step 4 - Send a test email from Inflowave

Inflowave's "Send test" button on the linked domain card sends a single email through your new credentials. A successful 250 response confirms SMTP auth + From-address alignment. If you get 535 here, the most common cause is Step 1 (POP/SMTP not enabled) - go back and verify the Sync email setting.

Volume cap: Outlook.com personal accounts have an opaque daily send cap (commonly ~300 messages per day for new accounts, expanding as the account ages and earns reputation). Suitable for transactional and low-volume notification mail, not for marketing or cold outreach.

Region note: Some legacy Hotmail accounts that originated in EU regions resolve to a different MX cluster but the SMTP host (smtp-mail.outlook.com) remains correct globally. You do NOT need a regional override.

Apps-on-the-account view: The same Advanced security options page also lists every App Password you have created and the date each was last used. If you suspect a compromised credential, revoke it from there and generate a new one.

Microsoft 365 / Exchange Online (business)

Microsoft disables SMTP AUTH tenant-wide by default since October 2022 (and again for any new tenant since 2023). To send through smtp.office365.com, an admin has to turn it on at three levels: tenant, mailbox, and authentication policy. Skipping any one of these returns the same generic "535 5.7.139 Authentication unsuccessful" error.

Step 1 - Confirm Security Defaults are OFF (or you have an exception)

If "Security defaults" is enabled in your tenant (the default on new tenants since 2019), SMTP AUTH is blocked organization-wide regardless of any other setting. To check: entra.microsoft.com → Identity → Overview → Properties → Manage Security defaults. If on, either turn it off (and replace it with Conditional Access policies), or accept that SMTP AUTH cannot be used in this tenant.

Step 2 - Enable SMTP AUTH at the tenant level

Two paths - Exchange admin center (EAC) or PowerShell.

EAC path:

1. Sign in to admin.exchange.microsoft.com.
2. Settings → Mail Flow.
3. Find the toggle "Turn off SMTP AUTH protocol for your organization". Set it to OFF (i.e. leave the protocol on).

PowerShell path (Exchange Online module):

Set-TransportConfig -SmtpClientAuthenticationDisabled $false

Confirm with:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Expected: SmtpClientAuthenticationDisabled : False

Step 3 - Enable SMTP AUTH on the specific mailbox

The per-mailbox setting overrides the tenant setting. Even with tenant-wide AUTH on, the mailbox must be allowed explicitly.

Admin center path:

1. Open admin.microsoft.com.
2. Users → Active users, click the mailbox you'll send from.
3. In the flyout, Mail tab.
4. In the Email apps section, click Manage email apps.
5. Check the Authenticated SMTP box.
6. Save changes.

PowerShell equivalent:

Set-CASMailbox -Identity sender@yourtenant.com -SmtpClientAuthenticationDisabled $false

Confirm:

Get-CASMailbox -Identity sender@yourtenant.com | Format-List SmtpClientAuthenticationDisabled

Step 4 - Generate the App Password

1. The mailbox user signs in to portal.office.com.
2. Top-right profile avatar → View account.
3. Left rail, Security info.
4. Click Add sign-in method, choose App password, name it "Inflowave".
5. Microsoft shows the password once. Copy and paste into Inflowave immediately.

App Password availability: Per-user App Passwords only appear if the user has MFA enabled AND your tenant authentication policy permits them. Some tenants gate App Passwords entirely via Conditional Access - if the option does not appear, ask your Microsoft 365 admin to verify that "App passwords" are allowed in the user's session controls.

UPN, not alias: The SMTP username must be the User Principal Name (UPN), not a SMTP alias. Sending as an alias returns "550 5.7.60 SMTP; Client does not have permissions to send as this sender". To send as an alias, add it as a primary SMTP address or configure Send As permissions in Exchange.

Long-term recommendation: Microsoft is steadily deprecating SMTP AUTH. For new production setups they recommend the High Volume Email API or OAuth-authenticated SMTP. For Inflowave today, App Password + SMTP AUTH still works and is supported through at least 2026 per Microsoft's roadmap.

Yahoo Mail

Where to find it

1. Sign in at login.yahoo.com/account/security.
2. Scroll to External connections (this section was renamed from "Other ways to sign in" in 2024).
3. Click Generate and manage app passwords, then Create app password.
4. Enter your app's name (e.g. "Inflowave"), then click Generate password.
5. Yahoo shows a one-time 16-character password. Copy and paste it into Inflowave, then click Done.

Browser warning: Yahoo's anti-abuse system flags app-password creation from unrecognized browsers. Generate the password from a browser you have signed into Yahoo with for several days. Incognito and brand-new browsers frequently get blocked with no error message.

Persistence: Unlike Google and Apple, Yahoo app passwords do NOT get revoked when you change your main Yahoo password. You must manually delete them from the same screen if you want to revoke them.

Zoho Mail

Zoho splits its SMTP host across two products: free/personal accounts use smtp.zoho.com, paid Mail/Workplace organizations use smtppro.zoho.com. The hosts are not interchangeable - using the wrong one returns a generic "authentication failed" error.

Regional hosts: If your Zoho account is on the EU data center, swap any .com in the host above for .eu (e.g. smtp.zoho.eu, smtppro.zoho.eu). India accounts use .in, Australia accounts .com.au. The exact host for your account is shown in the Zoho Mail settings under Server Configuration Details - always confirm there before saving.

Where to find your App-Specific Password

1. Sign in to accounts.zoho.com.
2. Left sidebar, Security, then App Passwords.
3. Click Generate New Password, name it "Inflowave SMTP".
4. Copy the generated password and paste it into Inflowave.

2FA prerequisite: App Passwords only appear under Security if you have Two-Factor Authentication enabled. If you do not see the App Passwords option, enable 2FA first (Security → Multi-Factor Authentication).

Email must match: Your sending email address in Inflowave must match the Zoho account that owns the App Password, OR an alias configured on that account. Sending as a different address returns "550 Relaying denied".

iCloud Mail

Where to find it

1. Visit account.apple.com and sign in.
2. Click Sign-In and Security.
3. Select App-Specific Passwords.
4. Click Generate an app-specific password, name it "Inflowave", and complete the on-screen prompts.
5. Apple shows the password once. Copy and paste it into Inflowave immediately.

2FA required: App-specific passwords only exist on Apple accounts with two-factor authentication enabled. There is no way to bypass this - Apple will silently hide the menu otherwise.

25-password cap: Apple allows up to 25 active app-specific passwords per account. If you hit the cap, revoke unused ones from the same screen before generating a new one.

Auto-revoke: Any time you change or reset your Apple Account password, ALL of your app-specific passwords are revoked simultaneously. You will need to regenerate the one used for Inflowave and update it in Settings.

Volume: iCloud caps outbound mail aggressively (around 1,000/day on a healthy account, much lower if Apple flags your traffic). Use only for personal volumes or test sends - never for marketing or cold outreach.

Twilio SendGrid

Built for transactional and bulk. The SMTP username is a literal string (the word "apikey"), not your account email. This trips up almost everyone setting it up for the first time.

Step 1 - Create the API key

1. Sign in at app.sendgrid.com.
2. Left sidebar, Settings → API Keys.
3. Click Create API Key (top-right).
4. Name it (e.g. "Inflowave SMTP").
5. Choose permissions:
   • Restricted Access (recommended) → scroll to Mail Send → set to Full Access.
   • OR Full Access if you want the same key to manage templates, suppressions, etc.
6. Click Create & View.
7. Copy the API key immediately - SendGrid shows it once and never again. The key starts with SG. and is ~69 characters long.

Step 2 - Paste into Inflowave

1. Inflowave → Settings → Email → Add sending domain → choose SMTP.
2. Host: smtp.sendgrid.net
3. Port: 587
4. Username: apikey (exactly this word, lowercase, no quotes)
5. Password: paste the SG.xxx key (no whitespace, no trailing newline - SMTP is line-oriented and a stray newline corrupts auth)

Per-connection limit: A single SMTP connection caps at 5,000 messages. Above that, the connection is dropped and you reconnect. Inflowave reconnects automatically; you do not need to manage this.

Concurrent connections: Up to 10,000 SMTP connections from a single sending IP. Plenty for any single-tenant Inflowave workspace.

Do not hardcode IPs: SendGrid rotates the IPs behind smtp.sendgrid.net without notice. Always use the hostname; never lock to an IP.

Why "apikey"?: The SendGrid SMTP layer treats the username as a fixed identifier and authenticates entirely on the API key. The literal string is required - putting your account email there returns "535 Authentication failed".

Mailgun

Mailgun splits its infrastructure between US and EU regions for GDPR/data-residency. The two have completely separate dashboards, separate SMTP hosts, and separate credentials. Pick the region when you create the account; you can't change it later.

Where to find the SMTP credentials

1. Sign in to app.mailgun.com (US) or app.eu.mailgun.com (EU).
2. Left nav, Send → Sending → Domains.
3. Click your verified domain (e.g. mail.yourbiz.com).
4. Top tabs, click Domain settings.
5. Click the SMTP credentials tab.
6. You'll see the auto-created postmaster@your-domain user. To use it, click Reset Password (Mailgun does not display the existing password, so a reset is required to get one you can paste).
7. Copy the new password immediately - it shows once.

Add a dedicated SMTP user (recommended)

Instead of reusing the master postmaster credential across multiple services, create a dedicated user per integration so a leak in one place doesn't compromise all sends.

1. Same SMTP credentials tab.
2. Click New SMTP user.
3. Set login name (e.g. inflowave@your-domain).
4. Mailgun generates a password automatically. Copy it once.

Sandbox domain limits: If you signed up but haven't added a verified custom domain yet, Mailgun gives you a sandbox domain (sandboxXXX.mailgun.org). The sandbox can only send to 5 authorized recipients you explicitly verify, total. It's for testing the integration, not for production sends.

Region matters for DNS, too: The DNS records Mailgun gives you (SPF, DKIM, MX, tracking CNAME) differ between US and EU. Paste the records from the region your account is in, not a copy from a tutorial.

Free tier (Foundation): 100 emails/day to verified recipients only - useful only for testing. Production volume requires the Flex plan or above.

Postmark

Built specifically for transactional email with strict reputation isolation. Postmark uses the unusual pattern of putting the same Server API Token into BOTH the username and password fields - most people fill it in once and get authentication errors before realizing they need to paste it twice.

Postmark isolates transactional and broadcast streams on separate IP pools, so a marketing list issue cannot drag down your password-reset deliverability. Pick the host that matches the stream you'll send through.

Where to find your Server API Token

1. Sign in to account.postmarkapp.com.
2. Click the Server you want to send through (or create one).
3. Top tabs, click API Tokens.
4. Copy the value labeled Server API Token (you may have multiple; pick the one matching your environment).

Server API Token, NOT Account API Token: Postmark has two token tiers. The Account API Token manages your billing and server list - it does NOT work for SMTP and Postmark will return "ServerAPI key required". Always use the per-server token.

Choosing a message stream (optional)

When sending via smtp.postmarkapp.com, Postmark routes to the default transactional stream unless you specify otherwise. To target a specific stream (e.g. a separate stream for receipts vs notifications), add a custom SMTP header:

X-PM-Message-Stream: your-stream-id

Most Inflowave use cases don't require manual stream selection - the default transactional stream is correct.

TLS: Postmark supports STARTTLS on the standard ports. The official guidance is "use TLS if possible" - Inflowave defaults to STARTTLS on port 587, no configuration needed.

Amazon SES

The cheapest path at scale once you are out of the sandbox - roughly $0.10 per 1,000 emails plus $0.12/GB for attachments. Requires more setup than the other providers but the unit economics are unbeatable above ~50k sends/month.

Pick the right regional endpoint

SES SMTP credentials are unique per AWS region. If you send from more than one region, you must generate a separate set of credentials per region. The 17 currently active SMTP endpoints:

Required IAM permissions (the gotcha)

The IAM user clicking "Create SMTP Credentials" must have permission to create OTHER IAM resources, because SES generates a new IAM user behind the scenes. You need all five:

• iam:CreateUser
• iam:CreateGroup
• iam:PutGroupPolicy
• iam:AddUserToGroup
• iam:CreateAccessKey

Without all five, the console either errors or (worse) silently creates credentials without the right SES sending policy attached, and your sends fail with "554 not authorized".

Generate SMTP credentials

1. Sign in to the AWS Console and open console.aws.amazon.com/ses/.
2. Switch to the AWS region you will send from (top-right region picker).
3. Left nav, click SMTP settings.
4. Click Create SMTP credentials in the upper-right. AWS opens the IAM console.
5. Leave the auto-suggested user name OR rename to something memorable like "ses-smtp-inflowave-us-east-1".
6. Click Create user.
7. Click Show next to SMTP password. Copy username + password OR click Download .csv file.
8. Click Return to SES console.

One-time view: AWS does NOT show the SMTP password again. If you lose it, delete the IAM user and repeat the process.

Get out of the sandbox

Until you request production access, SES is sandboxed: you can only send TO verified addresses, only 200 emails per 24 hours, and only 1 email per second. To request production access:

1. SES console, Account dashboard.
2. Top banner, click Request production access.
3. Fill out the use-case form - be specific about volume, bounce handling, and unsubscribe mechanism. Vague applications get rejected.
4. AWS typically responds within 24-48 hours.

September 2024 IAM change: SMTP credentials created after Sept 6, 2024 use a group policy attached to the IAM user. Older credentials use an inline policy. Both work, but the group-policy version is more secure and AWS recommends migrating. The migration is in the SES docs under "Migrating a SMTP user from an existing inline policy to a group policy".

cPanel / shared hosting (Bluehost, HostGator, SiteGround, Namecheap)

Most shared hosting providers expose SMTP through cPanel.

Where to find the exact host

1. Sign in to cPanel.
2. Email Accounts, find your mailbox.
3. Click Connect Devices or Configure Mail Client.
4. The page shows the exact SMTP host, port and SSL settings for your specific hosting setup.

Custom SMTP (anything else)

If your provider is not listed above (Mailjet, SparkPost, Brevo, Fastmail, ProtonMail Bridge, Migadu, self hosted Postfix, etc), the same 5 fields apply. Look in their docs for "SMTP settings" or "SMTP credentials". The four words always show up together.

DNS records you will be asked to add

Once you save the SMTP credentials, Inflowave verifies your domain with 4 DNS records. Add them in your DNS host (Cloudflare, Route 53, Namecheap, GoDaddy, whatever):

You do not need to write these yourself. Inflowave generates the exact values with the host, type, and TTL, ready to paste. Most DNS hosts propagate in 5 to 30 minutes. Cloudflare is usually instant.

Troubleshooting common errors