Email Deliverability for SMBs: Why Your Invoices Go to Spam (And How to Fix It)

The most expensive silent business problem I encounter at SMBs is broken email deliverability. Invoices that don't arrive. Sales emails that vanish. Password resets that get marked as phishing. Nobody complains, because customers don't know they're missing emails. They just stop responding.

The financial cost is real and quietly enormous. A B2B service business losing 20% of its outbound emails to spam folders is losing 20% of its closing efficiency, every month, forever, until someone fixes it. The fix is technical but bounded — usually a few hours of work that pays for itself in the first week. The hard part is realising it's the problem.

This article walks through the diagnostic process and the four-step fix.

How to know if you have a deliverability problem

Without checking, most SMB owners don't know they have a deliverability problem. The signal is invisible by design — spam folders are silent. Diagnostic steps:

Test 1: Send yourself an email from your business address. Use your normal email tool. Send to a personal Gmail, Outlook, and Yahoo account. Check whether the email lands in inbox or spam in each. If it's in spam in even one, you have a problem.

Test 2: Run Mail-Tester. Send a test email from your business tool to the unique address Mail-Tester gives you. They run a comprehensive check and give you a score out of 10. Anything below 8/10 is a deliverability problem.

Test 3: Check MXToolbox for your domain. Run their "Email Health" report. It surfaces missing SPF, broken DKIM, missing DMARC, blacklisted IPs, and reverse-DNS issues.

Test 4: Read your DMARC reports. If you have DMARC configured (you might not), reports come in via email or via a service like Postmark's DMARC Digests. They show what proportion of your email is actually authenticated correctly.

If any of these tests fail, deliverability is broken. The fix is the four-step process below.

The technical layer in plain English

To fix deliverability, you need to understand three acronyms that get thrown around like everyone knows them: SPF, DKIM, DMARC. They're not as complicated as they look.

SPF (Sender Policy Framework)

A list of which servers are allowed to send email from your domain. Lives as a TXT record in your domain's DNS.

Analogy: SPF is the bouncer at the email club. When an email arrives claiming to be from you@yourbusiness.com, the receiving server (Gmail, Outlook, etc.) looks up your domain's SPF record. If the email came from a server on your SPF list, it's allowed in. If it came from a server not on your list, the email is suspicious — usually marked as spam, sometimes outright rejected.

Why it breaks for SMBs: most businesses send email from multiple services without realising it. Your transactional emails from Postmark. Your marketing emails from Mailchimp. Your sales emails from your founder's Gmail. Your invoicing emails from QuickBooks. If any of these aren't in your SPF record, their emails get treated as suspicious.

DKIM (DomainKeys Identified Mail)

A cryptographic signature added to every email you send. Lives as a TXT record in your domain's DNS, with the public key.

Analogy: DKIM is the wax seal on a letter. When the email arrives, the receiving server reads the digital signature and checks it against the public key published in your DNS. If the signature is valid, the email is provably from you and hasn't been tampered with. If invalid (or missing), the email is suspect.

Why it breaks for SMBs: each email service generates its own DKIM keys. You need to add a separate DKIM record per service. Most businesses set up DKIM for one service (their main email) and forget about the others. The "other" services then send unsigned emails that fail authentication.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Tells receiving servers what to do if SPF or DKIM fail. Also asks them to send you reports. Lives as a TXT record in your domain's DNS.

Analogy: DMARC is the bouncer's rulebook. SPF and DKIM tell the bouncer "is this person allowed in?" DMARC tells the bouncer "if they're not allowed in, what do I do — turn them away, or send them in but watch them?"

DMARC has three policy levels:

p=none: monitor only. Servers report failures but don't act on them. Right starting point.
p=quarantine: failed emails go to spam folder.
p=reject: failed emails are bounced.

Why it breaks for SMBs: most businesses don't have DMARC at all, which means failed emails are handled by each receiving server's defaults (usually marked as spam). When DMARC is configured, it's often set to p=reject immediately, before SPF/DKIM are properly set up — which means legitimate emails get rejected because they fail authentication checks no one has configured properly.

The four-step fix

Working order matters. Don't skip ahead.

Step 1: Inventory your sending services

List every service that sends email from your business domain:

Your main email provider (Google Workspace, Microsoft 365)
Transactional email (Postmark, SendGrid, SES, Mailgun, Resend)
Marketing email (Mailchimp, ConvertKit, ActiveCampaign, Klaviyo)
E-commerce platform's order emails (Shopify, WooCommerce)
Invoicing tools (QuickBooks, Xero, FreshBooks, Stripe)
CRM email (HubSpot, Pipedrive, Salesforce)
Calendar tools that send emails on your behalf (Calendly, Cal.com)
Internal tools (your application, your customer support tool)

