Blog/Educational

Why your emails land in spam

It is almost never about the words you wrote. The real causes are missing DNS records, broken authentication, and sender reputation - all fixable.

Mohit Gaddam12 min read

TL;DR

Most emails land in spam because of missing or misconfigured DNS records (SPF, DKIM, DMARC) - not because of the words in the email. Fix authentication first, then worry about content. Or let SendMailAs handle it automatically.

The real reasons (it is not your content)

When people discover their emails are going to spam, they usually start editing the email body. Removing links, changing subject lines, avoiding words like "free" or "urgent." This almost never fixes the problem.

Modern spam filters - Gmail, Outlook, Yahoo - barely look at content anymore. They care about three things:

  1. Authentication - Can the sender prove they own the domain they claim to send from?
  2. Reputation - Has this domain or IP address sent spam before?
  3. Engagement - Do recipients open, read, and reply to emails from this sender?

Content is a distant fourth. Here is each cause in detail, with exactly how to fix it.

Missing or broken SPF record

The #1 cause of spam delivery

SPF (Sender Policy Framework) is a DNS record that declares which servers are allowed to send email for your domain. Without it, any server in the world can send email claiming to be from your domain - and receiving servers have no way to verify the claim.

When a receiving server gets an email from your domain and there is no SPF record, the result is SPF: NONE. This does not immediately mean spam, but it is a strong negative signal that gets combined with other factors.

Common SPF mistakes

No SPF record at all

Add a TXT record: v=spf1 include:_spf.google.com ~all (adjust includes for your email services)

Multiple SPF records on the same domain

Merge all include: statements into one record. Two TXT records starting with v=spf1 causes a PermError - all emails fail authentication

Too many DNS lookups (more than 10)

Each include: counts as one or more lookups. Remove services you no longer use. Check your count at mxtoolbox.com/spf.aspx

Using +all instead of ~all or -all

+all authorizes every server in the world to send as your domain. Use ~all (softfail) or -all (hardfail)

Correct SPF Record (example)
TypeTXT
Name@
Valuev=spf1 include:_spf.google.com include:sendmailas.com ~all

For a deeper explanation of SPF records, how they work, and how to build one correctly, read our SPF, DKIM, and DMARC guide.

Missing or misaligned DKIM

The cause of the "via" banner - and worse

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server checks this signature against a public key published in your DNS. If it matches, the email is verified as genuine and unmodified.

There are two distinct DKIM problems that cause spam:

Problem 1: No DKIM signature at all

Without DKIM, there is no cryptographic proof that the email came from your domain. The receiving server sees DKIM: NONE and treats the email with suspicion. Combined with other negative signals, this often means spam.

Problem 2: DKIM is present but misaligned

This is more subtle and more common. Your email is signed with DKIM, but the signing domain does not match the From address domain. For example:

  • From address: you@yourdomain.com
  • DKIM signed by: smtp2go.com

DKIM technically passes, but DMARC alignment fails because the signing domain does not match the From domain. Gmail shows the "via smtp2go.com" banner, and DMARC reports a failure.

The "via" banner is a symptom. When Gmail shows "via someserver.com" next to the sender name, the real problem is DKIM alignment. The email is signed, but not by your domain. Most free-tier SMTP relays sign with their own domain, not yours.

No DMARC policy

The missing policy that ties everything together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM. It tells receiving servers two things:

  1. What to do when SPF or DKIM fails (deliver, quarantine, or reject)
  2. Where to send reports about authentication failures

Without DMARC, receiving servers make their own judgment call. Some deliver the email. Some spam it. Some reject it. You have no control and no visibility.

Since February 2024: Gmail and Yahoo require DMARC for bulk senders (5,000+ emails/day). But even for low-volume senders, a missing DMARC record is a negative signal. Adding one - even with p=none (monitor only) - improves deliverability.

Basic DMARC Record
TypeTXT
Name_dmarc
Valuev=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start with p=none to collect reports without affecting delivery. After reviewing reports for a week, move to p=quarantine (spam folder) then p=reject (bounce). Each level gives receiving servers more confidence in your legitimate emails.

Bad sender reputation

Your domain or IP has a history

Every domain and IP address builds a sending reputation over time. Gmail, Outlook, and Yahoo track how recipients interact with emails from your domain:

  • Do recipients open emails from this sender?
  • Do they reply, or do they hit "Report spam"?
  • Does the sender consistently pass SPF, DKIM, and DMARC?
  • Is the sending volume consistent, or does it spike suddenly?

Things that damage your reputation

Sending to invalid addresses

High bounce rates signal that you are sending to purchased or scraped lists, not real contacts

