Business Emails Going to Spam? How to Fix

Short answer: nearly always, your domain isn’t proving that the mail is really from you. That proof is three DNS records called SPF, DKIM and DMARC. Check them first, in that order, before you blame the wording of your emails or the recipient’s filter.

I’m a web developer in Columbus, not an email company, but this one lands in my inbox a lot. The usual story is a contact form that stopped reaching the owner, or invoices that go to spam at one customer and not another. The fix is rarely hard. Finding which of six things is wrong is the job.

The five-minute diagnosis

Send a test message from the address that’s failing to a personal Gmail account. Open it, click More next to Reply, and choose Show original (Gmail Help, checked October 29, 2026). That opens the full header, and the header holds the SPF, DKIM and DMARC results (Google Workspace Help, checked October 29, 2026). Google’s Messageheader tool will read it for you: click Copy to clipboard in that window, paste the header into the tool and analyze it. You want to see all three pass.

Read it like this:

All three pass: authentication isn’t your problem. Look at content, list quality or sender reputation instead.
SPF or DKIM fail: the sending service isn’t authorized or isn’t signing. That’s causes 1 to 4 below.
DMARC fails while SPF and DKIM pass: they passed for the wrong domain. This is “alignment,” and it’s the one that confuses everybody. Under relaxed alignment, the From domain and the domain SPF or DKIM checked need the same organizational domain, so mail.example.com lines up with example.com; strict alignment needs them identical (RFC 9989, checked October 29, 2026).

Why this is stricter than it used to be

Gmail’s sender guidelines require SPF or DKIM from everyone who sends to Gmail, valid reverse DNS (PTR) records for your sending servers, and a TLS connection (added December 2023). Google also says to keep your spam rate in Postmaster Tools below 0.10% and never reach 0.30%. Starting February 1, 2024, anyone sending more than 5,000 messages a day to Gmail also needs SPF, DKIM and a DMARC record (the policy can be none), a From domain aligned with the SPF or DKIM domain on direct mail, and one-click unsubscribe on marketing and subscribed messages (Google, checked October 29, 2026). Yahoo has the same shape, with enforcement starting February 2024: SPF or DKIM for everyone and a spam rate below 0.3%, and for bulk senders both, plus a DMARC policy of at least p=none, an aligned From domain and one-click unsubscribe (Yahoo, checked October 29, 2026). Yahoo’s page doesn’t give a bulk number.

Outlook.com has rules too. For domains sending more than 5,000 emails a day, Microsoft’s April 2025 announcement requires SPF and DKIM to pass and DMARC at p=none or stricter, aligned with SPF or DKIM, with enforcement starting May 5, 2025: mail that fails is rejected, with the error “550; 5.7.515 Access denied” (Microsoft, checked October 29, 2026).

Most small businesses are nowhere near 5,000 a day. But filters don’t wait for you to hit the bulk line. A domain with no DMARC record and a sloppy SPF looks worse than one that’s set up, whatever your volume.

The six usual causes, in the order I check them

1. There’s no SPF record, or there are two. A domain gets exactly one. The spec says that if a lookup finds more than one SPF record, the result is a permanent error (RFC 7208, checked October 29, 2026). This happens when someone adds a second record for Mailchimp instead of merging it into the first. Combine them into one line.

2. The SPF record doesn’t list everything that sends for you. Google Workspace alone is v=spf1 include:_spf.google.com ~all. With another service it becomes v=spf1 include:_spf.google.com include:amazonses.com ~all (Google Workspace Help, checked October 29, 2026). Every service that sends as you needs an include: in that one record.

3. Too many lookups. SPF is allowed ten DNS-querying terms. Go over and it fails with a permanent error (RFC 7208). Every include: counts, and the included services have their own includes. If you’ve stacked a CRM, a newsletter tool, a helpdesk and your mail provider, you can be over without noticing.

4. DKIM isn’t turned on, or a third-party sender isn’t signing as you. In Google Workspace, DKIM is off until you generate a key and switch it on. In Microsoft 365 it’s records at your DNS host, then you enable signing. Same for Mailchimp, QuickBooks, your CRM: each has its own “authenticate your domain” step. Skip it and the mail is signed with their domain, so SPF and DKIM can pass while DMARC fails. That’s the alignment problem from the diagnosis.

5. Your website sends mail from the wrong place. This one gets its own section below.

6. Reputation or content. If authentication all passes and you’re still in spam, look at who you’re sending to (a purchased list, a long-dormant list), how many people hit the spam button, and whether you’re sending from a brand-new domain. Gmail’s Postmaster Tools shows your spam rate; Google says to keep it below 0.10% and avoid ever reaching 0.30%.

The three records, in plain words

You add these at whoever hosts your DNS. That’s often your registrar, sometimes your web host. Replace example.com with your domain.

