# Email delivery and responsible sending **“Accepted” means the SMTP transport accepted the message for onward processing. It does not mean delivered, opened or placed in the inbox.** The receiving provider can later reject, bounce, quarantine or classify an accepted message as spam. This application cannot guarantee inbox placement. It does not implement provider delivery/bounce/complaint webhooks or open tracking, so its activity records must not be presented as confirmed delivery or engagement. ## Before the first campaign Use a verified sender address on a domain you control and an SMTP service that permits your intended marketing use and volume. Configure the application’s admin SMTP settings, preserve the original `APP_KEY` used to encrypt those settings, and send a test only to an explicit address you control. Do not use a purchased, scraped or third-party celebrity-fan list. Marketing recipients must be opted in and not unsubscribed or suppressed; retain the consent timestamp, source and wording. **The installation does not contain a real physical business address. The administrator must enter a valid business mailing address before sending any campaign.** Also fill the business name and legitimate sender identity. Contact phone/email and social links are optional, but any configured values must be genuine. Blank social settings produce no invented active links. Review your applicable marketing/privacy obligations; this technical guide is not a substitute for jurisdiction-specific legal advice. Photographs and sample campaign copy are illustrative. They do not assert celebrity representation, endorsement, agency relationships or talent availability. Review [asset credits and rights](assets-credit.md) before public marketing and replace photographs with properly authorized material where needed. ## Gmail authentication and infrastructure Google’s official sender guidelines apply to personal `@gmail.com` and `@googlemail.com` accounts. For all senders, Google requires SPF **or** DKIM, valid forward/reverse DNS, TLS transmission, standards-compliant messages and spam rates below 0.3%. Senders of more than 5,000 messages per day to Gmail have additional requirements: SPF **and** DKIM, DMARC, From-domain alignment and one-click unsubscribe for marketing/subscribed messages, alongside a visible body unsubscribe link. Google recommends configuring SPF, DKIM and DMARC even below bulk volume. Check the live official guidance before launch because requirements can change. [1] - **SPF:** Publish one valid SPF TXT policy for the sending domain that authorizes every legitimate sender, including your SMTP provider. Use that provider’s exact documented DNS values; do not guess an `include` domain or create competing SPF records. - **DKIM:** Enable signing at the SMTP provider and publish its selector records. Google requires a key of at least 1024 bits for personal Gmail delivery and recommends 2048 bits when supported. Verify that a real received test message passes DKIM. [1] - **DMARC:** Publish the provider-appropriate policy and align the visible From domain with a passing SPF or DKIM domain. Google accepts `p=none` as the minimum bulk-sender policy, but monitoring reports and a planned enforcement rollout help detect misuse. Do not adopt a stricter policy until all legitimate sending streams are correctly authenticated. [1] - **TLS:** Use the SMTP provider’s supported STARTTLS or implicit-TLS connection, with certificate validation. The production website and unsubscribe endpoints must also use HTTPS. Website HTTPS does not by itself prove that mail is transmitted using TLS. - **PTR and forward DNS:** The public sending SMTP IP must reverse-resolve to a hostname whose A/AAAA record resolves back to that IP. With a hosted SMTP service, ask the provider to verify this; PTR is normally controlled by the IP owner, not your website DNS panel. Shared-IP reputation is affected by other senders on the same IP. [1] After configuring DNS, wait for propagation and inspect a controlled received message’s authentication results. A syntactically valid DNS record is not enough: test the actual From address, envelope sender and DKIM signing domain used by the provider. Check provider sending limits and account restrictions before queuing a batch. ## Consent, reputation and pacing Send only the content recipients agreed to receive. Confirm addresses, keep consent records, remove stale/unengaged contacts through an appropriate re-consent or suppression process, and make sender identity and subject lines truthful. Do not add `Re:` or `Fwd:` unless the message is an actual reply or forward. Google recommends opt-in subscriptions and reputation monitoring, and requires spam rates below 0.3%; aim comfortably below that threshold rather than treating it as a sending target. [1] Start with a small, legitimate, engaged audience and increase volume cautiously within the provider’s limits. The application’s queued/throttled sends help pace transport requests, but cannot create consent or repair a bad domain/IP reputation. Monitor provider logs, complaints, blocklists and Google Postmaster Tools where sufficient data is available. Pause campaigns when rejection or complaint levels rise; investigate the audience, authentication and content before resuming. The templates use a white body, table layout, Arial fallback, accessible image alt text, text-based calls to action and a plain-text alternative. They escape paragraph content rather than accepting arbitrary HTML. Keep subjects and preheaders honest, provide meaningful CTA labels, and do not rely on an image to carry essential information. Large image-heavy messages or a beautiful design are not evidence of deliverability. Use public absolute HTTPS URLs for the logo, banner, CTA and unsubscribe endpoint. Relative asset paths are normalized against the application’s configured URL, but a recipient cannot load local files, authenticated admin media or a private development hostname. Remote-image blocking is normal; the message must remain understandable without its photographs. Test at least Gmail, an Outlook client and a mobile mail client using received mail, not only the browser preview. ## Visible and one-click unsubscribe Every marketing email must show the business address and a plainly visible unsubscribe link in both HTML and text alternatives. A body link alone does **not** satisfy Gmail’s bulk one-click requirement. The backend must also emit these RFC 8058 headers using the real per-recipient HTTPS endpoint: [1] ```text List-Unsubscribe: List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The placeholder above is documentation only, not a configured endpoint. Verify both headers in the source of a received test message. Gmail’s one-click request is an HTTPS POST containing `List-Unsubscribe=One-Click`; the endpoint must process it without sign-in, a confirmation step or a cookie-dependent browser session. The normal visible link must also provide a usable opt-out path. Ask the SMTP provider to preserve and DKIM-sign the unsubscribe headers as required for RFC 8058; transport support and header signing must be checked in real received mail. [1] Honor opt-outs promptly and confirm in admin that the contact is no longer eligible for marketing. Do not reactivate that contact when importing a list or restoring a backup. A test/preview without a recipient can show an unavailable-link notice, but that is not an acceptable substitute for a real recipient-specific unsubscribe URL in a sent marketing campaign. ## Bounces, complaints and manual suppression **Bounce and complaint suppression is manual in this version. No SMTP-provider webhook, feedback-loop receiver or automatic bounce mailbox processor is implemented.** A successful send job records SMTP acceptance, not a later hard bounce. Watch the provider’s dashboard and the return/bounce mailbox, and ensure an administrator has access to both. For a permanent failure such as a nonexistent mailbox, or a spam complaint, locate the matching contact in admin and mark it suppressed. Preserve its consent/unsubscribe history and record the provider response, reason and time in your operational records. Do not delete it merely to import the same address again. Verify that its suppressed state excludes it from future sends and that already queued jobs re-check eligibility before transport. For temporary failures such as mailbox full or transient provider throttling, inspect the SMTP response and your provider’s policy. Use bounded retries only when appropriate; repeated temporary failures should be manually suppressed until resolved. Do not repeatedly retry a hard bounce or a complaint. Monitor queued failures and stop a campaign if a systemic issue appears. A job timeout can happen after a remote server has accepted a message. Retrying such a job may duplicate mail, so compare application activity with provider logs before retrying or starting another campaign. Unsubscribe handling is implemented separately from bounce processing; the existence of an unsubscribe route does not imply automatic feedback ingestion. ## References Official guidance checked on 15 November 2026. [1]: https://support.google.com/mail/answer/81126?hl=en "Google Gmail Help — Email sender guidelines"