Deliverability 101: Why Your Emails Go to Spam

Deliverability is one of those topics that sounds intimidating until you understand that ninety percent of it comes down to a small number of mostly mechanical decisions. The remaining ten percent is judgment built up over thousands of campaigns, and you can absorb most of it from a guide like this one. By the end you should know not just what SPF, DKIM, and DMARC are, but why they exist, how they fail, and what to do when they do.

What “deliverability” actually means

Deliverability is the percentage of your sent emails that land in the recipient’s inbox rather than their spam folder, the promotions tab, or worst of all, the bit bucket where rejected mail simply disappears. Most senders track only “sent” and “opened,” but the gap between those numbers hides the real story. An email sent and not opened might mean bad subject line — or it might mean it never reached the inbox in the first place. Deliverability is the difference.

The fundamental problem inboxes are trying to solve is: how do we know an email claiming to be from jane@company.com was actually sent by Jane at company.com, and not by an attacker forging her address? The entire SPF/DKIM/DMARC stack exists to answer that question.

SPF: who is allowed to send for this domain?

SPF (Sender Policy Framework) is a public list, published in your domain’s DNS, of every server allowed to send email claiming to come from your domain. When a receiving server gets an email from jane@company.com, it looks up company.com‘s SPF record, sees the list of allowed servers, and checks whether the actual sending server appears on that list. If it does, SPF passes. If it does not, SPF fails.

An SPF record is a single TXT record that looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Translated into English: “I am an SPF version 1 record. The servers listed at _spf.google.com and sendgrid.net are allowed to send for me. Anything else, treat as a soft failure.”

The most common SPF mistake is having multiple SPF records on the same domain. You are only allowed to have one, ever. If you use Google Workspace and SendGrid and Mailgun, all three providers go inside the single SPF record, separated by includes — not three separate records. Multiple records cause SPF to break entirely, not just one of them.

The second most common mistake is the +all mechanism, which is a wildcard meaning “let anyone send for this domain.” This effectively disables SPF and is usually the result of someone copying an example record without understanding it. Always use ~all (soft fail) or -all (hard fail), never +all.

DKIM: a cryptographic signature on every message

SPF answers “is this server allowed to send?” but it does not verify the actual content of the message. An attacker who somehow gained access to an allowed sending server could still send forged content. DKIM (DomainKeys Identified Mail) closes that gap by attaching a cryptographic signature to every message, computed from the message body and headers using a private key that only the legitimate sender controls.

The receiving server reads the signature, fetches the public key from a TXT record at a known location in your DNS, and verifies that the signature matches. If it does, the content has not been tampered with. If it does not, DKIM fails.

You generate DKIM inside your email provider’s admin panel. For Google Workspace go to Apps → Gmail → Authenticate email and click Generate New Record. You will receive a long TXT record — usually around two hundred to four hundred characters of base64-encoded key material. Paste it into your DNS at the location your provider tells you, wait for propagation, then activate signing inside your provider’s admin.

One subtle DKIM issue: rotating keys. Best practice is to rotate your DKIM keys every six to twelve months. Most providers now do this automatically, but if you set up DKIM manually years ago and never rotated, you may be vulnerable. Check your provider’s admin panel for an auto-rotation setting.

DMARC: telling receivers what to do when SPF or DKIM fails

SPF and DKIM tell the receiver whether something is wrong. DMARC tells the receiver what to do about it. Without DMARC, even if SPF and DKIM both fail, most inboxes will still deliver the message (perhaps to spam, perhaps to inbox depending on other signals). DMARC lets you say definitively: “if SPF and DKIM both fail, reject this message — I do not authorize it.”

A typical DMARC record looks like this:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; sp=quarantine; aspf=r; adkim=r

The most important field is p=, which sets your enforcement policy. Three options:

