Why Are SendGrid Emails Going to Spam?

SendGrid emails usually go to spam for one of a few reasons: domain authentication was never finished, so mail goes out signed for sendgrid.net instead of your domain; you're on a shared IP pool and inherit some of other senders' reputation; or your own sending (bad addresses, complaints, sudden volume) has damaged your domain or IP reputation. SendGrid is a delivery pipe. It doesn't decide where your mail lands. Gmail, Microsoft and Yahoo do, based on what they see from you.

How SendGrid sending works

SendGrid (Twilio SendGrid) is used for two very different jobs: transactional mail from an application (password resets, receipts, alerts) and marketing campaigns. Both go through the same basic setup.

Domain authentication is the setup that matters most. You add DNS records, usually CNAMEs, and SendGrid signs your mail with DKIM for your domain and uses a subdomain of yours as the return-path (the envelope sender, where bounces go). With automated security on (the default), SendGrid manages the SPF and DKIM records behind those CNAMEs for you. Without domain authentication, Gmail shows a "via sendgrid.net" tag next to your name, and your mail can't pass DMARC aligned to your own domain.

Link branding is a separate step. It rewrites tracked links to a subdomain of yours instead of a SendGrid domain, so your links carry your reputation rather than a shared one.

IPs. SendGrid's docs say Trial and Essentials accounts send from groups of shared IP addresses, and those IPs can change. Another sender's problems on the same pool can affect you. Pro Email API and Advanced Marketing Campaigns plans include one dedicated IP, with more available to buy.

Common causes, most likely first

1. Domain authentication missing or incomplete. Someone added the CNAMEs to the wrong DNS zone, or authenticated example.com but sends from mail.example.com. SendGrid's docs note that subdomains don't inherit authentication from the parent domain. Gmail and Yahoo require SPF or DKIM from every sender, and aligned DMARC from bulk senders. If DMARC fails under p=reject, you'll see 550 5.7.26 bounces rather than spam placement.
2. Shared IP reputation. On a shared pool, a listing or a bad week from another customer can affect your delivery. If your bounces name a blocklist and an IP you don't control, see what to do when your ESP's shared IP is listed.
3. Bad addresses. Old lists, imported data, or a sign-up form being hit by bots that submit other people's addresses. These produce hard bounces (550 5.1.1) and spam traps, and receivers read both as a sign you don't manage your list.
4. Spam complaints. Marketing mail people didn't expect, or transactional mail sent so often that people report it. Gmail's limit is 0.3%, and trouble starts well before that. The spam rate threshold guide explains how Google measures it.
5. Marketing and transactional mixed together. Password resets and promotional blasts on the same domain and IP. When the marketing stream gets filtered, the password resets go with it.
6. A new dedicated IP sent too hard, too fast. A cold IP has no reputation. Sending full volume on day one looks like a spammer spinning up new infrastructure.

How to diagnose it

1. Read the bounces and blocks. In SendGrid, look at the Bounces and Blocks suppression lists and the activity feed. A block that names a blocklist or a receiver's policy points to IP or content reputation. Bounces that say the address doesn't exist point to list quality. SendGrid's own table describes blocks as relating to "the sender's IP address or the message content."
2. Check authentication on a real message. Send to a Gmail address, choose "Show original," and check that SPF, DKIM and DMARC say PASS. Paste the headers into the header analyzer. DKIM should be signed with d=example.com and the return-path should be your subdomain, not sendgrid.net.
3. Check your DNS. Run your domain through the email checker. If you also send from other services, count SPF lookups with the SPF analyzer, since SendGrid's include adds to the total. See the SPF lookup limit guide if you're close to 10.
4. Find out whether your IP is shared or dedicated. Check Settings, IP Addresses. If shared, look up the sending IP from a bounce against the major blocklists.
5. Look at Google Postmaster Tools. Verify your sending domain in Google Postmaster Tools for Gmail's view of your spam rate and authentication.
6. Check SendGrid's reputation score. SendGrid shows an account reputation score based on bounces, spam reports and other basic signals. It's not your inbox placement, but a falling score is an early warning.

How to fix it

1. Finish domain authentication. Authenticate the exact domain or subdomain you send from. Leave automated security on unless your DNS host can't handle it.
2. Add link branding. Point tracked links at your own subdomain.
3. Separate your streams. Use different subdomains (for example notify.example.com for transactional and news.example.com for marketing), and on paid plans, separate IPs or IP pools. A marketing problem then stays a marketing problem.
4. Publish DMARC. Start at p=none with a reporting address if you don't have a record yet. The DMARC generator will build one, and the authentication overview explains how the pieces fit.
5. Stop sending to bad addresses. SendGrid suppresses addresses that hard bounce, are invalid or report spam, and you should leave those suppressions in place. Don't bulk-remove the bounce list to "retry" old addresses.
6. Protect your sign-up forms. If you send a welcome or confirmation email to any address typed into a form, add bot protection and rate limits, and use confirmed opt-in for marketing. Otherwise attackers can use your form to send your mail to people who never asked for it.
7. Trim marketing to engaged recipients. Send campaigns to people who clicked or bought recently, and run a re-engagement sequence for the rest before removing them.
8. Warm new dedicated IPs. Turn on SendGrid's automated IP warmup, which caps hourly volume on the new IP and sends overflow through your other warm IPs. Their docs say it needs at least one other warm IP and runs through day 41 of the schedule.

How to confirm it's fixed

• Test messages pass SPF, DKIM and DMARC with your domain, with no "via sendgrid.net."
• Blocks in SendGrid drop off, and any blocklist named in them clears.
• Your Gmail spam rate in Postmaster Tools stays well below 0.1%.
• Engagement (clicks, conversions, password-reset completions) recovers at the provider that was filtering you.

How to keep it from coming back

• Keep marketing and transactional mail on separate subdomains and, where you can, separate IPs.
• Monitor bounces, blocks and spam reports per send, and alert on spikes.
• Watch sign-up sources for bot abuse.
• Re-check authentication whenever someone changes DNS or adds a new sending subdomain.

Other platforms have their own versions of the same problems: see Amazon SES, Mailchimp and Klaviyo.

When to get help

If you've authenticated everything, separated your streams, and mail is still going to spam, or you can't tell whether the problem is your data or the shared pool, it's worth having someone read your logs and headers with you. Get in touch.

FAQ

Why does Gmail show "via sendgrid.net" on my emails?

Because your mail isn't signed with your own domain. Complete domain authentication in SendGrid for the exact domain in your From address and the tag goes away.

Should I get a dedicated IP on SendGrid?

Only if you send enough steady volume to keep it warm. SendGrid recommends at least two dedicated IPs at 250,000 messages a month. Smaller senders usually do better on a shared pool with solid domain authentication.

My SendGrid shared IP is on a blocklist. What can I do?

Check whether the listing is actually causing bounces before you panic. If it is, open a ticket with SendGrid, since only they can move you or fix the pool. The shared IP guide covers your options.

Can I just delete my bounce list and resend?

You can, but you shouldn't. Those addresses bounced for a reason, and sending to them again hurts your reputation. SendGrid also charges a credit for every attempt to send to a suppressed address.