En fördröjning från Microsoft är ett tillfälligt SMTP-avslag, alltså ett svar som börjar med 4, som Outlook.com eller en server i Microsoft 365 skickar när den inte vill ta emot ditt meddelande just nu. Din server ska behålla meddelandet och försöka igen. Det mest kända är 451 4.7.500 Server busy. Please try again later, och samma kod kan betyda ”dina utskick ser misstänkta ut” eller ”Microsoft har en dålig dag”.

Den 4 september 2026 betydde den det senare, och minst en erfaren driftansvarig ägnade förmiddagen åt att jaga det förra. Så här skiljer du dem åt.

Det viktigaste i korthet

• Läs värdnamnet först. *.olc.protection.outlook.com är Outlook.com med privata brevlådor, *.mail.protection.outlook.com är en tenant i Microsoft 365. Olika dokumentation, olika eskaleringsvägar.
• Ett 4xx-svar betyder köa och försök igen: enligt RFC 5321 med minst 30 minuters mellanrum, i minst 4 till 5 dagar. Ett 5xx-svar betyder stopp. Microsofts policyer förbjuder nya försök.
• Om alla IP-adresser får samma kod från Microsoft under samma minut medan Gmail och Yahoo fungerar som vanligt, misstänk Microsoft och kolla mailop innan du ändrar något.
• Sedan den 5 maj 2025 kräver Outlook.com SPF, DKIM och DMARC av domäner som skickar fler än 5 000 meddelanden per dag. 550 5.7.515 är alltid ditt problem att åtgärda.
• Registrera dina IP-adresser för utskick i SNDS och JMRP redan nu. Åtkomsten till SNDS upphör efter 10 månader om du inte intygar på nytt.
• Försök inte oftare, byt inte till nya IP-adresser och spärra inte fördröjda kontakter.

Ta först reda på vilket Microsoft du har att göra med

Microsoft driver två mottagande system.

Outlook.com är privat e-post: outlook.com, hotmail.com, live.com och msn.com, med MX-värdar som hotmail-com.olc.protection.outlook.com. Här finns Postmaster-webbplatsen för Outlook.com, SNDS för rykte och ett eget supportformulär för avsändare.

Microsoft 365 (Exchange Online) är värd för företagens brevlådor. E-post till acme.com går till acme-com.mail.protection.outlook.com. Felen dokumenteras på Microsoft Learn, blockeringar hanteras via sender.office.com, och mottagarens administratörer styr hur deras tenant behandlar dig.

Domännamnet avslöjar inte vilket av systemen du träffar. Det gör svaret. I den här loggraden, som publicerades på mailop den 4 september, är relay=-värden en tenant i Microsoft 365:

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))

Tolka svaret

Läs grundkoden (451), den utökade statuskoden (4.7.500) och underkoden inom parentes, till exempel (S77714). Microsoft publicerar inte S-underkoderna, men om många avsändare rapporterar samma underkod samtidigt är det en signal.

Källor: Microsofts referens över NDR:er i Exchange Online, artikel om ASxxx, kodtabellen på Postmaster-webbplatsen och artikel om 550 5.7.515; Al Iverson om S775 och S3115; Twilio SendGrid om blockeringar med S3140/S3150.

Fyran eller femman är själva instruktionen

Enligt M3AAWG:s Sender Best Common Practices ska ”avsändaren stänga anslutningen och öppna en ny anslutning senare” efter ett tillfälligt fel, och avsändare får aldrig behandla ett tillfälligt fel som permanent. Microsofts policyer för avsändare om 5xx: ”avsändaren får inte försöka skicka om meddelandet till den mottagaren.”

Ett 451-svar är ingen studs. Om din plattform eller ett skript behandlar det som en studs ska du åtgärda det först.

Incident hos Microsoft eller ditt rykte

Microsofts vägledning om 4.7.500 pekar på dina egna utskick. Oftast stämmer det, men inte alltid.

