# Microsoft a odklady 451 4.7.500: příručka pro odesílatele

Kanonická URL: https://brew.new/cs/blog/microsoft-451-4-7-500-deferrals-playbook
Autor: Thomas Park
Publikováno: 2026-10-05
Aktualizováno: 2026-10-05

Když Microsoft odloží doručení (deferral), jde o dočasné odmítnutí SMTP, tedy odpověď začínající čtyřkou, kterou pošle server Outlook.com nebo Microsoft 365, když tvou zprávu zrovna nechce přijmout. Tvůj server by si zprávu měl ponechat a zkusit to znovu. Nejznámější je `451 4.7.500 Server busy. Please try again later` a stejný kód může znamenat „tvoje odesílání vypadá podezřele“ i „Microsoft má zrovna špatný den“.

Dne 4. září 2026 platila ta druhá možnost, a přesto nejméně jeden zkušený provozovatel poštovních serverů strávil dopoledne honbou za tou první. Tady je návod, jak je od sebe rozeznat.

## Hlavní body

- Nejdřív se podívej na hostitele. `*.olc.protection.outlook.com` je spotřebitelská pošta Outlook.com, `*.mail.protection.outlook.com` je tenant Microsoft 365. Jiná dokumentace, jiná eskalace.
- Odpověď 4xx znamená nechat zprávu ve frontě a opakovat pokusy: podle RFC 5321 v rozestupech alespoň 30 minut a nejméně 4 až 5 dní. Odpověď 5xx znamená stop. Pravidla společnosti Microsoft její opakování zakazují.
- Pokud Microsoft vrátí všem tvým IP adresám ve stejné minutě stejný kód a Gmail i Yahoo fungují normálně, podezírej Microsoft a než cokoli změníš, podívej se do konference mailop.
- Od 5. května 2025 vynucuje Outlook.com SPF, DKIM a DMARC u domén, které posílají více než 5 000 zpráv denně. `550 5.7.515` musíš opravit vždycky ty.
- Zaregistruj odesílací IP adresy v SNDS a JMRP hned teď. Přístup do SNDS vyprší po 10 měsících, pokud ho opětovně nepotvrdíš.
- Nezkoušej to usilovněji, nepřecházej na čerstvé IP adresy a neblokuj kontakty s odloženým doručením.

## Nejdřív zjisti, který Microsoft je na druhé straně

Microsoft provozuje dva systémy pro příjem pošty.

**Outlook.com** je spotřebitelská pošta: `outlook.com`, `hotmail.com`, `live.com` a `msn.com`, s MX hostiteli jako `hotmail-com.olc.protection.outlook.com`. Má [web Outlook.com Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), SNDS pro reputaci a vlastní formulář podpory pro odesílatele.

**Microsoft 365** (Exchange Online) hostuje firemní schránky. Pošta pro `acme.com` jde na `acme-com.mail.protection.outlook.com`. Chyby jsou zdokumentované na [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), blokace se řeší přes `sender.office.com` a to, jak se k tobě jejich tenant chová, řídí administrátoři příjemce.

