The guides explain a narrow email launch question using the current first-party documentation cited on each page. They do not report an original customer test, benchmark, ranking, payment result, or inbox placement outcome. A reader should be able to follow every material provider claim to its source and tell when an example is only an example.
What the guides are
Each article starts with the decision a sender or operator needs to make, then names the recipient scope, message path, relevant identity, and next owner. The source set includes current provider pages such as Google’s sender guidelines, Microsoft’s Outlook.com NDR guidance, and Mailchimp’s domain-authentication instructions. Protocol explanations link to the applicable primary standards, such as RFC 9989.
How evidence is labeled
| Evidence level | How it appears | What it can establish |
|---|---|---|
| Primary documentation | Named provider or standards page, linked inline and dated | The published wording and scope of that source at review time |
| Constructed case | Reserved domains, illustrative results, or a labeled decision row | How an operator could reason through a pattern; it is not customer evidence |
| Genuine message evidence | A received header, NDR, or sanitized result from the exact sending path | What that receiver reported for that message and route |
| Customer benchmark | Not presented by these public pages | Nothing; no original benchmark or customer outcome is claimed |
How citations and dates work
The review date records when the linked documentation was checked, not when a provider last changed its systems. Provider wording, enforcement, product screens, and plan availability can change. Recheck the source before applying a rule to a launch, especially when a page distinguishes personal mail from an enterprise tenant, or standard Mailchimp from Mailchimp Transactional. The articles preserve meaningful scope differences instead of combining them into a universal threshold or DNS instruction.
A public DNS answer, setup badge, or provider status is kept separate from receiver-generated
Authentication-Results. Where message evidence is missing, the guide says so. Where an
example is constructed, the text labels it. That distinction keeps a useful unknown visible instead of
turning documentation into a certification.
What these pages do not promise
The guides do not promise inbox placement, acceptance by every recipient, sender-reputation recovery, search visibility, AI visibility, or a successful change for a domain the author has not tested. They do not ask for credentials, raw headers, recipient lists, or customer exports. A manual Folderly Launch Audit can interpret one authorized domain or subdomain and one ESP/CRM path, but the authorized operator remains responsible for DNS, ESP, and campaign changes.
Ownership and corrections
Folderly owns the editorial review of this guide set. To report a factual correction, send the page URL, the exact claim, the primary source that supports the correction, and the date you checked it to vlad@belkins.io. Do not include credentials, raw message headers, recipient data, or customer exports. Corrections are reviewed against the cited source; a material change updates the page’s review date and wording.