Unauthenticated mail now bounces

Since November 2025, Gmail refuses unauthenticated mail during the SMTP conversation instead of filing it in spam. Microsoft got there six months earlier, on May 5, 2025, with a bounce string that reads your domain name back to you. For anyone sending from a domain they own, that turns a DNS mistake from a soft cost into a hard one. The message does not arrive, and nobody can fish it out of a junk folder later.

This is the news. The rule-by-rule version, with the exact artifact that satisfies each requirement, is our walkthrough of the Gmail sender rules.

Google: February 2024 wrote the rules, November 2025 gave them teeth

Google's sender requirements took effect in February 2024. For most of the two years that followed, non-compliant mail met temporary failures, the 4.7.x codes that tell a sending relay to try again later. Relays retried. Some of that mail eventually landed. The whole failure looked like slowness rather than refusal, which is why so many senders never went looking.

Google's sender guidelines FAQ now says this, and the wording matters (checked August 2026):

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.

Permanent is the new word. A 5.7.x response is not retried by any well-behaved relay, and it does not land in spam either, because the receiving server never accepted the message in the first place. Your recipient has nothing to rescue.

Microsoft: announced in April 2025, enforcing since May 5

Microsoft published its requirements for high-volume senders on April 2, 2025 and switched them on a month later. The scope is domains sending more than 5,000 messages a day into Microsoft consumer mailboxes: Outlook.com, Hotmail.com, Live.com, and MSN.com. The requirements are SPF passing, DKIM passing, and a DMARC record of at least p=none that aligns with one of the two.

The first plan was the junk folder, with outright rejection promised for a later unnamed date. That later date arrived early. Before enforcement began, Microsoft changed the outcome to rejection at the envelope, and its support documentation for the resulting bounce is now titled, plainly enough, "Fix NDR error 550 5.7.515 in Outlook.com."

We think the reversal was right, and the reason is in the shape of the two outcomes. A message in Junk is ambiguous to everyone involved: the sender's dashboard shows a delivery, the recipient sees clutter, and no one learns which record is broken. A 5xx names the failing domain in one line. Bad news that arrives immediately is cheaper than good news that turns out to be false.

The 5,000 line is not the entry ticket

Both providers use 5,000 messages a day as the threshold for their strictest tier, and that number gets quoted as though smaller senders are exempt. They are not. Google's baseline requirement, that every sender authenticate with SPF or DKIM, carries no volume floor at all. A consultant sending thirty emails a day from a domain with no records is squarely inside the scope of a 5.7.26 rejection.

Our own compliance floor is written the same way, and the phrasing in the deliverability handbook is deliberate: every send must satisfy all of it, at any volume. We send dozens of messages a day, not thousands, and we hold the bulk-sender line anyway. It costs nothing to comply early and a great deal to retrofit reputation later.

What a rejection looks like in your logs

Gmail returns a multi-line block. With the domain and IP swapped for examples:

550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [example.com] with ip: [203.0.113.10] = did not pass
550 5.7.26  For instructions on setting up authentication, go to
550 5.7.26  https://support.google.com/mail/answer/81126#authentication

Microsoft's is one line and just as blunt:

550 5.7.515 Access denied, sending domain [example.com] does not meet the required authentication level

Google publishes both its throttling codes and its blocking codes, and reading them side by side tells you which failures are fatal today and which are merely expensive. This table pairs them up, from Google's sender guidelines FAQ, checked August 2026.

Note the last two rows. A missing DMARC record and a misaligned From header are still only rate limited at Gmail, which reads to us as a schedule rather than a reprieve. Nothing on this list has ever moved in the other direction.

In a relay dashboard these arrive classified as blocked or rejected, not as invalid recipients, and the giveaway is that they cluster at one mailbox provider. If your Gmail bounces spike while everything else stays flat, stop auditing your list and go read your DNS.

The records that fix it

Three TXT records, published on the domain in your visible From address. SPF first, with the include value your relay documents:

example.com.  TXT  "v=spf1 include:spf.yourrelay.com ~all"

DKIM second. The relay generates the key pair and hands you the record; only the selector name changes between providers:

selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

DMARC third, and p=none is enough to satisfy both Google and Microsoft today. Publish the reporting address with it, because the reports are how you find out who else is sending as you:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Then verify rather than trust the control panel:

dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

The fourth requirement, a PTR record on the sending IP, is not yours to set on a shared relay. The relay owns the IP and its reverse DNS, which is one of the quieter arguments for using one. How the three records interlock as a single system is covered in our authentication piece.

Where we stand

We treat authentication as a precondition for sending at all, not as a setting that improves your results. A domain sends from LetterDuck under its own DKIM signature on its own name. There is no shared fallback sending domain to route around a record that has not propagated, and no mode where a workspace sends "for now" while DNS gets sorted out. Borrowed authentication converts a problem you could have fixed in DNS this afternoon into a reputation you discover is damaged in November.

The one place we allowed ourselves to be clever, we paid for it. Our inbound pipeline used to copy every message into a Gmail archive with a standard forward, one line of code, obviously fine. A forward hands your message to a second set of servers to deliver, and alignment does not survive that trip. In June 2026 we counted Gmail rejecting roughly 73 percent of those copies, quietly, for weeks, with our own logs showing green. The full teardown is here. The lesson runs past forwarding: the authentication chain has no polite failure mode left in it.

What we do instead is watch. A canary email travels our real send-and-receive path every two hours on a cron, and if DNS shifts underneath us the probe stops arriving and one alert goes out. No email from the watchdog is the only good news it knows how to give.

Three things to do this week

Send one message to a Gmail address you control, open Show original, and confirm three PASS lines with your domain named on each. Two out of three is a live risk, not a near miss.

Pull last month's bounces out of your relay and filter for 5.7.2 and 5.7.515. Those are configuration bugs wearing a bounce costume, and they will still be there next month.

If you have no DMARC record, publish p=none with a reporting address today. It is a 4.7.31 throttle at Gmail right now and a hard requirement at Microsoft above 5,000 a day, and the temporary list has a long history of turning into the permanent one.