Yleisimmät virheet

Moduuli 8: Muutto ja verkkotunnuksen kuntoon laittaminen · Lukuaika: 13 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen tunnistat kaksitoista yleisintä sähköpostivirhettä niiden oireista, osaat selittää miksi ne tapahtuvat ja osaat korjata ne.

Keskeiset käsitteet: kaksi SPF-tietuetta, liikaa SPF-hakuja, DMARC liian aikaisin reject-tilassa, DKIM ei käytössä lähetyspalvelussa, uudelleenohjaus Gmailiin, catch-all, kävijä lähettäjänä, lähtevä palvelin ilman todennusta, mail.-palvelinnimi ilman sopivaa varmennetta, täysi postilaatikko, MX unohtui muuton yhteydessä, POP3 useilla laitteilla

Näin käytät tätä oppituntia

Jokaisella virheellä on sama rakenne: mitä näet (oire, sellaisena kuin asiakas sen kertoo), miksi se menee pieleen ja miten sen korjaat. Oireet muistuttavat usein toisiaan ("sähköpostini ei tule perille"), vaikka syy on aivan erilainen. Siksi jokaisen virheen kohdalla kerrotaan myös, miten sen vahvistat: mitä todistetta etsit ennen kuin muutat mitään. Älä arvaa, mittaa ensin (oppitunti 6.3).

Numeroita käytetään tehtävässä.

DNS-virheet

Virhe 1: kaksi SPF-tietuetta.
Näet: sähköposti Gmailiin ja Outlook.comiin alkaa yhtäkkiä mennä roskapostiin sen jälkeen, kun olet ottanut käyttöön uuden palvelun (Microsoft 365, uutiskirjeen, kirjanpito-ohjelman). Otsikkoriveillä lukee spf=permerror.
Miksi: palvelu sanoi "lisää tämä SPF-tietue", ja nyt verkkotunnuksella on kaksi TXT-tietuetta, jotka alkavat merkinnällä v=spf1. RFC 7208:n mukaan tämä on pysyvä virhe: SPF ei enää laske ollenkaan.
Vahvista: hae verkkotunnuksesi TXT-tietueet ja laske v=spf1-tietueiden määrä.
Ratkaisu: yhdistä kaikki yhteen tietueeseen (oppitunti 4.2).

Virhe 2: yli kymmenen SPF-hakua.
Näet: sama spf=permerror, mutta tietueita on vain yksi. Usein ilmestyy sen jälkeen, kun on lisätty järjestyksessä niin monenteen include-merkintä.
Miksi: jokainen include, a, mx, exists ja redirect maksaa yhden DNS-haun, myös includejen sisällä. Yli kymmenen haun jälkeen SPF on virheellinen.
Vahvista: tarkista SPF rekursiivisesti laskevalla työkalulla (tehtävä Z4.2).
Ratkaisu: poista palvelut, joita et enää käytä, korvaa a ja mx merkinnöillä ip4/ip6 jos ne ovat kiinteitä, tai anna palvelun lähettää oman bounce-aladomeenin kautta (oppitunti 7.1).

Virhe 3: DMARC suoraan tilaan p=reject.
Näet: sen jälkeen kun DMARC-tietue on asetettu, kirjanpito-ohjelman laskut tai verkkosivuston sähköposti eivät enää tule perille. Vastaanottajat palauttavat 550 5.7.1 viitaten DMARC:iin.
Miksi: kaikkia lähettäjiä ei ollut kartoitettu. Se mikä ei tule linjassa olevan SPF:n tai DKIM:n kautta, hylätään nyt.
Vahvista: DMARC-tietue ja raportit (oppitunti 4.5): mitkä lähteet epäonnistuvat?
Ratkaisu: palaa tilaan p=none raportointiosoitteen kanssa, korjaa kaikki lähettäjät, etene sitten vaiheittain tiloihin quarantine ja reject (oppitunti 4.4). Tämä on myös tämän kurssin suositus.

Virhe 4: DKIM ei ole käytössä lähetyspalvelussa.
Näet: uutiskirjeet eivät pääse yhä useamman vastaanottajan saapuneisiin. Otsikkoriveillä: dkim=pass header.d= palvelun oma verkkotunnus, dmarc=fail.
Miksi: palvelu allekirjoittaa omalla verkkotunnuksellaan, joten DMARC ei voi onnistua DKIM:n kautta, eikä SPF ole myöskään linjassa.
Vahvista: testiuutiskirjeen otsikkorivit (tehtävä Z7.1).
Ratkaisu: todenna verkkotunnuksesi palvelussa (DKIM CNAME:n kautta, oppitunti 7.1).

