Mitä palautusviestin virhekoodi tarkoittaa?

Kun sähköposti palautuu ja palautusviestissä mainitaan SPF, DKIM, DMARC tai ”authentication level”, vastaanottava palvelin on tarkistanut, tuleeko viesti todella siitä verkkotunnuksesta, josta se sanoo tulevansa, eikä viesti ole läpäissyt tarkistusta. Korjaus tehdään lähettäjän päässä. Palautusviestin teksti on englanniksi, vaikka viestisi olisi suomeksi, joten etsi alta koodi tai englanninkielinen lause. Jokaisen koodin kohdalla kerrotaan, mitä palvelin tarkisti, kenen pitää korjata, mitä tietuetta pitää muuttaa ja miltä vika näyttää DMARC-raportissa.

Etsi virhekoodisi

Tekstit ovat Microsoftin Exchange Online -virhekoodiluettelosta, Microsoftin 5.7.515-ohjeesta ja Googlen Gmail-virhekoodiluettelosta. Oikeassa palautusviestissä on lisäksi verkkotunnuksesi, lähettävän palvelimen osoite ja palvelimen omia tietoja.

Esimerkeissä verkkotunnuksesi on example.com ja lähettävä palvelu newsletter.example.

550 5.7.515 (Outlook.com)

Outlook.com hylkäsi viestin, koska From-osoitteen verkkotunnus ei läpäissyt tarkistuksia, joita Microsoft vaatii suurilta lähettäjiltä. Microsoftin ohjeessa virhe kuuluu näin:

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.

Mitä tarkistettiin. Microsoftin ohjeen mukaan sääntö koskee verkkotunnusta, joka lähettää Microsoftin kuluttajapalveluihin vähintään 5 000 viestiä, ja kaikissa on sama From-verkkotunnus. Ohje ei kerro, miltä ajalta viestit lasketaan. Microsoftin ilmoituksessa raja on yli 5 000 viestiä päivässä. Kuluttajapalveluja ovat Outlook.com, Hotmail, Live.com ja MSN. Rajan ylittävän verkkotunnuksen jokaisen viestin on täytettävä kolme ehtoa. SPF menee läpi. DKIM menee läpi. DMARC menee läpi eli SPF tai DKIM on yhdenmukainen From-osoitteen verkkotunnuksen kanssa, ja käytännöksi riittää p=none. Ilmoitus kertoi hylkäämisen tällä virheellä alkavan 5. toukokuuta 2025.

Huomaa ensimmäinen ehto. Viesti läpäisee DMARC-tarkistuksen jo pelkän DKIM:n ansiosta, mutta Outlook.com vaatii lisäksi SPF:n. Jos palvelu allekirjoittaa postin verkkotunnuksellasi, mutta puuttuu SPF-tietueestasi, sen posti läpäisee DMARC-tarkistuksen kaikkialla, mutta palautuu silti Outlook.comista.

Kuka korjaa. Verkkotunnuksen omistaja eli yleensä sinä, yhdessä sen kanssa, joka postin lähettää. Se voi olla sähköpostipalvelusi, kuten Microsoft 365 tai Google Workspace, lähettävä palvelu, kuten uutiskirje-, laskutus- tai verkkokauppapalvelu, tai operaattorin tai webhotellin postipalvelin. Kysy palvelimen ylläpitäjältä SPF-tietueeseen lisättävä include ja se, allekirjoittaako palvelin lähtevän postin DKIM:llä, mieluiten sinun verkkotunnuksellasi. Vastaanottaja ei voi korjata tätä, koska tarkistukset koskevat sinun verkkotunnustasi.

Tietueet. Kun lähetät Microsoft 365:n ja yhden uutiskirjepalvelun kautta:

example.com                TXT    v=spf1 include:spf.protection.outlook.com include:_spf.newsletter.example -all
s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example
_dmarc.example.com         TXT    v=DMARC1; p=none; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

Verkkotunnuksella on yksi SPF-tietue, joten lisää uusi palvelu siihen äläkä luo toista. Ohjeet: SPF-tietueen korjaaminen, DKIMin käyttöönotto lähettävässä palvelussa ja Julkaise DMARC-tietue.

DMARC-raportissa. Lähteen rivillä policy_evaluated-kohdan dkim on pass, mutta spf on fail, ja auth_results-kohdassa SPF:n tulos on fail. DMARC menee siis läpi, mutta Outlook.com vaatii molemmat. Suoraan Outlook.comiin lähetetyssä postissa SPF epäonnistuu, koska palvelu puuttuu SPF-tietueesta. Mailmoni näyttää tällaisen lähteen DMARC-tarkistuksen läpäisevänä, ja selitys kertoo SPF:n epäonnistuvan, kun posti välitetään eteenpäin tai kun palvelu puuttuu SPF-tietueesta.

550 5.7.509 (Microsoft)

Microsoft hylkäsi viestin, koska se ei läpäissyt DMARC-tarkistusta ja From-osoitteen verkkotunnuksen DMARC-käytäntö on p=reject. Käytäntö on verkkotunnuksen omistajan oma pyyntö, ja Microsoft noudatti sitä. Microsoftin virhekoodiluettelossa koodin 5.7.509 teksti kuuluu näin, ja palautusviestissä sen edellä on 550 5.7.509:

Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.

