The 9 Most Common Deliverability Issues, Solved
Email deliverability issues almost always trace back to one of nine causes: broken SPF, unsigned or misaligned DKIM, a missing DMARC record, a stale list, spam traps, a high complaint rate, a volume spike on a cold domain, content and link reputation problems, or a blocklisting. Each has a distinct symptom and a specific fix.
Diagnose before you fix
The instinct when mail stops landing is to change everything at once — rewrite the copy, switch providers, buy a dedicated IP. That destroys your ability to learn anything. Start by matching the symptom to the likely cause.
| # | Symptom you observe | Most likely cause |
|---|---|---|
| 1 | Mail fails at one provider, fine elsewhere; headers show spf=fail | Broken or incomplete SPF |
| 2 | Headers show dkim=none or dkim=fail | Unsigned or misaligned DKIM |
| 3 | Gradual decline at large mailbox providers, no obvious trigger | No DMARC policy or failing alignment |
| 4 | Hard bounce rate above roughly 2% | Stale, purchased, or unverified list |
| 5 | Sudden hard block after mailing an old segment | Spam traps and recycled addresses |
| 6 | Placement drops across the board over several sends | Complaint rate above provider tolerance |
| 7 | First large send after a quiet period gets deferred | Volume spike on a cold domain |
| 8 | Consistent spam-folder placement despite clean auth | Content and link reputation problems |
| 9 | Rejection message names a specific list or DNSBL | Blocklisting or shared-pool neighbor damage |
Pull the full headers of a message that landed badly and read the Authentication-Results line first. It answers issues one through three in about ten seconds, and it is the only piece of evidence that is not a guess. If you would rather have it checked for you, run our free deliverability audit against your sending domain.
Issues 1-3: the authentication triad
Broken SPF. The classic failure is the ten-lookup limit. Every include: in your SPF record costs a DNS lookup, and once you exceed ten the whole record returns a permanent error — which most receivers treat as a fail. If you have accumulated includes for a CRM, a help desk, a billing tool, and a marketing platform, you are probably already over. Fix it by flattening rarely-changing includes into IP ranges, removing tools you no longer use, and keeping exactly one SPF TXT record on the domain. Two SPF records is an automatic fail.
Unsigned or misaligned DKIM. DKIM proves the message was not altered and that your domain authorized it. Two things go wrong: the selector's public key was never published (so signing silently does nothing), or the signing domain does not match the visible From domain, which breaks alignment even though the signature itself is valid. Publish the selector your provider gives you, then confirm with a test send that the header shows your own domain, not the provider's.
Missing DMARC. DMARC ties SPF and DKIM to the From address a human actually sees, and large mailbox providers increasingly expect bulk senders to have it. Start at p=none with an rua reporting address, read the aggregate reports for two to four weeks to find every legitimate system sending as you, then move to p=quarantine and eventually p=reject.
All three should be handled for you. IGSendMail configures SPF, DKIM, and DMARC automatically when you add a sending domain, which removes the most common category of failure before it happens.
Issues 4-5: what is actually on your list
Stale addresses. Business email churns constantly as people change jobs. A list you have not mailed in a year will contain a meaningful share of dead addresses, and a hard bounce rate above roughly 2% is enough to trigger throttling at major providers. Verify before any send to a segment you have not touched in six months, and remove hard bounces permanently rather than retrying them.
Spam traps. These are addresses that exist only to catch senders with poor hygiene. Pristine traps were never valid and only appear on scraped or purchased lists. Recycled traps are former real addresses that a provider reactivated as traps after a long dormancy — which is why mailing a very old segment can cause an immediate hard block with no warning.
You cannot detect traps directly; you avoid them structurally:
- Never buy, rent, or scrape a list. There is no safe version of this.
- Use confirmed opt-in for any source you do not fully control.
- Suppress anyone with no open or click in 12 months rather than trying one more re-engagement blast.
- Verify imported lists before the first send, and re-verify anything older than six months.
- Add a honeypot field to signup forms so bots that fill every field get rejected.
Issue 6: complaints
A spam complaint is the strongest negative signal a mailbox provider receives, and tolerance is low — the working threshold most senders aim to stay under is roughly 0.1%, or about one complaint per thousand delivered messages. Two or three sends above that is enough to move you from inbox to spam folder across an entire provider.
Complaints are usually an expectation problem, not a content problem. People mark mail as spam when they do not remember subscribing, when the frequency changed without notice, or when unsubscribing looks harder than clicking the spam button.
- Put a plainly visible unsubscribe link in the body, not only in a grey 9px footer.
- Support one-click unsubscribe headers so mailbox-provider unsubscribe buttons work without a landing page.
- Send a welcome email immediately after signup so the first campaign is not the first contact.
- Keep the From name consistent across every send so you are recognizable in a crowded inbox.
- Offer a frequency downgrade — "get this monthly instead" — beside the unsubscribe option.
- Process complaint feedback loops automatically and suppress permanently.
Issue 7: volume spikes on a cold domain
Reputation is built on consistency. A domain that sends 500 messages a week and then suddenly sends 80,000 looks, from a filter's perspective, exactly like a compromised account. The result is deferrals, then outright rejections.
Warm up deliberately. A workable ramp for a new sending domain looks like this:
| Days | Daily volume | Who to send to |
|---|---|---|
| 1-3 | 50-200 | Your most recently active, most engaged subscribers |
| 4-7 | 500-1,000 | Opened or clicked in the last 30 days |
| 8-14 | 2,000-5,000 | Active in the last 90 days |
| 15-21 | 10,000-25,000 | Active in the last 180 days |
| 22-30 | Full volume | Full engaged list |
Hold at the current step, do not advance, if bounce rate exceeds 2% or complaints exceed 0.1%. The ramp is a guide, not a schedule you push through.
Issue 8: content and link reputation
Once authentication is clean and the list is healthy, remaining spam-folder placement usually comes from signals inside the message:
- URL shorteners. Public shorteners are heavily abused and carry borrowed reputation. Use your own tracking domain instead.
- Image-only emails. A single large image with no meaningful text is a classic evasion pattern. Keep a real text-to-image balance and always include a plain-text alternative part.
- Mismatched From name. If the From name, the domain, and the content feel like three different businesses, filters and humans both react badly.
- Fresh or unrelated domains in links. Newly registered domains and links to unrelated third parties both raise flags.
- Broken HTML. Unclosed tags, hidden text, and white-on-white text read as deliberate obfuscation.
- Attachments in bulk mail. Link to files instead. Attachments in marketing mail are unusual enough to be suspicious.
Issue 9: blocklists and shared-pool neighbors
If a rejection message names a specific list, you have been blocklisted. Read the actual SMTP rejection text — it almost always includes a URL explaining the listing and the delisting process.
Fix the underlying cause first. Requesting delisting while the behavior that caused it continues gets you relisted faster and with less patience from the operator. Once fixed, submit the delisting request honestly, describing what happened and what changed.
Shared-pool damage from other senders is rarer than people assume with a well-managed provider, because pools are segmented by sender reputation. If you genuinely suspect it, compare your placement against a seed test and ask your provider directly which pool you are in. A deeper walkthrough of pool management and reputation monitoring lives in our guide to email deliverability.
A 30-day recovery plan
- Days 1-2. Pull headers, confirm SPF, DKIM, and DMARC all pass with alignment. Fix anything failing before sending again.
- Days 3-5. Verify the list. Remove hard bounces, role addresses, and anyone inactive for 12 months.
- Days 6-10. Send only to subscribers active in the last 30 days. Small volume, high engagement, consistent cadence.
- Days 11-20. Expand to 90-day actives. Watch bounce and complaint rates daily and hold if either rises.
- Days 21-30. Return to full engaged volume. Set standing alerts on bounce rate, complaint rate, and deferral rate so the next problem surfaces in hours, not weeks.
Frequently asked questions
Why are my emails going to spam all of a sudden?
Sudden changes almost always follow a specific trigger: a new sending domain, a list import, a volume spike, or a DNS change that broke authentication. Check your message headers for SPF and DKIM results first, then look at what changed in the 48 hours before placement dropped.
What is a good bounce rate for email?
Aim to keep hard bounces under roughly 2% of delivered mail, and ideally under 1%. Anything consistently above that suggests list hygiene problems and will eventually trigger throttling at major mailbox providers.
How long does it take to recover email deliverability?
With the underlying cause fixed and a disciplined re-warming schedule, most senders see meaningful recovery within two to four weeks. Reputation rebuilds through consistent, well-received sending, so there is no way to shortcut it.
Does buying a dedicated IP fix deliverability problems?
Usually not, and it often makes things worse. A dedicated IP has no reputation at all until you build one, which requires sustained high volume — below that, a well-managed shared pool typically performs better.
Do I need DMARC if I already have SPF and DKIM?
Yes. DMARC is what ties SPF and DKIM to the From address recipients actually see, and large mailbox providers increasingly expect bulk senders to publish a policy. Start at p=none with reporting enabled, then tighten once you know every legitimate sender.
Tired of guessing why your mail lands in spam? Launch with IGSendMail — automatic SPF, DKIM and DMARC, 99% inbox deliverability, and free 24-hour migration from your current platform.