You write a newsletter, send it to 1,800 addresses, and your sending tool reports 98 per cent delivered. Two days later the report shows eleven opens. The obvious explanation is the copy. The likelier one is email deliverability. Because delivered, in your tool, only means that the receiving server accepted the message. Which folder it ended up in is not part of that number. This piece covers what Google and Microsoft have actually required since 2024 and 2025, why a DMARC record enforces nothing on its own, and what you can repair in a single afternoon.
What does delivered mean, and what does arrived mean?
Three things can happen between your send and someone reading it, and your report only knows about the first.
One: the receiving server refuses the message. That is a bounce, you see it immediately and with an error code. Two: the receiving server accepts the message and files it in the spam folder. Technically that is a successful delivery, your tool counts it as delivered, and nobody tells you anything. Three: the message lands in the inbox. Nobody tells you that either. So the delivery rate only separates the first case from the other two, the inbox placement rate means the third alone, and between those two metrics sits the entire difference between a newsletter that works and one that quietly evaporates.
Anyone looking for a benchmark figure ends up at the annual deliverability report from Validity, a vendor of deliverability software. The report sits behind a form, and the public page names its data basis as "trillions of global inbox data points" and nothing else: no sample size, no description of the seed lists, no definition of the regions. That is why this piece quotes no average inbox placement rate. What is solid instead: the rules the receiving side publishes itself, and your own technical state, which you can measure.
What do Google and Microsoft actually require?
Google tightened its requirements on 1 February 2024. The email sender guidelines say, verbatim: "Starting February 1, 2024, email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section." For those bulk senders the list reads: set up SPF and DKIM, publish DMARC for the sending domain (the enforcement policy may be none), align the From address with the SPF or DKIM domain, use TLS, and give marketing messages one-click unsubscribe plus a visible unsubscribe link in the body.
The threshold is lower than it sounds, and it is a one-way street. In the accompanying FAQ Google defines: "A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period." And further: "Senders who meet the above criteria at least once are permanently considered bulk senders", with the status carrying "no expiration date". A single large send, say at the turn of the year, makes you a bulk sender for good, even if you go back to 300 messages a month afterwards.
Since November 2025 this has teeth. The same FAQ states: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections." Not the spam folder, rejection.
Microsoft followed on 5 May 2025, for outlook.com, hotmail.com and live.com, and likewise from 5,000 messages a day: SPF, DKIM and DMARC are mandatory, DMARC at least at p=none and aligned with SPF or DKIM. Non-compliant mail first goes to the junk folder, after that it is rejected, with the message "550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level".
And below 5,000? Google still applies a shorter list to every sender: SPF or DKIM at minimum, a valid reverse DNS record for the sending IP, TLS, correctly formatted headers and a complaint rate below 0.30 per cent. Authentication has stopped being an advantage you earn. It is a condition you either meet or fail.
Why does a DMARC record enforce nothing?
DMARC is a short text record in your domain's DNS that settles two things: what a receiver should do with messages that claim to come from your domain but fail the checks, and where it should send the reports about them. Three levels exist. p=none means do nothing, just report. p=quarantine means put it in the spam folder. p=reject means do not accept it at all.
The Google and Microsoft requirements are already satisfied by p=none. Nobody is protected by it. To see how wide that gap runs, we measured it: on 15 August 2026 we queried the _dmarc records of the main domains of all 20 ATX companies, the largest listed businesses in Austria. 18 out of 20 publish a DMARC record. But only 10 of them instruct the receiver to do anything at all: 7 sit at reject, 3 at quarantine. Eight sit at none, and two domains have no record whatsoever.
_dmarc TXT records on 15.08.2026, sample being the main domains of the 20 ATX companies (index composition as of April 2026). What was measured is the published policy, not the deliverability of these businesses.For your own setup one detail matters more than the distribution: the subdomain. Sending services rarely send from your main domain, they use something like news.yourdomain.com. Without a separate instruction that subdomain inherits the main domain's policy; the sp= tag sets it independently. Our sample runs both ways: two companies set sp=reject and deliberately pull their subdomains in, two others set sp=none and deliberately leave them out. If your newsletter runs over a subdomain, that one tag decides whether your handsome reject policy applies to the newsletter at all. What the individual parts do is set out in the glossary entry on DMARC.
The honest limit of this measurement: a DNS record measures policy, not deliverability. It says nothing about whether these companies' newsletters arrive, and some of their sends run over other domains that we did not query.
How much is 0.3 per cent on a small list?
The second check is not technical, it is reputational. Google's sender guidelines name two numbers: the complaint rate reported in Postmaster Tools should stay below 0.30 per cent, and the target reads "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher".
Percentages make small lists sound safe. Convert them: at 2,000 delivered messages, 0.30 per cent is exactly 6 people tapping "report spam". The 0.10 per cent target is 2 people. At 500 delivered messages a single complaint already puts you at 0.20 per cent, and two put you at 0.40 per cent, over the line. It does not take a campaign going wrong. It takes one recipient who cannot find the unsubscribe link and reaches the spam button first.
And now the uncomfortable part: you probably cannot see that rate. It lives in Google Postmaster Tools, and their help page says: "Data might be missing if the total number of messages for a given day is too low. This is to protect users' privacy." Google names no figure; in practice it takes a few hundred messages a day to Gmail addresses. The threshold applies to you, the instrument does not come with it. What you do get: the DMARC reports sent to the address in your rua tag. Those arrive at small volumes too and show you who is sending in your name and whether the checks pass.
What can you fix today, and what takes months?
The two checks run on different clocks, and that is the real message of this piece.
What you can do today lives in DNS and in your sending tool. Set one SPF record that includes your sending service, and only one. Have the tool sign with DKIM, using a key on your domain rather than the provider's. Publish a DMARC record with a rua address, read the reports for four weeks, then move up to quarantine. Check the sp= tag if you send from a subdomain. Add one-click unsubscribe, technically the header standard RFC 8058, and keep the visible unsubscribe link in the body anyway.
One point belongs here explicitly, because small businesses regularly miss it: never send with a free mailbox address in the From field. On 15 August 2026 we also queried the policies of the large mailbox providers. yahoo.com sits at reject, gmx.at and web.de sit at quarantine, aon.at and a1.net sit at reject. If your sending service pushes out a message that says "From: you@gmx.at", the receiver files it in spam exactly as instructed, no matter how good your copy is.
What takes months is the other column. Complaints happen where people do not remember signing up. That is why double opt-in is not a formality but the raw material of your complaint rate. That is why bought addresses are not growth but a bet against your own domain. And that is why the least comfortable measure is usually the most effective one: take recipients who have opened nothing for a year out of the regular list. It shrinks the list, lifts the rates and lowers precisely the number the receiver judges you by. Why your own list is worth that work at all is covered in Newsletter 2026: owned audience over algorithm lottery, and what email deliverability covers as a metric is in the glossary.
The three levers
1. Check your three DNS records before you write the next newsletter. SPF, DKIM, DMARC. That is one afternoon with your hosting provider, and it decides the fate of every single message you send afterwards.
2. Read DMARC reports for four weeks before you move up. The reports show you which services send in your name. Only once you know all of them and they sign cleanly is quarantine risk-free. Jumping straight to reject reliably stops your own invoice emails too.
3. Convert the complaint rate into people, not percentages. Six people out of 2,000 addresses. That number changes how you decide on frequency, unsubscribe links and list hygiene, and it is the reason a smaller list is so often the better one.
If you want to know whether your sending domain stands on solid ground and what the DMARC reports say about you, we are happy to take a look together. 📬