Sama virhe voi tulla myös koodilla 550 5.7.1. Microsoftin DMARC-ohjeen mukaan Microsoft 365 hylkää käytännön p=reject mukaisesti läpäisemättömän postin jo toimitusvaiheessa, jos vastaanottavalla organisaatiolla on asetus ”Honor DMARC record policy” päällä. Jokainen organisaatio valitsee asetuksen itse, joten sama viesti voi mennä perille yhteen yritykseen ja palautua toisesta.

Mitä tarkistettiin. Ensin DMARC: läpäisikö SPF tai DKIM From-osoitteen verkkotunnukselle. Lähettävän palvelun omalle verkkotunnukselle mennyt läpäisy ei kelpaa. Sitten verkkotunnuksen käytäntö: p=reject pyytää hylkäämään läpäisemättömän postin. Microsoft luettelee syiksi puutteelliset tai virheelliset DNS-tietueet, puuttuvan DKIM-avaimen tai allekirjoittamattoman viestin sekä edelleenvälityksen, joka rikkoo SPF:n tai DKIM:n.

Kuka korjaa. Katso palautusviestin hakasulkeissa olevaa verkkotunnusta.

• Verkkotunnus on sinun. DMARC-tietueesi pyytää hylkäämistä, ja tarvitsemasi posti ei läpäise tarkistusta. Ota lähettävässä palvelussa käyttöön oma DKIM, tai lisää palvelu SPF-tietueeseesi ja käytä sen kanssa omaa palautusosoitetta. Jos korjaus vie aikaa, voit palata käytäntöön p=quarantine, jolloin läpäisemätön posti menee roskapostiin, tai p=none, jolloin se toimitetaan. Kumpikin kohtelee samoin myös nimissäsi väärennettyä postia.
• Verkkotunnus on jonkun muun. Posti lähti toisen verkkotunnuksen nimissä palvelimen kautta, joka ei voi läpäistä DMARC-tarkistusta sille. Näin käy esimerkiksi verkkosivun yhteydenottolomakkeella, joka laittaa kävijän osoitteen From-kenttään. Lähetä omasta verkkotunnuksestasi ja laita toinen osoite Reply-To-kenttään.
• Vastaanottajan yritys haluaa postisi silti. Microsoft 365:ssä yrityksen ylläpitäjä voi päästää yhden lähettäjän läpäisemättömän postin perille, esimerkiksi sallittujen luettelolla. Microsoftin DMARC-ohje kehottaa olemaan tässä varovainen. Se auttaa vain siinä yhdessä yrityksessä, joten korjaa myös lähettävä pää.
• Posti välitettiin eteenpäin. Edelleenvälitys rikkoo SPF:n, ja viestiä muuttava postituslista rikkoo myös DKIM:n. Ohje Edelleenvälitetyt ja postituslistan viestit eivät läpäise DMARC-tarkistusta kertoo, mitä lähettäjä ja välittäjä voivat tehdä.

Tietueet. Palautuksen takana on tällainen tietue:

_dmarc.example.com  TXT  v=DMARC1; p=reject; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

Pidä se ja korjaa lähettävä palvelu. Korjaus on yleensä palvelun antama DKIM-avain sen nimeämän valitsimen alla, esimerkiksi s1._domainkey.example.com CNAME s1.dkim.newsletter.example. Jos palasit välillä lievempään käytäntöön, Siirry tiukempaan DMARC-käytäntöön vie sinut takaisin.

DMARC-raportissa. Lähteen rivillä disposition on reject, ja policy_evaluated-kohdan dkim ja spf ovat fail. RFC 9990 määrittelee arvon reject näin: ”Failed DMARC, marked as reject”. auth_results-kohdassa molemmat menevät usein läpi, mutta palvelun omille verkkotunnuksille. Mailmoni luettelee lähteen sivulla sen viimeisimmät tietueet ja sen, mitä postilaatikkopalvelu niille teki. Kun tunnistamme palvelun, selitys nimeää sen verkkotunnukset ja asetuksen, joka palvelussa pitää ottaa käyttöön.

550 5.7.26 (Gmail)

Gmail esti viestin, koska se ei läpäissyt SPF- eikä DKIM-tarkistusta, tai koska se tuli palvelimelta, joka puuttuu -all-loppuisesta SPF-tietueesta. Gmail vaatii tätä kaikilta lähettäjiltä määrästä riippumatta. Googlen virhekoodiluettelossa koodilla 550 5.7.26 on kolme tekstiä. Kaksi ensimmäistä kuuluvat tähän:

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass. For instructions on setting up authentication, go to Email sender guidelines.

The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [ip-address]. To best protect our users from spam and phishing, the message has been blocked. For more information, go to Email sender guidelines.

Kolmas teksti kertoo DMARC-käytännöstä, ja sen selitys on seuraavassa kohdassa. Tilapäinen muoto 421 4.7.26 alkaa sanoin This email has been rate limited because it is unauthenticated, ja sen syy ja korjaus ovat samat.

Mitä tarkistettiin. Gmailin lähettäjäohjeet vaativat jokaiselta lähettäjältä SPF:n tai DKIM:n ja kertovat, että todentamattomat viestit voidaan merkitä roskapostiksi tai hylätä virheellä 5.7.26. Ensimmäisessä tekstissä Gmail tarkisti SPF:n kuoren lähettäjän verkkotunnukselle eli palautusosoitteelle ja etsi DKIM-allekirjoitusta, eikä kumpikaan mennyt läpi. Toisessa tekstissä palautusosoitteen verkkotunnuksen SPF-tietue päättyy -all, joka käskee hylkäämään kaikki listaamattomat palvelimet, eikä lähettävä palvelin ole listalla.