Z názvu domény nepoznáš, na který z nich narážíš. Z odpovědi ano. V tomto řádku logu, který někdo 4. září [poslal do konference mailop](https://www.mail-archive.com/mailop@mailop.org/msg27209.html), je hostitel v `relay=` tenant Microsoft 365:

```text
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))
```

## Rozlušti odpověď

Přečti si základní kód (`451`), rozšířený stavový kód (`4.7.500`) a podkód v závorce, třeba `(S77714)`. Podkódy začínající na S Microsoft nezveřejňuje, ale když stejný podkód hlásí najednou mnoho odesílatelů, je to signál.

| Odpověď | Kde | Co uvádí dokumentace Microsoft | První krok |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Microsoft Learn uvádí rozsah 4.7.500-699 jako „Access denied, please try again later“: podezřelá aktivita, odesílání je dočasně omezené. | Nech frontu opakovat pokusy. Nejdřív ověř, jak široký problém je. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | Omezování IP adresy, která „změnila dosavadní vzorce odesílání e-mailů tím, že začala posílat mnohem vyšší objem“. | Zpomal náběh. Omezení odezní „během několika dní“. |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | V tabulce, kterou Microsoft zveřejnil, chybí. | Sniž objem a souběžnost, pak zkontroluj SNDS. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | V tabulce chybí. Příčinu uvádí přímo text odpovědi. | Otevírej méně připojení. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Překročené limity rychlosti, rychlosti na jedno připojení a počtu připojení, „související s reputací IP adresy nebo domény“. | Zpomal odesílání, pak zkontroluj SNDS. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | Doména posílá více než 5 000 zpráv denně a nesplňuje požadavky na SPF, DKIM a DMARC. | Oprav ověřování a zarovnání. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | Blokace tvé IP adresy nebo rozsahu. | Přestaň z té IP adresy posílat a otevři tiket. |
| `550 SC-001`, `SC-004`, `OU-002` a podobné | Outlook.com | Odmítnutí podle pravidel kvůli obsahu, reputaci nebo stížnostem. SC-004 odkazuje na JMRP. | Než odesílání obnovíš, najdi příčinu. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | IP adresa je na seznamu blokovaných odesílatelů. | Požádej o vyřazení na `sender.office.com`. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Vyžaduje ruční prošetření. | Přepošli NDR na `delist@microsoft.com`. |

Zdroje: Microsoft – [přehled zpráv NDR v Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), [článek o ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), tabulka kódů na webu Postmaster a [článek o 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson o [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) a [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid o [blokacích S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Čtyřka, nebo pětka: první číslice je pokyn

[Doporučené postupy M3AAWG pro odesílatele](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) (Sender Best Common Practices) říkají, že po dočasném selhání „by měl odesílatel spojení ukončit a později otevřít nové“ a že odesílatelé nikdy nesmějí brát dočasné selhání (tempfail) jako trvalé. Microsoft ve svých [pravidlech pro odesílatele](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) k odpovědím 5xx píše: „odesílatel se nesmí pokoušet tuto zprávu tomuto příjemci znovu odeslat“.

Kód 451 není nedoručení (bounce). Pokud ho tak bere tvoje platforma nebo nějaký skript, oprav nejdřív tohle.

## Incident společnosti Microsoft, nebo tvoje reputace?

Pokyny společnosti Microsoft ke kódu 4.7.500 tě posílají hledat chybu ve vlastním odesílání. Obvykle je to správně, ale ne vždycky.

### Jak vypadal 4. září 2026

Firma Qboxmail [napsala do konference mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html), že problém „začal v 9:47 SELČ na všech našich IP adresách najednou“, s podkódy S77714, S77717 a S77719. Firma Poppulo na své [stavové stránce](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) uvedla ID incidentu od společnosti Microsoft, EX1467029, se začátkem v 11:19 BST.

Podle [shrnutí webu emailexpert ze dne 10. září](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/) jeden provozovatel sváděl problém na přerušené optické kabely, dokud One.com, Qboxmail, Mailjet a Poppulo nenahlásily stejné kódy napříč všemi odesílacími IP adresami a regiony. Microsoft to nejdřív přičetl antispamovému modelu, pak pravidlu pro omezování, které se spouštělo i během obnovy. Veřejnou zprávu po incidentu web emailexpert nenašel. Samostatná chyba ověřování, MO1465074, trvala zhruba 67 hodin, od 31. srpna do 3. září. Těm deseti dnům se věnuje naše [zářijové vydání The State of Email](/cs/blog/state-of-email-september-2026).

### Pět kontrol, než začneš jednat

1. **Rozsah u tebe.** Problémy platformy zasáhnou během několika minut každou IP adresu, doménu i proud pošty. Problémy s reputací obvykle začínají u jedné z nich.
2. **Ostatní poskytovatelé.** Pokud Gmail, Yahoo a Apple přijímají poštu normálně a ostatní odesílatelé hlásí stejný kód, jaký vrací Microsoft, je příčinou nejspíš Microsoft.
3. **Tvých posledních 72 hodin.** Skokový nárůst objemu, novou IP adresu, importovaný seznam, úpravu DNS nebo reaktivační rozesílku je potřeba řešit tak jako tak.
4. **Poptej se.** Projdi archiv konference mailop a stavové stránky. Administrátor Microsoft 365 může otevřít **Health > Service health** (stav služeb), kde [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) (historie problémů) ukazuje incidenty zveřejněné pro tvého tenanta za posledních 7 nebo 30 dní. Právě tam firma Poppulo našla EX1467029.
5. **SNDS.** Zelená bez blokací, zatímco odklady přibývají, ukazuje, že chyba není u tebe.

| Signál | Ukazuje na Microsoft | Ukazuje na tebe |
|---|---|---|
| Načasování | Všechny IP adresy začnou ve stejné minutě | Jedna IP adresa nebo doména, případně postupný nárůst |
| Ostatní poskytovatelé | V pořádku | Taky se zhoršují, nebo přibývá stížností |
| Ostatní odesílatelé | Stejný kód v konferenci mailop a na stavových stránkách | Nikdo jiný o tom nemluví |
| Tvoje nedávné změny | Žádné | Skok v objemu, nová IP adresa, nový seznam |
| SNDS | Zelená, žádná blokace | Žlutá nebo červená, stížnosti, „Blocked“ |
| Kód | 4.7.500 s podkódem, který hlásí i ostatní | RP-00x, 4.7.650, 5.7.515, S3150 |

![Rozhodovací diagram pro odpovědi serverů Microsoft: kódy 5xx vedou k opravě ověřování, k portálu pro vyřazení z listiny nebo k tiketu na podporu; kódy 4xx vedou ke kontrole incidentu a pak buď k vyčkání, nebo ke zpomalení odesílání a kontrole SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Jak naložit s odpovědí serverů Microsoft, podle dokumentace společnosti Microsoft a zpráv o incidentu ze září 2026.*

## SNDS a JMRP: nastav si je dřív, než je budeš potřebovat

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) je bezplatný portál společnosti Microsoft, který ukazuje reputaci jednotlivých IP adres u Outlook.com. [Časté dotazy k SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) uvádějí, co se u každé autorizované IP adresy zobrazuje:

- **Výsledek filtrování** (Filter result). Zelená znamená méně než 10 % zpráv vyhodnocených jako spam, žlutá 10 až 90 %, červená víc než 90 %.
- **Míra stížností** (Complaint rate), tedy počet stížností vydělený počtem příjemců. Víc než 30 % IP adres se drží pod 0,3 %, což je „dobrá laťka“.
- **Příkazy RCPT oproti příjemcům zprávy** (RCPT commands vs. message recipients). Velký rozdíl znamená zastaralé seznamy.
- **Stav IP adresy** (IP status): Blocked, Bot nebo Junked.

Data „nemusí být k dispozici u IP adres, které daný den odeslaly méně než 100 zpráv“. Pro přístup požádej o IP adresu, rozsah nebo ASN a SNDS pošle odkaz na adresy, které najde přes reverzní DNS (`postmaster@`, `abuse@`) nebo RDAP. Ruční žádosti nepřijímá.

Služba SNDS byla v červnu 2026 znovu spuštěna. Al Iverson [19. června upozornil](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html), že adresy return-path ve zprávách z JMRP už spolehlivě neurčují kampaň a příjemce, takže tyto údaje zakóduj jinde. Podle domovské stránky SNDS (aktualizované 22. září) vyprší přístup 10 měsíců po schválení nebo migraci a předtím přijdou tři připomínky. Zapiš si to do kalendáře.

[Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP), do kterého se přihlašuješ přímo v SNDS, ti vrací každou zprávu, kterou uživatel služby Outlook.com označí jako nevyžádanou, často „už do 72 hodin“ od přihlášení. Lidi, kteří si stěžovali, odeber ze všech seznamů a nové IP adresy přihlašuj průběžně, jak je přidáváš. U sdílených IP adres, které registrovat nemůžeš, se zeptej svého poskytovatele, co sleduje.

## Podpora pro odesílatele a vyřazení z listiny

**Outlook.com.** Formulář podpory na [stránce Postmaster pro řešení potíží](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) vyžaduje účet Microsoft, pokrývá jen čtyři spotřebitelské domény a doručení „nezaručuje“. Twilio SendGrid (rada poskytovatele odesílání) doporučuje uvést doménu, IP adresy, popis proudu pošty, text nedoručení a snímky obrazovky ze SNDS, na první automatickou odpověď reagovat žádostí o eskalaci a požádat o sdělení kvóty objemu a o přezkoumání limitu podle objemu (Volume-Based Limit).

**Microsoft 365.** U kódů `5.7.606-649` použij [portál pro vyřazení z listiny](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) (delist portal) na `sender.office.com`: při jedné návštěvě jedna adresa a jedna IP adresa, potvrzení přijde e-mailem. Vyřazení „může trvat až 24 hodin nebo déle“. U kódu `5.7.511` pošli NDR e-mailem na `delist@microsoft.com` a počítej s odpovědí do 48 hodin.

U omezení ASxxx žádné vyřazení z listiny neexistuje. Pokud firma příjemce filtruje příchozí poštu přes službu třetí strany ještě před Microsoft 365, podle článku na Microsoft Learn omezení odstraní konektor, který nastaví její administrátor. Jinak omezení zmizí, jak si budeš budovat historii.

## Opakuj, zpomaluj a postupně navyšuj

**Opakuj podle plánu.** [RFC 5321, oddíl 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) uvádí, že „interval mezi pokusy BY MĚL být alespoň 30 minut“ a že doba, po které to odesílatel vzdá, „obecně musí být alespoň 4–5 dní“, se dvěma pokusy během první hodiny a pak jedním každé dvě až tři hodiny. Kvůli naléhavé rozesílce tento plán nezkracuj.

**Zpomaluj podle cíle.** Podle M3AAWG přijímající servery očekávají, že úprava proběhne „souhrnně pro všechny e-maily, které jim posílá stejná IP adresa“. Když Microsoft odkládá doručení, zpomal všechno, co jde do dané rodiny MX serverů (Outlook.com, nebo Microsoft 365).

**Hlídej připojení.** Pravidla Outlook.com říkají, že odesílatelé bez předchozí domluvy „nesmějí otevřít víc než 500 souběžných připojení“. To je strop a `4.7.652 (S3115)` znamená, že tvůj vlastní limit je překročený.

**Nové IP adresy a domény rozjížděj postupně.** Microsoft uvádí, že nová IP adresa „může počítat s plným rozjezdem během pár týdnů nebo dřív“, podle objemu, přesnosti seznamu a stížností. Nové IP adresy, které pokrývá stávající záznam SPF, zdědí část reputace domény. Začni kontakty, které se nedávno zapojily.

## Co nedělat

- **Zkoušet to usilovněji.** Když každých pár minut ručně spustíš doručení celé fronty, nahrneš připojení na IP adresu, kterou chce Microsoft zpomalit, a vysloužíš si 4.7.652.
- **Přejít na jiné IP adresy a problém tak obejít.** Nové IP adresy nemají žádnou reputaci a problémy u nich hrozí spíš. Rozkládat poštu mezi čerstvé IP adresy je navíc přesně to, co dělají spammeři technikou snowshoe.
- **Opakovat pokusy po odpovědi 5xx.** Microsoft to zakazuje a po „opakovaných odpovědích o nedoručení“ musíš tomu příjemci přestat posílat.
- **Blokovat kontakty s odloženým doručením.** Adresa je pořád platná.
- **Posílat příjemcům s odloženým doručením e-mail znovu.** Jejich zprávy pořád čekají ve frontě. Odešly by duplikáty.
- **V panice upravovat DNS.** Změna SPF nebo DKIM uprostřed incidentu přidá druhý problém, pokud ti ovšem nepřišlo `5.7.515`.

Zarovnání DMARC a přechodu z `p=none` k vynucení se věnuje náš [průvodce doručitelností](/cs/blog/email-deliverability). Jak udržet obnovu hesla a účtenky v pohybu díky samostatné doméně, popisuje náš [průvodce transakčními e-maily](/cs/blog/transactional-emails).

## Jak to vypadá v Brew

Odesílací infrastrukturu provozuje Brew a dočasná selhání sám opakuje, takže fronty ani limity připojení nikdy neladíš. Co uvidíš:

- **Události Zpožděno.** Odklad se zaznamená jako událost Zpožděno (`delivery_delayed`) a příjemce přejde ze stavu přijato do stavu zpožděno a pak doručeno, nebo nedoručeno. V sekci **Události** zadej do vyhledávání „delayed“ a pak napiš `@hotmail.com` nebo `@outlook.com`, čímž výsledky zúžíš na Outlook.com (filtry domén se kombinují pomocí NEBO; příjemci na Microsoft 365 mají vlastní domény). Událost říká, že zpráva čeká, ale ne proč.
- **Podrobnosti o nedoručení.** V části Metadata u události Nedoručeno najdeš typ nedoručení a zprávu od poskytovatele.
- **Počty přes API.** [Přehled analytiky](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) vrací vedle doručených a nedoručených zpráv také `deliveryDelayed` a `pending`. Přes MCP totéž umí `get_email_analytics`.
- **Blokování, které respektuje 4xx.** Trvalá nedoručení a stížnosti adresu zablokují okamžitě. Dočasná nedoručení ji zablokují, až když nastanou tři během 30 dní.
- **Postupný náběh.** [Postupné odesílání](https://docs.brew.new/create-emails/send-options#gradual-send) rozdělí velkou rozesílku do hodinových nebo denních dávek podle procent, které můžeš pozastavit, pokud Outlook.com začne odkládat doručení.
- **Stav domény.** Karta Doručitelnost u každé domény ji hodnotí od 0 do 100 v oblastech doručení do inboxu, reputace, autentizace, obsahu a nastavení odesílání; stejné údaje vrací i MCP nástroj `get_domain_health`. Test doručení do inboxu (10 kreditů) pošle e-mail do testovacích schránek u poskytovatelů Gmail, Outlook, Yahoo, Apple a dalších.

Webhooky pro doručení ani data ze SNDS nebo JMRP zatím Brew nemá (počty podle poskytovatelů získáš z API událostí s parametrem `groupBy=recipientDomain`), takže reputaci sleduj na portálech společnosti Microsoft. Při podezření na incident na straně společnosti Microsoft bychom rozesílku nechali být a sledovali, jak se Zpožděno mění na Doručeno.

## Časté dotazy

### Co znamená odpověď 451 4.7.500 Server busy od služby Outlook nebo Microsoft 365?

Jde o dočasné odmítnutí od Microsoft 365 (Exchange Online), které dokumentace po podezřelé aktivitě uvádí jako „Access denied, please try again later“ (přístup odepřen, zkus to později). Obvykle se změnil tvůj způsob odesílání, ale 4. září 2026 šlo o incident na straně společnosti Microsoft (EX1467029). Nech svůj server opakovat pokusy a ověř si, jestli to vidí i ostatní odesílatelé.

### Jak dlouho bude Microsoft doručování mých e-mailů odkládat?

Microsoft uvádí, že omezování kvůli změně vzorců odesílání odezní „během několika dní“, jak si budeš budovat historii, a vyřazení z listiny může trvat až 24 hodin nebo déle. Pokusy opakuj alespoň 4 až 5 dní, jak doporučuje RFC 5321, a většina odložené pošty se nakonec doručí.

### Co je 550 5.7.515 a jak to opravit?

Outlook.com odmítá poštu z domén, které posílají více než 5 000 zpráv denně a nesplňují jeho pravidla ověřování, vynucovaná od 5. května 2025. SPF i DKIM musí projít, doména musí mít zveřejněný DMARC (stačí `p=none`) a SPF nebo DKIM musí být zarovnané s doménou v adrese From.

### Mám si pořídit novou IP adresu, když Microsoft tu moji zablokuje?

Ne. Microsoft uvádí, že nové IP adresy nemají žádnou reputaci a problémy u nich hrozí spíš. Odstraň příčinu, požádej o vyřazení z listiny a na stávající IP adrese postupně znovu navyšuj objem.

### Počítají se odklady, které posílá Microsoft, jako nedoručení?

Ne. Podle M3AAWG nesmějí odesílatelé brát odpověď 4xx jako trvalou. Nedoručením se stane, až když dojdou pokusy, nebo když server vrátí 5xx. V Brew se odklad zobrazí jako událost Zpožděno a kontakty se blokují až po opakovaných dočasných nedoručeních.