Quick answer
Emails from your domain go to Gmail spam when Gmail accepts the message but classifies it as risky, unwanted, or low-trust for the recipient. Start with public checks: SPF, DKIM, DMARC alignment, blacklist status, TLS, reverse DNS, and message-format basics. If those pass, move to Gmail-specific evidence: Postmaster Tools, headers, volume history, complaints, content, and engagement.
First confirm this is spam placement, not rejection
Spam placement means Gmail accepted the message and put it in the spam folder. Rejection means Gmail refused the message during delivery and returned a bounce or SMTP error.
The distinction matters because the evidence is different. A rejection usually gives you an SMTP code, such as an authentication or policy failure. Spam placement usually requires a delivered Gmail message header, plus context about the sender, recipient, content, and recent sending behavior.
Do not edit SPF, DKIM, DMARC, and MX records all at once. That can hide the original cause and create new failures. First decide whether Gmail rejected the message or accepted it into spam.
Check the visible From domain and actual sending path
The visible From domain is the domain users see in the message, and it is the domain DMARC is designed to protect. For a message from billing@example.com, the relevant domain is usually example.com, even if the message traveled through an ESP, CRM, helpdesk, or newsletter platform.
Map the exact sending path before changing DNS. Identify the platform, return-path domain, DKIM signing domain, tracking domain, sending IP if available, and From domain. Many Gmail spam incidents happen because one stream is different from the rest: transactional mail works, but newsletter mail uses a different ESP; employee mail works, but CRM mail signs with the vendor's domain.
Relaymetry can check public records for the domain. A real Gmail header is still needed to prove how Gmail evaluated a specific message.
Check authentication in the right order
SPF is the public DNS mechanism that lets a domain authorize outbound hosts for the SMTP identity described by RFC 7208. For Gmail troubleshooting, SPF is useful only when it matches the real sending path. MX records do not authorize outbound mail.
DKIM is the message-signing mechanism defined in RFC 6376. A public DKIM key in DNS does not prove real messages are signed. The sending platform must sign the message, and the Gmail header must show which selector and signing domain were used.
DMARC is the policy and alignment layer defined in RFC 7489. DMARC does not ask only whether SPF or DKIM passed somewhere. It asks whether an authenticated domain aligns with the visible From domain.
This is why the first technical workflow is: check SPF, check DKIM, then check DMARC alignment. If DMARC fails, do not treat the issue as "Gmail spam is mysterious." Fix the sending path until aligned SPF or aligned DKIM passes for the From domain.
Check Gmail sender requirements that public tools can partially verify
Google's sender guidelines say all senders to personal Gmail accounts should authenticate with SPF or DKIM, use TLS, maintain valid forward and reverse DNS for sending domains or IPs, keep spam rates low, and format messages according to RFC 5322. Bulk senders have additional requirements, including SPF and DKIM, DMARC, alignment for direct mail, and one-click unsubscribe for marketing or subscribed messages.
Public tools can verify some of that baseline. Relaymetry can check public DNS records, TLS-facing posture, DMARC policy, and public blacklist status. It cannot prove your actual Gmail spam rate, complaint rate, recipient engagement, or whether a particular outbound SMTP session used TLS.
For reverse DNS, the important IP is the actual sending SMTP IP, not necessarily the website IP, apex domain IP, or inbound MX host. If you use a major ESP, that IP may belong to the provider. If you run your own mail server, the PTR and forward DNS relationship is your responsibility.
For unsubscribe, the requirement applies to marketing and subscribed messages, not every transactional or person-to-person message. The relevant public standard for one-click unsubscribe is RFC 8058, but a DNS report alone cannot inspect the headers of a message you do not provide.
Check public blacklist status, but treat it as one signal
A public blocklist listing can explain why a receiver treats mail cautiously, especially if the listing is on a list that receiver trusts. If a sending IP or domain is listed, investigate the cause before requesting delisting.
A clean public blacklist result does not prove Gmail will trust the sender. Gmail has internal reputation systems that are not public DNSBLs. The useful conclusion from a clean blacklist check is narrower: public blocklists are not the obvious visible problem.
If Gmail spam placement continues after clean authentication and clean public blacklist checks, stop refreshing public tools and move to Gmail-specific evidence.
Use Postmaster Tools when the domain has enough Gmail traffic
Google Postmaster Tools can show Gmail-specific dashboards for domains and IPs after domain setup and verification. Google's setup documentation describes dashboards for spam rate, reputation, authentication, and delivery errors, but the data applies to messages sent to personal Gmail accounts.
Postmaster Tools is strongest when you have enough Gmail volume for useful data. It is not a public replacement for SPF, DKIM, DMARC, or blacklist checks. It is the next layer after the public technical baseline is clean.
If Postmaster Tools shows weak reputation or a high spam-rate signal, do not solve that by randomly changing DNS. Authentication fixes can remove technical failure, but reputation recovery usually requires safer sending behavior, better recipient expectation, list hygiene, and time.
Compare working and failing streams
If only one kind of mail goes to Gmail spam, compare that stream to a working stream from the same domain.
Useful comparisons include:
- Transactional mail vs newsletter mail.
- Google Workspace mail vs ESP mail.
- Old ESP vs new ESP.
- Existing domain vs new subdomain.
- Low-volume mail vs a recent large campaign.
- Messages without tracking links vs messages with tracking links.
- One DKIM selector vs another selector.
The domain can look healthy while one sending path is broken or low-trust. A domain-level report is the starting point; message headers and sending-platform context tell you which stream is actually affected.
What this does not prove
A clean Relaymetry report does not prove Gmail inbox placement. It means the public technical signals Relaymetry can inspect are not obviously broken.
Relaymetry cannot see Gmail's private domain reputation, IP reputation, recipient engagement, complaint history, content classifier output, or Postmaster Tools dashboards. It also cannot prove the actual SPF/DKIM/DMARC result for a specific delivered message unless you inspect that message's headers.
The practical boundary is simple: fix public technical failures first. If they pass, use Gmail-specific evidence instead of continuing to rewrite DNS.