A company can send support replies, receipts and newsletters through different systems while presenting the same brand to recipients. A domain-level green indicator is therefore only a starting point. The practical task is to connect each sending stream to evidence showing how its messages are constructed and delivered.
Establish the destination and requirement set
Google's requirements for personal Gmail took effect on February 1, 2024. All senders need SPF or DKIM, TLS, valid forward/reverse DNS, RFC 5322 formatting and low reported spam. Google recommends staying below 0.1% and avoiding 0.3% or higher; the latter is not a healthy target. Bulk senders need both SPF and DKIM, DMARC with at least p=none, and alignment for direct messages. The FAQ distinguishes forwarded and mailing-list messages from this direct-mail alignment requirement; that does not convert a protocol failure into a DMARC pass. Relevant bulk marketing and subscribed traffic also needs header-based one-click unsubscribe and a visible body link. Google sender guidelines.
Google's FAQ describes increased enforcement from November 2025. It recommends honoring unsubscribes within 48 hours and makes missing that window a barrier to delivery mitigation. As an internal operational rule, use no more than 48 hours, with prompt processing as the target; this is not a statement that RFC 8058 specifies that deadline. Google requirements FAQ.
Use the linked sources as the maintained checklist rather than treating a static article as an enforcement calendar. Record when the source was checked and who owns checking it again before a significant launch. Bulk classification deserves its own inventory step; a single stream's volume is not enough evidence to classify the organization.
Build one evidence row per stream
References: RFC 6376 §3.5.
For each application or service, record the business owner, visible From domain, envelope sender domain, DKIM signing domain and selector, sending infrastructure, message purpose and recipient destination. Include forgotten systems such as billing exports, event platforms and support tools. Distinguish a service that submits mail from the infrastructure that makes the final outbound connection.
Attach a recent authorized message sample to the row. Examine the complete delivered message rather than only the application's template preview. A preview may omit headers added later, while a downstream gateway may alter a signed field. Keep recipient information and unsubscribe tokens out of broadly shared screenshots and tickets.
Turn a policy requirement into a testable check
References: RFC 8058 §3.1, RFC 8058 §4.
Use separate columns for configured, observed and unresolved. A published key is configuration evidence; a valid signature on the final message is observation evidence. A vendor saying it supports a feature is not proof that this account has enabled it. For each failed check, assign the owner capable of making the correction and identify the smallest safe retest.
For a promotional stream, inspect the final unsubscribe headers, their DKIM coverage and the recipient/list association. Use only a controlled recipient to exercise the endpoint. For a transport concern, preserve the actual response and connection evidence. Do not declare TLS verified merely because the provider's marketing page mentions encryption.
Apply an illustrative launch gate
Consider a fictional company with three streams: account notices from an application, newsletters from a campaign service and personal replies from a mailbox service. The campaign service's setup page reports authentication enabled, but the delivered newsletter lacks the required unsubscribe POST header. The account notice has a valid signature; the personal reply has not yet been sampled.
The correct launch record is not “the domain passed.” It is a corrected-and-retested newsletter action, an observed account-notice result and a pending personal-reply sample. This is an illustrative review exercise, not evidence that any real tenant has those defects. The exercise is reproducible by making three inventory rows and refusing to turn unknown cells into passes.
Recheck after changes and retain uncertainty
References: RFC 6376 §6.
Repeat the affected checks after changing a sender, gateway, signing configuration or template. Keep the old sample and the new sample so a reviewer can see what changed. Avoid unrelated DNS edits when the failed requirement concerns message construction or unsubscribe handling.
A readiness record should end with specific stream outcomes and remaining gaps. Compliance is not an inbox guarantee, and this guide does not claim a live Gmail tenant test. Its output is a practical evidence plan that can be executed against the organization's authorized sending streams.