"My emails are going to spam" is a symptom with a dozen possible causes, and guessing wastes days. The efficient approach is a fixed order of checks, from the cheap and objective (DNS, authentication, blocklists) to the slow and subjective (reputation, content, engagement). This checklist is written for the person who runs the domain, not for a marketer tuning subject lines.
First, a distinction. Bounced mail returns an error to you (see bounce codes explained). Spam-foldered mail is accepted by the receiving server and then filed in junk, which means authentication passed well enough to be accepted and something else lowered the score. Silence with no bounce and no inbox is usually the second case, or a quarantine you cannot see.
Step 1: Reproduce and read the headers
Do not rely on one recipient's report. Send a test to a few mailbox types (a Gmail address, a Microsoft address, one on a smaller host) and to the ईमेल डिलीवरेबिलिटी टेस्ट, which shows you the authentication results as a receiver sees them.
Open the full headers of a message that landed in spam and find Authentication-Results:.
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=mail2026;
spf=softfail (google.com: domain of transitioning bounce@example.com does not designate 198.51.100.7 as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com
Three results to read: SPF, DKIM, DMARC. Anything other than pass on all three is your first priority. Also note the X-Spam-* headers some receivers add. They sometimes include a score and rule names.
Step 2: Authentication
- SPF. Is there exactly one
v=spf1record, and does it include the system actually sending this mail? Check with the SPF रिकॉर्ड चेकर. A mail server sending from an IP not listed gives softfail or fail. A record with more than ten lookups gives permerror: see fixing too many lookups. - DKIM. Is the message signed by your domain, with a valid 2048-bit key? See DKIM setup and troubleshooting.
- DMARC. Does a record exist at
_dmarc.example.com, and does SPF or DKIM align with the From domain? Confirm with the Email DNS Checker.
Since 2024 the largest mailbox providers have required authentication for bulk senders and treat unauthenticated mail harshly even for small volumes. If any one of the three is missing, fix it before anything else.
Step 3: Check blocklists
Look up the sending IP and, separately, the domain in the Blacklist Checker. Then judge what you find.
- A listing on a major list used by receivers (Spamhaus lists are the most commonly referenced) matters. Obscure lists that few receivers consult usually do not.
- A shared IP (a hosting provider, cloud VM, or ESP pool) can be listed because of someone else's behavior. You may need your provider to act.
- Each list has its own delisting process. Our blacklist removal guide walks through it. Delisting without fixing the cause gets you relisted.
If you do not know your sending IP, take it from the Received: headers of a test message and look it up with the IP लुकअप.
Step 4: Server identity (rDNS, HELO, TLS)
Receivers sanity-check the connecting server:
- The sending IP should have a PTR record whose hostname resolves back to the same IP. Missing or generic PTR names (
ec2-203-0-113-25.compute.example) count against you, and Gmail will reject mail from IPs with no PTR. See reverse DNS for email. - The
HELO/EHLOname your server announces should be a real hostname that resolves, ideally matching the PTR. - Modern receivers expect TLS on delivery. Check your MTA offers STARTTLS with a valid certificate. For a policy layer on top, see MTA-STS and TLS-RPT.
- Is the sending IP in a residential or dynamic address range? Many receivers distrust it regardless of anything else. Send through a proper SMTP relay instead.
Step 5: Reputation and sending patterns
This is the area with no DNS fix. Mailbox providers score domains and IPs on past behavior:
- Complaints. People clicking "Report spam" is the strongest negative signal. Gmail's published guidance for bulk senders keeps the complaint rate low and recommends watching it in Google Postmaster Tools.
- Bounces to dead addresses. A list full of non-existent mailboxes signals a stale or purchased list.
- Spam traps hidden in old or scraped lists.
- Sudden volume spikes from a new domain or IP. See warming up a new domain.
- Low engagement. Providers observe whether recipients open, reply, move to the inbox, or delete unread. Mail nobody wants trains the filter against you.
What to do: stop mailing unengaged contacts, remove hard bounces immediately, use confirmed opt-in where you can, and make unsubscribing easy. Bulk senders are expected to support one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers. Register with Google Postmaster Tools and Microsoft's sender programs to see domain-level data.
Step 6: Content and formatting
Content matters less than people think compared with authentication and reputation, but it still contributes:
- An image-only message, or very little text beside a large image
- URL shorteners and links whose visible text differs from the destination
- Links to domains that are themselves blocklisted (check them too)
- Attachments of executable or archive types
- A From name that impersonates another brand, or a mismatch between From domain and reply-to
- Missing plain-text alternative on HTML mail
- Broken HTML, huge messages, or spammy phrasing in the subject line
Send a plain, short, clean message from the same address. If that reaches the inbox and your campaign does not, the problem is content or list quality. If both land in spam, the problem is infrastructure or reputation.
Step 7: Mix and separate your streams
If one domain sends invoices, newsletters, cold outreach and password resets, a complaint-heavy stream drags down the rest. Use separate subdomains (for example news.example.com for marketing, mail.example.com for transactional) so each builds its own reputation. For the transactional side, use the transactional email DNS checklist.
Quick decision table
| What you see | Most likely cause | Go to |
|---|---|---|
spf=fail/softfail, dmarc=fail | Sender missing from SPF | Step 2 |
dkim=none | Signing not enabled | Step 2 |
| All pass, still spam, only at one provider | Reputation or content at that provider | Steps 5 and 6 |
| Spam everywhere, new domain | No history, volume too fast | Step 5 |
| Sudden drop after months of fine delivery | Blocklisting, compromised account, list change | Steps 3 and 5 |
| Bounces mentioning PTR or IP reputation | Server identity or listing | Steps 3 and 4 |
Also check for compromise. A hacked mailbox or a vulnerable web form sending spam under your domain will tank reputation fast. DMARC aggregate reports and your mail server logs reveal unfamiliar senders.
अगले कदम
- Run a full check with the ईमेल डिलीवरेबिलिटी टेस्ट.
- Look up your sending IP in the Blacklist Checker.
- Verify records with the Email DNS Checker and the MX लुकअप.
- Build a correct SPF and DMARC pair with the SPF & DMARC Generator.
- Read about bounces in email bounce codes explained.
सामान्य प्रश्न
Why does my email go to spam only at Gmail or Outlook?
Each provider keeps its own reputation data for your domain and IP. Passing at one and failing at another points to reputation or content, not DNS. Use that provider's postmaster tools to see your standing.
Can I fix spam placement just by adding SPF?
Rarely on its own. You need SPF, DKIM and DMARC all passing and aligned, plus a clean IP and good list hygiene. Authentication is the entry ticket, not a guarantee.
How long does it take to recover a damaged reputation?
It varies and nobody can promise a number. Reputation improves only after you stop the bad behavior and send consistent, wanted mail over time.
Should I ask recipients to mark my mail as "not spam"?
It helps a little for individual recipients but does not fix the underlying cause. Fix authentication and list quality first.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.