Why business email lands in spam: fix SPF, DKIM and DMARC

If your invoices, quotes or password-reset emails land in spam, the cause is usually one of three DNS records: SPF, DKIM or DMARC. Gmail, Yahoo and Outlook.com all publish rules that make authentication a condition of delivery, and a single missing or broken record is enough to send legitimate mail to the junk folder.

The quick fix: list every service that sends mail as your domain, make sure each one passes SPF or DKIM with your domain, and publish a DMARC record that starts at p=none. This guide shows how to diagnose each record, the mistakes that break them, and what the mailbox providers require as of October 2026.

What the big mailbox providers require

Google, Yahoo and Microsoft now publish sender requirements. The bar is lower for ordinary business mail and higher for "bulk" senders, which Google and Microsoft both define as more than 5,000 messages a day to their users.

Microsoft's rejection message is worth recognising, because it tells you the problem is authentication rather than content: 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Even if you send far fewer than 5,000 emails a day, treat the bulk rules as the target. They are the clearest public statement of what the providers expect, and meeting them costs nothing but a few DNS records.

Step 1: list everything that sends as your domain

Most deliverability problems in small businesses come from a sender nobody remembered. Before touching DNS, write down every system that puts your domain in the From address:

• Your mailbox provider (Google Workspace, Microsoft 365, Zoho Mail or a hosting company's mail server).
• Newsletter and marketing tools such as Mailchimp or HubSpot.
• Your website or app: contact forms, order confirmations and password resets, often sent through a transactional service.
• Helpdesk, CRM, invoicing and payment tools that email customers "from" you.
• Printers, scanners and monitoring tools that send alerts.

Each of these must either be listed in SPF or sign with DKIM using your domain. Ideally both.

Step 2: check what is published now

You can read all three records with dig (macOS and Linux) or an online DNS lookup. This small script prints the MX, SPF, DMARC and one DKIM record for a domain:

#!/bin/sh
# Usage: ./check-mail-dns.sh example.com [dkim-selector]
domain="$1"
selector="${2:-google}"

echo "MX records:";   dig +short MX "$domain"
echo "SPF record:";   dig +short TXT "$domain" | grep -i 'v=spf1'
echo "DMARC record:"; dig +short TXT "_dmarc.$domain"
echo "DKIM key ($selector):"; dig +short TXT "$selector._domainkey.$domain" | cut -c1-80

The DKIM selector is the label before ._domainkey; each sending service tells you its selector in its DKIM setup screen. You can also find it in a received message's DKIM-Signature header as the s= value.

A healthy result for a domain that uses Google Workspace and one marketing tool looks something like this:

SPF record:
"v=spf1 include:_spf.google.com include:_spf.newsletter-tool.example ~all"
DMARC record:
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Step 3: fix SPF

SPF (RFC 7208) is a TXT record on your domain listing the servers allowed to send mail for it. The common faults are easy to spot once you know them:

Two SPF records

A domain must publish exactly one v=spf1 record. If a new tool told you to "add an SPF record" and you created a second one, receivers return a permanent error and SPF fails for everything. Merge the mechanisms into a single record.

Too many DNS lookups

RFC 7208 limits SPF evaluation to 10 mechanisms that need DNS queries: include, a, mx, ptr, exists and the redirect modifier. Nested includes count too. Past the limit, the result is permerror. Remove services you no longer use, drop a, mx and ptr if those hosts do not send mail, and prefer DKIM for tools that support it.

A sender that is simply missing

If one tool's emails fail and others pass, that tool is not in SPF and is probably signing DKIM with its own domain. Add its include (from the vendor's documentation) or, better, set up its custom-domain DKIM.

Ending with +all

+all authorises the whole internet. End with ~all (soft fail) or -all (fail) once you are confident the list is complete.

Step 4: turn on DKIM for every sender

DKIM adds a cryptographic signature to each message; receivers check it against a public key in your DNS at selector._domainkey.yourdomain. Google requires DKIM keys of at least 1024 bits and recommends 2048 bits where your provider supports them.

• Google Workspace and Microsoft 365 generate the key in their admin consoles; you publish the TXT or CNAME records they show, then switch signing on.
• Marketing and transactional tools usually ask you to add two or three CNAME records for "domain authentication". Until you do, they sign with their own domain, which passes DKIM but does not align with your From address.

DKIM matters more than SPF for forwarded mail, because forwarding changes the sending server (breaking SPF) but usually keeps the signature intact.

Step 5: publish DMARC and read the reports

DMARC tells receivers what to do when a message fails both aligned SPF and aligned DKIM, and where to send reports. "Aligned" means the domain that passed SPF or DKIM matches the domain in the visible From address. Start with monitoring only:

Host:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Aggregate reports arrive daily as XML from the large providers. A DMARC reporting service, or the free report view some DNS providers offer, turns them into a list of sending sources and pass rates. Use it to find the senders you missed in Step 1.

When legitimate sources pass consistently, tighten the policy to p=quarantine and later p=reject. Microsoft explicitly recommends p=reject once you are ready. A strict policy is what stops criminals sending invoices "from" your domain.

The 2026 DMARC standard

DMARC was revised in 2026 as RFC 9989, a Proposed Standard that obsoletes RFC 7489. Existing records keep working: they still start with v=DMARC1. The main changes for domain owners are that the pct tag has been removed and replaced by a t (test mode) tag, a new np tag sets policy for non-existent subdomains, and receivers find the organisational domain by walking DNS instead of using the Public Suffix List. If your record uses pct to roll out gradually, plan to switch to the new approach as receivers adopt RFC 9989.

Troubleshooting by symptom

To see exactly what a receiver decided, open a delivered message and view its original headers. In Gmail, "Show original" lists SPF, DKIM and DMARC results at the top. The Authentication-Results header shows the same in any client.

Limitations and gotchas

• Authentication is necessary, not sufficient. Providers still filter on complaints and engagement. Google asks bulk senders to keep the spam rate below 0.10% and never reach 0.30%.
• DNS changes take time. Changes can take up to the record's TTL to be seen everywhere; check again before concluding a fix failed.
• Do not jump straight to p=reject. Without a week or two of reports you may block your own invoicing or helpdesk system.
• Subdomains help. Sending marketing from news.example.com and transactional mail from mail.example.com keeps one stream's reputation problems from affecting the other.

What to do next

1. Make the sender inventory and run the DNS check above.
2. Fix SPF to a single record under 10 lookups.
3. Enable custom-domain DKIM in every tool that sends as you.
4. Publish p=none DMARC with a reporting address and review reports for two weeks.
5. Move to quarantine, then reject, and add a calendar reminder to review reports monthly.