Waar kijkt de Google Workspace-checker naar?
Mail via Google Workspace rust op vier DNS-records: MX-records die naar Google wijzen (smtp.google.com, of de oudere aspmx-hosts die Google nog ondersteunt), een SPF-record met _spf.google.com erin, een DKIM-sleutel op de standaardselector google._domainkey, en een google-site-verification-token dat bewijst dat het domein bij Google is geverifieerd.
De uitkomst lezen
De bovenste regel zegt of de MX-host met de hoogste voorkeur van Google is. Daaronder wordt elk van de vier records gemeld als gevonden of ontbrekend, en staan de fouten met wat je moet aanpassen. Alles komt alleen uit DNS, dus de tool kan niet zien of een domein voor Workspace betaalt of hoe het account is ingericht.
Beat draait op dezelfde engine, volgens een vast schema, over alle 41 checks en 25 blacklists. Wat Beat toevoegt: steeds opnieuw vragen, merken wanneer een antwoord verandert en je vertellen wat je eraan moet doen.
Veelvoorkomende DNS-problemen bij Google Workspace
SPF zonder de include van Google
Google documenteert v=spf1 include:_spf.google.com ~all voor domeinen die alleen via Workspace verzenden. Zonder de include faalt mail die Workspace verstuurt voor SPF, tenzij een andere term de adressen van Google dekt.
Geen sleutel op google._domainkey
Google gebruikt de selector google, tenzij je een andere kiest. Geen sleutel daar betekent meestal dat DKIM nooit is aangezet in de Admin-console.
MX-records van een oude provider
Meng je de MX-hosts van Google met die van een andere dienst, dan wordt inkomende mail over beide verdeeld, en wat op de oude terechtkomt, leest zelden iemand.
Twee SPF-records
Zet je het record van Google naast een bestaand record, dan heb je er twee, en dat maakt RFC 7208 voor elk bericht tot permerror. Voeg de includes samen in één record.