Sådan opsætter du Google Workspace e-mail korrekt: DNS-guide trin for trin

Googles egen dokumentation for Google Workspace-opsætning er præcis og velskrevet. Den fortæller dig, hvilke records du skal oprette, og hvor du skal gøre det. Men den forklarer sjældent hvad du egentlig gør, og hvorfor det virker. Resultatet er IT-ansvarlige og webudviklere der kopierer værdier ind i deres DNS-panel uden at forstå konsekvenserne - og som derfor ikke ved, hvad de skal kigge efter, når noget går galt.

Denne guide gennemgår hele opsætningen trin for trin, men med forklaringerne som Google udelader. Når du er færdig, har du ikke blot en fungerende Google Workspace-opsætning - du forstår også, hvad der sker bag kulisserne.

De seks DNS-records du skal bruge

Google Workspace kræver præcis seks DNS-records for at e-mail virker korrekt og sikkert. Mange stopper efter MX-records og opdager uger senere, at deres mails ender i spam - fordi SPF, DKIM og DMARC aldrig blev sat op.

Trin 1: Opret Google Workspace-kontoen

Gå til workspace.google.com og opret en konto. Du bliver bedt om at angive det domæne, du vil bruge til e-mail - det er her dit eksisterende domæne kobles til tjenesten. Google opretter en administratorkonto med en midlertidig adresse, mens opsætningen er i gang.

Når kontoen er oprettet, lander du i Google Admin Console. Det er herfra du styrer brugere, sikkerhedsindstillinger og - vigtigt for denne guide - henter de DKIM-nøgler, du skal bruge senere. Lad Admin Console stå åben, du vender tilbage til den flere gange.

Trin 2: Domænebekræftelse via TXT-record

Før Google giver dig adgang til at sende e-mail på vegne af dit domæne, skal du bevise at du faktisk ejer det. Det sker ved at oprette en specifik TXT-record i din DNS - en record med en unik tekststreng, som Google genererer til dig.

Google beder dig oprette en TXT-record på dit roddomæne (@ eller selve domænenavnet) med en værdi der ligner google-site-verification=ABC123.... Logikken er simpel: kun den der kontrollerer DNS for et domæne, kan oprette records der. Når Google efterfølgende forespørger din DNS og finder den record, er ejerskabet bekræftet.

Husk at DNS-ændringer tager tid at propagere. Typisk 5-30 minutter hos moderne DNS-udbydere, men op til 48 timer i sjældne tilfælde. Klik ikke "Bekræft" i Google Admin Console, før du har kontrolleret at recorden faktisk er synlig i DNS.

Du kan verificere at TXT-recorden er propageret, med DNSinfos DNS-opslag - vælg recordtype TXT og søg på dit domæne.

Trin 3: MX-records - Googles fem mailservere

MX-records (Mail Exchanger) fortæller andre mailservere, hvor de skal levere e-mail til dit domæne. Uden korrekte MX-records modtager du ingen e-mail overhovedet.

Google Workspace bruger én MX-record til at modtage e-mail. Prioritetstallet angiver rækkefølgen - lavest tal forsøges først. Den primære server er smtp.google.com med prioritet 1. Har du en ældre Google Workspace-konto oprettet før 2023, kan du have de gamle fem ASPMX-records - de understøttes stadig og kræver ikke ændring, hvis e-mail virker.

Alle fem records oprettes på roddomænet (@). Husk at slette eventuelle eksisterende MX-records fra din tidligere mailhostingudbyder - to sæt MX-records på samme domæne skaber uforudsigelig maillevering.

Trin 4: SPF TXT-record

SPF (Sender Policy Framework) er en TXT-record der angiver, hvilke mailservere der har lov til at sende e-mail på vegne af dit domæne. Når en modtager-mailserver får en mail fra dit domæne, slår den din SPF-record op og tjekker om den afsendende server er på listen. Er den ikke det, er det et stærkt signal om spoofing eller fejlkonfiguration.

For Google Workspace er SPF-recorden enkel:

v=spf1 include:_spf.google.com ~all

Recorden oprettes som en TXT-record på roddomænet. include:_spf.google.com peger på Googles egen SPF-record, der indeholder alle Googles afsendende IP-adresser. ~all betyder "softfail" - mails fra ikke-godkendte servere markeres som mistænkelige, men afvises ikke hårdt. Det er et fornuftigt udgangspunkt, men overvejer du at stramme det til -all (hardfail), skal du være sikker på at alle legitime afsendere er dækket.

Bruger du andre tjenester der sender mail på dine vegne - nyhedsbrevsplatforme, CRM-systemer, faktureringssoftware - skal de inkluderes i SPF-recorden. DNSinfos SPF-generator hjælper dig med at bygge en korrekt record der dækker alle dine afsendere.

Har du allerede en SPF-record fra en tidligere mailudbyder, må du ikke oprette en ny ved siden af. Du kan kun have én SPF TXT-record per domæne. Rediger den eksisterende og tilføj include:_spf.google.com.

Validér din SPF-record med DNSinfos SPF-analyse, der tjekker syntaks, opslag-grænser og dækning.

Trin 5: DKIM-opsætning

DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til udgående mails. Google genererer et nøglepar - en privat nøgle der bruges til at signere mails på Googles servere, og en offentlig nøgle du publicerer i din DNS. Modtager-mailservere bruger den offentlige nøgle til at verificere at mailen faktisk er sendt af Google og ikke er blevet manipuleret undervejs.

Opsætningen foregår i to trin:

1. Generer DKIM-nøglen i Google Admin Console: Gå til Apps - Google Workspace - Gmail - Authenticate email. Vælg dit domæne og klik "Generate new record". Google anbefaler 2048-bit nøgler - vælg det, hvis din DNS-udbyder understøtter det.

2. Opret TXT-record i din DNS: Google giver dig et hostnavn (selector) og en TXT-recordværdi. Opret en TXT-record med det angivne hostnavn og indsæt den lange nøglestreng (der starter med v=DKIM1) som værdi.

DKIM-recorden ser typisk sådan ud:

Når CNAME-recorden er propageret, går du tilbage til Google Admin Console og klikker "Start authentication". Google begynder nu at signere udgående mails med din DKIM-nøgle.

Bemærk: Google Workspace bruger TXT-records til DKIM. Når du skifter til en ny nøgle (fx fra 1024-bit til 2048-bit), skal du generere en ny nøgle i Admin Console og opdatere TXT-recorden i din DNS.

Trin 6: DMARC som næste skridt

DMARC (Domain-based Message Authentication, Reporting and Conformance) er den overordnede politik der binder SPF og DKIM sammen. En DMARC-record fortæller modtager-mailservere, hvad de skal gøre med mails der fejler SPF- eller DKIM-tjek - og den giver dig rapporter om, hvem der sender mail på vegne af dit domæne.

Start med en overvågningspolitik:

v=DMARC1; p=none; rua=mailto:dmarc@ditdomæne.dk

Recorden oprettes som en TXT-record på _dmarc.ditdomæne.dk. p=none betyder at ingen mails afvises endnu - du observerer blot. Rapporterne der sendes til den angivne adresse, viser dig hvilke servere der sender mail fra dit domæne, og om SPF og DKIM godkendes.

Når du har analyseret rapporterne og er sikker på at al legitim mail godkendes, kan du gradvist stramme politikken til p=quarantine og til sidst p=reject. Den komplette DMARC-guide gennemgår hele processen fra overvågning til fuld håndhævelse. DNSinfos DMARC-generator hjælper dig med at bygge den korrekte record.

Typiske fejl og hvad de forårsager

Selv erfarne IT-folk laver disse fejl ved Google Workspace-opsætning:

• Gamle MX-records slettes ikke: Har du tidligere brugt en anden mailudbyder, sidder de gamle MX-records måske stadig i din DNS. Resultatet er uforudsigelig maillevering - noget mail ender hos Google, andet hos den gamle udbyder. Slet alle eksisterende MX-records inden du tilføjer Googles.

• To SPF-records på samme domæne: Mange DNS-paneler tillader det teknisk, men det er ugyldigt ifølge RFC 7208. Modtager-mailservere returnerer en SPF PermError, og alle mails fra domænet fejler SPF-tjekket - uanset om de er legitime eller ej. Har du allerede en SPF-record, skal du redigere den - ikke oprette en ny.

• DKIM aktiveres i Admin Console før CNAME er propageret: Google forsøger at verificere CNAME-recorden med det samme. Fejler det, skal du vente og prøve igen. Tjek altid at CNAME er synlig i DNS inden du klikker "Start authentication".

• Forkert TTL på records under migration: Sætter du en høj TTL (fx 86400 sekunder) på dine MX-records under en migration, kan DNS-caching betyde at ændringer tager meget lang tid at slå igennem. Sænk TTL til 300-600 sekunder et par dage inden en planlagt migration. Forstå DNS-caching for at undgå den klassiske fælde.

• DMARC udelades helt: Uden DMARC er der ingen mekanisme der håndhæver SPF og DKIM-politikken. Domænet forbliver sårbart over for spoofing, og du modtager ingen rapporter om misbrug.

Komplet referencetabel over alle records

Verificér din opsætning

Når alle records er oprettet, bør du verificere dem aktivt frem for at stole blindt på at DNS-panelet har gemt dem korrekt.

Brug DNS-opslag på DNSinfo til at kontrollere MX-, TXT- og CNAME-records enkeltvis. Vælg den relevante recordtype, indtast dit domæne og bekræft at værdierne matcher det, du har oprettet. For MX-records er det særlig vigtigt at prioritetstallene er korrekte.

For SPF-recorden giver SPF-analysen en dybere validering - den tjekker ikke blot om recorden eksisterer, men om syntaksen er gyldig, om include-opslag kan løses, og om du er inden for RFC-grænsen på 10 DNS-opslag.

Hvis du vil tjekke om dit domæne er endt på nogen DNSBL-lister som følge af en tidligere mailkonfiguration, kan blacklist-checket afsløre potentielle leveringsproblemer.

Når de seks records er på plads - domænebekræftelse, fem MX-records, SPF, DKIM og DMARC - fungerer Google Workspace som forventet: mails leveres pålideligt, udgående mails bærer kryptografiske signaturer der bekræfter deres oprindelse, og du har et fundament der aktivt beskytter dit domæne mod at blive misbrugt til spoofing og phishing.