Email Spam Tester

HomeBloggMejl i Outlook hamnar i skräppost: orsaker och lösningar

Mejl i Outlook hamnar i skräppost: orsaker och lösningar

Outlook.com, Microsoft 365 och Outlook-appen filtrerar e-post på olika sätt. Microsofts krav sedan maj 2025, vad 550 5.7.515 betyder och lösningarna.

På den här sidanOutlook.com och reglerna från maj 2025
  1. Outlook.com och reglerna från maj 2025
  2. Vad felkoden berättar
  3. Tredjepartsavsändare och SPF-kravet
  4. Microsoft 365 filtreras enligt någon annans policy
  5. Läs bedömningen i rubrikerna
  6. SNDS och JMRP, nu på Postmaster-webbplatsen
  7. Vad personen i andra änden kan ändra
  8. Testa före det riktiga utskicket

"Outlook" är tre olika filter, och lösningen beror på vilket av dem som flyttade ditt e-postmeddelande till skräpposten. Det finns Outlook.com, Microsofts e-posttjänst för privatpersoner, som även hanterar adresser på hotmail.com, live.com och msn.com. Det finns Microsoft 365, företagsbrevlådorna som företag betalar för, där en administratör på mottagarens företag anger skräppostpolicyn. Och det finns Outlook-appen på någons dator, som kan köra ett eget skräppostfilter utöver serverns bedömning. Avsändarreglerna som Microsoft tillkännagav 2025 gäller endast den första av dessa.

Innan jag ändrar en enda DNS-post tittar jag därför på mottagarens adress. En adress på hotmail.com eller outlook.com innebär att reglerna för privatpersoner nedan gäller. En adress hos ett företag som kör sin e-post på Microsoft innebär att en klientorganisationspolicy gäller, skriven av företagets IT-team.

Outlook.com och reglerna från maj 2025

I april 2025 meddelade Microsoft nya krav för domäner som skickar fler än 5 000 e-postmeddelanden per dag till företagets konsumenttjänst. På sidan med Postmaster-policyer anges den 5 maj 2025 som det datum då kraven började gälla. Över den volymen gäller följande:

  • SPF måste godkännas för den sändande domänen.
  • DKIM måste godkännas.
  • DMARC måste vara publicerad med "minst p=none" och vara linjerad med SPF eller DKIM, "helst båda". På policysidan rekommenderas dessutom p=reject.

Supportartikeln om studsmeddelandet formulerar det lite annorlunda. Den räknar 5 000 eller fler meddelanden till Microsofts konsumenttjänster som alla använder samma domän i From-adressen. Där står att både SPF- och DKIM-kontrollerna måste godkännas. När en domän når den nivån förväntar sig Microsoft att "alla meddelanden från avsändare på domänen" uppfyller kraven, inte bara nyhetsbrevet som gjorde att gränsen passerades. Deras DMARC-exempel är ungefär så kort som en post kan bli:

TXT·_dmarc
Hostname:   _dmarc
TXT value:  v=DMARC1; p=none

Jag skulle lägga till en rapportadress, rua=mailto:dmarc@example.com eller den adress där du faktiskt läser e-post. Outlook.com skickar aggregerade rapporter (i Microsofts FAQ står det att RUA skickas och att det inte finns några planer på att skicka RUF), och DMARC-kontrollen visar om adressen du anger kan ta emot dem.

Google satte samma gräns på 5 000 meddelanden per dag för Gmail i februari 2024 och började stegvis skärpa tillämpningen, inklusive avvisningar, i november 2025. Yahoo tillämpar en liknande lista med krav utan att ange någon gräns.

Hur regeln tillämpas ändrades medan tillkännagivandet fortfarande var nytt. I det ursprungliga inlägget stod det att e-post som inte uppfyllde kraven först skulle hamna i skräpposten och eventuellt avvisas senare. I en uppdatering daterad den 29 april står det att Microsoft i stället beslutade att avvisa meddelandena, men längre ned i samma inlägg finns fortfarande det äldre stycket om att de först hamnar i skräpposten. Den försiktiga tolkningen i dag är att e-post som inte uppfyller kraven har hamnat i skräpposten sedan den 5 maj 2025 och att Outlook.com nu även avvisar den med följande meddelande:

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