Sudden volume spikes

Going from 10 emails/day to 1,000 emails/day looks like a compromised account or a spam campaign

Recipients marking you as spam

Even a few spam reports out of hundreds of emails can tank your reputation. Gmail weighs these heavily

Shared IP reputation

If you use a shared SMTP relay, other senders on the same IP affect your deliverability. Dedicated IPs avoid this but cost more

How to check your reputation

  • Google Postmaster Tools - Shows your domain reputation with Gmail (Low, Medium, High)
  • MXToolbox Blacklist Check - Checks if your domain or IP is on any email blacklists
  • mail-tester.com - Send an email and get a detailed deliverability score

Content that triggers spam filters

Less important than you think, but still real

Content-based spam filtering is less dominant than it was a decade ago. Modern filters lean heavily on authentication and reputation. But content still matters at the margins - especially when authentication is borderline.

Things that still trigger filters

Image-only emails with no text

Spam filters cannot read images. An email with a single large image and no text body looks like a spam technique designed to evade text-based filters

URL shorteners (bit.ly, t.co)

Spammers use URL shorteners to hide malicious destinations. Use full URLs in emails. If the URL is long, hyperlink it with descriptive anchor text

Excessive HTML formatting

Emails with heavy HTML, inline styles, and complex layouts are more common in marketing spam than legitimate correspondence. Keep formatting simple

Attachments from unknown senders

Executable attachments (.exe, .zip, .js) are almost always filtered. Even PDFs from a new sender domain can trigger caution

Misleading subject lines

Subject lines like 'RE: Your account' when there is no prior conversation, or 'Urgent action required' for routine content. Filters detect the pattern

The word "free" will not send you to spam. The idea that certain words trigger spam filters is outdated. In 2026, no major email provider filters based on individual words. If your authenticated, reputable email gets filtered because you said "free," something else is wrong.

Email forwarding breaking authentication

When Cloudflare (or another forwarder) causes SPF failures

This catches a lot of people off guard. You set up email forwarding (Cloudflare Email Routing, Forward Email, ImprovMX) and suddenly emails from other people to your domain start failing SPF checks.

Here is why:

  1. Someone sends you an email from sender@company.com
  2. The email arrives at Cloudflare (the forwarding server)
  3. Cloudflare forwards it to your Gmail inbox
  4. Gmail checks SPF for company.com - but the email is now coming from Cloudflare's IP, not the original sender's IP
  5. SPF fails because Cloudflare's IP is not in company.com's SPF record

How good forwarding services fix this

Proper forwarding services use two techniques to maintain authentication through the forwarding chain:

  • Preserve DKIM signatures - The original DKIM signature stays intact. Even though SPF fails, DKIM still passes because the email body was not modified
  • Add ARC headers - ARC (Authenticated Received Chain) is a standard that lets forwarding servers vouch for the authentication results they saw before forwarding. Gmail trusts ARC from known forwarders like Cloudflare

Not all forwarders are equal. Some forwarding services modify the email body (adding footers, rewriting links), which breaks DKIM signatures. Cloudflare Email Routing preserves DKIM and adds ARC headers, which is why it works well for this use case.

How to diagnose your specific problem

A step-by-step debugging process

Do not guess. Check the email headers to find exactly what is failing.

Step 1: View the original email

In Gmail, open the suspicious email, click the three-dot menu, and select Show original. Look for these lines at the top:

Authentication Results (what to look for)
SPFPASS / FAIL / SOFTFAIL / NONE
DKIMPASS / FAIL / NONE
DMARCPASS / FAIL / NONE

Step 2: Interpret the results

ResultMeaningFix
SPF: NONENo SPF record foundAdd an SPF TXT record
SPF: FAILSending server not authorizedAdd the server to your SPF includes
DKIM: NONENo DKIM signatureEnable DKIM at your email provider
DKIM: FAILSignature invalid or key mismatchVerify the DKIM DNS record matches the provider's key
DMARC: FAILNeither SPF nor DKIM aligned with From domainFix SPF or DKIM alignment
DMARC: NONENo DMARC record foundAdd a DMARC TXT record

Step 3: Use diagnostic tools

If the headers are not enough, use these tools for deeper analysis:

  • mail-tester.com - Send an email, get a score out of 10 with detailed explanations of what is wrong
  • mxtoolbox.com - Check your DNS records, blacklist status, and email server configuration
  • Google Admin Toolbox - Check MX, SPF, DKIM, and DMARC records for any domain
  • dmarcian.com - Analyze DMARC reports and understand authentication failures

The fix: a complete checklist

