Email deliverability for Gmail and Outlook (what each one rewards)

Gmail and Microsoft do not measure the same object. Google rates your sending domain and publishes that rating back to you. Microsoft rates the sending IP and publishes that rating to whoever owns the IP — which, if you send through Google Workspace or Microsoft 365, is not you. That single asymmetry explains most cases of clean on Gmail, filtered on Outlook. What the two reward is a similar short list: authentication, alignment, low complaint rates and a plausible volume curve. What each one shows you when it goes wrong is completely different.

Google rates a domain, Microsoft rates an IP, and that decides what you can fix

Open Google Postmaster Tools and you get two separate reputation dashboards. Google's own definitions: IP reputation is "the quality rating for the IP addresses you use to send email", and Domain reputation is "the quality rating for the domains you use to send email". Two ratings, computed independently, displayed side by side.

Now notice which of them a cold-outreach sender can actually move. If your mail leaves through Google Workspace, the connecting IPs belong to Google and are shared with every other Workspace tenant. If it leaves through Microsoft 365, they belong to Microsoft. If it leaves through a shared ESP pool, they belong to the ESP. In all three cases, the domain rating is the one that reflects your behaviour and the IP rating is mostly a statement about your provider's other customers.

Microsoft's instrument is keyed the other way round. Smart Network Data Services, the free Outlook.com sender dashboard, organises its data around IP addresses, IP ranges and autonomous system numbers, and registration asks you to prove control of the IP space. That design assumption — the sender owns the IPs — was true of the bulk mailers it was built for and is false for almost every small outbound team today.

So the practical position is asymmetric in a way nobody says out loud. Against Gmail, you have a published, per-domain rating with defined bands. Against Outlook, unless you run your own IPs, you have the bounce text and whatever your own inbox-placement testing tells you. Plan your diagnosis around that gap rather than being surprised by it.

What Gmail publishes that it measures, dashboard by dashboard

Postmaster Tools is the only place either provider tells you, in their own words, what they are scoring. The dashboards and Google's definitions:

• Spam rate — "The percent of your messages that recipients manually mark as spam in Gmail."
• IP reputation — "The quality rating for the IP addresses you use to send email."
• Domain reputation — "The quality rating for the domains you use to send email."
• Feedback loop — "Email campaign messages that recipients have marked as spam."
• Authentication — "The percent of your email that passes SPF, DKIM, and DMARC authentication."
• Encryption — "The percent of your email that's sent over an encrypted SSL or TLS connection."
• Delivery errors — "The percent of all authenticated messages (SPF or DKIM) that were rejected or that temporarily failed."
• Compliance status — "Your compliance with the email sender requirements described in our Email sender guidelines."

The reputation bands are defined too, and the wording matters because the gap between two adjacent bands is not linear. High is "History of very low spam rates, and complies with Gmail's sender guidelines. Email is rarely marked as spam." Medium is "History of sending legitimate email, but occasionally sends spam. Most email has a fair deliverability rate." Low is "History of sending a significant volume of spam regularly. Email from this domain or address is likely to be marked as spam." Bad is "History of sending a high volume of spam regularly. Email from this domain or address is almost always marked as spam or rejected."

Read Medium as the warning, not the average. A domain sitting at Medium is one that Google has already observed sending spam, and the recovery from Medium is a great deal cheaper than the recovery from Low.

The number to hold yourself to is published: Google's sender guidelines tell you to keep the Postmaster Tools spam rate below 0.30%, and as a guideline below 0.10%. Both figures are percentages of messages manually marked as spam by Gmail users, over Gmail traffic only.

There is one catch that bites small cold programmes hard. Google states that Postmaster Tools data "might be missing if the total number of messages for a given day is too low", withheld to protect user privacy, and publishes no threshold for what counts as too low. A team sending a few hundred a day frequently sees empty charts. The dashboard is most informative exactly when you least need it, which is why inbox-placement seed testing is not optional at low volume.

What Microsoft publishes, and why SNDS is useless to most cold senders

Microsoft's two free sender programmes are Smart Network Data Services and the Junk Mail Reporting Program. SNDS shows volume, complaint rates and trap hits for IP ranges you have registered. JMRP is a feedback loop: when an Outlook.com user marks your mail as junk, Microsoft forwards you a copy including headers, so you can suppress that recipient.

Both are genuinely useful. Both are keyed on infrastructure you probably do not own. If you connect through Microsoft 365's own SMTP submission or through Google Workspace, the outbound IPs are the provider's, and there is no range for you to register. JMRP has the same constraint, because enrolment is per IP range.

That leaves three instruments for the Microsoft half of your programme, and it is worth being blunt that they are weaker than the Gmail half:

1. The non-delivery report text. Microsoft is unusually specific in its bounce strings, and the enhanced status code names the rule you broke. This is the highest-information signal available to a small sender.
2. Inbox-placement seed tests. Mailing monitored Outlook mailboxes and recording which folder each probe reaches. Slow, sampled, and the only direct evidence of placement you can generate yourself.
3. The Microsoft sender support form, for requesting mitigation once you have fixed the underlying cause. It is a remediation channel, not a monitoring one.

The 5,000-a-day rule is two different rules with the same number

Both providers drew a line at roughly 5,000 messages a day. The lines mean different things and almost every summary collapses them.

