How to fix Gsuite sender reputation issues when business emails are sent to quarantine in Outlook?
Updated on 23 Jul 2026: We added a Microsoft false-positive submission workflow and tightened the authentication and recovery guidance.
Fix Google Workspace sender reputation issues with Outlook quarantine by proving the exact sending path first, then fixing authentication, then rebuilding recent reputation with clean one-to-one mail. Treat this as a Microsoft filtering verdict on a Google Workspace sender, not as an Outlook app problem.
The fast path is straightforward: confirm whether the messages are typed in Gmail or sent through another app, make DKIM pass for the visible From domain, keep SPF valid and under lookup limits, publish DMARC with reporting, pause bulk sends, and test real messages to Microsoft 365 recipients until quarantine stops.
If proper DKIM was added only after the problem started, authentication can begin passing after the DNS record propagates and signing is active, but Microsoft reputation does not reset instantly. Microsoft publishes no guaranteed recovery clock. Retest clean person-to-person mail over several days, and if authenticated messages remain quarantined, ask a recipient admin to submit a false positive with the original headers.
Immediate fix order
- Path: Find out whether Gmail, a CRM, an SMTP relay, or a bulk tool sent the message.
- Auth: Make SPF, DKIM, and DMARC pass for the domain users see in the From address.
- Evidence: Get message headers and the Microsoft 365 quarantine reason before changing content.
- Recovery: Send only wanted business mail while Microsoft learns the fixed identity again.
Confirm the sending path before changing DNS
G Suite is now Google Workspace, but the failure pattern is the same: a business user sends mail, a Microsoft recipient sees it in quarantine, and everyone assumes the Google account has a reputation problem. Sometimes that is true. Often the real problem is that the message did not come directly from Gmail, or it used a third-party sender that never had DKIM and DMARC set up for the same domain.
Split the investigation into two paths because the fix changes completely when a tool is involved. A typed Gmail message should authenticate through Google. A CRM, mail merge app, helpdesk, or bulk platform needs its own DKIM, return-path, and DMARC domain-match checks.
Gmail or Google Workspace
- Route: The user composes in Gmail or an official Google client.
- DKIM: The signature should use the sender's domain, not only a Google domain.
- SPF: The sending IP should be covered by Google's include.
- Fix: Enable Google DKIM, keep SPF clean, and monitor DMARC reports.
CRM, mail merge, or bulk tool
- Route: The user still appears as the sender, but another system transmits.
- DKIM: The tool needs a domain-matching signature of its own.
- SPF: The envelope domain can differ, so SPF alone is not enough.
- Fix: Authenticate the tool or stop using it until business mail recovers.
A Microsoft quarantine detail screen is useful because it shows whether the message was caught for spoofing, bulk signals, malware policy, phishing verdicts, or spam confidence. Without that detail, DNS changes become guesswork.
Microsoft Defender for Office 365 quarantine details for a Google Workspace email.
Read the headers and quarantine verdict
Ask a Microsoft 365 recipient admin for the original headers, message trace, and quarantine details. A screenshot that says "quarantined" is not enough. Collect the authentication results, spam confidence level, bulk complaint level, phishing verdict, composite authentication result, and any spoof intelligence reason.
Useful header lines to inspecttext
Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass action=none header.from=example.com; compauth=pass reason=100 X-Forefront-Antispam-Report: SCL:5; BCL:0; PCL:0; X-MS-Exchange-Organization-AuthAs: Anonymous
|
|
|
|---|---|---|
DKIM fail | Signature did not validate | Check selector, key, and message changes |
DMARC fail | No passing method matched From | Fix SPF or DKIM domain match |
SCL high | Microsoft assigned a spam verdict | Review policy, content, and URLs |
BCL high | Message looks like bulk mail | Pause bulk sends and check consent |
Spoof or compauth fail | Microsoft distrusts the claimed identity | Read the reason code and fix identity |
Compact map of Microsoft-side signals to next actions.
For a deeper Microsoft 365 quarantine workflow, compare the evidence against Outlook quarantine fixes. If the affected recipients use consumer Outlook.com rather than Microsoft 365 tenants, Microsoft sender support is the relevant escalation path.
Fix Google Workspace authentication
If DKIM was missing, start there. Google Workspace can sign mail with a domain key that matches the visible From domain. A valid signature often survives forwarding when the signed content remains unchanged, while SPF can fail after forwarding because the connecting IP changes.
Then review SPF. A Google-only domain normally needs Google's include plus any legitimate third-party senders. Do not publish multiple SPF TXT records at the root. Do not keep old vendors in SPF after they stop sending. SPF evaluation permits no more than 10 DNS lookups, so unnecessary includes can produce a permanent error and make incident response harder.
SPF for Google Workspace onlytext
v=spf1 include:_spf.google.com ~all
Starter DMARC monitoring policytext
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Do not stop at SPF
SPF passes on the envelope sender. DMARC checks whether a passing SPF or DKIM domain matches the visible From domain. For Google Workspace business mail, domain-matching DKIM is often the cleanest signal when messages are forwarded.
- One record: Keep a single SPF TXT record for the domain.
- Domain match: Make DKIM sign with the same domain users see.
- Reports: Use aggregate DMARC data to identify spoofing and unknown senders.
Google's sender guidelines apply to delivery into Gmail, not Microsoft 365. Their baseline checks still help here: authenticate mail, keep DNS valid, control spam complaints, and avoid abrupt sending changes.
If you need a quick outside-in view, run a domain health check and confirm that DMARC, SPF, and DKIM are all visible from public DNS.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Check the reputation signals Microsoft uses
Authentication verifies identity. Reputation affects trust. Microsoft can still quarantine mail after DKIM and DMARC pass if the recent pattern looks risky: sudden volume, poor engagement, repeated sends to stale contacts, misleading subjects, link-heavy signatures, or a compromised account sending unwanted mail.
Check the domain and any dedicated sending IP against blocklist and blacklist sources, but interpret results carefully. Google Workspace often uses shared infrastructure, so a listed shared IP is less actionable than a listed domain, a bad link domain, or authentication failures tied to your domain.
Quarantine recovery priorities
Use the highest-risk active issue to decide what to fix first.
Broken authentication
Fix now
DKIM or DMARC fails on real mail.
Mixed routing
Isolate
Gmail and tools send as the same domain.
Clean business mail
Rebuild
Replies and one-to-one mail pass checks.
For ongoing reputation checks, use blocklist monitoring to catch domain or IP listings before support teams learn about quarantine from customers.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product supports this workflow by bringing DMARC aggregate data, SPF and DKIM checks, blocklist monitoring, alerts, and remediation steps together. Use Suped to map each sending source, confirm that authentication matches the visible From domain, and keep watching for regressions after Microsoft 365 accepts the mail again.
If the domain was spoofed, DMARC monitoring shows which sources participating receivers observed and how those messages authenticated. Aggregate reports are delayed, and not every receiver sends them, so use the data as source evidence rather than a real-time record of every spoofing attempt.
Send controlled tests and rebuild trust
After DNS is corrected, test like a recipient, not like a DNS checker. Send a normal business email from Gmail to a Microsoft 365 mailbox, reply to it, then send the same kind of message through any connected tool. Compare headers and quarantine outcomes. Use an email tester for a separate content and authentication read, then validate the result with a real Microsoft recipient.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Keep the recovery period boring. That means no sales blasts, no recycled lists, no new tracking domain, no URL shorteners, no sudden signature redesign, and no mail merge experiments. The goal is to create a recent pattern of wanted, authenticated, person-to-person mail.
- Baseline: Send one plain Gmail message to a Microsoft 365 mailbox and save the headers.
- Compare: Send one message through each connected app and compare authentication.
- Reduce: Pause bulk and cold outreach until business mail stops hitting quarantine.
- Ask: Request SCL, BCL, compauth, and spoof details from a recipient admin.
- Track: Log test date, sender, route, subject, authentication, and final placement.
Example recovery tracking
Track accepted test mail by day after authentication is fixed. Use this as a target, not a promise.
Accepted
Submit confirmed false positives to Microsoft
Once a direct Gmail test passes SPF, DKIM, and DMARC but Microsoft 365 still quarantines it, ask the recipient tenant's security admin to release the message and submit it to Microsoft as a false positive. This receiver-side step gives Microsoft the exact message and filtering verdict. It does not replace sender-side authentication fixes.
- Preserve evidence: Save the original headers, network message ID, quarantine reason, sender, and recipient.
- Confirm the route: Verify that the submitted message came directly through Google Workspace and passed authentication.
- Submit the message: In Microsoft Defender quarantine, release it and choose the option to send it to Microsoft to improve detection.
- Limit temporary access: If delivery is business-critical, use a temporary similar-attributes allow entry instead of broadly allowing the whole domain.
- Read the verdict: Review the submission result, correct any tenant policy issue it identifies, remove temporary access, and retest.
Do not use a permanent domain allowlist
A broad allowed-domain entry can bypass parts of spam filtering and email authentication checks, which creates spoofing risk. Use a temporary entry only to restore urgent mail while the admin waits for Microsoft's submission verdict.
If one Microsoft 365 tenant quarantines the message while other tenants accept the same authenticated test, inspect that tenant's anti-spam policy, anti-phishing policy, mail flow rules, and impersonation settings. If several unrelated tenants quarantine the same mail, focus on the sender domain, message content, URLs, complaint history, and the Microsoft verdicts.
A practical 10-day recovery plan
A quarantine incident needs a written plan because random changes make it harder to know what worked. Use a short recovery window, document each change, and avoid changing more than one major variable per day unless authentication is clearly broken.
- Day 0: Preserve headers from quarantined messages and identify every sending system.
- Day 1: Publish the Google Workspace DKIM key, activate signing, clean SPF, and publish DMARC reporting.
- Day 2: Stop all tool-sent mail that cannot pass domain-matching DKIM.
- Days 3-5: Send normal business mail, record Microsoft placement, and keep volume stable.
- Days 6-10: Submit authenticated false positives and reintroduce one tool at a time only after direct Gmail mail is stable.
Avoid reputation shortcuts
Do not move staff to a fresh domain, rotate display names, or ask every recipient to allowlist the sender as the main fix. Those moves hide the evidence and create a second reputation problem. Fix the identity, prove clean mail, then escalate with the data if Microsoft still quarantines it.
Views from the trenches
Best practices
Verify the exact sending app before changing DNS because Gmail and a CRM leave different traces.
Keep bulk mail off the business domain until Microsoft accepts normal replies again consistently.
Use DMARC reports to prove whether spoofing or a third-party sender caused the failure.
Common pitfalls
Assuming a 500-contact send is harmless hides weak engagement and sudden volume changes.
Publishing DKIM after the incident fixes authentication, but reputation still needs clean mail.
Treating Outlook quarantine as an Outlook bug misses Microsoft 365 filtering evidence in headers.
Expert tips
Compare one Gmail web message with one tool-sent message to separate domain and app issues.
Ask the recipient admin for SCL, compauth, and spoof details before changing content.
Pause link-heavy signatures during recovery so tests measure the domain, not extra signals.
Expert from Email Geeks says the first check is whether the business mail is truly one-to-one and not a small bulk campaign with weak engagement.
2021-07-08 - Email Geeks
Marketer from Email Geeks says a previous bulk send through a separate app matters because Microsoft can connect domain identity, content, and recent engagement.
2021-07-08 - Email Geeks
The fix for Google Workspace quarantine
Start with the Microsoft verdict, prove the sending route, make Google Workspace DKIM pass, clean SPF, publish DMARC reporting, and stop unauthenticated tool sends until the domain has clean recent traffic.
If the issue started suddenly and proper DKIM was only added after the fact, missing authentication is a credible root cause, but DKIM alone does not guarantee inbox placement. Keep business sending predictable, document every test, and escalate with headers when authentication passes but Microsoft still quarantines the message.
