Why Your Business Emails End Up in Spam (And How to Fix It)

You sent a quote to a potential client three days ago. They never responded. You followed up. Nothing. Then they mentioned they never received your email.

It was sitting in their spam folder.

This is one of the most common and most invisible problems facing small businesses. Your emails are technically being delivered, but they're being dumped into a folder that nobody checks. You lose deals, miss invoices and look unreliable to people who assume you just never replied.

The fix is almost always the same: your domain is missing one or more email authentication records.

What's actually happening

When you send an email from your business domain, the receiving server (Gmail, Outlook, Yahoo) runs a series of checks before deciding where to put it. These checks look for three specific DNS records on your domain: SPF, DKIM and DMARC.

If those records are missing, the receiving server has no way to verify that your email is legitimate. It can't tell the difference between a real email from you and a phishing attempt from someone pretending to be you. So it does the safe thing: it flags the message as suspicious and routes it to spam.

Your email isn't being blocked because of what you wrote. It's being blocked because your domain can't prove who you are.

The Google and Yahoo deadline that changed everything

In February 2024, Google and Yahoo rolled out new requirements for email senders. The rules are straightforward:

• All senders must have a valid SPF or DKIM record
• Bulk senders (5,000+ messages per day) need SPF, DKIM and DMARC
• Emails that fail authentication are more aggressively filtered

Microsoft followed with similar requirements for Outlook.com in 2025.

Even if you're a small business sending a few dozen emails per day, these changes affect you. The threshold for "suspicious" got lower. Domains that were borderline before now get flagged. If you haven't set up authentication, your deliverability has probably gotten worse over the past two years without you realizing it.

SPF: telling the world who can send your email

SPF stands for Sender Policy Framework. It's a DNS record that lists every server authorized to send email on your behalf.

When someone receives an email from your domain, their mail server checks your SPF record. If the sending server isn't on the list, the email fails the check.

How to set it up:

1. List every service that sends email from your domain. Your email provider is the obvious one, but don't forget: your website's contact form, your newsletter tool, your invoicing software, your CRM. Every service that sends as you@yourdomain.nl needs to be included.
2. Look up the SPF include statement for each service. Every provider publishes this in their docs. For Google Workspace, it's include:_spf.google.com. For Mailchimp, it's include:servers.mcsv.net.
3. Combine everything into a single TXT record:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

4. Add this record in your DNS settings at your domain registrar.
5. Test it with MXToolbox's SPF checker or a dig TXT yourdomain.nl command.

The -all at the end means "reject anything not on this list." Some guides suggest ~all (soft fail) as a safer starting point, but -all gives you stronger protection once your list is complete.

For a deeper walkthrough of SPF, including real-world examples, see our SPF, DKIM and DMARC technical guide.

DKIM: proving your emails haven't been tampered with

DKIM stands for DomainKeys Identified Mail. Where SPF checks who sent the message, DKIM checks whether the message itself is authentic.

Your mail server attaches a cryptographic signature to every outgoing email. The receiving server looks up your public key in DNS and verifies that the signature matches. If someone intercepted and modified the email in transit, the signature breaks and the check fails.

How to set it up:

Most email providers handle the signing automatically. You just need to publish the public key in your DNS.

For Google Workspace: go to Admin console > Apps > Google Workspace > Gmail > Authenticate email. Generate a new record and add the TXT record to your DNS.

For Microsoft 365: go to the security portal, find email authentication settings, select your domain and follow the DKIM wizard. You'll add two CNAME records to your DNS.

For other providers: search their documentation for "DKIM setup" and follow the instructions. The process is always the same pattern: they generate a key pair, you publish the public key as a DNS record.

The DNS record will look something like:

google._domainkey.yourdomain.nl  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

That long string after p= is your public key.

DMARC: the policy that ties it all together

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It does two things: it tells receiving servers what to do when SPF or DKIM checks fail, and it sends you reports about who is sending email from your domain.

Without DMARC, SPF and DKIM failures are suggestions. With DMARC, they're rules.

How to set it up:

Start with a monitoring-only policy. Add this TXT record to your DNS:

_dmarc.yourdomain.nl  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.nl"

This tells receiving servers: "Don't block anything yet, but send me reports about authentication failures."

Leave this running for two to four weeks. Review the reports. You're looking for legitimate services that are failing checks because you forgot to include them in SPF or didn't set up DKIM for them.

Once you've fixed all legitimate senders, upgrade your policy:

• p=quarantine sends failed emails to spam instead of the inbox
• p=reject blocks failed emails entirely

The full process takes four to eight weeks. Don't skip straight to p=reject or you risk blocking your own legitimate emails.

How to check what you have right now

You might already have some of these records. Here's how to find out.

Command line (Mac/Linux):

# Check SPF
dig TXT yourdomain.nl | grep spf

# Check DKIM (replace 'google' with your selector)
dig TXT google._domainkey.yourdomain.nl

# Check DMARC
dig TXT _dmarc.yourdomain.nl

Online tools:

• MXToolbox.com has dedicated lookup tools for SPF, DKIM and DMARC
• mail-tester.com lets you send a test email and scores your entire setup
• dmarcian.com/dmarc-inspector checks your DMARC record specifically

If any of those lookups return empty results, that record is missing and needs to be added.

Mistakes that break your email authentication

Getting the records in place is half the battle. Getting them right is the other half. These are the mistakes we see most often when scanning business domains.

Multiple SPF records. You can only have one SPF record per domain. If you add a second one (maybe your web designer added one and your email provider added another), both become invalid. Merge them into a single record.

Too many DNS lookups. SPF has a hard limit of 10 DNS lookups. Each include: statement counts as at least one lookup, and nested includes add more. If you use a lot of services, you can hit this limit. Tools like MXToolbox will flag this. The fix is to consolidate: replace multiple includes with their resolved IP ranges using the ip4: mechanism, or use an SPF flattening service.

DMARC stuck on p=none. Many businesses set up DMARC in monitoring mode and never move beyond it. p=none collects data but provides zero protection. Attackers can still spoof your domain freely. It's a diagnostic step, not a security measure. Set a reminder to review your reports and upgrade to p=quarantine or p=reject.

Forgetting a sending service. You set up SPF with your email provider but forgot that your invoicing tool also sends emails from your domain. Those emails now fail SPF checks. Audit every service that sends email as your domain before finalizing your SPF record.

DKIM not enabled on all sending services. You enabled DKIM for Google Workspace but not for your newsletter provider. Emails from the newsletter fail DKIM checks. Each service that sends email needs its own DKIM key published in DNS.

What our scanner checks

Our free website scanner checks your domain for email authentication as part of a broader security review. Specifically, it looks for:

• Whether an SPF record exists and is syntactically valid
• Whether DKIM records are published for common selectors
• Whether a DMARC record exists and what policy level it's set to
• Whether your SPF record exceeds the 10-lookup limit

These checks run alongside tests for SSL certificates, security headers, domain expiry risk and other items on the security checklist for small businesses. You get a clear pass/fail for each check with a plain-language explanation of what to fix.

The 30-minute fix that protects your business

Email authentication isn't glamorous. Nobody starts a business excited about DNS records. But the gap between "emails that arrive" and "emails that land in spam" can be the gap between winning a client and losing one.

The setup takes about 30 minutes if you have access to your DNS. If your web designer or IT person manages your DNS, forward this article to them and ask them to verify all three records are in place. If they can't tell you within five minutes whether you have SPF, DKIM and DMARC set up, that's a red flag worth investigating.

Not sure where you stand? Run a free scan and find out in seconds.

Scan your website now