Business Email That Doesn't Land in Spam
Gmail and Outlook both tightened sender rules — Outlook now rejects unauthenticated high-volume mail outright with a 550 5.7.515 error. Here's the afternoon of DNS work that keeps your quotes, invoices and form notifications in the inbox.
Provider requirements described here were checked on August 5, 2026. Gmail’s rules took effect February 2024 and Outlook’s enforcement escalated through 2025 — this area keeps tightening, so re-verify before assuming you’re fine.
Two complaints get mashed together constantly: “our email doesn’t look professional” and “our email doesn’t arrive.”
They’re related. They’re not the same.
- Professional means the address looks like a real business.
- Deliverable means the message actually reaches an inbox.
You can own a beautiful domain and still rot in spam. You can also have flawless authentication and write like a phishing kit. You need both — and the second half is now enforced by machines with published rules, which is good news, because published rules can be satisfied on purpose.
The rules got real, and most small businesses missed it
For years, deliverability advice was folklore. That changed.
Gmail, since February 2024, requires every sender to authenticate with at least SPF or DKIM, publish valid forward and reverse DNS for the sending host, transmit over TLS, and keep spam complaints under 0.3%. Bulk senders — 5,000+ messages a day — additionally need SPF and DKIM, a published DMARC policy, alignment between the From: domain and an authenticated domain, and one-click unsubscribe on marketing mail.
Outlook.com followed for high-volume senders — 5,000 or more messages a day to Microsoft consumer accounts from one From: domain. From May 5, 2025, non-compliant mail went to Junk. Microsoft then escalated to outright rejection, with a bounce that reads:
550 5.7.515 Access denied, sending domain does not meet the required authentication level
That isn’t a filter you can charm. It’s a door that doesn’t open.
Now the honest part: a five-person shop isn’t sending 5,000 messages a day, so the bulk rules don’t bind you. Two reasons to do this anyway.
- The all-senders baseline already applies to you. Authentication is not optional at any volume on Gmail.
- These thresholds only ever move down. Every requirement on that list started as an enterprise concern and became everyone’s. Setting it up correctly costs an afternoon. Discovering it mid-quarter costs customers.
Step 1 — stop using free webmail as the brand
coolplumberguy84@gmail.com is fine for texting your cousin. On an invoice, a quote, or a password reset it reads as temporary — and increasingly it’s a deliverability problem too, because you cannot authenticate a domain you don’t control.
What you need:
- A domain you own, at a registrar you control
- Mailboxes on that domain —
hello@,yourname@ - The discipline to send business mail from it, always
Same ownership principle as not renting your whole audience from Instagram and not leasing your website forever without a plan. The address is infrastructure, not decoration.
What mailboxes actually cost
The two mainstream options land within pennies of each other at the entry tier, both listed on annual billing:
| Plan | Per user / month | Notes |
|---|---|---|
| Google Workspace Business Starter | $7.00 | Custom domain email; new customers currently see a promotional rate for the first three months |
| Microsoft 365 Business Basic | $7.00 | Custom domain email, 100 GB mailbox plus 50 GB archive |
For a two-person shop, that’s $168 a year to stop looking temporary and to gain a domain you can authenticate. Compare that to the value of one job you lost because a quote went to spam, and the debate ends.
Pick on ecosystem rather than deliverability — both authenticate properly when configured. If your business already lives in Excel and Teams, take Microsoft. If it lives in Docs and Meet, take Google. Don’t overthink it; the DNS work below matters far more than the logo on the login page.
Step 2 — the three records, in plain English
When your domain sends mail, the receiving server asks one question: is this sender actually allowed to send as this domain? Three DNS records answer it.
SPF — who is allowed to send
A published list of servers permitted to send for your domain. Your mailbox provider goes in it. So does your newsletter tool, your booking system, your invoicing app — anything that sends “as you.”
The trap nobody warns you about: SPF has a hard limit of 10 DNS lookups, and each include: can consume one or more. Add a mail host, a newsletter tool, a CRM, an invoicing app and a booking system, and you can quietly exceed it — at which point SPF returns a permanent error and everything you send starts failing. If you’ve accumulated more than a few includes, check your lookup count with an SPF validator before adding another.
DKIM — cryptographic proof it’s really you
A signature tied to a key published in your DNS. It proves the message came from your domain and wasn’t altered in transit. Your provider generates the key; you publish it. Enable it for every tool that sends on your behalf, not just the main mailbox.
DMARC — what happens when the first two fail
A policy record telling receivers how to treat mail that fails authentication, plus an address for reports.
| Policy | What it tells receivers | When to use it |
|---|---|---|
p=none | Do nothing, just report | Where you start — monitoring only |
p=quarantine | Send failures to spam | Once you know every legitimate sender |
p=reject | Refuse failures outright | The destination, once alignment is clean |
Microsoft’s own guidance is to move through those gradually, so you discover a forgotten sender in a report rather than in a customer’s missing invoice.
One detail that saves enormous confusion: DMARC passes if SPF or DKIM passes and aligns. It fails only when both fail. You don’t need perfection on both paths — you need at least one authenticated, aligned path for every system that sends as you.
What the records actually look like
For anyone who has to paste these into a DNS panel and wants to recognize what they’re looking at:
SPF — one TXT record on the root domain, and only ever one:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Everything authorized goes in that single record. A second SPF record doesn’t add to the first — it invalidates both. ~all means soft-fail; -all is a hard fail and is where you land once you’re confident the list is complete.
DMARC — a TXT record on the _dmarc subdomain:
v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.com; pct=100
rua is where aggregate reports go. Point it at a mailbox you’ll actually open, or a reporting service.
DKIM — generated by your provider, published at a selector hostname they specify, such as google._domainkey. You copy their value; you don’t invent it.
If your DNS panel and your mail provider’s setup wizard disagree about what to paste, trust the provider’s wizard and re-run their verification until it reports pass.
Step 3 — inventory everything that sends as your business
This is the step people skip, and it decides whether any of the above actually works.
Write down every system that puts your domain in a From: address:
- Mailbox provider (Google Workspace, Microsoft 365)
- Website form notifications
- Newsletter or marketing tool
- Booking or scheduling system
- Invoicing and accounting software
- CRM or helpdesk
- E-commerce order confirmations
Each one needs authentication. Each unauthenticated one is a way for your domain to look forged.
While you’re there, check how your website form sets its From: header. Many plugins default to the visitor’s address, which fails authentication by construction — the single most common cause of “the form works but the notification vanished.” Full explanation in why your contact form is silently losing leads; the fix is one settings change.
The same applies to automated messages like appointment reminders — a reminder that lands in spam is worse than no reminder, because you’ve stopped expecting to make the call.
Step 4 — write like a person, not a malware sample
Authentication gets you delivered. Content decides whether you stay delivered, because complaint rate is now a published threshold: over 0.3% on Gmail and you have a real problem.
What filters and humans both flinch at:
- ALL-CAPS subject lines and free-money energy
- Link shorteners hiding the destination
- “Dear customer,” with no context about who you are
- Unexpected attachments from an unfamiliar domain
- Mismatched identity — domain A, logo B, reply-to C
For transactional mail — quotes, confirmations, invoices — plain and specific wins: what this is, what it concerns, what happens next, one clear action.
Step 5 — don’t blast strangers from a new domain
A new domain that abruptly sends 5,000 cold emails is telling a story, and the story is “spam.” Domain reputation is built from consistent, engaged sending over time.
For normal small-business use — replies, quotes, invoices, an opt-in newsletter — stay in that lane: permission-based lists, steady volume, real engagement. It’s also the most reliable way to keep complaints under the threshold, because people who asked to hear from you don’t hit the spam button.
If you genuinely need cold outreach at volume, that’s a different sport: separate domain, separate warming, separate risk. Don’t run it through the domain your invoices depend on.
Two things that quietly break a working setup
Forwarding. When mail is auto-forwarded — an employee sending business mail to personal Gmail, or a mailing list relaying it — SPF breaks, because the forwarding server isn’t in your record. ARC exists to preserve the original authentication result across that hop, but not every system honors it. If people forward business mail to personal accounts because the business mailbox is awkward on their phone, fix the awkwardness. Workarounds become shadow IT, and shadow IT breaks your authentication story in ways nobody reports.
Staff turnover. The departed employee’s mailbox becomes a forward, the forward breaks, and quotes bounce for months before anyone notices. When someone leaves, decide explicitly what happens to their address and who watches it.
The setup checklist
- ☐ Domain registered at a registrar you control
- ☐ Business mailbox live on that domain
- ☐ SPF published, including every sending system
- ☐ SPF lookup count verified under 10
- ☐ DKIM enabled and published for every sending tool
- ☐ DMARC published, starting at
p=nonewith a reports address - ☐ Reports actually reviewed for two weeks
- ☐ Policy raised to
p=quarantine, thenp=reject - ☐ Website form sends from your domain, Reply-To the visitor
- ☐ Newsletter and booking tools authenticated
- ☐ Test sends to Gmail and Outlook, Inbox vs Junk checked
- ☐ Signature with a real phone number and site link
How to test without guessing
- Send to a personal Gmail and a personal Outlook account. Between them they cover most consumer inboxes and enforce the strictest published rules.
- Open the message headers and look for
spf=pass,dkim=pass,dmarc=pass. That’s ground truth — not whether it arrived in your own inbox, which proves nothing. - Run your provider’s authentication wizard until every domain reports pass.
- After DNS changes, wait for propagation — up to a day — then retest instead of assuming.
- Recheck after adding any new tool. Adding a sending system without updating DNS is how a working setup breaks months later.
Put a quarterly reminder in the calendar. Deliverability isn’t a project you finish; it’s a state you maintain while the rules move underneath you.
Reading a DMARC report without a degree
Publishing p=none with a reports address means aggregate reports start arriving — XML files, daily, from every major mailbox provider. They look like machine output because they are.
You don’t need to parse them by hand. Paste one into any free DMARC report viewer, or use a reporting service, and read for exactly three things:
- Sources you recognize that are failing. Your invoicing tool showing
dkim=failmeans it’s not properly configured. That’s your to-do list, and it’s usually a checkbox in that tool’s settings. - Sources you don’t recognize at all. Sometimes this is a forgotten system from three years ago. Occasionally it’s someone spoofing your domain, which is exactly what DMARC exists to surface.
- The share of mail passing. When effectively all of your legitimate mail is authenticating, you’re safe to move to
p=quarantine, thenp=reject.
Two weeks of reports is usually enough for a small business to see the full picture, because your sending patterns are simple. Don’t sit at p=none for a year — a monitoring-only policy protects nobody. It’s a diagnostic step, not a destination.
If you’re already landing in spam
Remediation is different from setup. Work in this order:
- Fix authentication first. Everything below is wasted effort while SPF, DKIM and DMARC are failing. Confirm with real headers.
- Check whether you’re on a blocklist. Several public lookup tools check your domain and sending IP at once. If you’re on one, each list has its own delisting process — follow it rather than resending harder.
- Sign up for the free postmaster tools from the major providers. They show your domain’s reputation and spam complaint rate directly rather than by inference.
- Cut volume back to real correspondence for a few weeks. Replies, quotes, invoices. Engaged mail rebuilds reputation; broadcast mail while damaged reinforces it.
- Ask a handful of customers to mark your message “not spam” and, better, to reply. Replies are the strongest positive signal a mailbox provider gets.
- If your host’s shared IP is the problem, move transactional sending to a dedicated provider. You can’t fix the reputation of an IP address shared with strangers.
Expect this to take weeks, not hours. Reputation is slow to lose and slower to rebuild, which is the strongest argument for setting it up correctly before you need it.
What I’m not saying
You don’t need an IT department. For a small shop this is an afternoon of correct setup plus a quarterly check — not a lifestyle, not a consultant on retainer.
What I am saying: an unprofessional address plus broken authentication is a tax on every quote you send, and unlike most taxes you can’t see this one. The invoice that never arrived doesn’t bounce back with an apology. The customer simply concludes you never followed up, and hires the person who did.
If you’d rather have domain mail, DNS authentication and form notifications set up correctly so leads and invoices stop disappearing, that’s the kind of unglamorous infrastructure we do. Boring when it works. Expensive when it doesn’t.
Sources
- Google Workspace Admin Help — Email sender guidelines (all-sender and bulk-sender requirements, 0.3% spam rate, effective February 2024) — https://support.google.com/a/answer/81126 (accessed 2026-08-05)
- Microsoft Tech Community — Strengthening the email ecosystem: Outlook’s new requirements for high-volume senders — https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730 (accessed 2026-08-05)
- Microsoft Support — Fix NDR error 550 5.7.515 in Outlook.com — https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com (accessed 2026-08-05)
- Microsoft Learn — Set up DMARC to validate email in Microsoft 365 (policy ramp: none → quarantine → reject) — https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure (accessed 2026-08-05)
- Google Workspace — Pricing (Business Starter list price) — https://workspace.google.com/pricing (accessed 2026-08-05)
- Microsoft — Compare Microsoft 365 Business plans (Business Basic pricing and mailbox size) — https://www.microsoft.com/en-us/microsoft-365/business/compare-all-microsoft-365-business-products (accessed 2026-08-05)
- RFC 7208 — Sender Policy Framework, including the 10 DNS lookup limit — https://www.rfc-editor.org/rfc/rfc7208 (accessed 2026-08-05)
- RFC 7489 — DMARC, including identifier alignment and policy semantics — https://www.rfc-editor.org/rfc/rfc7489 (accessed 2026-08-05)