Så såg 4 september 2026 ut

Qboxmail skrev på mailop att problemet ”började kl. 9:47 CEST på alla våra IP-adresser samtidigt”, med underkoderna S77714, S77717 och S77719. Poppulos statussida angav Microsofts incident-id, EX1467029, med start kl. 11:19 BST.

I en sammanställning från den 10 september skriver emailexpert att en driftansvarig skyllde på fiberavbrott, tills One.com, Qboxmail, Mailjet och Poppulo rapporterade samma koder för alla IP-adresser och regioner. Microsoft skyllde först på en antispammodell och sedan på en strypningsregel som fortsatte att slå till under återställningen. Någon offentlig incidentrapport i efterhand har emailexpert inte hittat. Ett separat autentiseringsfel, MO1465074, pågick i cirka 67 timmar från 31 augusti till 3 september. State of Email för september går igenom de tio dagarna.

Fem kontroller innan du agerar

1. Din egen omfattning. Plattformsproblem drabbar alla IP-adresser, domäner och typer av utskick inom några minuter. Ryktesproblem börjar oftast på en av dem.
2. Andra leverantörer. Om Gmail, Yahoo och Apple tar emot som vanligt och andra avsändare rapporterar samma kod från Microsoft ligger orsaken troligen hos Microsoft.
3. Dina senaste 72 timmar. En volymtopp, en ny IP-adress, en importerad lista, en DNS-ändring eller ett återaktiveringsutskick behöver åtgärdas oavsett.
4. Hör dig för. Kolla mailop-arkivet och statussidor. En administratör i Microsoft 365 kan öppna Health > Service health (Hälsa > Tjänstens hälsotillstånd i det svenska gränssnittet), där fliken Issue history visar incidenter från de senaste 7 eller 30 dagarna som har publicerats för din tenant. Det var där Poppulo hittade EX1467029.
5. SNDS. Om SNDS visar grönt utan blockeringar medan fördröjningarna hopar sig pekar det bort från dig.

Så hanterar du ett svar från Microsoft, utifrån Microsofts dokumentation och incidentrapporterna från september 2026.

SNDS och JMRP: konfigurera dem innan du behöver dem

Smart Network Data Services (SNDS) är Microsofts kostnadsfria portal för rykte per IP-adress hos Outlook.com. Vanliga frågor om SNDS listar vad som visas för varje auktoriserad IP-adress:

• Filterresultat. Grönt betyder att under 10 % bedöms som spam, gult 10 till 90 % och rött över 90 %.
• Klagomålsfrekvens, klagomål delat med antal mottagare. Mer än 30 % av IP-adresserna ligger under 0,3 %, ”en bra nivå att sikta på”.
• RCPT-kommandon jämfört med antal mottagare. Ett stort glapp tyder på inaktuella listor.
• IP-status: Blocked, Bot eller Junked.

Data ”saknas eventuellt för IP-adresser som skickade färre än 100 meddelanden under den aktuella dagen”. För att få åtkomst begär du en IP-adress, ett IP-intervall eller ett ASN, och SNDS mejlar en länk till adresser som tjänsten hittar via omvänd DNS (postmaster@, abuse@) eller RDAP. Det går inte att göra manuella förfrågningar.

SNDS relanserades i juni 2026. Al Iverson noterade den 19 juni att returadresserna (return-path) i JMRP inte längre på ett tillförlitligt sätt identifierar kampanj och mottagare, så koda in de uppgifterna någon annanstans. Enligt startsidan för SNDS (uppdaterad 22 september) upphör åtkomsten 10 månader efter godkännandet eller migreringen, med tre påminnelser. Lägg in det i kalendern.

Junk Mail Reporting Program (JMRP), som du anmäler dig till i SNDS, skickar tillbaka varje meddelande som en användare av Outlook.com markerar som skräppost, ofta ”inom så lite som 72 timmar” efter anmälan. Ta bort dem som klagar från alla listor och anmäl nya IP-adresser när du lägger till dem. På delade IP-adresser som du inte kan registrera frågar du din leverantör vad den bevakar.

