July is the point where many email programs discover that their Q3 campaign plan is more ambitious than their sending setup.
The DNS records look familiar. The sending platform says authentication is enabled. The campaign team has an unsubscribe link in the footer. Then a new audience, a new subdomain, or a sudden volume increase exposes the part of the mail path nobody tested.
This checklist is framed for a July 2026 tune-up before Q3 campaigns. If Q3 mail is already running, use it before the next significant send. The goal is not to collect screenshots of settings. The goal is to prove that the final message sent by every real path is authenticated, aligned, easy to leave, and unlikely to generate complaints.
Google's current Email sender guidelines and sender guidelines FAQ apply to mail sent to personal Gmail accounts. Yahoo publishes its own Sender Requirements & Recommendations. These requirements are not a universal deliverability guarantee, but they are a useful minimum operating standard for a Q3 sender program.
Before approving a Q3 campaign, verify these six things on a live sample from every promotional sending path:
From: domain. A policy of p=none is a monitoring starting point, not the finish line.Run the checks against the delivered message and the real endpoint. An ESP configuration page can be correct while a downstream relay, second platform, or template variant is still sending something else.
The most useful deliverability fix is often finding a sender that was never included in the original audit.
Make a current inventory of every system that can place your domain in a From: header. Include campaign platforms, product marketing tools, support systems, event software, billing systems, recruitment tools, local business units, and scripts that send directly through an SMTP relay.
For each sender, record:
From: address and domainDo not treat a vendor's name as a sender identity. A platform may use one domain for its dashboard, another for the envelope, and a customer domain for DKIM. The values in the final headers are what receivers evaluate.
Send a representative message from each promotional path to a controlled mailbox. Save the raw source and the SMTP result. Test a normal campaign, a template with the most tracking, and any path that changed since the last quarter.
For background, building a sender inventory with DMARC reports explains how aggregate reports can reveal senders that do not appear in documentation.
SPF answers whether the host delivering a message is authorized to send for the envelope-from domain. It does not authenticate the visible From: address by itself, and it does not replace DKIM.
For each envelope-from domain:
v=spf1.include:, ip4:, ip6:, or other mechanism.~all during a controlled migration or -all once the inventory is complete.The one-record rule is easy to miss. Multiple SPF TXT records do not combine into a larger allow list. Receivers can return a permanent error instead.
SPF has a limit of 10 DNS-querying terms during evaluation. An include can contain more includes, redirects, or mechanisms that perform DNS lookups. A record that looks short can still exceed the limit.
Use an SPF evaluation tool or inspect the full include chain. Count include, a, mx, exists, and redirect lookups. Avoid copying a provider's record into another provider's record without understanding the combined chain.
If a new campaign platform would push the record over the limit, do not solve it by randomly deleting an existing sender. First identify which systems are actually active. Then consolidate mail paths, use a provider-supported authorization design, or remove obsolete senders. SPF's 10-DNS-lookup limit covers the failure modes in more detail.
SPF can pass while DMARC fails if the SPF-authenticated domain is not aligned with the domain in From:. Capture the delivered Authentication-Results header and check both the SPF result and its authenticated domain.
For example, this is not enough on its own:
From: offers@example.org
Return-Path: bounce@mailer.example.net
SPF: pass (mailer.example.net)The SPF result can be valid for example.net and still be unaligned with example.org. Either align the envelope domain or make sure DKIM provides the aligned DMARC pass.
DKIM gives the receiver a cryptographic way to verify the signing domain and selected message headers. It also provides the stable domain identity that many reputation and feedback systems use.
For every sample message:
DKIM-Signature is present.dkim=pass in the receiver's authentication results.d= signing domain and s= selector.selector1._domainkey.example.org.A DKIM key can exist in DNS while the live platform signs with a different selector. Test the message, not just the record.
Use a 2048-bit RSA key where the provider supports it. Google requires at least a 1024-bit DKIM key for mail to personal Gmail accounts and recommends 2048 bits when supported. A longer key does not fix a missing signature, a stale selector, or a message changed after signing.
A message can leave the campaign platform with a valid signature and arrive with dkim=fail after a footer, tracking URL, MIME part, or header is rewritten. Compare the platform's captured message with the delivered raw source.
Pay particular attention to:
For one-click unsubscribe, the DKIM signature must cover list-unsubscribe and list-unsubscribe-post. This is a separate check from merely seeing those headers in the source. DKIM canonicalization and common breakage and DKIM selector rotation are useful follow-ups.
DMARC evaluates the visible From: domain and requires at least one authenticated method to pass with alignment. SPF alignment uses the authenticated envelope domain. DKIM alignment uses the d= signing domain.
For each live sample, record:
From: domaind= domainThis is the result to aim for:
From: offers@example.org
SPF: pass (example.org)
DKIM: pass (example.org)
DMARC: passBoth aligned methods are preferable when the mail path supports them. If a forwarding hop later breaks SPF, aligned DKIM still gives the message a chance to pass DMARC. If a gateway modifies the body and breaks DKIM, aligned SPF may still help on a direct path.
Check that the domain has one syntactically valid DMARC record at _dmarc.example.org. Confirm that its rua destination is authorized and monitored. Aggregate reports should show whether all known senders pass, whether an unknown source is impersonating the domain, and whether a new sender is missing alignment.
Starting or remaining at p=none can be appropriate while the inventory is incomplete. It tells receivers to collect evidence without asking them to quarantine or reject mail. It does not make an alignment failure harmless, and it does not protect recipients from spoofing.
Once legitimate traffic passes consistently and unknown sources are understood, plan a controlled move toward enforcement. Use a staged policy and observe the result after each change. DMARC policy modes and DMARC pct rollout cover the tradeoffs.
Do not use a successful DMARC result as proof that a campaign is wanted. Authentication establishes authorization. It does not establish consent, relevance, or a healthy complaint rate.
For bulk senders, Google requires one-click unsubscribe for marketing and promotional messages, plus a clearly visible body link. Yahoo requires easy unsubscribe, a visible body link, and processing within 2 days. Google recommends fulfilling requests within 48 hours.
The final promotional message should contain headers like these:
List-Unsubscribe: <https://example.org/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickRFC 8058 requires the message to have a valid DKIM signature covering both headers. Its HTTPS endpoint must identify the recipient and list, accept the POST without cookies or login, and process the request without an HTTPS redirect. Use an opaque or hard-to-forge token so an attacker cannot easily unsubscribe arbitrary recipients.
The visible body link may lead to a preference page. The RFC 8058 header endpoint should directly perform the relevant unsubscribe action. A mailto: option can be useful as an additional fallback, but it does not replace Google's required HTTPS one-click method for bulk promotional mail.
Extract the HTTPS URL from the delivered header and test it as a machine would:
curl -i -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "List-Unsubscribe=One-Click" \
"https://example.org/unsubscribe/opaque-token"Then verify all of the following:
Repeat this test for each ESP, brand, region, template family, and promotional message type. A footer link on the main newsletter does not cover a forgotten product-announcement workflow. One-click unsubscribe in 2026 has a longer audit sequence.
Google's current guidance says to keep the Postmaster Tools spam rate below 0.10% and avoid reaching 0.30% or higher. Google's FAQ says bulk senders above 0.3% are ineligible for mitigation until the rate remains below that level for 7 consecutive days. Yahoo requires bulk senders to stay below 0.3% and calculates its rate from mail delivered to the inbox.
These figures are provider-specific signals, not one universal complaint-rate formula. For internal reporting, use:
complaint rate = confirmed complaints / messages delivered * 100Do not use messages queued or attempted as the denominator when comparing streams. Keep sent, accepted, delivered, complained, unsubscribed, bounced, and deferred counts separate.
Track complaint and unsubscribe events by:
Gmail Postmaster Tools reports on personal Gmail traffic and may omit data when volume is too low to protect privacy. Missing dashboard data is not a zero complaint rate. Verify the domain using the DKIM signing domain or SPF Return-Path domain that actually identifies the traffic, and add subdomains separately when they need independent visibility. See Google's Postmaster Tools setup guidance.
Yahoo's Complaint Feedback Loop is based on DKIM-signed mail. Enroll each relevant DKIM domain, process ARF complaints, and suppress the complaining address from the affected promotional stream. A CFL count will not necessarily match Yahoo's inbox-delivered rate, so label the denominator and time window clearly.
The following are internal control bands, not provider policy:
| Band | Rate | Action |
|---|---|---|
| Green | below 0.05% | Continue and review the trend. |
| Watch | 0.05% to below 0.10% | Do not expand into colder audiences. Check frequency and unsubscribe. |
| Amber | 0.10% to below 0.20% | Pause volume expansion and isolate the campaign or segment. |
| Red | 0.20% to below 0.30% | Stop the suspect promotional segment and investigate before resuming. |
| Critical | 0.30% or higher | Stop the affected promotional stream, preserve only genuinely necessary transactional mail, and begin recovery. |
The correct response to a complaint spike is not to move the same audience to a fresh IP or subdomain. Find the cause first. Common causes include an unclear subscription promise, a frequency increase, stale recipients, a misleading subject or sender name, a broken unsubscribe path, or a new acquisition source with poor consent quality.
For more detail, see spam complaint rate control in 2026.
Run the following sequence at least once before the first large Q3 campaign and again after any sender or template change.
Export the systems, domains, selectors, IPs, message types, owners, and suppression sources. Mark every entry that has not produced a live sample in the current quarter.
Send from every promotional path to personal Gmail and Yahoo test mailboxes where those providers matter. Preserve the raw source and delivery result. Do not rely only on a preview from the sending platform.
Confirm SPF and DKIM pass. Confirm DMARC pass. Confirm the aligned domain is the one intended for that From: identity. Investigate any none, neutral, softfail, permerror, temperror, dkim=fail, or alignment mismatch before launch.
Confirm both RFC 8058 headers, DKIM coverage for those headers, the visible body link, direct POST behavior, list-specific suppression, and the actual processing time.
Review Gmail Postmaster Tools, Yahoo CFL events, internal complaints, unsubscribes, bounces, deferrals, and recent changes. Compare the same provider and denominator rather than combining unlike data.
Remove recent complainers, unsubscribers, hard bounces, and recipients outside the subscription promise. Start with the most engaged audience when the template, sender, domain, IP, or volume is new. Keep the rate consistent and avoid an immediate doubling of the previous volume.
The campaign owner must know which alert pauses the send, who can pause it, and what evidence is required before resuming. A control that requires three approvals during an active complaint spike is not an effective control.
If the preflight finds a problem, use this order:
From: alignment or sign with an aligned DKIM domain.Do not make several unrelated changes at once. If authentication, content, audience, and infrastructure all change in the same campaign, a later improvement will not tell you which fix worked.
The July tune-up should become a repeatable control rather than a quarterly scramble.
Run the campaign gate, record delivered and complaint counts, confirm suppression is available, and keep a sample of the final message.
Review provider dashboards, SMTP deferrals and rejections, complaints, unsubscribes, bounces, and suppression latency. Pause expansion when an internal band is crossed.
Compare each provider, stream, sender domain, DKIM selector, IP pool, and audience segment with the last healthy campaign. Re-test a one-click endpoint after any platform or gateway change.
Reconcile the sender inventory with DMARC reports. Remove retired SPF dependencies, review selectors, confirm DMARC report delivery, and check that every campaign owner still has a working stop procedure.
Q3 readiness is not a green checkmark in an email platform. It is evidence from the final message and the operating process around it:
From: domainAuthentication protects the identity of the mail. Unsubscribe protects the recipient's choice. Complaint-rate controls protect the reputation built by every campaign before it. Treat all three as one preflight system, and the next Q3 launch will have room to handle an unexpected sender, a bad segment, or a provider feedback delay without turning a small defect into a quarter-wide deliverability incident.
The practical July 2026 fix is to test the whole path, not to add another isolated DNS record. Inventory the senders, verify SPF and DKIM on live mail, require aligned DMARC, exercise the RFC 8058 POST, measure complaints against delivered mail, and pause the stream that is causing harm.
That is the tune-up that makes a Q3 campaign safer before the campaign volume makes every weak assumption visible.