Defaults.Exposed › Korjaukset › Guides

Outlook hylkää sähköpostisi: 550 5.7.515, 550 5.7.509 ja compauth=fail selitettyinä ja korjattuina (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

Kaksi eri Microsoftin järjestelmää hylkää postia. Kuluttaja-Outlook.com palauttelee suuren volyymin lähettäjiä, joiden todennus epäonnistuu (550 5.7.515, valvotaan toukokuusta 2025 alkaen); Exchange Online palauttelee postin, joka epäonnistuu omassa DMARC-hylkäyskäytännössäsi (550 5.7.509). 10,205,070:stä verkkotunnuksesta, jotka valtuuttavat spf.protection.outlook.com:n, 85.0%:lla on tiukka SPF mutta vain 21.7% valvoo DMARC:ia Defaults.Exposed-palvelun 261,086,232 verkkotunnuksen väestölaskennan mukaan.

Useimmat “Outlook hylkää sähköpostini” -ongelmat eivät ole hylkäyksiä lainkaan — ne ovat postia, joka päätyy hiljaa Roskapostiin, otsakkeessa compauth=fail. Tämä opas tulkitsee Microsoft-koodit, näyttää miten lukea Authentication-Results-otsaketta ja opastaa korjauksen järjestyksessä: vahvista SPF, ota käyttöön DKIM omalle verkkotunnuksellesi, julkaise ja valvo DMARC, testaa uudelleen.

Mikä Microsoft-virhe sinulla oikeasti on?

Microsoft käyttää kahta erillistä vastaanottopalvelua, ja ne hylkäävät eri syistä. Selvitä oireesi ensin — väärä diagnoosi tuhlahtaa päivän.

Tarkka NDR-sanamuoto muuttuu; varmista lainaamasi merkkijonot live-palautusta vasten ennen niihin luottamista.

Mitä 550 5.7.515 tarkoittaa?

Se on kuluttaja-Outlook.com/Hotmail-vaatimus, ei Microsoft 365 -tenantvirhe. Toukokuusta 2025 alkaen, yli 5 000 viestiä päivässä kuluttaja-Outlook-osoitteisiin lähettävien on läpäistävä SPF, läpäistävä DKIM ja julkaistava DMARC-tietue (vähintään p=none) linjautuneena From-verkkotunnuksen kanssa. Tämän rajan alittaminen ja kuluttaja-Outlook hylkää viestillä kuten:

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

Kaksi asiaa, jota tämä ei ole: se ei ole vuoden 2026 toimenpide (jos postisi alkoi äskettäin palautella, volyymisi tai DNS:si muuttui, ei sääntö), eikä se koske vastaanottajan M365-tenantasetuksia. Korjaus on alla oleva todennustikkaat — ja satunnaiset kampanjapäivät, jotka ylittävät 5 000/päivä, lasketaan.

Mitä 550 5.7.509 tarkoittaa?

Tämä tulee Exchange Online Protectionista yritystenantilla, ja se tarkoittaa, että omaa DMARC-käytäntöäsi noudatetaan:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Lue tämä huolellisesti — Microsoft ei ole vaikea. Verkkotunnuksesi julkaisee p=reject, tämä viesti epäonnistui DMARC:ssa, ja vastaanottaja teki täsmälleen mitä pyysit. Jos palautunut posti on laillista, jokin lähetyslähde (uutiskirjotyökalu, CRM, skannaus-sähköpostilaite) ei ole todennettu linjautuneesti. Älä heikennä käytäntöä; anna kyseiselle lähteelle linjautunut SPF tai DKIM — katso korjaa DMARC ja p=none:sta p=reject:iin.

Miksi Outlook sijoittaa postini Roskapostiin compauth=fail -arvolla sen sijaan että palauttelisi sen?

Useimmat Microsoft-toimitettavuusongelmat eivät koskaan tuota palautusta. Viesti hyväksytään, pisteytetään ja arkistoidaan Roskapostiin — ainoa todiste on Authentication-Results-otsake. Vastaanottajan postilaatikossa (tai omassa outlook.com-testilaatikossasi), avaa viesti, valitse Näytä viestin lähde ja etsi rivi:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth on Microsoftin komposiittitodennuksen tuomio: jopa kun verkkotunnus ei julkaise DMARC-tietuetta, Microsoft soveltaa implisiittisiä DMARC-tyyppisiä tarkistuksia. Yleisesti näkyvät arvot:

• compauth=fail reason=000 — viesti epäonnistui eksplisiittisessä todennuksessa: verkkotunnuksesi DMARC-käytäntö on quarantine/reject ja viesti epäonnistui siinä.
• compauth=fail reason=001 — viesti epäonnistui implisiittisessä todennuksessa: verkkotunnuksesi ei julkaise (tai riittävästi) todennustietueita, eikä viesti näyttänyt tulevan sinulta. Klassinen “emme koskaan asettaneet DKIM:ää/DMARC:ia” -signaali.
• compauth=fail reason=6xx — implisiittisen todennuksen virhevariantit; 601 tarkoittaa erityisesti, että lähettävä verkkotunnus on yksi organisaatiosi hyväksytyistä omista verkkotunnuksista (organisaation sisäinen väärennös, itse-itselle).

Opetus: Microsoftin kanssa lue otsake, älä vain NDR:ää. spf=, dkim= ja dmarc=-tuomiot samalla rivillä kertovat tarkalleen, mikä osa korjataan.

Miten korjaat Outlook-hylkäykset ja Roskapostiin sijoittelun?

1. Aja ilmainen skannaus ensin. Se arvioi SPF:n, DKIMin ja DMARCin yhdellä kertaa ja näyttää mikä osa epäonnistuu ennen DNS-muutoksia.
2. Vahvista SPF — yleensä jo kunnossa Microsoft 365:ssä. Standardi tietue on v=spf1 include:spf.protection.outlook.com -all, ja M365-asennus asettaa sen: 85.0% 10,205,070:stä verkkotunnuksesta, jotka valtuuttavat spf.protection.outlook.com:n, jo päättyy tiukkaan -all:iin (tiedot päivätty 2026-06-29). Yksi varoitus: vastaanottajat arvioivat SPF:n Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan, ei From-otsiketta — joten uutiskirjotyökalu voi läpäistä SPF omalla palautusosoitteensa verkkotunnuksella samalla tehden mitään sinulle. Siksi vaiheet 3 ja 4 ovat tärkeämpiä.
3. Ota käyttöön DKIM omalle verkkotunnuksellesi — kaksi selector-CNAME:a. M365 allekirjoittaa epälinjautuneella onmicrosoft.com-oletuksella kunnes kytket päälle oman verkkotunnuksen allekirjoituksen: julkaise selector1._domainkey- ja selector2._domainkey-CNAME:t osoittamaan tenantisi avaimiin, sitten ota allekirjoitus käyttöön Defender-portaalissa. Täydellinen klikkauspolku: aseta DKIM Microsoft 365:lle. Jos DKIM näyttää “pass” mutta DMARC epäonnistuu silti, olet oletusallekirjoitusansassa.
4. Julkaise DMARC, valvo se sitten. Aloita v=DMARC1; p=none; rua=mailto:... raporttien saamiseksi, korjaa jokainen laillinen lähde, jonka se paljastaa, sitten nosta p=quarantine:een ja p=reject:iin — porrastettu polku on korjaa DMARC -oppaassa. Tämä on se vaihe, jonka useimmat Microsoft-kaupat ohittavat: vain 21.7% M365-lähettäjäverkkotunnuksista valvoo DMARC:ia.
5. Testaa uudelleen lukemalla otsake. Lähetä kuluttaja-outlook.com-postilaatikkoon, avaa viestin lähde ja vahvista spf=pass, dkim=pass, dmarc=pass ja compauth=pass.
6. Suuren volyymin lähettäjät: täytä kuluttaja-Outlookin vaatimukset. Yli 5 000/päivä tarvitset myös kelvollisen, seuratun From/reply-to-osoitteen, toimivan peruutuslinkin ja puhtaat listat — todennus poistaa 5.7.515; valitusnopeus pitää sinut S3140/S3150 IP-estojen ulkopuolella. Jos olet jo IP-estettynä, SPF/DKIM/DMARC:n korjaaminen ei nosta estoa: pyydä poislistaamista Microsoftin lähettäjätuen kautta ja käytä todennusta syynä, miksi et palaa.

Miksi niin monet Microsoft 365 -verkkotunnukset epäonnistuvat edelleen?

Koska oletus tekee ensimmäisen askeleen puolestasi eikä mitään muuta. 10,205,070:stä verkkotunnuksesta, jotka valtuuttavat spf.protection.outlook.com:n, 85.0%:lla on tiukka SPF — tietue, jonka M365 antaa asennuksessa — mutta vain 21.7% valvoo DMARC:ia Defaults.Exposed-palvelun 261,086,232 verkkotunnuksen väestölaskennan mukaan. M365 antaa tiukan SPF:n oletuksena, sitten useimmat tenantit pysähtyvät sinne — täsmälleen populaatio, jonka compauth rakennettiin nappaamaan (vaikkakin vielä 10.59%:n DMARC-valvontaa kaikista arvioiduista verkkotunnuksista edellä). Täydellinen palveluntarjoajavertailu: sähköpostipalveluntarjoajan SPF-liigataulu.

Usein kysytyt kysymykset

Onko 550 5.7.515 Microsoft 365 -virhe? Ei. Se tulee kuluttaja-Outlook.com/Hotmailista ja kohdistuu >5 000 viestiä/päivä lähettäville, valvotaan toukokuusta 2025 alkaen. Yritys-Exchange Online -hylkäykset käyttävät eri koodeja — yleisimmin 550 5.7.509 (DMARC-hylkäyskäytäntösi) tai 5.7.511 (kielletty lähettäjä).

Saimme 550 5.7.509 mutta posti oli laillista — pitäisikö meidän pudottaa p=reject? Ei — käytäntösi nappasi todentamattoman lähteen, ja se toimii. Löydä lähde otsakkeesta tai DMARC-raporteistasi ja anna sille linjautunut DKIM (tai linjautunut SPF). Heikentäminen p=none:ksi avaa uudelleen tarkan verkkotunnuksen väärennöksen kaikille.

Tarkoittaako compauth=fail, että joku huijaa meitä? Ei välttämättä. reason=001 tarkoittaa yleensä, että oma postisi ei voi todistaa tulevansa sinulta — ei linjautunutta DKIMia, ei DMARC:ia. Vain 21.7% 10,205,070:stä M365-lähettäjäverkkotunnuksesta valvoo DMARC:ia (tiedot päivätty 2026-06-29), joten Microsoft soveltaa implisiittisiä tarkistuksia kaikille muille, ja todentamaton laillinen posti epäonnistuu niissäkin.

Lähetän alle 5 000 sähköpostia päivässä — voinko jättää tämän huomiotta? Vältät 550 5.7.515:n, mutta et Roskapostikansiota: compauth soveltuu missä tahansa volyymissa. Gmail ajaa saman pelin — katso Gmail 550 5.7.26 -opas. Korjaukset ovat ilmaisia; este on tietoisuus, ei kustannukset.

Lähetä omistajalle raportti

Jos korjaat sähköpostia jonkun muun puolesta — asiakkaalle, pomolle, yritykselle, jonka laskut palautuivat — viimeistele työ todisteella. Aja ilmainen skannaus uudelleen DNS:n asettumisen jälkeen ja lähetä arvioitu raportti. Se näyttää SPF:n, DKIMin ja DMARCin muuttuvan vihreiksi selkokielellä, jota yrityksen omistaja voi lukea, ja se on artefakti, jota he tarvitsevat seuraavalla kerralla kun kyberturvallisuusvakuutuksen uusiminen tai asiakkaan turvallisuuskysely kysyy, onko heidän sähköpostinsa todennettu. Korjattu on hyvää; todistettavasti korjattu on se, mistä saat palkan ja he saavat vakuutusturvan.

Tarkista verkkotunnuksesi ilmaiseksi

Katso, missä osassa — SPF, DKIM, DMARC — Microsoft epäonnistuu sinulla — yksityisesti ja vain omistajalle.

Tarkista verkkotunnuksesi → · Korjaa DMARC → · DKIM läpäisee mutta DMARC epäonnistuu → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.