Studstext från Outlook.com, citerad i Microsofts supportartikel

Jag har inte hittat något publicerat datum för övergången till avvisning. Supportartikeln beskriver det bara i presens.

Vad felkoden berättar

Ett studsmeddelande från Outlook.com är mer användbart än ett meddelande som hamnar obemärkt i skräpposten, eftersom det anger en orsak. Microsofts felsökningssida innehåller en tabell över koderna. Det här är de som vanliga avsändare brukar stöta på:

KodVad Microsoft säger att den betyder
550 5.7.515Domänen skickar över 5 000 meddelanden per dag och är inte autentiserad med SPF, DKIM och DMARC
550 SC-001Avvisat enligt policy, "content with spam-like characteristics or IP/domain reputation"
550 SC-004Din IP har blockerats efter klagomål på e-post som skickats från den
421 RP-001Frekvensbegränsning för anslutande IP, även här på grund av dåligt anseende

Ett vanligt 550 5.7.1 utan Microsofts egna koder är en annan typ av avvisning. Det finns en separat sida om hur du tolkar det.

Tredjepartsavsändare och SPF-kravet

Många domäner skickar via flera tjänster samtidigt: en nyhetsbrevsplattform, ett CRM-system, en helpdesk och ett faktureringssystem. Var och en skickar med din domän på From-raden, och alla måste omfattas av dina poster. På frågan om reglerna fortfarande gäller när en leverantör skickar åt dig svarar Microsofts vanliga frågor: "Ja. Även om du lägger ut utskicken är autentiseringen knuten till din domän." Supportartikeln anger vad du ska verifiera: att DKIM signerar med din domän och att din SPF-post "innehåller den IP-adress eller de include-värden som tjänsten kräver".

Det är här kravet på både SPF och DKIM blir förvirrande. Många plattformar använder en returadress på sin egen domän, och SPF kontrollerar i praktiken denna Return-Path. SPF godkänns då för plattformen, vilket uppfyller kravet att kontrollen måste godkännas, medan DMARC-anpassningen måste komma från DKIM-signering med din domän. Om plattformen i stället signerar med sin egen domän får du två godkända kontroller men ingen anpassning, och efterföljande DMARC fail är precis vad 5.7.515 handlar om. Supportartikeln ber dig också kontrollera om Return-Path-domänen är anpassad till From-domänen.två godkända kontroller, ingen anpassning: hela historien om 5.7.515

Varje tjänst du lägger till i SPF kostar också DNS-uppslagningar. Microsofts vanliga frågor uttrycker det så här: "Om du överskrider 10 DNS-uppslagningar kan SPF-kontrollen misslyckas." SPF-kontrollen räknar dem åt dig, och om du har för många kan du läsa så här kommer du tillbaka under tio. DKIM-kontrollen utför motsvarande kontroll för varje plattforms selektor.

Microsoft 365 filtreras enligt någon annans policy

En Microsoft 365-organisation har policyer mot skräppost som administratörerna konfigurerar. Som standard hamnar skräppost, skräppost med hög sannolikhet och massutskick i mappen Skräppost, medan nätfiske hamnar i karantän och nätfiske med hög sannolikhet alltid sätts i karantän. För avsändaren är karantän det sämsta utfallet, eftersom mottagaren inte hittar meddelandet i någon mapp om de inte aktivt letar efter det. Standardpolicyn behåller det där i 15 dagar, medan förinställningarna Standard och Strict behåller det i 30 dagar.

