Dedicated SMTP and Sending Domains

On one side sits a sending service, either the platform's own included sending infrastructure or a third-party provider connected over SMTP or an API, such as a transactional email vendor you already hold an account with. On the other sits your DNS: the zone where you publish the records that tell the receiving world which servers may send on your behalf, which signatures to trust and what to do when something fails those tests. Between them sits AppBO, holding templates, campaigns, workflow emails and the suppression state of every contact.

You set this up because deliverability is a property of a domain, not of a message. A mailbox connection borrows an existing domain's reputation and is limited to human-scale volume. A dedicated sending domain (usually a subdomain reserved for marketing mail) gives you a reputation you control, volume headroom, and a separation that protects your primary corporate domain if a campaign goes badly. The cost is that you own the work: authentication records, warm-up, list hygiene and monitoring are now yours.

The decision worth making deliberately is whether to send through the platform's bundled infrastructure or bring your own provider. Bundled is faster to start and the platform handles the relay. Bringing your own gives you the provider's own analytics, suppression lists and reputation tooling, and lets you keep one sending identity across several systems. Either way the DNS work is the same, and either way the records must be published on the sending domain rather than on whichever domain happens to host the website.

1. Choose the sending domain. A subdomain of the brand domain is the usual choice, because its reputation is separate from the corporate mail that staff depend on. Keep it recognisably related to the brand. A recipient should see the sender and trust it.
2. Confirm you control DNS for that domain and can add TXT and CNAME records. If a third party manages the zone, arrange that access before starting; a half-configured sending domain sends worse than no sending domain.
3. Decide whether to use the platform's bundled sending or to connect your own provider. If your own, create the account, verify the domain there, and generate the credentials or API key you will give the platform.
4. In the sub-account's email settings, add the sending domain. The platform will present the exact records to publish. Use the values it generates rather than copying examples from anywhere else, including this page.
5. Publish the SPF record. SPF is a TXT record on the sending domain naming the authorized senders. A domain may carry only one SPF record, so merge rather than add a second; and SPF has a lookup limit, so a record that chains through many includes can fail silently. Validate it with a checking tool after publishing.
6. Publish the DKIM records exactly as given. These are usually CNAME or TXT records on a selector-prefixed hostname. The selector string matters and is specific to your sender, so copy it verbatim.
7. Publish a DMARC record on the domain. Start in monitoring mode so you receive reports without rejecting your own mail, and include a reporting address you will actually read.
8. Decide the envelope and return-path configuration. For alignment, the return-path domain should align with the visible from-domain; the platform or provider will tell you which record to publish for this, often a dedicated CNAME.
9. Add the tracking-domain record if the platform offers one. Click and open tracking that rewrites links to a domain matching your sending domain looks far less suspicious to filters than a generic shared tracker.
10. Wait for DNS propagation and then verify inside the platform. Do not skip the platform's own verification step. A record that resolves publicly can still be rejected for a formatting error.
11. Independently verify authentication from the receiving side. Send a test to an address you control on a major provider and inspect the received headers: SPF pass, DKIM pass, and DMARC alignment. Treat a neutral or soft-fail result as a failure.
12. Configure the from-identity: from-name, from-address on the new domain, and a reply-to that reaches a mailbox somebody monitors. Mail from an unmonitored address attracts complaints.
13. Add the compliance furniture before the first campaign: a physical postal address in the footer, a working one-click unsubscribe, and a preference link. Confirm the unsubscribe actually writes back to the platform's suppression state.
14. Warm the domain. Begin with small volumes to your most engaged contacts, increase gradually over several weeks, and let engagement rather than a calendar decide the pace. A cold domain sending a full list in one go is the classic way to earn a lasting reputation problem.
15. Set up monitoring: watch bounce rate, complaint rate and the DMARC reports, and register with the major providers' postmaster tools where available so you can see reputation rather than guess at it.
16. Document which domain sends which traffic, and assign campaigns to the dedicated domain while leaving one-to-one conversation mail on connected mailboxes.

Platform to the sending service

• The assembled message: from-name and address, to, subject, HTML and plain-text parts, headers, and attachments.
• List-unsubscribe headers and the unsubscribe link, where the platform generates them.
• Custom headers or tags that identify the campaign or workflow, used later to segment reporting on the provider side.
• Rewritten click URLs pointing at the tracking domain, and the open-tracking pixel, where tracking is enabled.
• The recipient address, after the platform has applied its own suppression checks. A suppressed contact should never reach the relay at all.

The sending service to the platform

• Acceptance or rejection of each message at submission.
• Delivery events: delivered, deferred, bounced, with the bounce classified as hard or soft.
• Complaint and spam-report notifications, which should mark the contact unsubscribed or suppressed.
• Open and click events, where tracking is enabled and the provider reports them back.
• Unsubscribe signals originating from the provider's own or the mailbox provider's one-click mechanism.

DNS to the receiving world

• SPF: which hosts may send for the domain.
• DKIM public keys under their selectors, so receivers can verify the signature on each message.
• DMARC policy and reporting addresses.
• The return-path and tracking-domain records that give alignment and a branded click path.

What does not move

