> ## Documentation Index > Fetch the complete documentation index at: https://ahasend.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > AhaSend stores all message data in the EU. See /facts. > The API base URL is https://api.ahasend.com. Send the API key in the Authorization: Bearer header. See /api-reference/authentication. > Use send.ahasend.com for SMTP. Ports 25, 587 and 2525 use STARTTLS. Port 465 is not supported. See /smtp. > For send-only integrations, create an API Key v2 under Credentials → Add and scope it to messages:send:{your-domain}. See /send-api/credentials and /api-reference/scopes. # Email Deliverability Best Practices > Improve transactional email deliverability with AhaSend: sender reputation, domain and IP warm-up, separate subdomains, Gmail and Yahoo rules and opt-outs. AhaSend helps you track transactional email delivery; this guide explains how to protect sender reputation, warm up sending, separate mail streams and meet mailbox-provider requirements. ## What Does Delivered Mean? Delivered means the recipient's mail server accepted the message. It does not prove the message is in the inbox or that a person read it. Review [delivery events](/docs/api-reference/webhooks/message-delivered.md), [bounces](/docs/bounces.md) and user reports together. Open and click tracking can be affected by mailbox software and bots; it is not a complete measure of engagement. ## How Do I Protect Sender Reputation? Send messages people expect from their actions, such as a requested reset or an order receipt. Verify addresses during signup, remove invalid addresses from future jobs, and keep complaints and opt-outs blocked. Use consistent From names and domains so users recognize the sender. Keep promotional content out of time-sensitive service messages when it changes what the recipient signed up for. Watch delivery failures and temporary deferrals by receiving domain. A sudden rise can show a bad import, broken authentication, an unexpected volume change or a provider-specific block. Start with the [bounce report](/docs/api-reference/reports/get-bounce-report.md) and [delivery statistics](/docs/api-reference/reports/get-deliverability-report.md), then read actual SMTP replies. Repair the cause before raising volume. ## How Should I Warm Up a Domain or IP? Warm-up means increasing real, wanted email gradually so receiving systems see a stable sending pattern. A new domain needs care even on a shared IP; a new dedicated IP also needs its own sending history. Buying a dedicated IP does not repair an untrusted recipient list. See [dedicated IP availability](/docs/scale/dedicated-ips.md) and [IP pools](/docs/scale/ip-pools.md) for the product settings and plan rules. There is no fixed daily schedule that works for every sender. Base the next increase on your normal traffic and the receiving domains' responses. This is a decision schedule, not a promised volume allowance: | Step | Traffic to send | Condition before increasing | | - | - | - | | Before starting | Sandbox tests and authentication checks | Correct records, message format, suppression import and event handling | | First live portion | A small part of recent, expected transactional traffic | Low failure and complaint rates; no growing deferral queue | | Gradual increases | More of the same legitimate traffic, spread over time | Stable results at each major recipient provider | | Steady operation | Normal recurring traffic | Continue watching bounces, complaints and sudden changes | | A provider starts deferring | Hold or reduce traffic to that provider | Investigate its reply and wait for recovery before increasing | Avoid creating fake engagement or mailing old addresses just to warm an IP. Keep the previous sending path available during a migration, while ensuring each job is assigned to only one provider. The account's [sending limits](/docs/facts.md) still apply. ## Should Transactional Mail Use a Separate Subdomain? Use a subdomain such as `notify.example.com` for transactional mail when you need separate credentials, reporting and mail policies from newsletters or employee mail. [Add and verify that exact subdomain](/docs/domains.md), then use it in the visible From address and review DMARC alignment. A separate subdomain makes operations easier to manage; it does not guarantee that reputation is fully isolated from the parent domain. Keep the main domain's mailbox MX records in place. A return-path subdomain and a visible From subdomain serve different purposes; follow the records AhaSend gives you for each. ## Which Sending Type Should My Domain Use? Each sending domain is transactional or marketing. The type decides which infrastructure and sending limit the domain's API and SMTP mail uses, and whether that mail gets one-click unsubscribe headers. Match it to the mail you send: transactional for messages a recipient expects from their own actions, marketing for newsletters, promotions and announcements. If you send both kinds, use a separate [subdomain](#should-transactional-mail-use-a-separate-subdomain) for each, so the two reputations stay apart. Campaigns made with [Campaign Builder](/docs/campaigns.md) always use the marketing infrastructure, whatever the domain's type. How to set the type, and what each setting does, is on [sending type](/docs/domains.md#sending-type). > [!WARNING] > > Do not send marketing mail through the API or SMTP from a transactional domain. It can get your account paused. ## What Do Gmail and Yahoo Require? Review these rules before launch and whenever a provider changes its guidance. This summary was checked in September 2026; the provider pages remain the source of current requirements. | Requirement | Gmail | Yahoo | | - | - | - | | Basic authentication | SPF or DKIM for all senders | SPF or DKIM for all senders | | Bulk authentication | SPF, DKIM and DMARC, with aligned From identity | SPF, DKIM and DMARC, with aligned From identity | | Infrastructure | Valid forward/reverse DNS and TLS | Valid forward/reverse DNS | | Spam complaints | Keep reported spam below 0.3%; aim much lower | Keep reported spam below 0.3% | | Marketing and subscribed mail | One-click unsubscribe plus a visible body link for bulk senders | Functioning list unsubscribe plus a visible body link for bulk senders; honor requests within two days | Gmail applies its bulk requirements to senders exceeding 5,000 daily messages to personal Gmail accounts; do not apply that number to Yahoo as though it were Yahoo's threshold. Gmail accepts `p=none` as the minimum bulk-sender DMARC policy. AhaSend's own required domain setup is on [domains](/docs/domains.md). See [Gmail sender guidelines](https://support.google.com/mail/answer/81126) and [Yahoo sender best practices](https://senders.yahooinc.com/best-practices/). A password reset requested by a user is different from a newsletter. Decide whether a message is marketing or subscribed mail by its actual purpose and content; calling it transactional does not remove provider requirements. ## How Do I Add One-Click Unsubscribe? It depends on how the mail is sent: * **Campaigns** always have one: Campaign Builder adds a link for each recipient and the one-click headers, and will not send a campaign without the link. See [the unsubscribe link in a campaign](/docs/campaigns/create.md#the-unsubscribe-link). * **API or SMTP mail from a marketing domain** gets the one-click headers from AhaSend. Add the visible link in the body yourself, with `{{unsubscribe_url}}` for a signed AhaSend link, or with your own unsubscribe endpoint. * **API or SMTP mail from a transactional domain** gets the link and the headers only when you put `{{unsubscribe_url}}` in the content. Whichever you use, keep the opt-out in your own data too, so the address is left out of your next send. The rules for `{{unsubscribe_url}}`, for your own `List-Unsubscribe` headers and for building your own endpoint are on [unsubscribe links and one-click headers](/docs/campaigns/unsubscribe.md). ## Related Guides * [Domain setup](/docs/domains.md), [DNS providers](/docs/dns.md) and [send-only API keys](/docs/send-api/credentials.md). * [REST API](/docs/send-api/send-email.md), [SMTP settings](/docs/smtp.md), [CLI quickstart](/docs/cli/quickstart.md), [Node.js SDK](/docs/guides/nodejs-sdk.md) and [Go SDK](/docs/guides/go-sdk.md). * [Plans and limits](/docs/facts.md), [delivery webhooks](/docs/integrations/webhooks.md) and [troubleshooting](/docs/troubleshooting.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.