Massutskick har ett eget mått, bulk complaint level. Ett BCL-värde på 1 till 3 innebär en avsändare av massutskick med få klagomål, medan 8 eller 9 innebär en avsändare med många klagomål. Standardpolicyn skickar massutskick till Skräppost från BCL 7, förinställningen Standard från 6 och Strict från 5. Sedan juli 2026 finns också ett nyare lager: massutskick av reklamkaraktär får etiketten Promotions oavsett BCL, och om en administratör har aktiverat "Bulk moves enabled" hamnar de i en Promotions-mapp. Det är inte skräppost, men det är inte heller inkorgen. Funktionen lanseras fortfarande stegvis.

De två Microsoft-systemen är inte isolerade från varandra. Microsoft uppger att Microsoft 365:s skräppostfiltrering "lär sig från kända skräppost- och nätfiskehot samt användarfeedback från vår konsumentplattform Outlook.com", så det som användare av hotmail.com rapporterar påverkar filtret som används för företagsinkorgar.

Administratörer kan också lägga till en avsändare i en lista över tillåtna avsändare, vilket kringgår det mesta av skyddet förutom skyddet mot skadlig kod och nätfiske med hög sannolikhet. Om ett partnerföretag fortsätter att få dina fakturor i Skräppost är det deras IT-team som kan se den faktiska bedömningen.

Läs bedömningen i rubrikerna

Om du kan komma åt meddelandet så som det togs emot i en Microsoft 365-postlåda, visar rubrikerna för skräppostskydd beslutet direkt. X-Forefront-Antispam-Report innehåller några fält som är bra att känna till:

  • SFV:SPM betyder att skräppostfiltret markerade meddelandet som skräppost, SFV:NSPM att det inte markerades som skräppost och SFV:SFE att filtreringen hoppades över eftersom avsändaren finns i användarens lista över betrodda avsändare.
  • CAT anger vilken policykategori som tillämpades: SPM, HSPM (skräppost med hög tillförlitlighet), BULK, PHSH, SPOOF.
  • SCL är ett tal, -1 eller från 0 till 9. Äldre guider behandlar det som bedömningen. Microsofts aktuella sida om SCL säger att värdet "inte avgör om skräppostfiltret identifierar ett meddelande som skräppost eller skräppost med hög tillförlitlighet", så läs CAT först.

Rubrikerna innehåller också compauth, Microsofts sammansatta bedömning baserad på SPF, DKIM, DMARC och andra delar av meddelandet. Orsakskoden 001 betyder att implicit autentisering misslyckades, vanligtvis eftersom avsändardomänen inte hade några publicerade autentiseringsposter eller bara en svag policy.

SNDS och JMRP, nu på Postmaster-webbplatsen

Smart Network Data Services, eller SNDS, finns nu på den nya Postmaster-webbplatsen och ersätter den gamla på sendersupport.olc.protection.outlook.com. Tjänsten rapporterar per IP-adress, så du måste bevisa att du äger ett IP-intervall innan den visar dig något. Uppgifterna omfattar volym, klagomålsfrekvens och en färgkod för hur stor del av din trafik som filtret bedömde som skräppost: grönt under 10 %, gult mellan 10 % och 90 %, rött över 90 %. Åtkomsten upphör nu 10 månader efter godkännande eller migrering och måste förnyas.

För en liten avsändare kanske SNDS inte visar något alls, eftersom tjänsten kan utelämna en IP-adress som skickade färre än 100 meddelanden under en viss dag. Och om du skickar via en plattforms delade IP-adresser äger du inte dessa adresser och kan därför inte registrera dem.

JMRP, Junk Mail Reporting Program, är återkopplingssystemet. Registrera dig via SNDS så skickar Microsoft utvalda rubriker från meddelanden som Outlook.com-användare har markerat som skräppost, vanligtvis inom 72 timmar. Lägg till nya IP-adresser i JMRP när du börjar använda dem.

