Before we start: whose course this is
This course is independent. It is not written, reviewed or endorsed by Google. It describes Google Workspace as it stood when each path was checked, and it does not copy Google's documentation. Google moves admin screens around. When this course and Google's current admin help pages disagree, the help pages win. Those pages are now served from knowledge.workspace.google.com.
So the first habit to build is this: every console path you write in a ticket or a runbook carries the date you checked it.
The two views of the same mailbox
A user sees a small world: an inbox, a Spam folder, their filters, their signature, their calendars and the people they have shared them with. Support sees the machinery behind that world:
- Admin console (
admin.google.com). This is where tenant-wide policy lives. - Organisational units and groups. They decide which policy applies to whom. Level 4 covers them properly.
- DNS (MX records). These tell the rest of the internet where your mail goes.
- Gmail's inbound pipeline. This is where spam, phishing and malware checks, routing and compliance rules, and quarantine act on a message before the user ever sees it.
- Logs. Email Log Search shows what happened to a message.
Think of it like a block of flats. Users decorate their own flat (filters, signature, who can see their calendar). The landlord sets the building rules (whether IMAP is allowed, how external calendar sharing works). Most tickets come down to one question: is this a flat problem or a building problem?
Walkthrough 1: how a message reaches a Workspace inbox
Start where the sender's mail server starts, with DNS. You can do this check read-only from any machine:
# Ask DNS where mail for the domain should go
nslookup -type=mx example.co.uk
# Typical answer for a Workspace domain set up to Google's current guidance:
# example.co.uk MX preference = 1, mail exchanger = smtp.google.com
# If you see another provider's host here (a filtering gateway,
# or an old Exchange server), mail is NOT arriving at Google first.
# That changes everything downstream.
Google's current MX guidance (checked 2 Nov 2026) is a single record: priority 1, value smtp.google.com. Older tenants may still have the longer legacy set of aspmx records. New MX records can take up to 72 hours to be recognised.
Here is the journey, with the admin settings that can change the result at each hop:
1. Sender's server looks up MX -> DNS (your domain registrar, not Google)
2. Delivered to smtp.google.com -> Gmail > Hosts / Routing (inbound gateways)
3. Spam, phishing and malware checks -> Gmail > Spam, Phishing and Malware; Gmail > Safety
4. Routing and compliance rules -> Gmail > Routing; Gmail > Compliance
5. Possibly held in admin quarantine -> Gmail > Compliance (rules) + Admin quarantine
6. Address is a group? Expanded to members -> Groups (membership, who may post)
7. Lands in the user's mailbox -> user's own filters, blocked senders, forwarding
8. User reads it in a web, mobile or desktop client -> Gmail > End User Access (POP/IMAP)
Steps 1 to 6 are building rules. Only step 7, and the client choice in step 8, belong to the user.
Gotcha: when a user says "Gmail lost my email", the message often never reached step 2, or it stopped at step 3 or 5. Searching the inbox harder will not find it. Email Log Search (Menu > Reporting > Email Log Search) shows where the message stopped. By default it searches the last 30 days.
Walkthrough 2: how an invite reaches a guest's calendar
1. User creates an event and adds an outside guest
-> Calendar > Sharing settings > External invitations
("Warn users when inviting guests outside of the domain")
2. Google Calendar sends an invitation email with an .ics attachment
-> this travels as ordinary mail to the GUEST's MX records
3. The guest's mail system and their own calendar settings decide what happens next
(an outside guest may have to RSVP from the email before the event shows up)
4. What the guest can see of your user's calendar
-> Calendar > Sharing settings > External sharing options for primary calendars
The options for external sharing of primary calendars run from "Only free/busy information (hide event details)" up to "Share all information, and allow managing of calendars". A user can share less than the tenant allows, but never more.
Best practice: an invite is just an email once it leaves Google. If the guest "never got it", check outbound mail and the guest's side before you touch Calendar settings.
Walkthrough 3: find the pages and date your paths
Sign in to a test tenant or with your admin role and open each of these. Then record them like this:
# path-check.txt (keep it with your runbooks)
Path Checked Help page updated
Apps > Google Workspace > Gmail > Routing 2026-11-02 2026-10-26
Apps > Google Workspace > Gmail > End User Access 2026-11-02 (POP & IMAP page)
Apps > Google Workspace > Calendar > Sharing settings 2026-11-02 2026-10-26
Reporting > Email Log Search 2026-11-02 (ELS help page)
Check the console path against the matching help article, and note the "last updated" date shown at the bottom of the article. If the screen does not match the article, write down what you actually see. That record will be useful when you escalate.
Trade-off: most settings can be applied per organisational unit or group. Two users can be under different rules even though they sit next to each other. Never assume one setting covers everyone.
Gotcha: Google says changes "can take up to 24 hours but typically happen more quickly." If you changed something ten minutes ago and the user sees no difference, that is normal. Tell them, and agree a time to recheck.
Talking to the user: their settings or the tenant's?
| The user can change | The tenant sets |
|---|---|
| Filters, labels, blocked senders | Spam, phishing and malware policy |
| Their signature and vacation reply | Routing and compliance rules, quarantine |
| Who sees their calendar (within the cap) | The external calendar sharing cap |
| Which client they prefer | Whether POP/IMAP is allowed at all |
A good reply sounds like this: "Your filters are fine. The message was held by a company-wide rule before it reached you. I've checked the log and passed it to the team that manages that rule."
Key takeaways
- Mail reaches Workspace because the domain's MX records point at Google (currently
smtp.google.com). Check them first, read-only, withnslookup. - Before a message reaches the inbox, it passes through settings the user cannot see: Spam/Phishing/Malware, Safety, Routing, Compliance, quarantine and groups.
- A calendar invite to an outside guest is an email with an .ics file. Its delivery depends on mail on both sides.
- Gmail and Calendar settings live under Apps > Google Workspace > Gmail / Calendar. Date every path you record against Google's current help.
- Allow up to 24 hours for a change to take effect, and always tell the user which side of the line their problem sits on.