Kuka korjaa. Palautusviestissä nimetyn verkkotunnuksen omistaja ja lähettävän palvelimen ylläpitäjä.

• Palvelu lähettää verkkotunnuksesi nimissä. Lisää sen include SPF-tietueeseesi ja ota DKIM käyttöön palvelussa. Tavallisin tapaus on uusi palvelu, jota kukaan ei ole ottanut käyttöön verkkotunnuksellesi.
• Oma laite tai palvelin lähettää suoraan. Skanneri, verkkosivu, ajanvarausjärjestelmä tai toimiston palvelin lähettää usein ilman DKIM-allekirjoitusta osoitteesta, jota SPF-tietue ei mainitse. Lähetä sen posti sähköpostipalvelusi palvelimen kautta kirjautuneena, tai lisää palvelin SPF-tietueeseen ja allekirjoita sen posti.
• Et lähettänyt viestiä. Joku muu lähetti postia ja käytti verkkotunnustasi paluuosoitteena, joten palautusviesti tuli sinulle. Tietueesi tekivät tehtävänsä, eikä korjattavaa ole.

Kun -all vaihdetaan muotoon ~all, posti ei muutu todennetuksi. Viesti, joka ei läpäise SPF- eikä DKIM-tarkistusta, saa silti ensimmäisen tekstin.

Tietueet. Kun lähetät Google Workspacen ja yhden uutiskirjepalvelun kautta:

example.com                TXT    v=spf1 include:_spf.google.com include:_spf.newsletter.example -all
s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example

DMARC-raportissa. Ensimmäisen tekstin takana olevan lähteen rivillä ei ole todentamista lainkaan. auth_results-kohdassa ei ole dkim-osaa, eli postissa ei ollut allekirjoitusta, ja SPF:n tulos on fail. disposition kertoo, mitä postille tehtiin DMARC-käytäntösi perusteella, joten käytännöllä p=none siinä voi lukea none, vaikka Gmail esti viestin oman sääntönsä perusteella. Katso siis tarkistuksia, älä disposition-kenttää. Toisen tekstin takana olevalla lähteellä voi olla DKIM-allekirjoitus, joka menee läpi. Silloin rivin auth_results-kohdassa SPF:n tulos on fail palautusviestissä nimetylle verkkotunnukselle, mutta dkim on pass. DMARC voi jopa mennä läpi DKIM:n ansiosta, ja Gmail esti viestin silti -all-säännön vuoksi. Lisää silloin lähettävä palvelin sen verkkotunnuksen SPF-tietueeseen. Mailmoni näyttää, ettei SPF eikä DKIM mene läpi lähteelle, jolla ei ole todentamista. Jos tunnistamme palvelun, selitys kertoo, ettei palvelua ole otettu käyttöön verkkotunnuksellesi. Jos emme tunnista, selitys kertoo, että joku muu voi lähettää nimissäsi.

DMARC-käytäntö esti viestin (Gmail)

Gmail hylkäsi viestin, koska se ei läpäissyt DMARC-tarkistusta ja From-osoitteen verkkotunnuksen käytäntö pyytää hylkäämään sellaisen postin. Gmail noudatti verkkotunnuksen omistajan pyyntöä, eivätkä Gmailin omat lähettäjäsäännöt liity tähän. Googlen virhekoodiluettelossa teksti kuuluu koodin 550 5.7.26 kohdalla näin:

Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. Contact the administrator of domain-name domain if this was legitimate email. To learn about the DMARC initiative, go to Control unauthenticated email from your domain.

Koodilla 451 4.7.26 on tilapäinen muoto, jossa lisäksi lukee but temporary DNS failures prevent authentication. Silloin Gmail ei saanut tarkistusta valmiiksi, koska DNS-haku epäonnistui. Lähettävä palvelin yrittää myöhemmin uudelleen. Jos sama palautus toistuu, kysy DNS-palveluntarjoajaltasi, vastaavatko verkkotunnuksesi nimipalvelimet.

Mitä tarkistettiin. Googlen DMARC-ohjeen mukaan DMARC-tarkistuksen läpäisyyn tarvitaan SPF:n läpäisy ja yhdenmukaisuus tai DKIM:n läpäisy ja yhdenmukaisuus. Sen jälkeen Gmail luki verkkotunnuksen käytännön, ja se pyysi hylkäämään viestin.

Kuka korjaa. Googlen ohje tästä palautuksesta erottaa kaksi tapausta. Jos lähetit viestin Gmaililla, ohje vie Gmailin omiin palautusohjeisiin. Jos lähetit sen muulla sähköpostiohjelmalla, etsi ohjelmasta lähtevän postin palvelimen asetus ja vaihda palvelimeksi se, joka kuuluu osoitteeseen, josta lähetät. Jos se ei auta, ota yhteyttä sähköpostiosoitteesi palveluntarjoajaan.