• Reputation. It is earned per domain and per sending IP and cannot be transferred, bought or reset by changing providers. A new domain simply starts from nothing.
• Suppression lists between systems. A provider-side suppression and a platform-side suppression are separate stores unless the integration explicitly syncs them; verify rather than assume.
• Replies. A sending relay delivers outbound mail; inbound replies need a monitored mailbox or a connected mailbox integration.
• Historical sending history or warm-up progress when you move the domain to a different provider.
• Content review. Nothing in DNS or the relay checks whether a message is compliant with marketing law in the recipient's jurisdiction.

Scenario: a clinic that has outgrown mailbox sending stands up a dedicated marketing subdomain and warms it over a month.

1. The team picks a marketing subdomain of the clinic's brand domain and confirms the practice manager can edit DNS at the registrar.
2. They add the sending domain in the sub-account's email settings. The platform generates the SPF value, two DKIM selectors, a return-path record and a tracking-domain record.
3. The practice manager publishes all of them. The existing SPF record on the parent domain is left alone; the new record goes on the subdomain, avoiding a second SPF record on one name.
4. A DMARC record is published in monitoring mode with a reporting address that forwards to the marketing inbox.
5. After propagation they run the platform's verification, which passes, and then send a test to personal addresses on two different mailbox providers.
6. They inspect the received headers on both: SPF pass, DKIM pass with the expected selector, and DMARC aligned. One test initially shows DKIM failing because a trailing character was lost when pasting the record; they republish and retest.
7. They set the from-address on the new subdomain and the reply-to as the clinic's monitored inquiries mailbox, then build the footer with the postal address and the unsubscribe link.
8. Week one of warm-up: a short newsletter to the few hundred contacts who opened something in the last month. Bounce rate is negligible and opens are strong.
9. Week two: the audience widens to contacts engaged in the last three months, at roughly double the volume. A handful of hard bounces are suppressed automatically.
10. Week three: contacts engaged within the year. Complaint rate ticks up slightly, so they hold volume flat for a second send rather than increasing it.
11. Week four: the full active list. The DMARC reports show all mail authenticating from the expected sources, with no third party sending as the subdomain.
12. A workflow is then switched over so appointment-reminder emails also use the subdomain, while one-to-one replies continue going out through each practitioner's connected mailbox.
13. Ongoing: a monthly check of bounce and complaint rates, a quarterly review of the DMARC reports, and a decision deferred on tightening the DMARC policy from monitoring to a stricter setting once the reports have been clean for a full quarter.

Rate limiting

Three ceilings stack. The platform caps how fast it hands messages to the relay, the provider caps submission on your plan, and every receiving mailbox provider throttles unfamiliar senders independently of both. The third is the one that bites: a receiving provider will defer rather than reject, so a campaign appears to send and then crawls. Consult your provider's published submission limits and the receiving providers' postmaster guidance instead of assuming figures, and slow deliberately during warm-up rather than being slowed involuntarily.

Retries and idempotency

Soft bounces and deferrals are retried by the relay over a window; hard bounces are not and must suppress the address immediately. A submission that times out after acceptance is the duplicate risk, so never re-run a campaign to recover from an ambiguous failure: check what actually delivered first. Workflow sends need the same discipline as any other: anchor on one trigger and guard with a tag, because a replayed workflow sending to a warm list is both a duplicate and a complaint generator.

Field-mapping traps

The visible from-domain and the return-path domain must align for DMARC to pass, and it is entirely possible to have SPF and DKIM both passing while alignment fails, which is why you read the headers rather than trusting a green tick. One SPF record per name, and the lookup limit is real: chaining includes for several providers can break SPF for all of them. DKIM selectors are sender-specific, so a copied example record authenticates nothing. Empty merge fields render as literal placeholder text in subject lines, where it is most visible.

Duplicate creation

Duplicate sends come from the same contact sitting in two segments of one campaign, from a contact record duplicated by a form that matches on a different field, and from running a campaign twice after a partial failure. Duplicate suppression state is the subtler problem: a contact unsubscribed at the provider but still active in the platform will keep being submitted and keep being dropped, inflating your apparent volume and hiding the real complaint signal.

Sandbox versus live

Most providers offer a test mode or a sandbox that accepts messages without delivering them, which is useful for proving the relay connection and useless for proving deliverability. Reputation can only be built live. Keep a separate test domain for building workflows, and never warm a domain with test traffic to seed lists. That is how a new domain gets blocked before its first real campaign.

Authentication expiry

SMTP credentials and API keys can be rotated or revoked at the provider, and a key rotated for good security reasons will stop sending with no warning inside the platform. DNS is the other expiry risk: a zone migration, a registrar change or a well-meaning tidy-up removes DKIM records and mail starts failing authentication while still being accepted. Keep an inventory of the records, and re-verify after any DNS work.

What commonly breaks

• A second SPF record added for a new tool, which invalidates SPF for everything.
• A DKIM record truncated by a DNS interface that splits long TXT values incorrectly.
• DMARC tightened to a strict policy before the reports were clean, which rejects the business's own mail.
• Sending a purchased or scraped list on a new domain, which ends the domain's usefulness in a single campaign.
• A tracking domain pointed at the wrong host, breaking every link in every email at once.
• Unsubscribe links that do not write back to suppression, so unsubscribed contacts keep receiving mail and start complaining.
• A monitored reply-to that quietly stops being monitored after a staff change.
• Images and links hosted on a domain unrelated to the sender, which some filters weigh against you.