Avsändarsupport och avlistning

Outlook.com. Supportformuläret på felsökningssidan på Postmaster-webbplatsen kräver ett Microsoft-konto, gäller bara de fyra privata domänerna och ”garanterar inte” leverans. Twilio SendGrid (råd från en leverantör) säger att du ska ange din domän, dina IP-adresser, en beskrivning av trafiken, studstexten och skärmbilder från SNDS, svara på det första automatiska svaret och be om eskalering samt begära din volymkvot och en granskning av din Volume-Based Limit.

Microsoft 365. För 5.7.606-649 använder du avlistningsportalen på sender.office.com: en adress och en IP-adress per besök, bekräftat via mejl. Borttagningen ”kan ta upp till 24 timmar eller längre”. För 5.7.511 mejlar du NDR:en till delist@microsoft.com och kan räkna med svar inom 48 timmar.

Det finns ingen avlistning för en ASxxx-strypning. Om mottagarföretaget filtrerar inkommande e-post genom en tredje part före Microsoft 365 säger artikeln på Learn att en koppling (connector) som företagets administratör konfigurerar tar bort strypningen. Annars hävs den i takt med att du bygger upp en historik.

Nya försök, strypning och upptrappning

Försök igen enligt ett schema. RFC 5321, avsnitt 4.5.4.1 säger att ”intervallet mellan nya försök BÖR vara minst 30 minuter” och att tiden innan avsändaren ger upp ”i allmänhet behöver vara minst 4–5 dagar”, med två försök under den första timmen och därefter ett varannan eller var tredje timme. Korta inte ned schemat för ett brådskande utskick.

Sänk takten per mottagarsystem. Enligt M3AAWG förväntar sig mottagande servrar att avsändaren anpassar sig ”som en samlad process för all e-post som skickas till dem från samma IP-adress”. När Microsoft fördröjer sänker du takten för allt som går till den MX-familjen (Outlook.com eller Microsoft 365).

Håll koll på anslutningarna. Enligt policyn för Outlook.com ”får avsändare inte öppna fler än 500 samtidiga anslutningar” utan föregående överenskommelse. Det är ett tak, och ett 4.7.652 (S3115) betyder att du har överskridit din egen gräns.

Trappa upp nya IP-adresser och domäner. Enligt Microsoft ”kan en ny IP-adress räkna med att vara helt upptrappad inom ett par veckor eller tidigare”, beroende på volym, hur korrekta listorna är och klagomål. Nya IP-adresser som täcks av en befintlig SPF-post ärver en del av domänens rykte. Börja med mottagare som har engagerat sig nyligen.

Det här ska du inte göra

• Försök inte oftare. Att tömma kön med några minuters mellanrum öser anslutningar över en IP-adress som Microsoft vill bromsa, och ger dig ett 4.7.652.
• Byt inte IP-adress för att slingra dig undan. Nya IP-adresser saknar rykte och får lättare problem, och att sprida utskick över nya IP-adresser är precis vad snowshoe-spammare gör.
• Försök inte igen efter ett 5xx-svar. Microsoft förbjuder det, och efter ”flera svar om utebliven leverans” måste du sluta skicka till den mottagaren.
• Spärra inte fördröjda kontakter. Adressen är fortfarande giltig.
• Skicka inte om till fördröjda mottagare. Deras meddelanden ligger fortfarande i kön. Du skulle skicka dubbletter.
• Ändra inte DNS i panik. Att ändra SPF eller DKIM mitt under en incident ger dig ett problem till, om du inte har fått ett 5.7.515.

Om DMARC-alignment och om att gå från p=none till en tillämpad policy kan du läsa i vår guide om leveransbarhet. För att lösenordsåterställningar och kvitton ska fortsätta komma fram går vår guide om transaktionsmejl igenom hur du lägger dem på en egen domän.