• Verkkotunnus ei ole sinun. Lähetit toisen verkkotunnuksen osoitteesta, esimerkiksi toisen palveluntarjoajan henkilökohtaisesta osoitteesta tai toisen yrityksen osoitteesta, oman yrityksesi tai operaattorisi lähtevän postin palvelimen kautta. Se palvelin ei voi läpäistä DMARC-tarkistusta toiselle verkkotunnukselle. Lähetä osoitteen oman palvelimen kautta tai omasta verkkotunnuksestasi.
• Verkkotunnus on sinun. DMARC-tietueesi pyytää hylkäämistä, ja jokin palvelu tai palvelin lähettää nimissäsi läpäisemättä tarkistusta. Ota palvelussa käyttöön oma DKIM, tai lisää palvelu SPF-tietueeseen ja käytä sen kanssa omaa palautusosoitetta. Yhteydenottolomake, joka laittaa kävijän osoitteen From-kenttään, epäonnistuu kävijän verkkotunnukselle, joten lähetä se omasta verkkotunnuksestasi ja laita kävijän osoite Reply-To-kenttään.
• Et lähettänyt viestiä. Joku muu lähetti postia verkkotunnuksesi nimissä, ja palautus tuli sinulle. Käytäntösi teki tehtävänsä, eikä korjattavaa ole.

Tietueet. Palautuksen takana on käytäntö p=reject, kuten edellisen kohdan tietueessa. Pidä se ja korjaa lähettävä palvelu. Jos et saa palvelua heti kuntoon, voit palata lievempään käytäntöön: p=quarantine vie läpäisemättömän postin roskapostiin hylkäämisen sijaan, ja p=none toimittaa sen. Kumpikin kohtelee samoin myös nimissäsi väärennettyä postia. Ennen kuin siirryt taas askeleen lähemmäs käytäntöä p=reject, valmius tarkistaa, että jokainen lähde, joka lähettää merkittävän osan postistasi, läpäisee DMARC-tarkistuksen.

DMARC-raportissa. Rivillä disposition on reject ja policy_evaluated-kohdan molemmat tarkistukset ovat fail. auth_results näyttää ne joko epäonnistuneina tai palvelun omille verkkotunnuksille läpi menneinä.

421 4.7.32 ja 5.7.32 (Gmail)

Gmail hidasti tai esti viestin, koska SPF tai DKIM meni läpi, mutta eri verkkotunnukselle kuin From-osoitteessa. Googlen virhekoodiluettelossa koodin 421 4.7.32 teksti kuuluu näin:

Your email has been rate limited because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain.

Koodilla 5.7.32 teksti on muuten sama, mutta alussa lukee Your email was blocked. Googlen taulukko merkitsee senkin vastauskoodilla 421.

Mitä tarkistettiin. Gmailin lähettäjäohjeiden mukaan sen, joka lähettää yli 5 000 viestiä päivässä Gmail-tileille, on käytettävä From-osoitteessa verkkotunnusta, joka on yhdenmukainen SPF:n tai DKIM:n verkkotunnuksen kanssa. Googlen DMARC-ohjeen mukaan väljässä yhdenmukaisuudessa From-osoitteen verkkotunnuksen on oltava sama kuin DKIM-allekirjoituksen d=-tagin verkkotunnus tai sen aliverkkotunnus. SPF:llä vertailukohta on palautusosoitteen verkkotunnus. Tässä viesti läpäisi SPF:n palvelun omalle palautusosoitteelle ja DKIM:n palvelun omalla allekirjoituksella. Molemmat ovat oikeita läpäisyjä, mutta kumpikaan ei ole sinun verkkotunnuksesi.

Kuka korjaa. Sinä, lähettävän palvelun asetuksissa. Palvelut kutsuvat asetusta nimillä custom DKIM, authenticated domain, domain authentication tai custom domain. Ota se käyttöön verkkotunnuksellesi ja julkaise palvelun antamat tietueet. Monessa palvelussa voit myös käyttää palautusosoitetta oman verkkotunnuksesi alla, jolloin SPF:kin on yhdenmukainen. Jos palvelu ei tarjoa kumpaakaan, sen nimissäsi lähettämä posti ei voi olla yhdenmukainen verkkotunnuksesi kanssa. Pyydä palvelun tuelta omaa DKIM:ää tai lähetä posti palvelun kautta, jossa se on. Jos lähetät omalta palvelimeltasi, allekirjoita posti siellä DKIM:llä verkkotunnuksellesi.

Parin seuraavan päivän raportit näyttävät, toimiko korjaus. Yksi yhdenmukainen tarkistus riittää: kun DKIM tai SPF on yhdenmukainen, palvelun posti läpäisee DMARC-tarkistuksen ja täyttää Gmailin säännön.

Tietueet. DKIM-tietue on palvelun nimeämän valitsimen alla, yleensä jompaakumpaa muotoa:

s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example
s1._domainkey.example.com  TXT    v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

CNAME osoittaa avaimeen, jota palvelu ylläpitää ja vaihtaa. TXT-tietueessa on itse avain. Palvelu kertoo, kumpaa käytetään, ja antaa tarkan nimen ja arvon. Ohjeet: DKIMin käyttöönotto lähettävässä palvelussa.

