SMTP Connection Troubleshooting for GQ CRM

SMTP failures look mysterious, but they cluster into a handful of predictable causes. This guide walks through the common failure modes in order — auth, TLS/ports, From-domain, relay policy, and rate limits — with the exact symptoms and fixes for each.

1. Authentication failures

Symptom: 535 Authentication failed, Username and Password not accepted, Invalid login.

The most common causes:

• Wrong credential type. Gmail/Workspace requires an App Password, not your account password (see the Google Workspace guide). Mailgun requires the domain's SMTP login, not your dashboard password (see the Mailgun guide). SES requires a dedicated SMTP credential — your regular AWS access keys won't work (see the SES guide).
• Copy-paste corruption. App Passwords contain spaces (abcd efgh ijkl mnop) — remove spaces when pasting.
• A rotated credential. You changed the provider password, and the SMTP credential (App Password / SMTP password / SES credential) no longer matches. Recreate it.

Fix: re-read the provider's guide, create a fresh credential of the right type, and paste carefully.

2. TLS / port mismatches

Symptom: connection resets, STARTTLS handshake errors, or the test never completes.

Fix: use 587 STARTTLS or 465 SSL with secure connection on. If the provider supports both, 587 is the common default; if one fails, try the other.

3. From-domain problems

Symptom: 554 Message rejected, mail accepted for tests but not for real recipients.

• The From email's domain must be verified and authenticated with the relay — SES rejects mail from unverified domains; Mailgun rejects mail from domains not set up in your account; Google requires the From address to be the authenticated account (or an alias it controls).
• The From domain must be aligned with what you authenticated (SPF/DKIM/DMARC). Sending From: [email protected] through a relay configured only for mail.yourcompany.com is a mismatch filters notice.

Fix: verify the From domain in the provider's console, confirm SPF/DKIM/DMARC for that exact domain (see the authentication post), then re-test.

4. Relay policy restrictions

Symptom: 454, Access denied, Sandbox restriction, or mail only reaching the address you tested.

• SES sandbox mode — new accounts can only send to verified addresses at 1 email/sec until you request production access (see the SES guide).
• Mailgun sandbox domain — sending from the sandbox domain only works for authorized test recipients; create and verify your own domain (see the Mailgun guide).
• SES IAM permissions — the SMTP credential's IAM user needs ses:SendRawEmail; recreate the credential from SMTP settings if you see access-denied errors.
• Google "too many login attempts" (5.7.8) — the account was temporarily blocked; wait 1–24 hours and slow the rate.

Fix: follow the provider-specific step for leaving the restricted mode before scaling.

5. Rate limits and throttling

Symptom: delays, throttling, or failures only at high volume.

• Per-mailbox daily limits — Gmail ~500/day, Workspace ~2,000/day; for cold outreach keep it far lower (~10–50/day per mailbox) to protect reputation (see the Workspace guide).
• SES default throughput — starts at ~14 emails/sec; set task rate limits below it.
• Provider queues — Mailgun and others queue during spikes; lower your task rate limit to stay within your plan's throughput.

Fix: use GQ CRM's per-task rate limits to pace delivery, and ramp volume gradually.

The 5-minute triage

1. Re-check the credential type for your provider (App Password / SMTP login / SES SMTP credential).
2. Try 587 STARTTLS, then 465 SSL.
3. Confirm the From domain is verified with the relay and aligned in DNS.
4. Check for sandbox/restricted mode (SES sandbox, Mailgun sandbox domain).
5. Look at your rate limit vs the provider's throughput.

SMTP problems are almost never "the tool" — they're one of these five layers. Fix the layer, click Test connection, and you're live. For provider-specific walkthroughs, see Amazon SES, Google Workspace, and Mailgun.