Why does email between Microsoft 365 and Google Workspace go to spam?

Usually a mismatch between what the domain publishes and what actually sends. Hybrid and split-domain setups route mail out through one path and back through another, and connectors, on-premise relays and application servers frequently send as the domain without being covered by SPF or signed by DKIM. Each is invisible until a receiving side decides to enforce.

How do I find out why mail to one specific company bounces?

Read the rejection. A 5xx from their gateway usually names the reason, and the common ones are a TLS problem, a DMARC policy you are failing on that path only, or your address on a blocklist their filter subscribes to. Where the rejection is unhelpful, the sending path and the receiving side's published policy have to be compared by hand.

What is MTA-STS and do I need it?

MTA-STS tells other mail servers that they must use TLS when delivering to you, and refuse to deliver if they cannot. It closes a downgrade attack that is otherwise invisible. You need it if you exchange business correspondence that matters; you need it published correctly, because a policy that senders cannot fetch is worse than no policy at all.

Does the audit check inbound mail as well as outbound?

Yes, and for internal correspondence the inbound path usually matters more. MTA-STS, DANE, TLS-RPT, certificate validity and the MX configuration all decide how other companies' mail servers treat you, and none of them appear in the outbound checks most tools run.

Mail between your own offices is going missing

Business correspondence has the strictest requirements and the least attention. It is also the case where the inbound path matters as much as the outbound one, because you are being judged by the mail servers of companies you actually work with.

What this usually looks like

Mail between Microsoft 365 and Google Workspace landing in spam
Messages to a specific partner or customer bouncing, everyone else fine
Mail from an application server or a scanner never arriving
Transport encryption failing without anyone noticing

What the audit checks for this

Every audit covers the same ground. These are the parts that decide this one.

The inbound path as well as the outbound: MTA-STS, DANE, TLS-RPT, and whether your published policy is one a sender can actually fetch
Connector and relay configuration, including anything sending on behalf of the domain from inside the network
Split-domain and hybrid routing, where mail leaves by one path and returns by another
Certificate expiry and chain problems on the mail host, which fail silently and only for senders who check
Whether devices and applications relay through something that authenticates, or spoof the domain from outside it

What this will not do

It will not reconfigure your tenant for you; the report says what to change and where.
It will not resolve a dispute with another company's mail administrator, though it usually gives you the evidence to have that conversation.

Proving transport security instead of assuming it

Business correspondence is where transport encryption stops being a nicety. These are the records that let another company's mail server refuse to deliver to you in the clear, and you can read this domain's.

```
$ dig +short TLSA _25._tcp.mail.cyborg.ovh
```
```
2 1 1 6EBCEFB4210B088654A38B03FEA3D7D1C711B4FB1DDC363A...
```
DANE. The certificate a sender should expect, published in DNS, so a substituted certificate is detected rather than trusted.
```
$ dig +short DS strictmx.com | head -1
```
```
44746 8 2 CDB41DD97555A2AE954F67EC4EFF4DAE62A639D6...
```
DANE is worthless without DNSSEC — an attacker who can forge the DNS answer can forge the TLSA record too. The two are one control.
```
$ dig +short TXT _mta-sts.sslcanary.com
```
```
"v=STSv1; id=2020589072646294683"
```
MTA-STS, the other half. This record only announces that a policy exists and gives it an id; the policy itself lives somewhere else entirely, which is where this usually goes wrong.
```
$ curl -s https://mta-sts.sslcanary.com/.well-known/mta-sts.txt
```
```
version: STSv1
mode: testing
max_age: 604800
mx: mail.cyborg.ovh
```
The policy itself, fetched over HTTPS from a subdomain, exactly as a sending mail server would fetch it. mode: testing means failures are reported and not enforced — the right place to start, and a place a lot of domains never leave.

Four commands, four answers, and the last one is the one that catches people. A domain can publish the DNS record and serve nothing at the policy URL — most often because the certificate on the web server does not cover the mta-sts subdomain, which nothing else on the domain depends on and nobody looks at. Senders who have never cached a policy then proceed without one; senders who have keep using a stale copy until it expires; and if that copy said enforce, mail starts failing on a schedule nobody set. I check that the policy is fetchable, not that the record exists. Those are different questions and only one of them is usually asked.

Questions people ask about this

Why does email between Microsoft 365 and Google Workspace go to spam?: Usually a mismatch between what the domain publishes and what actually sends. Hybrid and split-domain setups route mail out through one path and back through another, and connectors, on-premise relays and application servers frequently send as the domain without being covered by SPF or signed by DKIM. Each is invisible until a receiving side decides to enforce.
How do I find out why mail to one specific company bounces?: Read the rejection. A 5xx from their gateway usually names the reason, and the common ones are a TLS problem, a DMARC policy you are failing on that path only, or your address on a blocklist their filter subscribes to. Where the rejection is unhelpful, the sending path and the receiving side's published policy have to be compared by hand.
What is MTA-STS and do I need it?: MTA-STS tells other mail servers that they must use TLS when delivering to you, and refuse to deliver if they cannot. It closes a downgrade attack that is otherwise invisible. You need it if you exchange business correspondence that matters; you need it published correctly, because a policy that senders cannot fetch is worse than no policy at all.
Does the audit check inbound mail as well as outbound?: Yes, and for internal correspondence the inbound path usually matters more. MTA-STS, DANE, TLS-RPT, certificate validity and the MX configuration all decide how other companies' mail servers treat you, and none of them appear in the outbound checks most tools run.

Where this comes from

Everything above is checkable against the specifications that define it. These are the documents, not a summary of them.

RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)
RFC 8460 SMTP TLS Reporting
RFC 7672 SMTP Security via Opportunistic DANE TLS
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Written by Philippe Namias, who runs the audit. Last reviewed August 2026.

Book the audit — €179

One domain, one report, by email within 48 hours of your intake. No account, no call.

Not sure it covers your setup? Ask before you buy: audit@strictmx.com