You send the email through SendGrid, the API returns 202, and the dashboard says "delivered." But the recipient never sees it. It is in spam, or it is not there at all. This is the most common complaint from teams using SendGrid, and it is almost never SendGrid's fault. SendGrid is doing exactly what you told it to do. The problem is upstream: the sending domain, the authentication records, the IP reputation, or the list you are sending to. Here are the five reasons SendGrid deliverability drops, in order of likelihood, and the exact fix for each one.
This is the number one cause. When you send through SendGrid, the mail leaves from a SendGrid IP, not your own server. The receiving mail server checks your SPF record to see if that IP is allowed to send as your domain. If your SPF record does not include include:sendgrid.net, the receiving server sees an unauthorized sender and flags the mail as suspicious.
The fix: add include:sendgrid.net to your SPF record. If you are also sending from your own server, add both: v=spf1 include:sendgrid.net ip4:YOUR_SERVER_IP -all. Then verify the record is actually live: run the SPF checker on your domain and confirm the include resolves.
DKIM is the second layer. SendGrid signs your mail with a DKIM key, and the receiving server verifies that signature against the DNS record for your domain. If the DKIM record is missing, expired, or the selector does not match, the signature fails and the mail is flagged.
The fix: go to SendGrid's settings, copy the DKIM host record and value, and add it to your DNS. Then verify it: run the DKIM checker on your domain and confirm the signature verifies. If you recently changed your DKIM key in SendGrid, the old selector may still be in your DNS and the new one may not be. Check both.
DMARC is the policy layer. It tells the receiving server what to do when SPF or DKIM fails. If you do not have a DMARC record, the receiving server has no policy to follow and may treat the mail as suspicious. If your DMARC record is misconfigured (wrong selector, wrong policy, missing reporting address), it can cause the same problem.
The fix: add a DMARC record that references your SPF and DKIM selectors. Start with p=none and a reporting address, then tighten it to p=quarantine or p=reject as your domain proves itself. Run the DMARC checker on your domain and confirm the record is live and correctly configured.
SendGrid uses shared IPs by default. If another sender on that IP has been flagged for spam, your mail can be affected too. Even on a dedicated IP, a blocklist hit will not announce itself: the mail is still "delivered" by SendGrid, but the receiving server rejects it at the SMTP level.
The fix: check your sending IP against the major blocklists. Run the IP blocklist checker on your sending IP. If it is listed, request delisting from the blocklist operator. If you are on a shared IP and your deliverability is inconsistent, consider moving to a dedicated IP in SendGrid.
The last two causes are on your side, not SendGrid's. A list full of hard bounces and cold recipients poisons your reputation. A sudden 10x spike in send volume trips spam filters. Both of these show up as a sudden drop in deliverability with no obvious cause in your infrastructure.
The fix: prune your list. Remove hard bounces, honor unsubscribes the same day, and keep your complaint rate under 0.1%. Ramp your volume in steps over days instead of all at once. If you are sending cold email, warm up the domain before you scale.
Do not guess. Run the checks in order. Start with the authentication layer (SPF, DKIM, DMARC), because it is the most common and the cheapest to verify. Then check the IP reputation. Then look at the list and the volume. The free audit runs the DNS and reputation checks in one pass, scores the domain, and points at the exact record to fix first. That is the fastest way to stop guessing and start fixing.
Want this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →