All guides

Why are my business emails going to spam? (Google Workspace and Microsoft 365)

Last reviewed 2026-10-22 · Based on the official references linked below

Has a client told you your email landed in spam? Or are clients not getting your emails at all? Start with one affected message. Missing or incorrect email authentication is one common cause, but it is not the only one.

Gmail and Outlook also consider the message, your sending reputation and the recipient's filters. Fixing SPF, DKIM and DMARC helps receiving systems recognize your mail; it does not guarantee inbox placement. Google explains why authentication alone is not enough.

1. Find out what happened to the message

Ask one affected customer to check Spam, Junk and, if they have an IT team, quarantine. Confirm the address you sent to. Save the date, subject, sending service and any bounce message, including its error code.

• In spam or junk: the receiving system accepted the message but filtered it. Its headers can help explain why.
• Bounced: read the delivery error before changing settings. An invalid address, a blocked sending IP or an authentication failure needs a different fix.
• Missing for one customer: ask their IT team to trace that specific message and check local rules. A problem across several unrelated customers points toward a wider sending issue.

If only invoices are affected, compare an invoice with an ordinary email. They may travel through different services. See why invoices go to customers' spam. Microsoft's delivery troubleshooting guide covers bounce errors and messages incorrectly marked as junk.

2. Check SPF, DKIM and DMARC

These are the settings Gmail and Outlook check to help establish who sent a message. You need access to your domain's DNS settings and an authorized Google or Microsoft administrator to fix them. Save the current records before editing anything.

1. Check a received message. Send a fresh email from your business account to an external Gmail account you can inspect. In Gmail on a computer, open the message, then the three-dot More menu next to Reply → Show original. Look for spf=pass, dkim=pass and dmarc=pass in the receiving system's Authentication-Results. Use the same check on an affected message when available. Google's header instructions show where to look.
2. Review SPF at your DNS host. Find the TXT record beginning v=spf1 for your sending domain. Have one SPF record, covering the services that actually send using that domain for their return-path. Do not create a second SPF record or replace the existing one with an example that omits your other senders.
3. Check DKIM signing. A DNS key alone does not prove your mail is signed. Check the received message for a passing signature and the signing domain (d=). The selector (s=) identifies its DNS key at selector._domainkey.signing-domain. Use your provider's generated records and confirm signing is enabled below.
4. Review DMARC. Look for a TXT record at _dmarc.yourdomain.com, replacing yourdomain.com with your sending domain. It begins v=DMARC1. DMARC needs a passing SPF or DKIM check that also matches your visible From domain under its alignment rules. A pass for an unrelated service domain is not enough.

For Google-only sending, SPF normally includes include:_spf.google.com. For commercial worldwide Microsoft 365, it normally includes include:spf.protection.outlook.com. Extra senders need a review of the whole record. SPF allows ten DNS lookups during evaluation, including nested lookups; counting visible includes is insufficient. References: Google SPF setup and Microsoft SPF setup.

If you have no DMARC policy, start with monitoring and a working report destination while you verify all legitimate senders. p=none does not turn failures into passes or ask receivers to block them. Preserve an existing working policy while investigating. Google's DMARC reference explains alignment and policies; our monitoring guide explains the next steps.

3. Turn on DKIM in Google Workspace

1. As a super administrator, open Google Admin → Apps → Google Workspace → Gmail → Authenticate email. Select your business domain and check its current status.
2. If no working key exists, select Generate New Record. Choose 2048 bits if your DNS host supports it. Copy the generated TXT record name and full value to your DNS host. Keep an existing working key.
3. After publishing the record, return to the same screen and select Start authentication. Confirm the status says Authenticating email with DKIM, then test another external message.

Newly activated Gmail may need 24–72 hours before a key can be generated; DNS updates can take up to 48 hours. Reference: Google's DKIM instructions. Our Google Workspace setup guide covers the full process.

4. Turn on DKIM in Microsoft 365

1. As an authorized administrator, open Microsoft Defender → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select your custom business domain.
2. If it shows NoDKIMKeys, try the enable toggle. Microsoft's documented flow displays a Client error containing DNS instructions, then CnameMissing. Open the domain details and copy both targets under Publish CNAMEs.
3. At your DNS host, publish the two CNAMEs for selector1._domainkey and selector2._domainkey. Copy the actual targets from Defender; do not guess them from an example.
4. Once Microsoft detects the records, enable Sign messages for this domain with DKIM signatures. Confirm signing is enabled and test a fresh message to an external recipient.

Reference: Microsoft's DKIM instructions. Our Microsoft 365 setup guide covers the full process.

5. What if authentication passes but emails still go to spam?

A passing message narrows the investigation. It does not prove every message or sending tool is configured correctly. Test each route separately, including invoices and website forms.

• Content and links: compare a simple, recognizable message with your usual template. Remove unnecessary attachments, shortened links and image-only content, then retest. Change one thing at a time.
• New domains and reputation: a new or little-used domain may have limited sending history. Send expected messages at a steady pace; avoid sudden bursts or repeatedly resending missing mail.
• Blocklists or shared sending IPs: use the bounce or recipient's filtering details to identify the sending IP. Your email provider can investigate its infrastructure and reputation.
• Recipient filters: ask the customer to mark a legitimate message as Not spam or Not junk. For recurring problems, their IT team can review quarantine and filtering rules for the actual message.

References: Microsoft's filtering FAQ covers content, reputation and recipient policies. Google's sender guidelines cover shared IP reputation and blocklists. Google's extra bulk-sender requirements apply around 5,000 or more messages a day to personal Gmail accounts; an ordinary small business should not assume every bulk rule applies to its everyday mail.