Most SMBs have 4–8 services on this list. Some have 12+. You can't fix deliverability without the complete list.

For each service, find the documentation page titled something like "DNS setup" or "SPF and DKIM configuration." You'll need the records they provide.

Step 2: Configure SPF correctly

You can only have one SPF record per domain. If you have multiple services, you combine them into a single record.

Wrong (one service per record — won't work):


v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.mailchimp.com ~all

Right (combined into one record):


v=spf1 include:_spf.google.com include:spf.mailchimp.com include:spf.postmarkapp.com ~all

The order: your most-trusted, highest-volume sender first, then others. The ~all at the end means "soft fail" anyone not on the list — they're suspicious but not rejected outright.

After updating SPF, wait 24 hours for DNS propagation, then re-run Mail-Tester to confirm SPF passes.

Step 3: Configure DKIM for every service

Each service that sends mail from your domain needs its own DKIM record. They each provide one. Add each as a separate TXT record in your DNS.

Each DKIM record has a unique selector (a subdomain prefix like google._domainkey or mail2024._domainkey). They don't conflict because each has a different selector.

After adding DKIM records, wait 24 hours, then verify by checking each service's "DKIM verified" status in their dashboard. Most services check periodically and update.

Step 4: Configure DMARC, starting in monitor mode

Add a DMARC record with p=none initially. Example:


v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.com; ruf=mailto:dmarc@yourbusiness.com

This tells servers to report SPF/DKIM failures to the email address you specified, but not to take action yet. Set up a Gmail/Outlook filter to send these reports to a folder (you don't want them in your inbox).

For 2–4 weeks, monitor the reports. Look for:

What percentage of email passes authentication? (Should be 98%+)
What sources are sending mail "from your domain" that you don't recognise? (Could be legitimate services you forgot, or could be spoofers)

Once authentication is at 98%+ and you've identified all legitimate sources, gradually raise the policy:


v=DMARC1; p=quarantine; pct=10; rua=mailto:...

The pct=10 means apply quarantine to 10% of failing emails initially. Watch for issues. Raise to 50%, then 100%. Eventually move to p=reject if you want maximum protection.

Don't skip the monitor phase. Going straight to p=reject is how you accidentally reject legitimate email for weeks before noticing.

What the four steps fix

After all four steps:

Inbox placement improves dramatically. Mail-Tester score should go from 5–7/10 to 9–10/10.
Spoofing protection. Bad actors can no longer send fake email "from your domain" because receiving servers will reject it.
Reputation builds correctly. Each authenticated email helps your sending reputation. Each authenticated email signal is a vote of confidence to the receiving servers.
Reporting visibility. DMARC reports show you when something breaks (a service starts failing authentication, a new spoofer appears) so you can respond.

What this doesn't fix

Some deliverability problems aren't authentication-related:

Reputation damage from past spam complaints. If your IP or domain has been used to send spam previously (intentionally or accidentally), authentication won't restore reputation. You need to "warm up" your domain — start with low send volumes, gradually increase, build a positive sending history. This takes 4–8 weeks.

Content-based filtering. Some emails get marked as spam not because of authentication issues but because of their content — too many sales-y words, too many links, image-only content, large attachments. Authentication doesn't fix this. Better email writing and design does.

Recipient list quality. If you're sending to addresses that don't exist (high bounce rate), or that haven't engaged with your emails (low open rate), receiving servers downgrade your reputation. Authentication doesn't fix this. List hygiene does.

Some specific provider quirks. Apple Mail, Yahoo, and Outlook have idiosyncratic deliverability rules that don't always align with SPF/DKIM/DMARC perfectly. Authentication fixes 90% of issues; the last 10% requires provider-specific tuning.

When to get help

The fix is bounded enough that most SMBs can do it themselves with a few hours of patient work. When to hire help:

You have 8+ sending services and the SPF record is getting complicated.
DMARC reports show patterns you can't interpret.
Authentication is configured but emails are still going to spam (suggests reputation or content problems).
You're rolling out DMARC p=reject and want a second pair of eyes on the configuration.
You've been blacklisted (showing in MXToolbox) and need to delist.

If you're doing this yourself, the SEOCheck tool can verify some of the basic technical setup as part of its broader audit. Mail-Tester and MXToolbox cover the email-specific stuff more thoroughly.

If you'd like a second pair of eyes, the first call is free — see the Lead Steer monthly retainer for ongoing L3 support including deliverability work.

What to do next

If deliverability isn't your problem, the other articles in this series cover the other six recurring L3 issues:

---

Part of the Level 3 Tech Support pillar guide.