Outlook throttled all our mail with 451 4.7.650, and nothing on our end changed
Senders on healthy dedicated IPs report waves of soft deferrals reading '451 4.7.650 ... temporarily rate limited due to IP reputation' at Outlook, Hotmail, and Live, even with 99 percent SendGrid reputation and clean SNDS. Mail is not rejected, it just retries for up to 72 hours, and Microsoft's first automated reply is usually 'nothing detected,' which stalls people.
The fix
Confirm the IP is green in Microsoft SNDS and rDNS resolves, then treat this as a Microsoft-side throttle, not a SendGrid fix. Open a ticket at olcsupport.office.com and reply to the first automated 'nothing detected' response to request escalation; Microsoft then resets the throttling limit against your IP to match your reputation and delivery usually clears within hours. On an established IP that is green in SNDS, do not slow to a crawl or restart warmup. The opposite applies only if these deferrals hit a genuinely new IP mid-warmup or one not green in SNDS: there, back off volume and pace the ramp.
SendGrid quietly put our new account 'under review' and our signup emails stopped going out
Every new SendGrid account enters a vetting hold before it can send, and an established account can be flipped to 'warned' or 'suspended' on a deliverability drop or spam complaints. While suspended, mail requests queue for up to 72 hours and then silently expire, so senders assume a spam-filter problem when the mail never left SendGrid at all.
The fix
Check the admin-email inbox for the SendGrid notification (vetting request, 'at risk for suspension' warning, or suspension notice) and reply directly to it, since it routes to the account-review and compliance team; general support cannot reactivate a flagged account. For a new account, answer the sending-purpose questions promptly to clear the hold, which normally resolves in 24 to 72 hours. Note the states differ: a 'warned' account can still send while you respond, but a suspended account has mail queued for up to 72 hours then dropped. To avoid the trigger, keep bounce and spam-complaint rates low, since SendGrid flags accounts when the delivered-over-processed ratio falls or complaints rise.
Our password resets started landing in spam right after we blasted a marketing campaign
By default SendGrid sends transactional and marketing mail over the same identity and IP reputation, and marketing mail drags reputation down through lower engagement and more complaints. When a promo campaign spikes complaints, the hit follows your OTPs, receipts, and password resets into the spam folder.
The fix
Separate the streams at the level ISPs judge: the sending domain. Sign transactional and marketing mail from different subdomains (for example mail.yourbrand.com for marketing, txn.yourbrand.com for password resets and receipts), each domain-authenticated under Settings > Sender Authentication, so complaints against the marketing subdomain do not follow a separately DKIM-signed transactional one. Changing only the visible From domain is not enough; the mail must be DKIM-signed by the separate subdomain. Also create a subuser per stream for independent stats and reputation. On Pro or Premier, put each subuser on its own dedicated IP or pool once you send at volume (roughly 250,000+ messages a month); Essentials cannot split IP reputation or use subusers, so there the subdomain separation is the fix that matters.
Our SendGrid open and click rates look amazing, and subscribers keep vanishing off the list
With open and click tracking on, corporate security gateways fetch every tracked link (through ct.sendgrid.net) in a sandbox before the recipient sees the email, including the unsubscribe link. That inflates opens and clicks, and a GET on the tracked unsubscribe link can silently unsubscribe valid recipients you never actually lost.
The fix
Do not trust raw open and click counts for deliverability decisions; SendGrid confirms it cannot distinguish a bot click from a human one and records all of it, so corroborate with replies, conversions, or seed-list placement. Make the mailbox-provider one-click control the primary unsubscribe path: enable Subscription Tracking so SendGrid emits the List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers (RFC 8058), where the unsubscribe happens on a POST that scanners do not send. If you keep an in-body link, ensure a GET only shows a confirmation page and only a POST unsubscribes, or use Group Unsubscribe. Filter non-human activity with the Event Webhook, and watch for clusters of clicks or unsubscribes landing within seconds of a send from the same corporate domain.
SendGrid mangles our List-Unsubscribe header, so one-click unsubscribe breaks in Gmail and complaints climb
Senders report that once the List-Unsubscribe header value exceeds 77 bytes, SendGrid's SMTP relay MIME-encodes it, which Gmail and Outlook cannot parse, so the one-click unsubscribe control disappears. Annoyed recipients hit report spam instead of unsubscribing, which lifts complaint rates and pushes placement toward spam. It hides because Gmail's Show original view decodes the header, so it looks fine on casual inspection.
The fix
Keep the List-Unsubscribe header value at or under 77 bytes so SendGrid relays it unchanged: use a short unsubscribe URL on a bare domain path rather than a long query string, and if you are near the limit send a single https or mailto entry instead of both. Confirm the raw header on a live send by inspecting the message source at the receiving mailbox, not Gmail's decoded Show original, and verify it is still plain ASCII. Also send the List-Unsubscribe-Post: List-Unsubscribe=One-Click header so Gmail and Yahoo honor one-click unsubscribe, since a broken header counts against the 2024 bulk-sender requirements.