DMARC-raportissa. auth_results näyttää molempien tarkistusten menevän läpi verkkotunnukselle newsletter.example, mutta policy_evaluated näyttää molemmat epäonnistuneina, koska siinä on yhdenmukaisuuden tulos. Microsoftin DMARC-ohje kutsuu läpäisyä ilman yhdenmukaisuutta nimellä ”classic alignment problem”. Mailmoni näyttää Lähteet-sivulla, että kumpikin tarkistus meni läpi toiselle verkkotunnukselle. Kun tunnistamme palvelun, selitys nimeää sen verkkotunnukset ja kehottaa ottamaan palvelussa käyttöön oman DKIM:n ja oman palautusverkkotunnuksen.

4.7.27 ja 5.7.27 (Gmail)

Gmail hidasti tai esti viestin, koska SPF ei mennyt läpi. Googlen virhekoodiluettelossa koodien 550 5.7.27 ja 421 4.7.27 tekstit kuuluvat näin:

This message was blocked because it didn't pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF.
Authentication results: SPF with ip-address = did not pass

Your email has been rate limited because SPF authentication didn't pass for this message. Gmail requires all bulk email senders to authenticate their email with SPF.
Authentication results: SPF domain-name with IP address: ip-address = Did not pass.

Mitä tarkistettiin. Gmailin lähettäjäohjeet vaativat yli 5 000 viestiä päivässä Gmail-tileille lähettäviltä sekä SPF:n että DKIM:n. Viesti, joka läpäisee DKIM:n, tarvitsee siis silti SPF:n. SPF tarkistaa palautusosoitteen verkkotunnuksen, ei From-osoitetta. SPF ei mene läpi kolmessa tapauksessa: palvelin puuttuu SPF-tietueesta, tietueessa on virhe, kuten kaksi SPF-tietuetta samalla verkkotunnuksella, tai tietue tekee liikaa DNS-hakuja. SPF-tarkistus saa tehdä enintään 10 hakua, ja sen jälkeen SPF palauttaa virheen.

Kuka korjaa. Sen verkkotunnuksen omistaja, jolle SPF tarkistettiin. Jos palautusosoite on sinun verkkotunnuksesi alla, lisää palvelin tai palvelun include SPF-tietueeseesi. Jos se on palvelun oma verkkotunnus, korjaus kuuluu palvelulle. Kerro sen tukeen palautusviestin palvelinosoite.

Tietueet. Verkkotunnuksella on yksi SPF-tietue, jossa ovat kaikki sen nimissä lähettävät palvelimet ja palvelut, esimerkiksi v=spf1 include:_spf.google.com include:_spf.newsletter.example -all. Jos tietue tekee jo paljon DNS-hakuja, poista ensin palvelut, joita et enää käytä. Ohjeet: SPF-tietueen korjaaminen ja SPF-tietueessa on liikaa DNS-hakuja.

DMARC-raportissa. policy_evaluated-kohdan dkim on pass ja spf on fail. Rikkinäinen tietue näkyy auth_results-kohdassa arvona permerror tai temperror. Mailmoni näyttää tällaisen lähteen DMARC-tarkistuksen läpäisevänä, ja selitys kertoo SPF:n epäonnistuvan, kun posti välitetään eteenpäin tai kun palvelu puuttuu SPF-tietueesta. DNS-välilehti tarkistaa itse tietueen: se näyttää tietueen virheet ja sen, montako DNS-hakua tietue tekee.

4.7.30 ja 5.7.30 (Gmail)

Gmail hidasti tai esti viestin, koska siinä ei ollut DKIM-allekirjoitusta, joka olisi mennyt läpi. Googlen virhekoodiluettelossa koodien 550 5.7.30 ja 421 4.7.30 tekstit kuuluvat näin:

This message was blocked because it didn't pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM.
Authentication results: DKIM = did not pass

Your email has been rate limited because DKIM authentication didn't pass for this message. Gmail requires all email bulk senders to authenticate their email with DKIM.
Authentication results: DKIM = Did not pass.

Mitä tarkistettiin. Gmail vaatii yli 5 000 viestiä päivässä Gmail-tileille lähettäviltä myös DKIM:n, vaikka SPF menisi läpi. Gmail etsi allekirjoitusta, haki sen nimeämän julkisen avaimen DNS:stä ja tarkisti allekirjoituksen. Joko allekirjoitusta ei ollut, tai se ei kelvannut: avain puuttuu DNS:stä, palvelu on vaihtanut avaimen ja DNS:ssä on yhä vanha, tai viestiä on muutettu allekirjoittamisen jälkeen.

Kuka korjaa. Postin lähettäjä allekirjoittaa, ja verkkotunnuksen omistaja julkaisee avaimen. Jos allekirjoitus puuttuu, ota DKIM käyttöön palvelussa tai sähköpostipalvelussasi ja julkaise sen antama tietue. Allekirjoita omalla verkkotunnuksellasi, niin allekirjoitus kelpaa myös DMARC-tarkistukseen. Jos allekirjoitus ei kelpaa, vertaa DNS:n avainta palvelun näyttämään saman valitsimen alla. Ohjeet: DKIM-avaimen tarkistus DNS:stä ja Otin DKIM:n käyttöön, mutta lähde ei läpäise DMARC-tarkistusta.

Tietueet. DKIM-avain on valitsimensa alla, _domainkey-nimen alla verkkotunnuksessasi, CNAME- tai TXT-tietueena kuten edellisessä kohdassa. TXT-avaimen joudut vaihtamaan itse, kun palvelu vaihtaa avaimensa. Kopioi nimi ja arvo täsmälleen niin kuin palvelu ne näyttää.