Uudelleenohjaukseen ja osoitteisiin liittyvät virheet

Virhe 5: kaiken uudelleenohjaus Gmailiin.
Näet: joidenkin lähettäjien sähköposti ei tule perille Gmail-osoitteeseen, johon ohjaat yrityssähköpostisi, tai se päätyy roskapostiin. Joskus lähettäjät saavat bouncen Gmaililta.
Miksi: uudelleenohjauksessa sähköposti saapuu Gmailiin palvelimeltasi, joka ei ole alkuperäisen lähettäjän SPF-tietueessa. Ilman DKIM:ää tai jos lähettäjällä on p=reject, DMARC epäonnistuu. Lisäksi Gmailin näkökulmasta uudelleenohjattu roskaposti näyttää siltä, että sinä lähetät roskapostia, mikä vahingoittaa mainettasi.
Vahvista: bounce tai otsikkorivit Gmailissa (spf=fail tai softfail, lähteenä palvelimesi).
Ratkaisu: älä ohjaa uudelleen, vaan lisää postilaatikko Gmail-sovellukseen puhelimessasi IMAP:n kautta (oppitunnit 2.4 ja 3.3).

Virhe 6: catch-all-osoite.
Näet: paljon roskapostia osoitteisiin, joita ei ole koskaan ollut olemassa (xyz123@example.com), ja täysi postilaatikko.
Miksi: catch-all ottaa vastaan sähköpostin mihin tahansa kuviteltavissa olevaan osoitteeseen. Roskapostittajat kokeilevat satunnaisia osoitteita, ja ne kaikki tulevat perille. Jos ohjaat catch-all-postin lisäksi ulos, syntyy virhe 5 suuremmassa mittakaavassa.
Vahvista: katso postilaatikosta, mihin vastaanottajaosoitteisiin roskaposti meni.
Ratkaisu: poista catch-all käytöstä, ja luo jokaiselle oikeasti käytetylle osoitteelle alias tai postilaatikko (oppitunti 3.3).

Virhe 7: kävijän osoite lähettäjänä lomakkeessa.
Näet: yhteydenottolomakkeen kautta lähetetyt viestit tulevat perille vaihtelevasti, erityisesti eivät niiltä kävijöiltä, joilla on osoite suurella palveluntarjoajalla.
Miksi: verkkosivustosi lähettää viestin "kävijän verkkotunnuksen puolesta". Jos tällä verkkotunnuksella on p=reject tai p=quarantine, vastaanottaja hylkää tai suodattaa sähköpostin (oppitunti 7.3).
Vahvista: tarkista, mitä From-osoitetta lomake käyttää.
Ratkaisu: oma osoite From-kenttään, kävijä Reply-To-kenttään.

Asetusvirheet

Virhe 8: lähtevä palvelin ilman todennusta.
Näet: vastaanottaminen toimii, lähettäminen ei. Virheilmoitus kuten "relay access denied", "authentication required" tai 550 5.7.1. iPhonessa usein: lähtevän palvelimen kentät jätetty tyhjäksi ("valinnainen").
Miksi: lähtevä palvelin välittää sähköpostia vain kirjautuneille käyttäjille. Muuten kuka tahansa voisi käyttää sitä roskapostitykkinä.
Vahvista: lähtevän palvelimen asetukset sähköpostiohjelmassa.
Ratkaisu: ota todennus käyttöön koko sähköpostiosoitteella ja salasanalla, portti 587 STARTTLS:n kanssa tai 465 SSL/TLS:n kanssa (oppitunnit 1.4 ja 2.3).

Virhe 9: mail.<verkkotunnus> palvelinnimenä ilman sopivaa varmennetta.
Näet: ilmoitus virheellisestä varmenteesta tai "palvelimen identiteettiä ei voi varmistaa", tai yhteys ei onnistu ollenkaan.
Miksi: ohjelma tarkistaa, onko palvelinnimi varmenteessa. mail.example.com saattaa osoittaa palvelimeen, mutta ei ole varmenteessa. Tai nimi osoittaa muuton jälkeen yhä vanhaan palveluntarjoajaan.
Vahvista: tarkista sähköpostiportit palvelinnimen kanssa (tehtävät Z2.1 ja Z8.4).
Ratkaisu: käytä palveluntarjoajan ilmoittamaa palvelinnimeä, äläkä koskaan vain klikkaa "jatka silti" (oppitunti 2.1).

