Outlook.com avvisar e-post utan DMARC-post: fel AS9031519

Sedan den 5 november 2026 kommer meddelanden till inkorgar hos Outlook.com, Hotmail, Live och MSN tillbaka med ett nytt fel när avsändardomänen inte har publicerat någon DMARC-post:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
(AS9031519)

Uppgifterna gäller per den 10 november 2026.

Vad Microsoft dokumenterar

Outlook.coms postmaster-riktlinjer innehåller fortfarande endast regeln från den 5 maj 2025: Domäner som skickar fler än 5000 meddelanden per dag till Outlook.com-konton måste klara SPF och DKIM samt publicera en DMARC-post med minst p=none, som är anpassad via SPF eller DKIM. Meddelanden som inte uppfyller detta hamnar först i skräppostmappen och kan senare avvisas med följande fel:

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

För alla andra avsändare formulerar samma sida endast en rekommendation. Tillägget AS9031519 och feltexten Message lacks SPF/DKIM/DMARC Auth Records förekommer varken i postmaster-riktlinjerna eller i supportartikeln om 5.7.515.

Microsoft har endast uttalat sig om den aktuella situationen i Microsoft Q&A-forumen. En moderator märkt som ”Microsoft External Staff” skrev den 9 november att det finns en pågående störning i Exchange-tjänsten vid leverans till Outlook.com, Hotmail.com och Live.com. Den är klassad som Service Degradation och Microsoft undersöker orsaken. Inlägget nämner varken incidentnummer, orsak eller någon tidpunkt för åtgärd. Det finns inget blogginlägg, ingen post i postmaster-riktlinjerna och inget offentligt Service Health-meddelande.

Vad operatörer har mätt

De mest tillförlitliga uppgifterna kommer från e-postleverantörer som har analyserat sina loggar och publicerat dem på sändlistan mailop samt i egna blogginlägg (MailRoute, Mythic Beasts, MXroute, Fastmail, one.com, EasyDMARC). Observationerna stämmer överens:

• Utlösare: Avsändardomänen saknar DMARC-post. SPF och DKIM var giltiga och anpassade i de dokumenterade fallen. Feltexten nämner visserligen alla tre mekanismerna, men avvisningen beror på den saknade DMARC-posten.
• Volym: Även domäner med få meddelanden per vecka påverkas, långt under gränsen på 5000 per dag.
• Mottagare: Endast konsumentinkorgarna (outlook.com, hotmail.com, live.com, msn.com och landsvarianter som hotmail.de eller outlook.be). Enligt tillgängliga rapporter avvisar Exchange Online-tenanter som mottagare inte med detta fel.
• Oregelbundet: Endast en del av meddelandena avvisas. Att skicka samma meddelande på nytt kan fungera.
• Åtgärd: En post med v=DMARC1; p=none räckte i de dokumenterade fallen. Efter publicering tog det mellan några minuter och ungefär en och en halv timme innan Outlook.com återigen accepterade meddelanden.

Två analyser begränsar utlösaren ytterligare: Hos one.com avvisades endast domäner vars uppslagning av _dmarc.<domain> slutar med NXDOMAIN. Domäner där namnet finns men endast saknar en TXT-post (NOERROR utan svar) påverkades inte där. MXroute hittade i en logg 367 avvisade avsändardomäner, varav 286 med NXDOMAIN på _dmarc. Denna avgränsning bygger på data från enskilda operatörer och är inte slutgiltigt klarlagd.

Sedan middagen den 9 november har enskilda berörda rapporterat att avvisningarna har upphört. Microsoft har inte bekräftat detta.

Särskilt fall: Microsoft 365 som avsändare

Tenanter i Microsoft 365 är som avsändare oproportionerligt ofta berörda. Microsoft 365 skapar ingen DMARC-post för en egen domän, och så länge DKIM inte har aktiverats för domänen signerar Exchange Online med tenantens onmicrosoft.com-domän. Rapporten om utebliven leverans kapslar dessutom in avvisningen i en andra statuskod som hänvisar till SPF:

550 5.7.23 The message was rejected because of Sender Policy Framework
violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC
Auth Records (AS9031519)

SPF-posten är i dessa fall vanligtvis korrekt. Det avgörande är det inre felet efter pilen.

Kontrollera din egen domän

TXT-posten under _dmarc.<domain> efterfrågas:

dig +short TXT _dmarc.example.com

Resolve-DnsName -Type TXT -Name _dmarc.example.com

