Miksi tärkeät sähköpostit eivät tule perille: SPF, DKIM ja DMARC järjestyksessä

”Asiakas sanoo lähettäneensä sähköpostin, mutta me emme saaneet sitä.” ”Tarjouksemme päätyvät vastaanottajan roskapostikansioon.” Nämä ovat kaksi yleisintä sähköpostikysymystä Google Workspace -käyttäjien joukossa, ja molemmissa tapauksissa syyllinen ei yleensä ole Gmail vaan DNS-tietueet, joita ei koskaan viimeistelty.

Kolme tietuetta, jotka ratkaisevat kaiken

Jotta verkkotunnuksesi sähköposti katsottaisiin aidoksi, vastaanottavan palvelimen on pystyttävä tarkistamaan kolme asiaa:

• SPF määrittää, mitkä palvelimet saavat lähettää postia verkkotunnuksesi nimissä. Yksi TXT-tietue, jossa on oltava include:_spf.google.com ja kaikki muut lähettäjät, jotka käyttävät verkkotunnustasi: CRM, laskutusjärjestelmä, uutiskirjepalvelu, verkkosivuston lomakkeet. Tärkeää: verkkotunnuksella saa olla vain yksi SPF-tietue. Kaksi SPF-tietuetta on yhtä huono kuin ei yhtään.
• DKIM on kryptografinen allekirjoitus, joka todistaa, ettei viestiä ole muutettu matkalla. Ilman omaa avainta Google allekirjoittaa oletusavaimella, jota ei ole sidottu verkkotunnukseesi ja joka ei anna DMARC-tarkistuksessa mitään. Tarkista Hallintakonsolista (Admin console) (Apps → Google Workspace → Gmail → Authenticate email), onko verkkotunnuksellasi tila Authenticating email; jos ei, luo avain ja lisää se DNS:ään. Tämä vaihe jää hyvin usein väliin.
• DMARC määrittää, mitä tehdään viesteille, jotka eivät läpäise tarkistusta. Aloita arvolla p=none ja raportointiosoitteella (rua=), jotta näet, kuka lähettää nimissäsi, ja siirry vasta sen jälkeen arvoon quarantine tai reject.

Miten DMARC oikeasti päättää: sidonta From-osoitteeseen

DMARC läpäistään, jos vähintään yksi tarkistuksista, SPF tai DKIM, onnistuu ja sen verkkotunnus vastaa vastaanottajan näkemän From-kentän verkkotunnusta. Tätä kutsutaan sidonnaksi (alignment): SPF katsoo palautusosoitetta (Return-Path), DKIM katsoo allekirjoituksen verkkotunnusta (d=).

Esimerkki. Uutiskirjepalvelu lähettää osoitteesta [email protected], mutta palautusosoite on [email protected]. SPF läpäistään, mutta sitä ei ole sidottu yritys.fi-verkkotunnukseen, eikä DMARC laske sitä. Viesti läpäisee vain, jos palvelu allekirjoittaa sen DKIM-avaimella, jossa on d=yritys.fi. Siksi jokainen ulkoinen lähettäjä tarvitsee oman DKIM-avaimen verkkotunnuksellesi. Edelleenlähetys on päinvastainen tapaus: SPF epäonnistuu, koska viestin toimittaa vieras palvelin, mutta DKIM-allekirjoitus säilyy ja DMARC läpäistään.

Älä tarkista tulosta pelkillä diagnostiikkatyökaluilla

Google Admin Toolbox ja vastaavat työkalut näyttävät varoituksia myös silloin, kun kaikki on kunnossa, ja päinvastoin. Luotettavampi testi: lähetä viesti omasta verkkotunnuksestasi tiliin toisessa palvelussa ja katso sen lähdekoodi (Gmail: Show original). Rivillä Authentication-Results ratkaiseva on dmarc=pass: jos SPF näyttää fail, mutta DKIM läpäistään ja on sidottu, viesti on kunnossa. Jos DMARC näyttää fail, katso, mikä epäonnistuu ja miksi: verkkotunnus ei vastaa, lähettäjä puuttuu SPF-tietueesta tai DKIM ei ole päällä.

Yksi testi näyttää yhden järjestelmän yhdellä hetkellä: toista se jokaisesta järjestelmästä, joka lähettää nimissäsi. Ja todennus on edellytys, ei toimitustakuu: vastaanottaja arvioi myös verkkotunnuksen maineen, lähetysmäärän, sisällön ja oman käytäntönsä.

Saapuva posti, joka ei koskaan tule perille

Jos tietyn lähettäjän viestit katoavat kokonaan, eivät edes roskapostikansioon, omilla SPF- ja DKIM-tietueillasi ei ole asian kanssa tekemistä: ne koskevat sinun lähettämiäsi viestejä. Aloita Hallintakonsolin Email Log Search -toiminnosta: siitä näkyy, saapuiko viesti ylipäätään Googlelle ja mitä sille tapahtui. Jos ei saapunut, pyydä lähettäjältä palautuneen viestin täydellinen ilmoitus: se kertoo, mikä palvelin kieltäytyi ja miksi. Yleisimmät syyt:

• Verkkosivustosi yhteydenottolomakkeet, jotka lähettävät postia asiakkaan osoite lähettäjänä. Google pitää sitä väärennöksenä. Ratkaisu: lomakkeen on lähetettävä verkkotunnuksesi osoitteesta ja asiakkaan osoite laitetaan Reply-To-kenttään.
• Lähettäjän oma SPF tai DKIM ei läpäise tarkistusta. Ongelma on hänen puolellaan, ja palautuneen viestin ilmoitus näyttää sen.
• Liian aggressiiviset Compliance– tai Content-säännöt Hallintakonsolissa, jotka tehtiin kerran ja unohdettiin.
• Vanha MX-tietue, joka osoittaa edelleen edelliseen postipalvelimeen. Posti menee sinne eikä etene.

Ja ei. Outlook ei ole ratkaisu

Kun posti alkaa käyttäytyä omituisesti, usein yritetään siirtyä Outlookiin tai Apple Mailiin. Google Workspace on rakennettu verkkosovellukseksi; IMAP:n kautta toimii vähemmän ominaisuuksia ja syntyy uusia synkronointiongelmia. Jos perussyy on DNS:ssä, sähköpostiohjelman vaihto ei muuta mitään.

Aiheeseen liittyen: DNS ja sähköpostin todennus ovat osa Google Workspace -käyttöönottoa. Jos siirryt Microsoft 365:stä tai muulta palvelimelta, katso migraatio ilman käyttökatkoja.

Aiheeseen liittyvät artikkelit: Migraatio Microsoft 365:stä Google Workspaceen · Jaettu postilaatikko Google Workspacessa

Sähköpostit katoavat edelleen tai päätyvät roskapostiin? Käymme läpi kyseisen postivirran, kaikki järjestelmät, jotka lähettävät verkkotunnuksesi nimissä, sekä SPF-, DKIM- ja DMARC-tietueet, ja testaamme sitten oikeilla lähetyksillä. Varaa maksuton 30 minuutin auditointi tai soita +371 22 30 50 90.

Pyydä sähköpostin tarkistus