Outlookin lähettäjävaatimukset toukokuusta 2025 ja hylkäys 550 5.7.515

Palautusviesti 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level tarkoittaa, että Outlook.com hylkäsi viestinne, koska verkkotunnuksenne ei läpäissyt SPF-, DKIM- ja DMARC-tarkistuksia, joita Microsoft edellyttää suurilta lähettäjiltä. Korjaus löytyy DNS:stä ja postia lähettävien järjestelmien asetuksista, ei viestin sisällöstä.

Microsoft julkisti säännöt Microsoft Defender for Office 365 -blogissaan huhtikuussa 2025, ja niiden valvonta alkoi 5.5.2025. Ne koskevat Outlook.comia, Microsoftin kuluttajapalvelua, johon kuuluvat osoitteet outlook.com, hotmail.com ja live.com.

Vaatimukset noudattavat tarkasti sitä, mitä Gmail ja Yahoo ottivat käyttöön vuonna 2024, joten yhdelle palveluntarjoajalle oikein määritetty verkkotunnus on yleensä pitkälti valmis myös muille.

Mitä Microsoft vaatii

Tiedotteen mukaan verkkotunnusten, jotka lähettävät Outlook.comiin yli 5 000 viestiä päivässä, on täytettävä 3 ehtoa:

• SPF:n on mentävä läpi lähettävälle verkkotunnukselle, ja DNS-tietueen on lueteltava valtuutetut IP-osoitteet ja palvelimet tarkasti.
• DKIM:n on mentävä läpi, jotta viestin eheys ja aitous voidaan varmistaa.
• DMARC on julkaistava vähintään käytännöllä p=none, ja sen on oltava kohdistettu joko SPF:ään tai DKIM:ään (Microsoftin mukaan mieluiten molempiin).

Microsoft luettelee lisäksi suurille lähettäjille sähköpostihygienian käytäntöjä ja pidättää oikeuden suodattaa tai estää lähettäjät, jotka sivuuttavat ne:

• Kelvollinen From- tai Reply-To-osoite, joka vastaa todellista lähettävää verkkotunnusta ja voi ottaa vastaan vastauksia.
• Selkeä ja toimiva tilauksen peruutus markkinointi- ja joukkopostissa.
• Virheellisten osoitteiden säännöllinen poistaminen ja palautusviestien käsittely.
• Totuudenmukaiset aiherivit, ei harhaanjohtavia otsakkeita ja vastaanottajat, jotka ovat suostuneet viestienne vastaanottamiseen.

Roskapostikansio vai hylkäys

Alkuperäisen tiedotteen mukaan vaatimuksia täyttämätön posti ohjattaisiin ensin roskapostikansioon. Microsoft päivitti julkaisua 29.4.2025: todennusvaatimukset täyttämättömät viestit hylätään virheellä 550 5.7.515, ja muutos tuli voimaan 5.5.2025 alkuperäisen suunnitelman mukaisesti (lähde).

Käytännössä tämä on hyödyllistä: hylkäys näkyy lähetyslokeissa ja palautusraporteissa, kun taas hiljainen siirto roskapostiin voi jäädä pitkäksi aikaa huomaamatta.

Miksi täysin asiallinen verkkotunnus saa virheen 5.7.515

Tavalliset syyt ovat puutteita asetuksissa, eivät mitään pahantahtoista:

Lähetystyökalu ilman DKIM:ää teidän verkkotunnuksellenne. Uutiskirjealustat, CRM:t ja laskutustyökalut allekirjoittavat usein omalla verkkotunnuksellaan, ellette lisää niiden DKIM-tietueita omaanne.

SPF menee läpi toimittajalle, ei teille. Monet palvelut käyttävät omaa palautuspolkuaan, joten SPF menee läpi verkkotunnukselle bounce.vendor.net. Ilman kohdistettua DKIM:ää DMARC epäonnistuu.

DMARC-tietue puuttuu. Microsoft vaatii vähintään p=none. Puuttuva _dmarc-tietue riittää hylkäykseen.

SPF ylittää hakurajansa. SPF sallii enintään 10 DNS-hakua (RFC 7208, kohta 4.6.4). Yksikin palvelu liikaa, ja SPF palauttaa virheen jokaiselle viestille.

Tuore DNS-muutos. Siirto uudelle DNS-palveluntarjoajalle tai sähköpostipalvelimelle, jonka yhteydessä DKIM-valitsin tai jonkin palvelun SPF-include jäi pois.

Miten syy löytyy

Aloittakaa DNS:stä:

dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com

Selvittäkää seuraavaksi, mikä järjestelmä lähetti palautuneen viestin. Palautusviesti sisältää yleensä alkuperäiset otsakkeet. Lähettäkää sitten samasta järjestelmästä testiviesti hallinnoimaanne Outlook.com-osoitteeseen ja tarkastelkaa Authentication-Results-otsaketta. Microsoft kertoo sen lukemisesta viestiotsakkeiden dokumentaatiossaan. Etsikää tällaisia rivejä:

spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com

Jos smtp.mailfrom tai header.d näyttää teidän verkkotunnuksenne sijaan toimittajan verkkotunnuksen, ongelma on kohdistuksessa. Jos näkyy dkim=none, järjestelmä ei allekirjoita lainkaan.

Miten korjaatte sen

1. Julkaiskaa DMARC-tietue, jos sellaista ei ole: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com.
2. Määrittäkää jokaisessa lähetystyökalussa DKIM omalla verkkotunnuksellanne (työkalu antaa lisättävät CNAME- tai TXT-tietueet).
3. Jos työkalu tukee omaa palautuspolkua, ohjatkaa se omaan aliverkkotunnukseenne, jotta myös SPF on kohdistettu.
4. Yhdistäkää SPF yhdeksi tietueeksi, poistakaa palvelut, joita ette enää käytä, ja pysykää alle 10 haun.
5. Lähettäkää uusi testi Outlook.comiin ja varmistakaa, että kaikki 3 tarkistusta menevät läpi.
6. Kun DMARC-raporteista näkyy, että kaikki oikea posti menee läpi, siirtykää kohti käytäntöä p=quarantine ja myöhemmin p=reject.

Lisäapua varten Microsoft ohjaa lähettäjät Outlookin lähettäjätukiportaaliin. Oppaamme SPF:stä, DKIM:stä ja DMARCista selittää jokaisen tietueen tarkemmin.

Lyhyt tarkistuslista

• SPF menee läpi, yksi tietue, alle 10 hakua.
• DKIM-allekirjoitus omalla verkkotunnuksellanne jokaisessa postia lähettävässä järjestelmässä.
• DMARC julkaistu, vähintään p=none, kohdistettu SPF:ään tai DKIM:ään.
• Palautuslokit tarkistettu virheen 5.7.515 varalta jokaisen DNS- tai palveluntarjoajamuutoksen jälkeen.
• Toimiva tilauksen peruutus ja siistit listat markkinointipostissa.

Datahorsesin rooli

Datahorses valvoo sähköpostiin liittyviä DNS-tietueitanne ulkopuolelta joka päivä, joten poistettu DKIM-valitsin, rikkinäinen SPF-tietue tai heikennetty DMARC-käytäntö huomataan, ennen kuin niistä tulee palautuksia. Asiantuntija käy jokaisen muutoksen läpi ja lähettää kehittäjällenne tarkat korjattavat tietueet. Katsokaa, mitä valvomme ja miten käsittelemme havainnon, tai tutustukaa esimerkkinäkymään.