Så ser det ut i Brew

Brew driver infrastrukturen för utskick och gör nya försök vid tillfälliga fel, så du behöver aldrig justera köer eller gränser för anslutningar. Det här ser du:

• Händelser av typen Försenad. En fördröjning registreras som en händelse av typen Försenad (delivery_delayed), och mottagaren går från accepterad till försenad och sedan till levererad eller studsad. Sök efter ”försenad” i Händelser och skriv sedan @hotmail.com eller @outlook.com för att begränsa till Outlook.com (domänfilter kombineras med ELLER; mottagare i Microsoft 365 har sina egna domäner). Händelsen visar att meddelandet väntar, inte varför.
• Detaljer om studsar. Under Metadata för en händelse av typen Studsad finns typen av studs och leverantörens meddelande.
• Antal via API:t. Statistiköversikten returnerar deliveryDelayed och pending bredvid levererade och studsade. get_email_analytics gör samma sak via MCP.
• Spärrar som respekterar 4xx. Hårda studsar och klagomål leder till spärr direkt. Mjuka studsar leder till spärr först när det har blivit tre inom 30 dagar.
• Upptrappning. Gradvist utskick delar upp ett stort utskick i omgångar per timme eller dag, angivna i procent, som du kan pausa om Outlook.com börjar fördröja.
• Domänens hälsa. Kortet Leveransbarhet för varje domän ger 0 till 100 poäng utifrån inkorgsplacering, rykte, autentisering, innehåll och utskickskonfiguration, och poängen finns även via MCP-verktyget get_domain_health. Ett test av inkorgsplacering (10 krediter) skickar till testinkorgar hos Gmail, Outlook, Yahoo, Apple med flera.

Webhooks för leveranser och data från SNDS eller JMRP finns inte i Brew än (antal per e-postleverantör får du från API:t för händelser med groupBy=recipientDomain), så använd Microsofts portaler för rykte. Vid en misstänkt incident hos Microsoft skulle vi låta utskicket vara och se Försenad bli Levererad.

Vanliga frågor

Vad betyder 451 4.7.500 Server busy från Outlook eller Microsoft 365?

Det är ett tillfälligt avslag från Microsoft 365 (Exchange Online), som listas som ”Access denied, please try again later” efter misstänkt aktivitet. Oftast har ditt utskicksmönster ändrats, men den 4 september 2026 var det en incident hos Microsoft (EX1467029). Låt din server försöka igen och kontrollera om andra avsändare också ser det.

Hur länge kommer Microsoft att fortsätta fördröja mina mejl?

Enligt Microsoft upphör strypning som beror på utskicksmönster ”under en period av några dagar” i takt med att du bygger upp en historik, och en avlistning kan ta upp till 24 timmar eller längre. Fortsätt försöka i minst 4 till 5 dagar, som RFC 5321 rekommenderar, så levereras de flesta fördröjda mejl till slut.

Vad är 550 5.7.515 och hur åtgärdar jag det?

Outlook.com avvisar e-post från domäner som skickar fler än 5 000 mejl per dag och inte uppfyller dess regler för autentisering, som gäller sedan den 5 maj 2025. SPF och DKIM måste godkännas, domänen måste publicera DMARC (p=none räcker) och SPF eller DKIM måste stämma överens med From-domänen.

Ska jag skaffa en ny IP-adress om Microsoft blockerar min?

Nej. Enligt Microsoft saknar nya IP-adresser rykte och får lättare problem. Åtgärda orsaken, begär avlistning och trappa upp igen på den IP-adress du har.

Räknas fördröjningar från Microsoft som studsar?

Nej. Enligt M3AAWG får avsändare inte behandla ett 4xx-svar som permanent. Det blir en studs först när de nya försöken tar slut eller servern svarar med ett 5xx-svar. I Brew visas en fördröjning som en händelse av typen Försenad, och kontakter spärras först efter upprepade mjuka studsar.