To stop CRM emails landing in spam, go to Settings → SMTP, connect your own mail provider, and set your From email to an address on your own domain. Without this, the CRM sends through a shared platform fallback address that recipients' spam filters increasingly distrust — not because anything is broken, but because a message claiming to be from "yourcompany.com" while actually sent through unrelated infrastructure is exactly the pattern spam filters are built to catch.
Why this happens even though nothing is "wrong"
Email providers (Gmail, Outlook, and every serious mail server) check whether the domain in a message's From address actually authorized the server that sent it — this is what SPF, DKIM and DMARC exist to verify. When your CRM sends without your own SMTP connected, it falls back to a generic sending path that has no such authorization tied to your business's domain. The email still arrives most of the time, just increasingly filtered as spam-suspicious, especially to recipients who've never received mail from that path before. Connecting your own SMTP fixes this at the source, because the emails then genuinely originate from infrastructure your domain has authorized.
Getting SMTP credentials
Any of these work — pick whichever you already use for business email:
- Google Workspace: host
smtp.gmail.com, port587, encryption TLS. You'll need an app password rather than your normal login password — generate one from your Google Account's Security settings under "App passwords" (only available if 2-Step Verification is turned on). - Microsoft 365 / Outlook: host
smtp.office365.com, port587, TLS, using your normal mailbox credentials (or an app password if your organization requires modern auth with MFA). - A transactional email provider (Amazon SES, SendGrid, Mailgun, Zoho Mail): each provides its own SMTP host, port, and a generated username/password specifically for SMTP sending — check that provider's SMTP relay documentation for the exact values.
Filling in the form
- Go to Settings → SMTP and turn the toggle on.
- Host and Port — from your provider, above.
- Encryption — TLS is the standard choice for port 587; use SSL only if your provider specifically requires port 465.
- Username and Password — your mailbox login or the provider's generated SMTP credentials.
- From email — an address on your own domain, e.g.
notifications@yourcompany.com. This is the single field that matters most for deliverability; a mismatched or generic address undoes most of the benefit of connecting SMTP at all. - From name — what recipients see as the sender name, e.g. your company name.
Save, then use the Send test email button on the same screen — it sends a real message to your own account through whatever is currently configured, so you'll know immediately if the credentials are wrong rather than finding out days later from an unrelated failed notification.
If the test email itself lands in spam even after connecting SMTP correctly, the remaining fix is on your domain's DNS: add or verify SPF and DKIM records authorizing your mail provider to send on your domain's behalf. Your provider's own documentation (Google Workspace, Microsoft 365, or your transactional provider) gives the exact DNS records to add — this is a one-time setup done with whoever manages your domain's DNS, not something configured inside the CRM.
What this affects
Every email the CRM sends goes through whatever's configured here — payment receipts, renewal reminders, password reset codes, and any notification email features you use. There's no separate configuration per email type; one correctly connected SMTP account covers all of it.