What belongs in a launch handoff? Record the observed blocker, missing evidence, one authorized operator, a bounded action and a recheck through the same sending path. If message-level evidence is missing, keep the result unknown; a DNS record alone cannot prove a received message passed.
This guide is a practical handoff for one domain or subdomain and one ESP or CRM path. It does not produce a launch score or approval.
Start with the path
Use the message received through the path under review. A preview, a staff mailbox, a transactional tool, or a forwarded message may use different settings. Check each item you can support and leave the rest unknown:
Keep secrets out. Do not paste passwords, API keys, DNS logins, ESP tokens, raw headers, message bodies, recipient lists, or customer campaign exports into a public page or request. A sanitized conclusion, public DNS result, or redacted screenshot can be enough to discuss fit.
Carry the conclusion into the handoff
Record the visible From: domain, the receiver-evaluated SPF identity, and the passing DKIM
signature’s d= domain in your private worksheet. Keep the authentication verdict separate
from the observed domain. If you still need to interpret those results, use the
aligned-authentication guide before assigning
a change.
If real message evidence is missing, write message-level authentication not observed. A
DNS checker can show that a record was found; it cannot, by itself, prove how a particular message was
signed or evaluated. RFC 8601 explains why
Authentication-Results must be interpreted within the receiver’s trust boundary.
Use this decision tree
- Is the exact domain, ESP path, destination, and message type known? If no, record unknown and name the missing owner or evidence. If yes, continue.
- Do you have a receiver result for that same path? If no, collect a private, sanitized result through an authorized test. Do not treat a copied header from an unknown intermediary as proof.
- Does a passing SPF or DKIM result align with the visible From domain? If neither method has a passing result that aligns, route to the ESP configuration owner and DNS owner for supported branded authentication. If one passes and aligns, record which one and continue.
- Does a separate provider rule apply? Check destination, provider-specific volume, message type, and consumer versus enterprise scope in the provider requirements guide. Google, Yahoo, and Microsoft publish different applicability; a “5,000/day” statement is not a universal sender rule.
- Is one authorized operator available to make the bounded change? If no, defer. If yes, assign one action, expected evidence, restore responsibility, and a recheck through the same path.
Authentication and alignment do not settle reputation, acceptance, or inbox placement. A DMARC pass can explain one protocol result while another provider requirement remains unmet.
Example handoff
This is a constructed handoff for reserved domains client.example and
vendor.example, assumed to have separate organizational boundaries. It is not a customer
result.
| Handoff field | Example |
|---|---|
| Observation | Receiver authenticated vendor.example; visible From used client.example. |
| Unknown | Whether this account supports the ESP’s branded DKIM and aligned return path. |
| Owner | Client’s authorized ESP operator, with the DNS operator available for supported records. |
| Action | Compare the account’s custom-domain settings with current ESP documentation; change only the reviewed supported setting. |
| Verification | Send an authorized test through the same path and inspect the receiver-generated result. |
| Recheck | Record changed, unchanged, or unknown on the agreed date and recipient. |
Use the downloadable one-path handoff worksheet to record the comparison, owner, expected evidence, rollback plan, recheck, and residual uncertainty. Use the page checklist for preparation and the downloaded worksheet for private notes; neither certifies a launch.
Decide whether human scope fits
If the evidence identifies the owner and next verification, your team may finish the work without purchase. If one real launch path still needs interpretation, prioritization, and a client-ready handoff, request scope for Folderly Launch Audit. The manual US$495 pilot covers one domain or subdomain and one ESP/CRM sending path. After payment and complete intake, the agreed start begins a 48-hour report window with up to five prioritized actions and owners, a 45-minute handoff, and one recheck within seven days of the report. It is read-only advice: your authorized operator makes production changes. There is no implementation, warming, reputation recovery, list repair, multidomain review, or inbox-placement guarantee.
The request form prepares an editable email draft. Review it and send it from your mail app; nothing is sent automatically.
Download the private handoff worksheetSources and applicability. This is a dated documentation synthesis, not a test of customer domains or an inbox-placement benchmark. Review the Google sender guidelines, Google bulk-sender FAQ, Yahoo sender best practices, and Microsoft’s current Outlook.com high-volume announcement before applying a provider rule. Their scopes differ by destination, volume, message type, and consumer or enterprise service. Reviewed 28 September 2026. Recheck the linked requirements before applying them to a launch.