Work through this checklist in order. Each step builds on the previous one.

1. Add or fix your SPF record

One TXT record listing all servers authorized to send for your domain. Use mxtoolbox.com/spf.aspx to validate it. Make sure you have exactly one SPF record with 10 or fewer DNS lookups.

2. Enable DKIM signing

Your email provider or SMTP relay provides the DKIM public key. Add it as a DNS record. Verify the selector name matches what the provider uses for signing.

3. Ensure DKIM alignment

The DKIM signing domain must match your From address domain. If your SMTP relay signs with its own domain, your emails will show a 'via' banner and DMARC alignment will fail.

4. Add a DMARC record

Start with p=none to monitor. Add rua= to receive aggregate reports. After one week of clean reports, move to p=quarantine, then p=reject.

5. Check blacklists

Look up your domain and sending IP at mxtoolbox.com/blacklists.aspx. If listed, follow the removal process for each blacklist (usually requires fixing the issue and submitting a removal request).

6. Warm up your domain

If your domain is new or has not sent email before, start with low volume (10-20 emails/day) and gradually increase over 2-4 weeks. Sudden high volume from a new domain is a spam signal.

7. Monitor with Google Postmaster Tools

Register your domain with Google Postmaster Tools to track your reputation with Gmail over time. It shows spam rate, authentication results, and delivery errors.

That is a lot of steps

SendMailAs automates all of it

Automatic SPF, DKIM (signed by your domain), and DMARC. No DNS records to manage. No "via" banner. Continuous monitoring if anything breaks.

The easy way: let SendMailAs handle authentication

Fix deliverability in 5 minutes

Every deliverability problem in this article comes down to DNS records being missing, misconfigured, or misaligned. This is exactly what SendMailAs automates.

SPF configured automatically

SendMailAs adds itself to your SPF record and merges with any existing includes. No manual DNS editing. No risk of creating duplicate records.

DKIM signed by your domain

Unlike most SMTP relays, SendMailAs generates a DKIM key pair for your domain and signs outgoing email with it. No 'via' banner. DMARC alignment passes.

DMARC policy created

A sensible DMARC policy with reporting enabled. You get notified if authentication starts failing for any reason.

Continuous monitoring

DNS records can break silently - someone edits a record, a provider changes their infrastructure, a record expires. SendMailAs watches your records and alerts you before deliverability drops.

First domain is free forever. Unlimited domains cost $29/year. Set up takes 5 minutes.

Frequently asked questions

Send a test email to a Gmail, Outlook, and Yahoo account. Check inbox and spam folders. For a detailed score, send to mail-tester.com - it checks SPF, DKIM, DMARC, content, and blacklists in one report. Aim for 9/10 or higher.

Yes. A missing SPF record alone can cause Gmail to mark your emails as spam. Since February 2024, Gmail and Yahoo require SPF, DKIM, and DMARC for bulk senders. Even for low-volume senders, missing any one of them significantly hurts deliverability.

Different email providers have different spam filters and thresholds. Gmail might accept an email that Outlook rejects. The recipient's own behavior also matters - if they previously marked similar emails as spam, the provider learns to filter them. Consistent SPF, DKIM, and DMARC passes improve delivery across all providers.

For personal email, no. But if you are sending from a custom domain through a relay, using a free address as the From address causes DMARC alignment failures. Gmail and Yahoo publish strict DMARC policies (p=reject) for their domains, so emails pretending to come from @gmail.com through your server will be rejected.

It depends on the severity. If you fix missing DNS records, you can see improvement within hours. If your domain or IP has been blacklisted, removal takes 1-7 days after you resolve the underlying issue. Building a positive sending reputation from scratch takes 2-4 weeks of consistent, authenticated sending.

It can. When Cloudflare or another service forwards email, the receiving server sees the forwarding server's IP - not the original sender's. This can break SPF checks. Proper forwarding services preserve the original DKIM signature and add ARC (Authenticated Received Chain) headers to maintain trust through the forwarding chain.

Less than you think. In 2026, authentication and sender reputation matter far more than content. That said, emails with no text body (image-only), excessive links, URL shorteners, or known spam phrases can still trigger filters. Write naturally and focus on fixing your DNS records first.

SendMailAs automatically configures SPF, DKIM, and DMARC for your domain, signs outgoing emails with your domain's DKIM key (no 'via' banner), and monitors your DNS records continuously. It handles the authentication side completely. Content quality and sending behavior are still up to you.

Stop landing in spam

SendMailAs automates SPF, DKIM, and DMARC for your custom domain email. Proper authentication, no "via" banner, continuous monitoring. First domain free.