Microsoft kallar klagomålsfrekvensen för skräppost "en av de viktigaste faktorerna" för en avsändares anseende, och i vanliga frågor om SNDS kallas en klagomålsfrekvens under 0,3 % "ett bra riktmärke att sikta på". Nya IP-adresser behöver tid. Microsoft uppger att en ny adress kan förväntas vara fullt upptrappad "inom ett par veckor eller tidigare, beroende på volym och listans kvalitet". Och nej, det finns ingen lista du kan köpa dig in på. På felsökningssidan ställer Microsoft frågan om Outlook.com har en lista över tillåtna avsändare som du kan bli upptagen på och svarar "Nej."

Vad personen i andra änden kan ändra

En del av detta ligger hos mottagaren, och det är rimligt att be läsaren om hjälp. I Outlook.com (Settings, sedan Mail, sedan Junk email) kan användaren markera ett meddelande som Not junk eller lägga till avsändaren i Safe senders and domains. Listan rymmer upp till 10 000 poster, och Microsoft uppger att avsändare på den vanligtvis får sina länkar och bilder aktiverade som standard. En strikt användare kan också aktivera läget "exclusive", som bara tar emot e-post från Contacts och Safe Senders.

Knappen Junk fungerar åt andra hållet. Microsoft använder dessa rapporter för att avgöra om framtida e-post från samma avsändare ska blockeras. I sina rekommendationer för avsändare efterfrågar Microsoft dessutom en länk för att avsluta prenumerationen som är "tydligt synlig". Microsofts text nämner inte de List-Unsubscribe-rubriker för avregistrering med ett klick som Gmail och Yahoo kräver, men eftersom samma kampanj skickas till alla tre skulle jag lägga till dem överallt (de två rubrikerna).

Skrivbordsappen har ett eget Junk Email Filter. Som standard är det inställt på "No Automatic Filtering", med Low, High och "Safe Lists Only" som striktare alternativ. Det sista behandlar allt från avsändare utanför användarens listor över betrodda avsändare som skräppost. Appens listor över betrodda och blockerade avsändare synkroniseras med servern och används även där.

Sedan finns Focused Inbox, som delar upp inkorgen i Focused och Other och, med Microsofts ord, "filtrerar bort störande källor som automatiskt genererad e-post eller massutskick". Other är en flik i inkorgen, och min tolkning är att ett nyhetsbrev som hamnar där redan har passerat skräppostfiltret.

Testa före det riktiga utskicket

På Microsofts egen felsökningssida står det att de "starkt rekommenderar att du testar e-posten innan du skickar riktiga meddelanden". Det är det steget som Email Spam Tester täcker. Du skickar det faktiska meddelandet till en adress som sidan genererar, från den server eller plattform som du verkligen tänker använda. Rapporten visar 42 kontroller: SPF, DKIM och DMARC med anpassning, omvänd DNS, den sändande IP-adressen på 21 blockeringslistor (därför spelar de roll), rubriker för att avsluta prenumerationen samt innehållet. Misslyckade kontroller innehåller en åtgärdsplan och DNS-poster som du kan kopiera. Hur många poäng varje åtgärd är värd hämtas från poängtabellen.

Lägg till testet av inkorgsplacering så skickas samma meddelande även till inkorgar hos Gmail, Outlook, Yahoo och andra leverantörer. Rapporten visar var det hamnade hos var och en, avläst direkt från inkorgen, inklusive Focused eller Other när leverantören sorterar på det sättet. Det är gratis och kräver inget konto. Dokumentationen förklarar varje kontroll och hur många poäng den kostar.

Om nästa steg är att skicka ett supportärende bör du tänka på att Microsofts formulär för leveransproblem endast tar emot ärenden om adresser på @outlook.com, @hotmail.com, @live.com och @msn.com. På sidan med policyer varnas det också för att om du inte följer kraven "it may not be possible for our support team to assist you."

Mer från bloggen

Skicka först det riktiga e-postmeddelandet till en testadress

42 kontroller av SPF, DKIM, DMARC, blockeringslistor, avregistreringsrubriker och innehåll, plus vilken mapp det hamnar i hos Gmail, Outlook, Yahoo och andra leverantörer. Gratis, ingen registrering.

Hämta en testadress