Gmail sender requirements: a practical verification checklist

Check which requirements apply

Google's guidance covers personal @gmail.com and @googlemail.com recipients. All senders need SPF or DKIM, valid forward/reverse DNS, TLS, compliant message formatting and low reported spam rates. Bulk senders need both SPF and DKIM, plus DMARC; direct mail must align the visible From domain with a passing SPF or DKIM identity. Bulk marketing and subscribed messages also need one-click unsubscribe and a visible body link. The threshold is around 5,000 daily messages to personal Gmail accounts; use Google's linked guidance and FAQ to establish your bulk classification.

These requirements do not grant permission to send unwanted email or guarantee inbox placement. Google's reported spam-rate ceiling is below 0.3%; treat complaints as a problem to investigate, not a budget to spend. Consult the current provider guidance when your sending pattern or configuration changes.

Source: Google: Email sender guidelines

Count the primary domain, not each mailbox separately

Google's FAQ describes bulk senders as reaching close to 5,000 or more messages to personal Gmail accounts within 24 hours. Messages from the same primary domain count together, including subdomains. Once classified, bulk status persists. Moving messages between mailboxes or subdomains does not make that classification disappear.

For example, add the Gmail-bound traffic from your staff, newsletter and application services before deciding which checklist applies. If those services have different owners, ask for their counts for the same time window. Do not substitute your total campaign count across all recipient providers for the Gmail-specific count.

Source: Google: Sender guidelines FAQ and bulk-sender classification

Build an inventory before changing DNS

Imagine a small company using one service for staff mail, another for billing notifications, and a third for a newsletter. An operator sees an authentication warning and replaces the domain's existing configuration with the newsletter provider's suggested record. The warning might disappear for that service while staff or billing mail breaks. This is an illustrative failure scenario, not a customer incident.

Create a row for each legitimate sending service. Assign an owner who can confirm whether the service is still active. Record the visible sender address, the account used to send, the return-path domain and the signing domain from a received message. Keep secrets and recipient addresses out of a shared troubleshooting document.

Use a received message as your test specimen

Use an account you control for the test, open the message's original headers, and save a redacted copy with the test time. The following is a synthetic, shortened result. It demonstrates the kind of evidence to collect; it is not a complete message, a live DNS configuration or a guarantee that a provider will accept your mail.

From: Morgan <[email protected]>
Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

1. Identify the receiving system's own authentication results, not an arbitrary header supplied earlier in the message path.
2. Write down each result and its domain. A green status for a different service or a previous message is not evidence for this sending path.
3. If a result fails, investigate that branch before changing unrelated records. Use the alignment guide when the individual methods pass but DMARC fails.
4. Ask the sending provider to verify its actual outbound infrastructure where you cannot inspect it yourself. Keep a clear list of checks still unverified.

Check the recipient's exit path

Include unsubscribe verification in your release checklist, with a test recipient you control. Record which sending path produced the message, the opt-out mechanism shown to the recipient, and what happens to subsequent scheduled messages. A button visible in an application preview does not establish that a delivered message contains the necessary headers.

Do not substitute the phrase ‘reply to unsubscribe’ for a required one-click mechanism. If a provider handles unsubscribe processing, ask how the resulting suppression reaches every relevant sending workflow. Investigate any test where the same recipient can be re-enrolled after opting out.

Source: Google: Email sender guidelines

Keep a small evidence log and retest

Use the table below as a handoff between the campaign owner and mailbox administrator. Mark an unresolved item as unknown rather than translating a partial diagnostic into a pass. Repeat the test after changing the provider, mailbox identity or domain configuration.

Zintara's domain diagnostics can help organize checks, but they do not establish complete sending-IP reputation, reverse-DNS correctness or inbox placement. Use the actual received message and the sending provider's evidence to close those gaps. When authentication passes but recipients are not responding, review relevance and actual replies separately from the technical setup.