For Ambassador versions 1 and 2, configure an email sending domain in Settings > Account > Email Setup, publish the account's generated SPF TXT, MX and DKIM TXT records, and use Verify before selecting outgoing addresses. Both the account-level outgoing address and campaign-specific addresses must receive replies. The official support center explicitly labels this workflow as legacy versions 1 and 2; do not apply it to another Ambassador edition without matching instructions. Ambassador sending-domain documentation.
A verified domain is one checkpoint. To accept a branded configuration, also require a delivered message with the intended From address, a passing aligned branded DKIM signature, and working replies. An SPF-only DMARC pass does not demonstrate that the requested DKIM setup works.
This is a documentation-based guide, not an account walkthrough performed on a customer tenant. No DNS records were changed and no messages were sent.
Before you start: confirm the account, domain and mailbox
This guide covers Ambassador's documented automated-email sending-domain workflow. It does not configure website hosting, tracking links, a mailbox service, or an unrelated product called Ambassador. If your account has different controls or generates a different record set, obtain instructions for that edition before publishing anything.
Prepare:
- Access to the applicable Ambassador account and its sending-domain settings.
- Permission to edit the domain's authoritative DNS, or a DNS administrator who can implement the approved change.
- The exact domain or subdomain to authenticate, and an inventory of existing SPF, DKIM, MX and DMARC records affecting it.
- The intended account-level From address and every campaign override, with a person responsible for receiving replies.
- A harmless test message, a controlled recipient mailbox and a rollback owner.
Record the current DNS and sender settings before editing. A subdomain used for this workflow can reduce conflicts, but it does not inherit an SPF policy from the parent, and it does not automatically have a working mailbox. Keep authentication, incoming mail routing and reply handling as separate checks.
Choose a domain without breaking an existing selector
Ambassador's documented collision rule matters: if an entry already exists at m1._domainkey for the proposed domain, use a subdomain. Its instructions recommend an unused name such as a referral-specific subdomain and say not to use mail or email. The page also notes DNS-provider differences; that is not permission to overwrite another sender's selector. Domain-selection guidance.
For example, m1._domainkey.example.com and m1._domainkey.referrals.example.com are different DNS owners. Moving the proposed sending domain can avoid a collision, but only the records generated for that domain tell you what to publish. The mention of m1 in a collision warning is not a universal public key or a reason to manufacture a selector.
Identify who owns an existing record before changing it. Replacing its key can break messages already signed by another service. See how to avoid DKIM selector collisions for the shared-domain planning issue. A CNAME cannot coexist with TXT or other ordinary record data at the same owner; resolve the name conflict rather than adding another record beside it.
Generate the complete Ambassador record set
In the documented account:
- Open Settings, then the Account settings and Email Setup section.
- Choose Add Domain, enter the approved domain or subdomain, and select Add.
- Keep the generated-record window open. Copy each complete Host/Name and Value with its record type.
- Prepare all three documented records: TXT for SPF, MX and TXT for DKIM. Do not convert the DKIM record to CNAME because another sender uses CNAMEs.
These controls and record types come from Ambassador's setup article. The values are account-generated. This guide deliberately provides no reusable Ambassador include, key, MX target or priority.
| Generated item | What to preserve | What to check before publication |
|---|---|---|
| SPF TXT | Owner and approved authorization mechanisms | Whether that owner already has an SPF policy |
| MX | Exact owner, target and supplied priority | Whether existing inbound-mail routing would change |
| DKIM TXT | Full owner, selector and complete public-key value | Existing selector dependency and TXT formatting |
Do not replace the organization's normal MX records to make a setup banner green. If the proposed MX owner already receives business mail, have the mail administrator reconcile the design or select an unused, supported sending subdomain. Keep the provider-generated MX and the receiving mailbox requirement visible in the same change review.
Publish SPF and DKIM without overwriting other senders
The authoritative DNS host is the service whose nameservers answer for the zone, which may differ from the domain registrar. Work there, not in an inactive DNS panel.
SPF: one policy at each evaluated owner
If the generated SPF owner has no existing SPF policy, review the generated policy against the domain's legitimate senders before publishing it. If it already has one, reconcile Ambassador's authorization into that one policy, preserving the other approved senders and terminal qualifier. Do not paste two complete v=spf1 strings together or create a second SPF TXT record.
Mechanisms must remain separate tokens, and a new authorization must appear before a terminal all. Policies using redirect= require careful evaluation rather than a blind append. Preserve unrelated TXT records. SPF publication and evaluation rules, merging multiple SPF records.
SPF has a limit of ten evaluated DNS-dependent terms, including nested include, a, mx, ptr, exists and redirect operations. This is not ten visible includes or ten network packets. ip4, ip6 and all do not consume that term budget. An eleventh evaluated term causes permerror; review dependency paths before adding another sender. RFC 7208, section 4.6.4.
DKIM: publish the generated public value unchanged
Publish the complete DKIM TXT value at its generated owner. Do not generate a replacement private/public key pair yourself: Ambassador must sign with the matching private key. Never place private keys or account credentials in DNS.
A DNS interface may split a long TXT value into multiple quoted character strings within one TXT resource record. That is different from publishing multiple independent key records. Check the reconstructed value, not its visual wrapping. TXT representation, DKIM key lookup.
Use the correct DNS owner
If the generated owner is SELECTOR._domainkey.referrals.example.com and you edit the example.com zone, a relative-name field usually needs SELECTOR._domainkey.referrals. In a separately delegated referrals.example.com zone, it usually needs SELECTOR._domainkey. Some editors require the full name instead. Replace SELECTOR with the actual generated selector and inspect the saved owner to avoid a doubled domain suffix.
Verify the domain, then configure every outgoing address
Return to the domain's record window and select Verify. Ambassador documents Pending, Verified and Error states, with changes potentially taking up to 24 hours to propagate. Removed records and wrong record types are named error causes. Waiting cannot repair either. Compare the published owners, types and values before making another change. Verification and sender settings.
Once verified, edit Outgoing Email, save the desired name and address, and check any campaign email-template overrides separately. Each address must be able to receive mail. Domain authentication does not create a mailbox, and a valid display name does not fix a broken reply destination.
Create a small campaign inventory: campaign/template, From address, authenticated domain, reply mailbox owner and last accepted test. A campaign that selects a different From domain needs its own alignment assessment even if the account's default sender passed.
Keep DMARC aligned with the actual From address
SPF authenticates the SMTP MAIL FROM domain, usually reflected in Return-Path, rather than the visible From address. DKIM identifies its signing domain in d= and selector in s=. DMARC compares the visible From domain with an authenticated SPF or DKIM identity. At least one must pass and align for a DMARC pass. Current DMARC standard, RFC 9989.
Relaxed alignment permits an organizational-domain match; strict alignment requires the exact domain. For example, d=referrals.example.com and From: program@example.com can align under relaxed adkim=r, but not strict adkim=s. An unrelated provider signing domain does not align with example.com. Check the actual result instead of guessing which identity the setup creates. The reviewed Ambassador page does not document a separate custom return-path control.
Inspect the existing DMARC policy and any inherited parent policy before changing it. Preserve established enforcement, reporting and alignment modes. Do not add a permissive subdomain policy merely to bypass a stricter parent policy.
For a new, approved monitoring policy with no conflicting existing or inherited enforcement, the owner mapping is:
| Visible From domain | DNS zone being edited | Relative TXT Host/Name | Full owner |
|---|---|---|---|
example.com |
example.com |
_dmarc |
_dmarc.example.com |
referrals.example.com |
example.com |
_dmarc.referrals |
_dmarc.referrals.example.com |
referrals.example.com |
referrals.example.com |
_dmarc |
_dmarc.referrals.example.com |
Illustrative value, not a replacement for an existing policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the reporting address with an approved, monitored destination. p=none requests monitoring, not protection through quarantine or rejection. A reporting service outside your domain may need external-destination authorization under RFC 9990. Limit report access and retention; do not add failure-reporting ruf destinations casually because reports can expose message-related information. Failure-report privacy considerations.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Do not plan a rollout around pct: RFC 9989 removed it. Separately assess all legitimate mail before stronger enforcement. A domain using p=reject must not rely solely on SPF and must apply valid DKIM signatures. DMARC interoperability requirements.
Run DNS checks and a real-message acceptance test
These are checks for your administrator to run, not results obtained for this guide. Substitute the exact generated names in these read-only commands:
dig +short NS example.com
dig @AUTHORITATIVE_NS TXT GENERATED_SPF_OWNER +noall +answer
dig @AUTHORITATIVE_NS TXT GENERATED_DKIM_OWNER +noall +answer
dig @AUTHORITATIVE_NS MX GENERATED_MX_OWNER +noall +answer
dig +short TXT _dmarc.referrals.example.com
Use the nameserver authoritative for the actual zone, including a delegated subdomain where applicable. Expect one SPF policy at its owner, the complete matching public DKIM value, and the intended MX target/priority without disrupting other receiving routes. Repeat against a recursive resolver after the relevant TTL expires. An empty +short answer alone does not distinguish a missing record from a lookup error; inspect the full response/status.
Then send harmless messages through the actual automated flow and each materially different campaign override to a mailbox you control. Open raw headers there. Trust only Authentication-Results added by your receiving service or trusted gateway, not an arbitrary field supplied by the sender. Use receiver-controlled message diagnostics or have the receiving administrator establish the trusted boundary and how externally supplied authentication headers are removed or ignored. A familiar authentication-server identifier or a header’s position alone is not proof. Receiver trust boundary.
| Acceptance evidence | Required observation |
|---|---|
| Visible From | Matches the approved campaign identity, not an unexpected default |
| Branded DKIM | Intended signing domain and selector are present; trusted receiver reports dkim=pass; signing domain aligns under the actual adkim mode |
| SPF | Record actual smtp.mailfrom, sending IP and result; resolve SPF errors even when DKIM carries DMARC |
| DMARC | Trusted receiver reports dmarc=pass for the intended From domain; identify the aligned passing path |
| Reply handling | A harmless reply reaches the approved monitored mailbox |
| Scope | Account and tested campaign/template recorded with UTC timestamp |
A provider-domain DKIM pass, missing branded signature, or SPF-only DMARC pass leaves the branded-DKIM setup incomplete. Record SPF alignment separately; both mechanisms need not align for one message to pass DMARC. Authentication also does not guarantee inbox placement or establish that a business request in a message is trustworthy.
Troubleshoot and recover without weakening protection
| Symptom | What to inspect | Safe next step |
|---|---|---|
| Selector already occupied | Owner of the existing m1._domainkey dependency |
Use the documented unused-subdomain route; do not overwrite the other key |
| Pending or Error | Authoritative owner, type, complete value and MX priority | Correct the specific mismatch; allow caches to expire before rerunning Verify |
spf=permerror |
Duplicate policies, malformed tokens, broken includes or more than ten evaluated DNS-dependent terms | Repair the policy/dependency; do not add another SPF record |
spf=temperror |
DNS timeouts, SERVFAIL or unavailable authoritative servers | Investigate DNS availability; do not rewrite a valid policy merely because a temporary lookup failed |
spf=fail, softfail or neutral |
Actual sending IP and MAIL FROM, versus the authorized route | Confirm the real sender and applicable policy; never use +all as a workaround |
| DKIM missing or failing | Actual d=/s=, correct key, domain status and any message modification |
Fix the exact route; inspect direct delivery before blaming forwarding |
| DMARC passes but branded DKIM does not | SPF may be supplying the pass | Keep DKIM acceptance open until the intended aligned signature passes |
| Replies disappear | Account and campaign sender addresses, mailbox provisioning and MX | Restore a known working address and verify its receiving route |
If a change breaks mail, pause the affected automated route or restore the previously approved sender configuration. Roll back only the incorrect DNS diff, preserving other senders. Keep old keys long enough for queued or delayed signed messages to be checked, under the mail administrator's retention plan. Do not downgrade domain-wide DMARC to conceal one campaign's mismatch.
Quick answers
Is there one SPF include for every Ambassador account?
This documented workflow generates the SPF value in the account. Use that value and reconcile it at its exact owner; do not invent a universal include from the provider name.
Does Ambassador use TXT or CNAME for DKIM?
The versions 1 and 2 guide specifies TXT for DKIM, alongside SPF TXT and MX. Use another record type only if current instructions for your actual edition and account explicitly require it.
Can I reuse a verified domain for any campaign From address?
Only after checking that the campaign's actual From and signing identities align. A different domain is not authenticated merely because another domain in the account is Verified.
Does Verified mean the setup is finished?
No. It establishes the application checkpoint. Complete the delivered-message, branded-DKIM alignment and reply tests as well.
Will successful authentication keep every referral email out of spam?
No. Receiver policy, reputation, content and recipient engagement remain relevant. Save placement observations separately from authentication results.