Virhe 10: täysi postilaatikko.
Näet: lähettäjät saavat bouncen koodilla 452 4.2.2 tai 552 5.2.2 (postilaatikko täynnä). Et itse huomaa mitään, tai huomaat vain, ettei uutta postia enää tule.
Miksi: postilaatikko on saavuttanut kiintiönsä. Usein syynä ovat vuosien varrella kertyneet liitteet, tai Sent- ja Trash-kansiot, jotka eivät koskaan tyhjene.
Vahvista: postilaatikon käyttöaste paneelissa tai webmailissa.
Ratkaisu: siivoa, arkistoi tai nosta kiintiötä (oppitunti 3.2).

Muuttoon liittyvät virheet

Virhe 11: MX unohtui muuton yhteydessä.
Näet: verkkosivuston tai verkkotunnuksen muuton jälkeen sähköpostia ei enää tule perille, tai se tulee perille paikkaan, jota kukaan ei katso. Tai päinvastoin: olet muuttanut sähköpostin uudelle palveluntarjoajalle, mutta MX osoittaa yhä vanhaan.
Miksi: nimipalvelimen vaihdon yhteydessä koko vyöhyke siirtyy mukana. Jos sähköpostipalveluntarjoajan MX-tietueet eivät ole uudessa vyöhykkeessä, sähköpostisi osoittaa uuteen verkkopalvelimeen. Tai MX:ää ei ole koskaan muutettu.
Vahvista: kysy MX-tietuetta auktoritatiiviselta nimipalvelimelta (tehtävä Z8.2).
Ratkaisu: aseta oikeat MX-tietueet siihen vyöhykkeeseen, joka on todella aktiivinen, ja kopioi sähköposti vielä kerran uudelleen (oppitunti 8.2).

Virhe 12: POP3 useilla laitteilla.
Näet: sähköposti on kannettavalla mutta ei puhelimessa, tai päinvastoin. Kannettavan vaihtamisen jälkeen vuosien sähköpostit ovat kadonneet.
Miksi: POP3 noutaa sähköpostin palvelimelta yhdelle laitteelle ja poistaa sen usein sieltä (oppitunti 1.3).
Vahvista: tilityyppi sähköpostiohjelmassa.
Ratkaisu: siirry IMAP:iin; vedä ensin pelkästään paikallisesti sijaitseva sähköposti IMAP-postilaatikkoon.

Mitä virheillä on yhteistä

Katso listaa vielä kerran. Lähes jokainen virhe syntyy siitä, että joku seurasi yksittäistä ohjetta ("lisää tämä tietue", "ota uudelleenohjaus käyttöön") näkemättä kokonaisuutta. Tämän kurssin punainen lanka:

• tiedä, kuka lähettää sähköpostia verkkotunnuksesi puolesta (inventaario, oppitunnit 4.2 ja 8.1);
• muuta yhtä asiaa kerrallaan ja tarkista sen jälkeen;
• lue todiste: bounce (oppitunti 6.1), otsikkorivit (oppitunti 1.5), DMARC-raportti (oppitunti 4.5) ja DNS auktoritatiiviselta palvelimelta.

Yhteenveto

• DNS-virheet: kaksi SPF-tietuetta, liikaa hakuja, DMARC liian aikaisin reject-tilassa, DKIM ei käytössä lähetyspalvelussa.
• Osoitevirheet: uudelleenohjaus Gmailiin, catch-all, kävijän osoite From-kenttänä.
• Asetusvirheet: ei todennusta lähtevässä liikenteessä, palvelinnimi joka ei ole varmenteessa, täysi postilaatikko.
• Muuttovirheet: MX unohtui, POP3 useilla laitteilla.
• Vahvista syy aina todisteella ennen kuin muutat mitään.

Tietovisa

Tehtävä

Tehtävä Z8.3: Mikä virhe on kyseessä? Saat kahdeksan lyhyttä tapausta, joissa jokaisessa on oire ja pieni todiste (otsikkorivi, bounce, DNS-vastaus tai asetus). Valitse jokaiselle tapaukselle virheen numero (1-12). Ohjelma tarkistaa vastauksen kiinteällä avaimella ja näyttää väärän vastauksen yhteydessä, minkä todisteen jätit huomiotta.

Lue lisää

Näiden artikkeleiden vaiheet koskevat WebOkén paneeleja; muilla palveluntarjoajilla toiminta on vastaavaa.

• DirectAdmin-ohje 18.9: En vastaanota enää sähköpostia
• DirectAdmin-ohje 18.10: En voi lähettää sähköpostia
• En saa enää sähköpostia: näin selvität syyn
• En voi lähettää sähköpostia (vastaanottaminen toimii)
• Sähköpostin uudelleenohjaus toiseen osoitteeseen (forwarderit, catch-all ei suositella)
• Ilmainen DNS-kurssi 8.4: Yleisimmät virheet