Google. Since 1 February 2024, a sender transmitting close to 5,000 messages or more to personal Gmail accounts within 24 hours, counted across the same primary domain, must authenticate with both SPF and DKIM, publish a DMARC record — a policy of p=none satisfies the requirement — align the visible From domain with either the SPF or the DKIM domain, and support one-click unsubscribe on marketing and subscribed mail. Below that volume Google asks for SPF or DKIM and does not require DMARC. Google has also stated that from November 2025 it began ramping enforcement on non-compliant traffic, including temporary and permanent rejections.

Microsoft. Announced 2 April 2025 and enforced from 5 May 2025, domains sending more than 5,000 messages a day to outlook.com, hotmail.com and live.com must pass SPF, DKIM and DMARC. Non-compliant mail is rejected with 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Here is the part that changes what you should do. Microsoft's rule covers consumer mailboxes. A prospect at a company running its own Microsoft 365 tenant is not covered by it — their mail is filtered by Exchange Online under Microsoft's ordinary filtering and their own tenant policy. Most business-to-business cold email goes to tenant domains. So if your Outlook placement is poor, the high-volume rule is very likely not the cause, and chasing it will waste a week. The Microsoft 365 and Outlook sending integration and the Gmail and Google Workspace integration sit on opposite sides of exactly this split.

The five rejections you will actually read, and how to tell them apart

These are the strings that decide your next action. The shared 5.7 prefix is the reason they get confused, and the owner of the fix is different for every one.

• 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Microsoft's consumer high-volume rule. Fix: publish and align SPF, DKIM and DMARC on the sending domain.
• 550 5.7.509 Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject Exchange Online enforcing a policy you published, at any volume. Fix: the alignment failure on your own sending path — usually a Return-Path that belongs to your platform rather than to you.
• 550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Gmail's version of the same enforcement. Same cause, same fix, different wording.
• 550 5.7.1 ... Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. ... - gsmtp Content and reputation, not authentication and not a bad address. Fix: volume, list quality and complaint rate. The recipient is innocent, and suppressing them is the wrong response.
• 550 5.1.1 The email account that you tried to reach does not exist. - gsmtp A genuinely dead mailbox. Fix: suppress the address permanently.

The first four are sender-side problems that a suppression list cannot solve. Only the last one is about the recipient. Getting that separation right is the whole subject of how a bounce should actually be classified.

Why Exchange Online rejects your mail at ten messages a day

The rule that catches small senders is not the high-volume one. Microsoft changed the tenant defaults so Exchange Online honours the sender's published DMARC policy: mail arriving for a Microsoft 365 tenant that fails DMARC against a domain publishing p=reject is rejected with 550 5.7.509, and against p=quarantine it goes to junk.

The irony is sharp. Publishing p=reject to stop other people spoofing your brand also arms every Microsoft tenant against your own misconfigured sending path. A new sending tool whose Return-Path is its own domain, with no DKIM key published on yours, produces spf=pass for the platform and dmarc=fail for you, and Microsoft acts on it before a human sees the message. That is an alignment failure rather than an authentication failure, and the distinction is the single most misdiagnosed thing in this subject — what DMARC alignment actually compares is worth reading before you touch a DNS record.

A routine that separates a Gmail problem from an Outlook problem

Do this in order. It costs about twenty minutes and it stops you rewriting subject lines to fix a DNS record.

1. Segment your reporting by recipient provider first. One placement number across all providers hides the failure. Split Gmail, Microsoft consumer, Microsoft tenant and everything else.
2. Read one real bounce from each side. The enhanced status code names the rule. Do not infer the cause from the volume of bounces; read the text of one.
3. Send yourself a message at each provider and read Authentication-Results. You want spf=pass, dkim=pass, dmarc=pass, with header.from showing your own domain. A dmarc=fail alongside spf=pass is alignment. Reading your own authentication records end to end covers what each field means,, and pasting the retrieved TXT value into the SPF and DMARC record checker reports the policy strength and the DNS-lookup count without a terminal. That tool parses the record text you give it; it does not perform the lookup for you, so fetch the record first.
4. Check Postmaster Tools for the Gmail half only. If the charts are empty, you are below Google's reporting volume; that is not a fault.
5. Run a seed test for the Microsoft half. With no SNDS access, this is the measurement. Placement, not acceptance.
6. Only then look at content. Copy is the last variable to change, because every step above can move placement more than any sentence you write.

Autocloz's free plan covers 5 users and 10 mailboxes with on-demand placement probes to seed mailboxes you register yourself at Gmail, Outlook and Yahoo — you trigger a run, nothing schedules one for you — plus SPF, DKIM and DMARC monitoring on each connected domain — start free if the Microsoft half of your programme is currently unmeasured.

What neither provider tells you, and what Autocloz does not do here

Being precise about the limits is more useful than another paragraph of reassurance.

Neither Google nor Microsoft publishes the weighting inside its classifier, and nobody outside those companies can tell you how much any single signal is worth. Every number in this post is one the provider published; anything more granular that you read elsewhere is inference presented as fact.

Postmaster Tools reports on Gmail traffic only, and only above an unpublished daily volume. It says nothing about Outlook, Yahoo or corporate filters, and domain reputation as a concept is not portable between providers even though the phrase is.

Autocloz does not run inside Google's or Microsoft's classifiers, because nobody does. It monitors SPF, DKIM and DMARC on every connected domain, flags a record that breaks after you publish it, runs seed tests to measure folder placement, and paces sending per mailbox — all of which measure outcomes and inputs rather than reasoning. It does not have an SNDS feed for IPs it does not own, it cannot see your Postmaster Tools account, and it does not sell contact data, so the list quality that drives your complaint rate remains yours. And no configuration of any of it makes placement certain; what it removes are the failure modes that are documented, measurable and inside your control.