SendGrid is a powerful platform. But out of the box, it won't protect you from yourself.
SendGrid handles the mechanics of sending email well. Authentication, IP management, event tracking, suppression lists — the tools are there. But having the tools and using them correctly are two different things. Most SendGrid deliverability problems aren't caused by SendGrid itself. They're caused by how the account is configured, how traffic is segmented, and what's missing from the setup that nobody thought to check.
We've audited SendGrid accounts ranging from a few thousand messages a month to networks pushing millions per week across hundreds of subusers. The same problems come up repeatedly. Here's what they are and how to fix them.
Domain Authentication Mistakes
SendGrid requires you to authenticate your sending domains with DKIM and SPF records. Most people do this once during initial setup and then forget about it. The problems start when the environment changes.
When companies migrate website providers, switch IDX platforms, or change CRMs, someone often forgets to re-authenticate the SendGrid domain records on the new infrastructure. The result: DKIM starts failing silently. Messages still get delivered — for a while — because your existing reputation carries you. But failing authentication is weight on the wrong side of the scale, and it accumulates.
The other common authentication mistake happens with subusers. A domain authenticated on the parent account is not automatically available to subusers. You can assign a domain from the parent account to a subuser, but if you need multiple domains on a single subuser, those domains must be authenticated directly on the subuser itself, not just assigned from the parent. This distinction catches people regularly, and the result is DMARC alignment failures that generate blocks at scale.
If you have more than a handful of sending domains — especially if you're a platform sending on behalf of clients — a comprehensive authentication audit across every domain and every subuser is one of the highest-ROI activities you can do. We routinely find domains with duplicate DMARC records, typos in DMARC records, or DMARC missing entirely. Each one represents messages being rejected that didn't need to be.
Suppression List Mismanagement
SendGrid maintains suppression lists for bounced addresses, spam reports, and unsubscribes. These lists exist to prevent you from repeatedly sending to addresses that have already signaled a problem. The system works — until you migrate accounts.
One of the most common migration failures we see is standing up a new SendGrid account (or new subuser) without carrying over the suppression lists from the old one. The immediate symptom is a spike in bounce rates as you re-send to every address that already bounced on the old account. The deeper problem is that you're now sending to addresses that have been converted into spam traps since the original bounce, which damages your reputation in ways that don't show up as bounces at all.
The related issue is bounce-drop events. These occur when you attempt to send to an address that's already on your SendGrid suppression list — SendGrid drops the message before it ever leaves. These drops don't hurt your deliverability, but they do cost credits. We've seen accounts generating 10,000 to 35,000 bounce-drop events per day. Properly syncing your application's mailing lists with SendGrid's suppression data would save millions of credits per year at that scale.
The fix is straightforward but requires discipline: before migrating to any new SendGrid account or subuser, export and import all suppression lists. And build a process that regularly syncs your application database with SendGrid's suppression endpoints so you're not paying to send messages that will never leave the platform.
IP Reputation Problems
SendGrid offers both shared and dedicated IP addresses. Most deliverability problems we see with IP reputation stem from one of three scenarios.
Shared IPs on the Essentials plan. SendGrid's Essentials plan doesn't include dedicated IPs, which means your reputation is pooled with other senders on the same infrastructure. If you're sending enough volume to justify dedicated IPs (generally above 50,000 messages per month), upgrading to the Pro plan and getting your own IPs is almost always worth it. Dedicated IPs give you direct control over your reputation — for better and for worse.
Unwarmed IPs. When you add a new dedicated IP to your SendGrid account, it has no sending history. Mailbox providers don't trust IP addresses they've never seen before. SendGrid offers automated IP warmup that gradually ramps volume over approximately 40 days. If you skip warmup or send too much volume too quickly, you'll see immediate blocking and spam folder placement — particularly at Microsoft, which relies heavily on IP reputation for filtering decisions.
Uneven volume distribution across IPs. If you have multiple IPs on your account, SendGrid will round-robin traffic between them. But if your sending patterns are erratic — high volume some days, near-zero on others — the IPs that go quiet lose their established reputation. We've seen accounts with six IPs where two handle 70% of the traffic and the other four generate unpredictable results. Stabilize volume across your IPs, or consolidate to fewer IPs that maintain consistent traffic.
A quick diagnostic: check your IPs against Google Postmaster Tools, Sender Score, and Talos Intelligence. These three sources don't always agree. An IP can score a 95 on Sender Score while showing "Low" on Postmaster Tools. You need the full picture.
Subuser Architecture Done Wrong
SendGrid subusers are one of the platform's most powerful features for organizations that send email on behalf of multiple clients or brands. Each subuser gets its own statistics, suppression lists, and API key. But the architectural decisions you make up front have long-term consequences.
No subusers at all. Some organizations route all traffic through a single parent account, relying on categories or custom parameters to differentiate clients. This works for reporting, but it means all suppression lists are shared. If Client A's recipient unsubscribes, that suppression applies to Client B too — or worse, it doesn't, because your application manages its own suppression logic and doesn't check SendGrid's lists at all.
Subuser-per-client at scale. The opposite extreme — creating a subuser for every client — is the cleanest architecture from a segmentation standpoint. Independent statistics, independent suppressions, and clean isolation. But it requires API automation for creation, and you'll eventually hit SendGrid's default subuser limit (which can be increased by contacting support). If you're adding 10+ clients per month, plan for this from the start.
Suppression list confusion between parent and subusers. This is a subtle one. When an application or a CRM platform is integrated with SendGrid via API, it may be making API calls to add addresses to your suppression list when users unsubscribe. If you later merge accounts or restructure subusers, those suppression entries may not carry over. The result is re-mailing people who've already unsubscribed — which generates spam complaints and erodes trust.
The right architecture depends on your scale and how your application integrates with SendGrid. But the general rule is: if you're a platform sending on behalf of distinct clients, subuser-per-client with API automation is the cleanest path, combined with categories for campaign-level tracking within each subuser.
IP Pooling That Doesn't Actually Pool
IP pools let you segment traffic across different IP addresses based on risk profile. The theory is sound: protect your high-trust transactional mail from the reputation impact of riskier promotional sends. In practice, we frequently find IP pool configurations that provide no actual benefit.
The most common version of this problem: an account with three IP pools where 95% of all traffic flows through a single pool. At that point, the pooling is just adding complexity without providing any protection. One pool handles virtually everything, and the "segmentation" exists only in the SendGrid configuration, not in practice.
Effective IP pooling requires thinking about what you're actually separating and why. Different pools should carry meaningfully different risk profiles. If you're a platform, that might mean one pool for clients with strong engagement metrics and another for new or unproven senders. For a single organization, it might mean separating transactional confirmations from marketing blasts. But the volume in each pool needs to be sufficient to maintain a stable reputation on its own.
If your current IP pool configuration doesn't have clear, defensible logic behind it, simplify. Fewer, more consistent pools are better than many pools where volume is erratic.
Missing One-Click Unsubscribe Headers
Gmail, Yahoo, and Microsoft now require bulk senders to implement one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers. This isn't optional — it's a compliance requirement, and Google Postmaster Tools will flag you as non-compliant if it's missing.
SendGrid does not add these headers automatically for all account types. If you're sending via the API and building your own messages, you need to include them explicitly:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/example>
When a recipient clicks unsubscribe through the mailbox provider's native button, an HTTP POST is sent to the URL you specify. Your application needs to handle that POST and actually suppress the address.
The absence of these headers doesn't just put you out of compliance — it directly drives up spam complaints. Without a frictionless unsubscribe path, recipients who want to stop receiving your email will hit the spam button instead. And every spam complaint at Gmail counts against your 0.3% threshold.
We see this missing in a surprising number of SendGrid implementations, including accounts sending millions of messages per month. It's a straightforward engineering task that pays immediate dividends in complaint rates and reputation protection.
Link Branding Not Enabled
When you send email through SendGrid with click tracking enabled, SendGrid rewrites your links to route through their tracking servers. By default, those rewritten links use the domain ct.sendgrid.net — a shared domain used by tens of thousands of SendGrid customers.
This is a deliverability risk. If any other sender on that shared domain damages its reputation, your messages are impacted too. Enabling link branding replaces ct.sendgrid.net with your own domain (or your client's domain), which isolates your link reputation and looks more trustworthy to both spam filters and recipients.
Enabling link branding requires adding a couple of DNS records. If you're a platform with hundreds of client domains, you can use a single default branded link domain across all subusers — it's not perfect, but it's dramatically better than the shared SendGrid default.
On a related note: if click tracking isn't providing meaningful data for your use case, consider disabling it entirely. Click-tracked links are rewritten with tracking parameters that can be a negative signal for spam filters, particularly when the goal is to make your email look as "human" as possible. Open tracking and delivery events may be sufficient for your reporting needs.
Reverse DNS (rDNS) Not Configured
When you add a dedicated IP to your SendGrid account, it comes with a default reverse DNS record that resolves to something like wfbthpfs.outbound-mail.sendgrid.net. This generic rDNS tells receiving mail servers nothing about who you are.
Configuring branded rDNS — so your IP resolves to something like o1.mail.example.com — is a simple process through SendGrid's Sender Authentication settings and requires adding a DNS record. It's a well-established best practice that adds a layer of trust with mailbox providers, and there's no good reason not to do it for every dedicated IP on your account.
We routinely find accounts where the primary IP has branded rDNS configured but a secondary IP (often in warmup) still uses SendGrid's default. Every IP on your account should have branded rDNS.
Not Using the SendGrid Engagement Quality (SEQ) Score
SendGrid's SEQ score is one of the most underutilized tools on the platform. It's only available via API, which means most people never look at it. But for organizations with multiple subusers, it's the fastest way to monitor deliverability health across your entire sender base.
The SEQ API returns a score for each subuser for a given date, going back 90 days. Pull and store these scores daily. When a subuser's score starts declining, you have an early warning signal before the problem shows up in your open rates or reputation dashboards. Combined with Google Postmaster Tools and your own event-level statistics, it makes it nearly impossible for a significant deliverability issue to go undetected.
If you're a platform with 50+ subusers, the SEQ score API should be part of your core monitoring infrastructure. It's free, it's already there, and it tells you exactly which senders need attention before they damage your network's reputation.
SendGrid Account Migration Failures
Migrating between SendGrid accounts — whether it's merging two accounts, moving from Essentials to Pro, or restructuring subusers — is one of the highest-risk events for deliverability on the platform.
The common failure modes: suppression lists don't get migrated (covered above), domain authentication records don't get re-created on the new account, IP addresses change and existing whitelisting at recipient organizations breaks, and API keys get scattered across applications with no clear inventory of which key powers which integration.
Before any account migration, inventory everything: every authenticated domain, every IP address, every API key and which application uses it, every suppression list, and every webhook endpoint. Migrate methodically — one integration at a time — and keep the old account running in parallel for at least 30 days so you can catch any traffic that's still routing through it.
The cleanest approach we've found: merge into the account with the best-performing IP addresses and the most consistent sending history, then migrate the integrations from the other account one at a time. Watch open rates and bounce rates closely after each migration step.
The Common Thread
Most SendGrid deliverability problems share a root cause: the initial setup was done quickly, and nobody went back to verify that every component was configured correctly as the account scaled, new domains were added, new clients onboarded, or infrastructure changed.
SendGrid gives you the tools. But the tools need to be configured correctly, monitored regularly, and reconfigured as your sending environment evolves. A deliverability audit that specifically evaluates your SendGrid account architecture — not just your content and engagement metrics — is the fastest way to find and fix the issues that are silently eroding your inbox placement.
At SH Consulting, we audit SendGrid accounts and email infrastructure for platforms and organizations that depend on email reaching the inbox. If your open rates are declining, your IPs are getting blocked, or you just want to know if your SendGrid setup is optimized — book a call and we'll walk through it.