DMARC-raportissa. policy_evaluated-kohdan dkim on fail. Jos auth_results-kohdassa ei ole dkim-osaa lainkaan, postissa ei ollut allekirjoitusta. Epäonnistunut allekirjoitus näkyy dkim-osana, jossa on verkkotunnuksesi, valitsin ja fail. Jos lähteellä ei ole allekirjoitusta, mutta SPF on yhdenmukainen, Mailmoni näyttää lähteen DMARC-tarkistuksen läpäisevänä ja selitys kehottaa ottamaan DKIM:n käyttöön palvelussa. Jos allekirjoitus ei kelpaa, selitys kehottaa tarkistamaan valitsimen DKIM-avaimen DNS:stä.

4.7.40 ja 5.7.40 (Gmail)

Googlen virhekoodiluettelossa koodien 421 4.7.40 ja 550 5.7.40 tekstit kuuluvat näin:

421 4.7.40 Your email has been rate limited because the sending domain doesn't have a DMARC record, or the DMARC record doesn't specify a DMARC policy. Gmail requires all bulk email senders to add a DMARC record to their sending domain.
550 5.7.40 Your message was blocked because the sending domain doesn't have a DMARC record or the DMARC record doesn't specify a DMARC policy. Gmail requires all bulk email senders to add a DMARC record to their sending domain.

Gmail etsi DMARC-tietuetta From-osoitteen verkkotunnuksen _dmarc-nimen alta eikä löytänyt sitä, tai tietueesta puuttui p-tagi. Gmailin lähettäjäohjeet vaativat tätä yli 5 000 viestiä päivässä Gmail-tileille lähettäviltä ja toteavat, että käytännöksi riittää none. Verkkotunnuksen omistaja korjaa tämän julkaisemalla yhden tietueen:

_dmarc.example.com  TXT  v=DMARC1; p=none; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

Ennen tätä tietuetta et saa yhtään DMARC-raporttia, koska postilaatikkopalvelut lähettävät raportit tietueen rua-osoitteeseen. Ohje Julkaise DMARC-tietue näyttää vaiheet.

4.7.28 ja 5.7.28 (Gmail)

Tämä virhe ei koske todentamista. Gmail hidasti tai esti viestin, koska se havaitsi epätavallisen paljon ei-toivottua postia viestin lähtöpaikasta: lähettävästä IP-osoitteesta, sen verkosta, DKIM- tai SPF-verkkotunnuksesta tai viestin linkeistä. Googlen virhekoodiluettelossa koodin 550 5.7.28 teksti kuuluu näin:

There is an unusual rate of unsolicited email originating from your IP address. To protect our users from spam, email sent from your IP address has been blocked. To review our bulk email senders guidelines, go to Email sender guidelines.

Koodilla 421 4.7.28 on kahdeksan tilapäistä muotoa. Jokainen nimeää, mitä Gmail laski. Tässä niiden kaksi ensimmäistä virkettä:

Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited.
Gmail has detected an unusual rate of email originating from your IP address ip-address. To protect our users from spam, email sent from your IP address has been temporarily rate limited.
Gmail has detected an unusual rate of unsolicited email originating from your IP Netblock ip-address. To protect our users from spam, email sent from your IP Netblock has been temporarily rate limited.
Gmail has detected an unusual rate of unsolicited email originating from your DKIM domain domain-name. To protect our users from spam, email sent from your domain has been temporarily rate limited.
Gmail has detected an unusual rate of unsolicited email originating from your SPF domain domain-name. To protect our users from spam, email sent from your domain has been temporarily rate limited.
Gmail has detected an unusual rate of unsolicited email containing one of your URL domains. To protect our users from spam, email with the URL has been temporarily rate limited.
Gmail has detected an unusual amount of unsolicited email originating from your IP address. To protect our users from spam, email sent from your IP address has been temporarily blocked.
Gmail has detected this sender exceeded the quota for sending messages that have the same Message-ID:. To best protect our users, the message has been temporarily rejected.

Mitä tarkistettiin. Gmail mittaa, kuinka suuren osan postista vastaanottajat merkitsevät roskapostiksi. Googlen lähettäjäohjeiden usein kysytyissä kysymyksissä sanotaan, että roskapostiprosentti lasketaan päivittäin ja että sen pitäisi olla alle 0,1 % eikä koskaan 0,3 % tai enemmän. Lähettäjäohjeet pyytävät jokaiselta lähettäjältä määrästä riippumatta, että Postmaster Toolsin näyttämä roskapostiprosentti pysyy alle 0,3 %:n. Myös määrä vaikuttaa: lähettäjäohjeiden mukaan Gmail hylkää viestit yleensä koodilla 4.7.28, kun lähettäjä ylittää kiintiönsä. Jaetussa IP-osoitteessa kaikkien sitä käyttävien lähettäjien toiminta vaikuttaa kaikkien maineeseen.

Kuka korjaa. Palautusviestin teksti kertoo, mistä etsiä.

