Confirm the legacy Ambassador product boundary
Ambassador's official “How to setup an Email Sending Domain” article appears in the support center explicitly labeled for legacy Ambassador versions 1 and 2. It documents a domain-setup workflow for automated email, followed by separate outgoing-address settings and optional campaign-level overrides. This guide applies to that documented route. It does not establish that a newer Ambassador edition has identical controls or that an inspected account has completed them. Current product applicability and actual tenant-generated records remain open. Ambassador sending-domain guide
Start with a route inventory: the account, referral or other automated message category, intended visible sender domain, responsible business owner and DNS administrator. Record which addresses should receive replies. A domain suitable for a tracking link is not automatically suitable for email delivery, and an address used as a display identity is not necessarily a functioning mailbox. This inventory is proposed preparation, not evidence that any account or domain has been inspected.
Choose the domain without overwriting an existing dependency
The documented path begins in Settings, then Account settings and Email Setup. Add Domain accepts the domain or subdomain intended for the route. Before proceeding, the provider highlights an existing m1._domainkey entry as a conflict requiring a subdomain, while also noting that some DNS-provider arrangements may permit adding entries without allocating one. It recommends an unused subdomain and explicitly says not to use “mail” or “email.” Treat that ambiguity as a reason to confirm the supported account-specific arrangement, not permission to overwrite an existing authentication dependency. Ambassador sending-domain guide
The proposed review should identify who uses any existing selector and whether the candidate subdomain already serves another purpose. Preserve active authentication records until their owner confirms a safe transition. Do not manufacture a second conflicting key simply to satisfy a product checklist. Where the provider's stated collision rule applies, retain the required subdomain decision rather than weakening it into an optional preference.
A DKIM selector works with the signing domain to identify the public verification material used by a receiver. A record at a similar-looking owner does not substitute for the owner actually referenced in a signature. The application must also sign with the corresponding private material; a DNS record alone cannot create that behavior. These protocol facts explain why an apparently small selector collision can affect another legitimate route. RFC 6376, sections 3.5 and 3.6.2.2
Preserve the complete generated record set
After adding the domain, Ambassador says the account supplies three records: TXT for SPF, MX and TXT for DKIM. Keep the actual record window available and transfer each supplied Host/Name and Value into the authorized change record. The provider offers copy controls and an option to send the records to a colleague when the operator lacks DNS access. No such email or account action has been performed for this draft. The three-record requirement is documented; the actual tenant values are not. Ambassador sending-domain guide
Do not infer an MX target, preference or DKIM public key from a screenshot belonging to another account. Do not substitute a CNAME merely because other email services use CNAME-based DKIM delegation. Follow the actual supplied type and confirm the full intended owner name. MX changes also deserve a separate mail-routing review: authentication setup is not blanket approval to replace unrelated incoming-mail routing at a shared domain.
The DNS operator should write the fully qualified owner independently of the editor's Name field. Some interfaces append the zone suffix, while other entry modes require a complete name. A repeated suffix can place a perfectly copied value under the wrong owner. DNS master-file conventions do not establish how every graphical editor interprets shorthand. Compare the intended name with the resulting publication rather than relying only on the form's appearance. RFC 1035, section 5.1
Reconcile SPF rather than adding a competing policy
If the generated SPF record belongs at an owner that already has an applicable SPF policy, review the complete policy and existing legitimate senders before changing it. Publishing two independent SPF policies does not combine their permissions and can produce a permanent error. Preserve unrelated TXT records while maintaining one applicable SPF policy for the evaluated identity. A short service example is not authority to erase another approved sender. RFC 7208, sections 3.1–3.3
SPF evaluates the relevant SMTP MAIL FROM identity or HELO identity in the applicable cases, not simply the address displayed to the recipient. Review the identity actually used by this route when authorized evidence becomes available. Also review the evaluated DNS-querying terms across nested dependencies. The protocol's limit is not a count of network packets or merely the include terms printed in the first record. RFC 7208, sections 2.3–2.4 and 4.6.4
TXT formatting requires care without guesswork. Several character strings may form one TXT resource record, and visible wrapping or quotation marks may be presentation rather than extra content. Preserve the intended logical value and distinguish it from multiple independent records. If the interface changes the representation, review the resulting data before accepting the publication. RFC 1035, section 3.3.14
Interpret domain status as one checkpoint
The provider documents Pending, Verified and Error states and a Verify control in the record modal. It associates common errors with removed records or incorrect record types and says changes may take up to 24 hours to propagate. That interval is provider guidance, not proof that every resolver will return the intended value at a particular moment. Record the current status and observation time separately from authoritative DNS evidence. Ambassador sending-domain guide
If verification fails, compare owner, type and complete value before making another edit. Repeatedly changing an already correct authoritative record can make diagnosis harder when a cache still holds an earlier result. Conversely, waiting cannot repair a wrong owner or record type. The proposed process distinguishes configuration intent, published DNS and application verification rather than turning elapsed time into evidence of correctness.
Configure reply-capable outgoing and campaign addresses
After domain verification, the documented workflow edits the Outgoing Email name and address. Ambassador explicitly requires that address to receive mail because replies are delivered there. Optional campaign-level changes to From name and address carry the same receive-mail requirement. Preserve that prerequisite for each override; a verified domain does not make a nonexistent or unmonitored mailbox an acceptable reply destination. Ambassador sending-domain guide
Maintain a campaign-to-address checklist with the mailbox owner and intended reply handling. Separately record the actual envelope identity and DKIM signing domain when an authorized message can be assessed. DMARC requires a qualifying aligned SPF or DKIM result relative to the visible From domain. The application displaying Verified does not by itself establish that every campaign override has the intended alignment. RFC 9989, section 4.4
Fictional diagnosis: verified domain, unusable reply address
In a fictional organization, Maple Circle, an operator prepares the legacy sending-domain setup and records a Verified state. A campaign editor then changes its sender to an attractive but nonexistent address. Another administrator also proposes reusing a selector already owned by a different route. This is an invented acceptance exercise, not an observed incident or executed test.
The review separates the issues. It retains the provider's reply-capable address requirement for the campaign override, obtains an approved mailbox decision and resolves the existing selector dependency without overwriting it. It then keeps actual received-message evidence pending. Neither the domain status nor a copied DNS value is treated as proof that the campaign's replies, signing and alignment are ready.
Blank acceptance worksheet
- Actual Ambassador edition, account and applicability confirmation: ____.
- Approved sending domain or subdomain and business owner: ____.
- Existing selector dependencies and collision decision: ____.
- Subdomain naming restrictions reviewed: ____.
- Three generated record types, complete owners and values: ____.
- Existing SPF policy and mail-routing dependencies preserved: ____.
- DNS operator, approved change reference and rollback owner: ____.
- Application status, DNS observation times and unresolved errors: ____.
- Outgoing and campaign addresses with reply-capable mailbox owners: ____.
- Authorized message identities, alignment evidence and release approver: ____.
All entries are blank. Original evidence, human/SME review, source applicability, production routes, visual/accessibility review and owner release remain open. No tenant setup, DNS change or message send has occurred. Authentication does not guarantee inbox placement or make a business request safe. RFC 9989, section 2.4