Troubleshooting mail flow

Mail problems are the helpdesk calls that never stop. During coexistence with Exchange they multiply, because every message to a migrated user takes an extra hop through the routing subdomain g.birchline.example that the second course set up. In the tenth session Sofia hands Owen five real complaints from the IT pilot rehearsal on test accounts and asks him to solve each one with evidence rather than guesses. This lesson covers a repeatable method for mail troubleshooting, the tools Google provides, and the problems that come up most often in a migration like Birchline's.

A method before the tools

Sofia's method has five questions, asked in order, because each answer narrows the next search.

• Which message? Get the sender, the recipient, the approximate time and, best of all, the subject or the message ID. "Mail isn't working" cannot be investigated; "the invoice from accounts@supplier.example to Ines at about 10:15 on Tuesday" can.
• Did it reach Google? If Google has no record of the message, the problem is before Google: the sender's system, DNS or the MX records, or Exchange still holding it.
• What did Google do with it? Delivered to the inbox, put in spam, quarantined, rejected, routed somewhere else, or delivered and then deleted by the user.
• Why? The log entry and the message headers show the reason: an authentication failure, a compliance rule, a routing setting, a spam verdict.
• What is the fix, and who owns it? Some fixes are Birchline's, such as a routing setting; some belong to the sender, such as their SPF record.

Email Log Search

Email Log Search (ELS), under Reporting in the Admin console, finds messages that passed through Gmail for the organization and shows what happened to each. Google's help pages describe searches by date range, which is required, and by sender, recipient, sender or recipient IP, subject and message ID. Searches over the past 30 days show the full delivery steps; for messages older than 30 days, the search needs the recipient's full address and the message ID and shows only what happened after delivery. Each search returns up to 1,000 messages, results can take from a minute to an hour depending on how many match, and the results can be exported. ELS never shows message content. Using it needs the Gmail Settings administrator privilege.

ELS answers the second and third of Sofia's questions directly. If the search finds nothing for a message the sender insists was sent, Google never received it, and Owen looks earlier in the path: DNS, the sender's own logs, or Exchange.

Message headers and the Toolbox

Every message carries headers that record its journey: a Received line added by each server it passed through, with times, and authentication results added by Gmail. In Gmail, a user or the helpdesk can open a message and choose Show original to see them. Google's Admin Toolbox includes Messageheader, which reads pasted headers and lays out each hop, the delay at each one and the authentication results, and Check MX, which tests a domain's DNS and MX records for common Workspace mistakes. Other Toolbox tools include Browserinfo for browser problems, Encode/Decode for formats such as Base64 and SAML, and Log Analyzer for logs from Google's sync and migration tools.

Header times are often the quickest way to answer a complaint that mail is slow. The program below takes the times from a message's Received lines, oldest first, and shows the delay at each hop.

from datetime import datetime

# Times from the Received headers of a slow message, oldest hop first (all in UTC).
hops = [
    ("Supplier's server", "2026-11-10 15:02:11"),
    ("Birchline Exchange", "2026-11-10 15:02:14"),
    ("Exchange outbound queue", "2026-11-10 15:41:52"),
    ("Google (g.birchline.example)", "2026-11-10 15:41:55"),
    ("Delivered to inbox", "2026-11-10 15:41:57"),
]
fmt = "%Y-%m-%d %H:%M:%S"
times = [datetime.strptime(t, fmt) for _, t in hops]
for i in range(1, len(hops)):
    gap = (times[i] - times[i - 1]).total_seconds()
    print(f"{hops[i - 1][0]:28} -> {hops[i][0]:28} {gap / 60:6.1f} min")
print(f"Total: {(times[-1] - times[0]).total_seconds() / 60:.1f} min")

Supplier's server            -> Birchline Exchange              0.1 min
Birchline Exchange           -> Exchange outbound queue        39.6 min
Exchange outbound queue      -> Google (g.birchline.example)    0.1 min
Google (g.birchline.example) -> Delivered to inbox              0.0 min
Total: 39.8 min

The total is about 40 minutes, and almost all of it is spent in Exchange's outbound queue. Google delivered the message within seconds of receiving it. The fix belongs to Exchange: its send connector to the routing subdomain was throttled after a large newsletter, and Sofia raises the limit. Without the header times, the complaint would have been "Gmail is slow".

Five common problems

The first row is the problem most migrations hit first. When another system relays mail to Gmail, Gmail has to be told which IP addresses belong to that system, or it judges every relayed message as if Exchange had written it. The second course configured the inbound gateway for exactly this reason, and Owen's first check for any spam complaint about relayed mail is whether Exchange's addresses are still listed correctly, especially after a network change.

Reading bounce messages

When a message is rejected, the sender gets a bounce, also called a non-delivery report, with a three-digit SMTP code and usually an enhanced code such as 5.7.26. The first digit says whether to retry: 4 means a temporary failure the sending server will retry, and 5 means a permanent failure. The text after the code, often with a link to Google's help, says why. Owen keeps a short table at the helpdesk.

Limits that cause mail problems

Some problems are not faults but limits. Gmail limits how many messages and recipients a user can send in a day, and how fast mail is accepted from one source; Google's help pages publish the current figures. A store manager who mails a weekly rota to 300 colleagues individually can hit a recipient limit, and a migration tool that pushes mail too quickly can be slowed down. The fixes are usually a group address for the rota and a slower migration schedule, not a support ticket.

Outbound problems

Not every complaint is about mail coming in. When Birchline's mail does not reach a customer or a supplier, the evidence is split: ELS shows that Gmail sent the message and what the receiving server answered, but the reason for a rejection lives in the recipient's system. Owen's checklist for outbound complaints starts with ELS for the receiving server's response, then checks Birchline's own SPF, DKIM and DMARC with Check MX and the DMARC reports from the second course, and only then contacts the recipient's administrator with the message ID and the exact response text. During coexistence there is one more step: if the sender is still on Exchange, the message never passed through Gmail at all, and the Exchange message trace is the place to look.

Outbound routing settings from the second course can cause their own surprises. A migrated user's reply to a colleague still on Exchange travels back through the outbound route to Exchange; if that route is misconfigured, replies inside the company fail while mail to the outside works. Owen tests that path explicitly after every routing change, by sending from a test account in the Pilot OU to a test mailbox still on Exchange and checking both ELS and the Exchange trace.

When to call Google support

Most mail problems are solved with ELS, headers and the Toolbox. A support case with Google makes sense when the evidence points inside Google, for example delays between Google's own hops in the headers, or a delivery step in ELS that makes no sense. A good case includes the message ID, the time with its time zone, the sender and recipient, the ELS export and the full headers. Sofia's experience is that a case with those five items is answered faster and more usefully than a case that says mail is slow.