Quick answer
Google Postmaster Tools and public DNS checks answer different questions. Postmaster Tools can show Gmail-specific dashboards after domain setup, verification, and enough Gmail traffic. Public checks show whether your visible technical baseline is broken: SPF, DKIM, DMARC, blacklist status, PTR/reverse DNS, TLS, message format, and unsubscribe headers where applicable.
Postmaster Tools and public checks are complementary
Postmaster Tools is Gmail-specific. Google's setup documentation describes it as a way to monitor outgoing email to personal Gmail accounts and view dashboards such as spam rate, reputation, authentication, and delivery errors.
Public checks are provider-neutral. They inspect DNS and SMTP-facing signals that any receiver can use: SPF, DKIM, DMARC, MX, blacklist status, TLS posture, and some infrastructure clues.
Use public checks first when you need a fast, no-account baseline. Use Postmaster Tools when you need Gmail's private view and you can verify the domain. If the public baseline is broken, Postmaster Tools may only confirm pain you can already fix.
Check the domain Gmail sees in the message
Start with the visible From domain and the domain used to authenticate outgoing mail. Postmaster Tools setup asks you to add a domain used for SPF or DKIM authentication. Public checks should follow the same discipline: do not check only the website domain if mail is sent from a subdomain or third-party platform.
If the message is from updates.example.com, check that domain and its relationship to the organizational domain. If the ESP signs with a vendor domain, public DNS for example.com may look clean while the actual message still fails alignment.
The public baseline is most useful when it matches the real sending path.
Check SPF, DKIM, and DMARC before interpreting reputation
SPF is defined in RFC 7208 and lets a domain publish which hosts are authorized for outbound mail identities. Public SPF checks can find missing records, multiple records, syntax errors, lookup-limit problems, and missing providers.
DKIM is defined in RFC 6376 and lets a receiver verify a message signature against a public key in DNS. Public DKIM checks need a selector. They can prove a specific key exists, but they cannot prove every real message is signed unless you inspect headers.
DMARC is defined in RFC 7489 and ties SPF/DKIM results to the visible From domain through alignment and policy. Public DMARC checks can show the published policy. A real message header shows whether a specific message passed.
If any of these fail publicly, fix them before treating Gmail reputation as the only explanation.
Check infrastructure signals: PTR, TLS, and message format
Google's sender guidelines include valid forward and reverse DNS for sending domains or IPs, TLS for transmitting mail, and formatting messages according to RFC 5322.
PTR and reverse DNS are about the actual sending SMTP IP. A public domain check may not know that IP unless you supply it from headers, bounces, or sending-platform logs. Do not assume the website IP or inbound MX host is the sender.
TLS checks can show whether a domain's inbound mail hosts support secure SMTP transport and related policies. They do not prove that one outbound message to Gmail used TLS. For a Gmail TLS bounce, preserve the exact bounce text and inspect sender logs.
Message-format checks often require the actual message. Public DNS cannot prove whether a campaign has duplicate single-instance headers, malformed Message-ID, misleading display names, or hidden content.
Check unsubscribe requirements only where they apply
Google's sender guidelines distinguish general sender requirements from additional requirements for bulk senders and for marketing or subscribed messages. One-click unsubscribe is not the same question as SPF or DKIM, and it is not visible from DNS.
For marketing and subscribed messages, inspect the actual message headers and body. The relevant standards are RFC 2369 for list unsubscribe headers and RFC 8058 for one-click signaling.
Relaymetry should not claim unsubscribe compliance from a domain lookup. At route implementation time, this page can explain the requirement and link users to message-header inspection as a future or external step.
Check blacklist status without treating it as Gmail's full model
Public blacklist checks can reveal visible reputation problems. If a sending IP or domain is listed, investigate abuse, compromised accounts, poor list acquisition, shared IP reputation, or sudden volume before asking for delisting.
Clean blacklist status is useful but limited. Gmail's internal reputation model is not the same as public DNSBL status. A sender can be absent from public blocklists and still have weak Gmail reputation.
This is a core positioning point for the page: public checks reduce uncertainty, but they do not expose Gmail-private signals.
When Postmaster Tools is the next step
Postmaster Tools is the right next step when the public baseline passes but Gmail-specific delivery problems continue.
Use it to look for Gmail-side patterns such as reputation, spam-rate, authentication, and delivery-error dashboards when data is available. Keep in mind that the data applies to personal Gmail accounts and requires domain setup/verification.
If Postmaster Tools shows poor reputation, use the public report to make sure the technical baseline is clean, then address sender behavior: list quality, recipient expectation, complaint risk, volume changes, stream separation, and content.
What this does not prove
Public checks do not prove Gmail inbox placement, Gmail reputation, Gmail spam rate, or Postmaster Tools compliance status. They also do not prove the exact authentication result for a specific message unless that message's headers are inspected.
Relaymetry can show the public technical baseline quickly. Postmaster Tools can show Gmail-specific dashboards for verified domains when Gmail has data. Both are useful, but they answer different questions.