• IP-osoite tai verkko jaetulla palvelimella. Sähköpostipalvelusi, lähettävän palvelun tai webhotellin palvelin lähettää monen asiakkaan postia, ja heidänkin postinsa lasketaan. Lähetä palautusviesti palvelun tukeen, koska palvelin on heidän.
• IP-osoite palvelimella, jota ylläpidät itse. Googlen lähettäjäohjeiden mukaan älä lähetä postia vähintään 10 minuuttiin ja selvitä syy. Jos virheilmoitus ei kerro, ylittyikö DKIM-, SPF- vai IP-kiintiö, oleta, että kaikki kolme ylittyivät. Lähetä 10 minuutin kuluttua yhden yhteyden kautta. Jos se epäonnistuu, odota taas 10 minuuttia. Jos se onnistuu, lisää yhteyksiä yksi kerrallaan.
• Oma DKIM- tai SPF-verkkotunnuksesi. Valitukset koskevat omaa postiasi. Lähetä postia vain niille, jotka ovat sitä pyytäneet, ja tee listalta poistumisesta helppoa. Googlen usein kysytyissä kysymyksissä neuvotaan antamaan vastaanottajille helppo tapa perua markkinointiviestit.
• Linkkien verkkotunnukset. Jokin verkkotunnus, johon viestin linkit osoittavat, esiintyy myös ei-toivotussa postissa. Tarkista viestin kaikki linkit, myös lähettävän palvelun mahdollisesti lisäämät seurantalinkit.
• Sama Message-ID. Postia lähettävä ohjelma antaa monelle viestille saman Message-ID:n. Ohjelman ylläpitäjä korjaa sen niin, että jokainen viesti saa omansa.

Roskapostiprosentti Postmaster Toolsissa. Googlen Postmaster Tools -ohjeen mukaan palvelu näyttää henkilökohtaisille Gmail-tileille lähettämäsi postin roskapostiprosentin, maineen, todentamisen ja toimitusvirheet. Kirjaudu Postmaster Toolsiin, klikkaa Hallinnoi verkkotunnuksia ‑sivulla Lisää uusi verkkotunnus ja anna verkkotunnus, jolla todennat lähtevän postin SPF:llä, DKIM:llä tai molemmilla. Valitse Luo. Vahvista verkkotunnus kopioimalla TXT- tai CNAME-tietue Vahvista verkkotunnuksen omistajuus ‑ikkunasta DNS-asetuksiisi ja klikkaamalla Vahvista. Tiedot koskevat vain henkilökohtaisille Gmail-tileille lähetettyä postia, eivät Google Workspacea käyttävien yritysten postilaatikoita.

Tietueet. Mikään SPF-, DKIM- tai DMARC-muutos ei poista tätä palautusta. Ainoa tietue, johon virhe liittyy, on Postmaster Toolsin vahvistustietue. Lisää palveluun se verkkotunnus, jolla postisi on allekirjoitettu. Jos palvelu allekirjoittaa postisi omalla verkkotunnuksellaan, ota siinä ensin käyttöön oma DKIM.

DMARC-raportissa. Koontiraportit eivät näytä tätä palautusta. Raportin rivillä on lähettävä osoite, viestimäärä sekä DMARC-, SPF- ja DKIM-tulokset, ei valituksia. Jos posti läpäisee DMARC-tarkistuksen, sen rivit näyttävät tavallisilta, vaikka Gmail esti sen. Yhden lähettävän osoitteen count-arvon äkillinen kasvu voi osua samaan aikaan kuin määrä, jota Gmail hidasti.

4.7.29 ja 5.7.29 (Gmail)

Tämäkään virhe ei koske todentamista. Gmail hidasti tai esti viestin, koska viestin lähettänyt palvelin ei salannut yhteyttä Gmailiin TLS:llä. Googlen virhekoodiluettelossa koodien 550 5.7.29 ja 421 4.7.29 tekstit kuuluvat näin:

This message was blocked because it wasn't sent over a TLS connection. Gmail requires all bulk email senders to use TLS/SSL for SMTP connections.
To set up TLS for email, visit TLS & SSL connections. To learn more about Gmail requirements for bulk email senders, visit Email sender guidelines.

Your email has been rate limited because you're not using a TLS connection. Gmail requires all bulk email senders to use TLS/SSL for SMTP connections.
To set up TLS for email, visit TLS & SSL connections. To learn more about Gmail requirements for bulk email senders, visit Email sender guidelines.

Mitä tarkistettiin. Salasiko Gmailiin yhteyden ottanut palvelin yhteyden TLS:llä. Palautusviesti puhuu joukkolähettäjistä (bulk), mutta Googlen lähettäjäohjeet luettelevat TLS-yhteyden kaikkia lähettäjiä koskevissa vaatimuksissa. Vaatimus koskee siis sinua määrästä riippumatta.

Kuka korjaa. Viestin lähettäneen palvelimen ylläpitäjä. Se voi olla sähköpostipalvelusi, lähettävä palvelu tai webhotelli, tai oma palvelimesi tai laitteesi, kuten toimiston postipalvelin, skanneri tai itse postia lähettävä verkkosivu. Jos kyse on palvelusta, lähetä palautusviesti sen tukeen ja kerro lähetysaika ja vastaanottajan osoite. Jos palvelin tai laite on oma, ota sen asetuksista käyttöön lähtevän postin TLS, jota kutsutaan usein nimellä STARTTLS. Jos laite ei osaa TLS:ää, lähetä sen posti sähköpostipalvelusi palvelimen kautta kirjautuneena.