• p=none — monitor only. Receivers report failures to you but do not act on them. Use this when first setting up DMARC.
• p=quarantine — failed messages are sent to spam. Use this after two or three weeks of clean monitoring data.
• p=reject — failed messages are refused outright. Use this once you are confident no legitimate mail is failing.

The rua field is where DMARC failure reports get sent. Set this to a real address (or a service like dmarcian or Postmark’s free DMARC monitor) so you actually see what is happening. Without monitoring, DMARC is invisible.

Why your emails go to spam — the top ten reasons

Even with perfect SPF/DKIM/DMARC, plenty of cold emails still land in spam. Here are the ten most common causes, in roughly the order we see them:

1. New domain or new IP with no reputation. Brand new sending infrastructure is treated as guilty until proven innocent. Warm up properly before sending real volume. There is no shortcut.

2. List quality is poor. Old data, scraped lists, or unverified emails produce hard bounces, and high bounce rates destroy reputation faster than almost anything else. Verify every list with NeverBounce or ZeroBounce before sending.

3. Spammy subject lines. All caps, excessive punctuation, money mentions, “FREE,” “ACT NOW,” “limited time” — modern spam filters are better at this than they used to be, but obvious spam triggers still cost you. Write subject lines like a human texting another human.

4. Image-heavy or HTML-heavy messages. Cold outreach should be plain text or very lightly formatted HTML. Image-only messages (or messages where the text-to-image ratio is bad) get filtered aggressively.

5. Tracking pixels. Open tracking pixels hurt deliverability. The data they produce is also unreliable thanks to Apple Mail Privacy Protection. Disable them.

6. Default tracking domains. If you use link tracking, your sending tool’s default shared tracking domain is on every spam blocklist on the internet. Use a custom tracking domain that you control.

7. Overly long messages with too many links. Three or more links in a cold email correlates strongly with spam folder placement. Keep cold emails to one link maximum.

8. Not enough conversational signal. Inboxes increasingly weight whether emails generate replies, forwards, and “not spam” actions. If your campaigns produce zero replies for the first three days, deliverability degrades from there. This is why warmup matters even after launch.

9. Sending too much volume too fast. Even after warmup, if you suddenly jump from forty to two hundred sends per day, inboxes notice and react. Ramp gradually.

10. The recipient marked similar emails as spam in the past. Inboxes remember individual user behavior. If you sent the same template to ten people and three marked it spam, the next seven recipients are more likely to land in spam regardless of your infrastructure.

How to test your deliverability before launching

Three free tools that should be in every operator’s pre-launch routine:

mail-tester.com — send a test email from your new mailbox to the address it provides, then check the score. You want 10/10. Anything below 9 means something is misconfigured.

Google Postmaster Tools — once you have been sending for a few days, register your domain in Google Postmaster. It shows you actual reputation data from Gmail itself. If your reputation drops from “high” to “medium” overnight, something just broke.

Glock Apps or InboxAlly — these send test emails to seed accounts across Gmail, Outlook, Yahoo, and other major providers, then report back which folder each one landed in. More expensive than mail-tester but the data is much richer.

The fix-it playbook

If you suspect deliverability has dropped, do these five things in this order, every time:

Run a fresh mail-tester score. If the score dropped, something on the technical side broke — start there. Check SPF, DKIM, DMARC, and your DNS for any recent changes.

Pull your bounce report for the past seven days. If bounce rate is above three percent, your list is dirty. Pause sending, re-verify, resume.

Check Google Postmaster Tools. If your domain reputation has dropped, look at when it dropped and what changed in your campaigns at that time.

Audit your subject lines and copy from the past two weeks. Look for spam trigger words and over-eager phrasing.

If everything else looks fine, the issue is volume or velocity. Cut your daily send by fifty percent for a week and let reputation recover before ramping back up.

Deliverability is not magic. It is a small set of mechanical rules and a slightly larger set of behavioral patterns. Master the mechanical rules and you have already eliminated the vast majority of problems.