Förklaringar av alternativ

Alternativ	Effekt
+short	dig visar endast postens innehåll
TXT respektive -Type TXT	Typ av post för frågan
_dmarc.example.com respektive -Name	Efterfrågat namn: etiketten _dmarc före avsändardomänen

Tom utdata vid dig +short eller felet DNS name does not exist vid Resolve-DnsName betyder att ingen DMARC-post finns. För underdomäner gäller: Om news.example.com skickar och själv saknar en post, räknas enligt RFC 7489 posten för organisationsdomänen example.com.

Mail-DNS-Check på den här sidan kontrollerar DMARC tillsammans med SPF, DKIM och anpassning i en enda körning.

Omedelbar åtgärd och vägen vidare

Om posten saknas återställer denna post leveransen till Outlook.com:

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

p=none ändrar inget i hanteringen av din e-post hos andra mottagare och kan därför publiceras utan förberedelser. Taggen rua krävs inte för acceptans hos Outlook.com. Utan rua får du dock inga aggregerade rapporter, och utan dessa rapporter saknas grunden för varje nästa steg. Adressen måste nå en inkorg eller en analystjänst som behandlar XML-rapporterna.

p=none skyddar inte domänen mot missbruk. Posten uppfyller endast acceptansvillkoret. För ett effektivt skydd följer dessa steg:

1. Kartlägg alla system som skickar med domänen (e-postservrar, nyhetsbrevstjänst, ERP, webbutik, skannrar).
2. Håll SPF komplett och giltigt för dessa system, med högst tio DNS-uppslagningar.
3. Aktivera DKIM med den egna domänen, i Microsoft 365 per domän i Defender-portalen.
4. Analysera de aggregerade rapporterna under några veckor och korrigera källor som inte är anpassade.
5. Höj policyn till p=quarantine och därefter till p=reject.

De vanliga felen vid publicering av dessa poster (dubbla SPF-poster, för långa DKIM-nycklar, automatiskt tillagt zonnamn) beskrivs i Guiden för DNS-administratörer.

Effekten i Schweiz: 152 kommuner på fem dagar

Mail-säkerhetsindex Schweiz kontrollerar varje natt DNS-posterna för 3364 schweiziska organisationer, däribland 2078 kommuner. Ändringsloggen visar sedan den 6 november en våg av nypublicerade DMARC-poster. Datumet är alltid datumet för den nattliga avstämningen.

På fem dagar har 169 organisationer publicerat en DMARC-post för första gången, varav 152 är kommuner. Antalet organisationer utan DMARC i indexet sjönk från 817 till 650. Tidpunkten sammanfaller med avvisningarna hos Outlook.com. Jag har inte frågat kommunerna själva om orsakerna.

Posterna har följande egenskaper:

• Policy: 139 av de 152 kommunerna har angett p=none, fem p=quarantine, tre p=reject. För fem består posten endast av v=DMARC1 utan taggen p= och är därför ogiltig.
• Rapporter: 114 poster innehåller enbart v=DMARC1; p=none. Totalt har 124 av de 152 kommunerna ingen rua-adress angiven och får därför inga rapporter.
• Centrala omläggningar: Ändringarna sker samlat. Den 10 november tillkom 32 kommuner i Genève, vars e-postservrar alla körs under acg-geneve.ch, samt 26 kommuner i Zürich och 19 i Fribourg. Den 7 november var det åtta kommuner i Nidwalden och sju i Ticino. Samlingen efter e-postserver och kanton tyder på att IT-tjänsteleverantörer har satt posterna för alla kommuner de förvaltar i en enda omgång.

För leverans till Outlook.com räcker dessa poster. De skyddar ännu inte kommunernas domäner mot förfalskade avsändare: Utan rua saknas data för att senare höja policyn. 537 av de 2078 kommunerna i indexet saknar fortfarande DMARC-post.

Bedömning

Det är oklart om Microsoft återtar avvisningen eller bekräftar den som regel. För planeringen spelar det liten roll: Google och Yahoo har krävt DMARC av massavsändare sedan februari 2024, Microsoft sedan maj 2025, och Outlook.coms postmaster-riktlinjer rekommenderar det för alla avsändare. En domän utan DMARC-post kunde de senaste dagarna inte längre levereras tillförlitligt hos en av de största e-postleverantörerna. Posten med p=none och rua publiceras på några minuter och har inga bieffekter för leveransen.