Tarkista, käyttääkö lähettäjä TLS:ää. Lähetä palvelusta tai palvelimelta viesti Gmail-osoitteeseen, jota luet. Googlen ohjeen mukaan avaa viesti Gmailissa, valitse yläreunasta vastaanottajan vierestä Näytä tiedot ja katso ikkunasta Suojaus-kohdan vieressä oleva salaustyyppi. Vakiosalaus (TLS) tarkoittaa, että yhteys oli salattu. Salausta ei tueta tarkoittaa, ettei ollut. Googlen mukaan sähköpostia ei ehkä salata, jos lähettäjän sähköpostipalvelu ei tue TLS:ää.

Tietueet. Ei yhtään. Lähtevän postin TLS on lähettävän palvelimen asetus. TLS:ään liittyvät DNS-tietueet, MTA-STS ja TLS-RPT, koskevat postia, jota muut palvelimet lähettävät sinun verkkotunnuksellesi.

DMARC-raportissa. Ei mitenkään. Koontiraportin rivillä on todentamisen tulokset, ei tietoa yhteyden salauksesta, ja ilman TLS:ää lähetetty posti voi läpäistä DMARC-tarkistuksen. TLS-raportit kertovat salauksesta, mutta muiden palvelimien sinun verkkotunnuksellesi lähettämästä postista.

Kenen pitää korjata

Katso, minkä verkkotunnuksen palautusviesti nimeää. Koodeissa 5.7.515 ja 5.7.509 sekä DMARC-käytännön tekstissä se on From-osoitteen verkkotunnus. SPF-teksteissä se on kuoren lähettäjän verkkotunnus eli palautusosoite.

• Verkkotunnus on sinun. Korjaat sen itse yhdessä sen kanssa, mikä postin lähetti: sähköpostipalvelusi, lähettävä palvelu, kuten uutiskirje- tai laskutuspalvelu, tai oma palvelimesi. Muutos tehdään palvelun asetuksiin ja verkkotunnuksesi DNS-tietueisiin.
• Verkkotunnus ei ole sinun. Lähetit toisen osoitteen nimissä palvelimen kautta, joka ei saa lähettää sen puolesta. Näin käy verkkosivun lomakkeella, joka laittaa kävijän osoitteen From-kenttään, ja sähköpostiohjelmalla, joka lähettää toisen verkkotunnuksen osoitteesta yrityksen palvelimen kautta. Jos sen verkkotunnuksen DMARC-käytäntö pyytää hylkäämistä, posti palautuu. Lähetä omasta verkkotunnuksestasi tai osoitteen oman palvelimen kautta.
• Et lähettänyt viestiä. Joku muu lähetti postia ja käytti verkkotunnustasi paluuosoitteena, joten palautusviesti tuli sinulle. Tietueesi tekivät tehtävänsä, eikä korjattavaa ole.

Vastaanottaja ei yleensä voi korjata näitä, koska tarkistukset koskevat lähettävää verkkotunnusta. Poikkeus on koodi 5.7.509 yrityksessä, joka käyttää Microsoft 365:tä. Sen ylläpitäjä voi päästää yhden lähettäjän läpäisemättömän postin perille, ja Microsoftin DMARC-ohje kehottaa olemaan tässä varovainen. Se auttaa vain siinä yhdessä yrityksessä.

Numerolla 4 alkava koodi on tilapäinen. RFC 3463 sanoo siitä: ”If this code accompanies a delivery failure report, sending in the future may be successful.” Syy ei kuitenkaan katoa, ennen kuin joku korjaa sen. Numerolla 5 alkava koodi on pysyvä: ”Some change to the message or the destination must be made for successful delivery.”

Miltä tämä näyttää DMARC-raportissa

Jokaisessa koontiraportissa on oma rivi kullekin lähettävälle osoitteelle ja jokaiselle tulosyhdistelmälle, jonka sen posti sai. Kaksi rivin osaa kertoo, mistä palautuksessa oli kyse:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <dkim>
    <domain>newsletter.example</domain>
    <selector>s1</selector>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>bounces.newsletter.example</domain>
    <result>pass</result>
  </spf>
</auth_results>

• policy_evaluated sisältää verkkotunnuksesi DMARC-tuloksen. Sen dkim ja spf ovat yhdenmukaisuustarkistusten tuloksia, ja disposition on RFC 9990:n kohdan 3.1.1.9 mukaan ”The result of applying the DMARC policy”.
• auth_results sisältää SPF:n ja DKIM:n tavalliset tulokset ja sen verkkotunnuksen, jolle kukin tarkistettiin.

Tällä rivillä SPF ja DKIM menevät läpi, mutta palvelun verkkotunnuksille, joten DMARC ei mene läpi. Microsoftin DMARC-ohje kutsuu tätä nimellä ”classic alignment problem”. disposition noudattaa omaa DMARC-käytäntöäsi, joten käytännöllä p=none siinä voi lukea none myös postille, jonka Gmail tai Outlook.com hylkäsi omien lähettäjäsääntöjensä perusteella. Katso siis tarkistuksia, älä disposition-kenttää.

Mailmoni lukee nämä raportit puolestasi: Lähteet-sivu näyttää jokaisen lähteen SPF- ja DKIM-tuloksen verkkotunnuksellesi, ja lähteen selitys kertoo, mitä pitää muuttaa.