SPF is the guest list: which servers may send as you. It lives in a TXT record on the bare domain:

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

DKIM is a wax seal. Your mail service signs each message, and the matching public key sits in DNS so receivers can check the seal. In Google Workspace, go to Apps, Google Workspace, Gmail, Authenticate email, pick your domain and generate a record. Google defaults the selector to google, recommends 2048-bit keys if your DNS host allows it, and says it can take up to 48 hours for DKIM authentication to start working. Add the TXT record first, then click Start authentication (Google Workspace Help, checked October 29, 2026).

DMARC is the instruction sheet: what to do when a message claims to be from you and fails the check, plus where to send reports. It’s a TXT record at _dmarc.example.com. Google recommends starting the policy at none, so a minimal record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

The rua address gets summary reports of who is sending as you. Use a dedicated mailbox or group, not your own inbox, because they can pile up. Google says to wait 48 hours after SPF or DKIM go live before adding DMARC (Google Workspace Help, checked October 29, 2026).

The WordPress contact form problem

This is the one I see most. A WordPress form notification is sent by the web server, using PHP, from your hosting company’s mail system. The From address says [email protected], but the server that actually sent it isn’t on your SPF list and has no DKIM key for your domain. To Gmail that looks exactly like a spoof.

The fix:

Stop sending through the web host. Install an SMTP plugin and connect it to a real sending service: your own Google Workspace or Microsoft 365 mailbox, or a transactional service such as Postmark, SendGrid or Amazon SES.
Authenticate that service for your domain. Add its include: to your single SPF record and publish the DKIM records it gives you.
Make the From address match. Send from [email protected], not from a Gmail address and not from the visitor’s email. Put the visitor’s address in Reply-To instead. Faking the visitor as the sender is what gets form mail filtered.
Submit the form and check the header again. SPF, DKIM and DMARC should all pass.

Google’s sender page says the same thing in its own terms for bulk senders: on direct mail, the From domain has to align with the SPF or DKIM domain. Smaller senders aren’t held to it, but filters like it either way.

Roll DMARC out in this order

Here’s where people hurt themselves. They publish p=reject on day one and then find out the invoicing tool wasn’t authenticated.

Fix SPF and DKIM for everything that sends as you.
Publish p=none with a rua address and leave it for a few weeks. Read the reports (or use a reporting service) to find every service sending as you, including ones you forgot.
Fix what the reports show failing.
Move to p=quarantine, then p=reject if your domain suits it and nothing legitimate is failing. Microsoft says to expect some false positives and to go slowly (Microsoft Learn, checked October 29, 2026), and its Outlook announcement advises the same none, quarantine, reject order. For a trial run, the current spec (RFC 9989) has a t=y test-mode tag: receivers that support it apply the policy one level softer, so p=quarantine; t=y acts like none and p=reject; t=y acts like quarantine, and you still get reports. Older receivers may ignore the tag and enforce the full policy, so don’t use it to skip step 3. Remove t=y when you want the policy fully enforced.

Know what each one means. In the DMARC spec, none means the domain owner offers no expression of preference, quarantine means the owner considers failing mail suspicious, and reject means the owner considers every such failure a clear sign that use of the domain isn’t valid (RFC 9989, checked October 29, 2026). p=none alone does not stop anyone from spoofing your domain. It’s the first step: it satisfies the bulk-sender rule and gives you reports. Protection starts at quarantine or reject.

One caution before p=reject on a domain where people send everyday mail. The spec warns that reject can break mailing lists, forwarding addresses and role aliases, and says domains whose users may post to mailing lists should not publish it. If you do anyway, it says to run p=none for at least a month and then p=quarantine for an equally long period first (RFC 9989, section 7.4, checked October 29, 2026). For many small businesses, quarantine is a perfectly good place to stop.

Also: if you own domains that no one should expect mail from, Microsoft suggests publishing v=DMARC1; p=reject; on them (Microsoft Learn, checked October 29, 2026).

When to stop DIY and call someone

You’ve fixed the records and the header still shows a failure. Alignment is subtle, and it’s quick for someone who does it daily.
Your SPF is over the lookup limit and you can’t tell which senders to drop.
Several tools send as you and nobody knows which ones.
You don’t control DNS. It’s at a registrar a former employee set up, or at an agency that’s gone quiet.
You’re about to go to p=reject and a wrong guess means customers don’t get invoices.

That last one is the real reason to get help. A mistake in DMARC doesn’t fail loudly. Mail just stops showing up.

Where I come in

Email authentication is one of the things I check in a website audit, along with who actually owns your domain and DNS. If a site is sending mail badly because something’s broken or compromised, that’s a rescue. Or just email me the domain and what’s going wrong at [email protected]. I’ll look at the records and tell you what I’d change, and whether it’s a ten-minute fix or not.