For Doppler email campaigns, validate your From domain, add it to the domain-authentication panel, publish its generated DKIM TXT record and merge include:spf.fromdoppler.com into SPF. Complete verification and approval, then inspect a newly delivered campaign for a passing, aligned branded DKIM signature. A verification code or green DNS status alone does not establish that result. Doppler authentication, From-domain validation
This guide covers Doppler Email Marketing and distinguishes the separate Doppler Relay transactional workflow below. It concerns the email platform at fromdoppler.com, not the similarly named secrets-management product. Do not use a campaign account's selectors or activation status as evidence for a Relay account.
Start with the sender domain and its DNS owner
Write down the actual From address for every campaign, automation and transactional application. If the address is offers@news.example.com, the domain to configure is news.example.com, not the website's www.example.com. Identify who operates authoritative DNS and who controls the Doppler account. They may be different teams.
Save current authentication records before editing. Include SPF authorizations, DMARC policy and reporting destinations, DKIM selectors belonging to other services, and any parent policy affecting a sending subdomain. Do not move nameservers or change MX records simply to add authentication.
Use a checklist with separate rows for each account, sending product and From domain. Each row should record the full DNS owner, issued value, activation status and fresh message evidence. This is especially useful for an agency: a working configuration for one client cannot be copied into another client's zone.
Validate the campaign From domain
Doppler's ownership check is a distinct step. In a campaign's Basic Campaign Information, enter the From address. Request the verification code at an address using that same domain, retrieve it from the mailbox, enter it in Doppler and select Verify. The documented process applies when adding a new domain. From-email domain validation
Use a mailbox your team can receive at, not an address that exists only as a typed sender label. If the code does not arrive, inspect junk filtering and the mailbox spelling, then try another authorized mailbox on the same domain or seek support. Do not work around ownership by selecting an unrelated domain.
Completing the code challenge proves access for the product's domain check. It does not publish a DKIM key, authorize a sending IP or demonstrate DMARC alignment. Keep its status separate from the DNS and delivered-message checks.
Get the campaign account's generated records
Open your username menu, then Control Panel → Advanced Preferences → DKIM, SPF & DMARC → Add Domain. The official guide allows up to ten domains and makes the first addition the default. For each domain, copy the issued DKIM record name and public key, together with the SPF/DMARC details. Campaign authentication workflow
Check the current account's allowance if adding another domain is blocked. Do not delete an active entry merely to create space. Review which campaigns depend on it and ask Doppler about the supported account arrangement.
A default is not a safe substitute for checking the actual campaign From address. Before a send, compare that address with the domain whose DNS you are configuring. The same caution applies to an automation cloned from an older campaign.
Publish the issued DKIM TXT record
Use the complete name and public value supplied for your domain. There is no tenant key to copy from this guide:
Type: TXT
Owner: EXACT_DKIM_RECORD_NAME_FROM_DOPPLER
Value: COMPLETE_PUBLIC_KEY_VALUE_FROM_DOPPLER
Both capitalized strings are placeholders. Do not publish them literally, choose a selector from another service or reuse a key from a vendor screenshot. Doppler's campaign instructions specify TXT, not a generic CNAME recipe. Doppler record publication
If the issued name is under _domainkey, preserve its selector exactly. For illustration, selector._domainkey.example.com becomes selector._domainkey in a zone editor that appends example.com. A sender subdomain may require selector._domainkey.news in the parent zone. In every case, verify the complete saved name rather than assuming what the editor appends.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
A long TXT key may be displayed as several quoted character strings within one record. That can be valid when they concatenate to the issued value. Separate conflicting key records at the same owner are different and must not be created. Never publish the private signing key. DKIM public-key lookup and record format
If the owner is occupied, establish which service uses it before replacing anything. Ask for supported selector or domain separation rather than choosing your own new selector: the sending service must sign with the corresponding key and selector too.
Configure Doppler SPF safely
The documented Doppler authorization is include:spf.fromdoppler.com. This example is appropriate only for a domain whose complete approved sender policy is Doppler alone:
Owner: example.com
Type: TXT
Value: v=spf1 include:spf.fromdoppler.com ~all
For an existing policy, add the mechanism before the terminal all, preserve other legitimate senders and retain the approved qualifier. Do not add a second SPF policy. Doppler SPF guidance
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
Use one contiguous v=spf1 marker and include:spf.fromdoppler.com without spaces inside the mechanism. Do not concatenate two full SPF policies. The Relay help page contains an older combined example with a repeated version marker and a separate spaced-out illustration; neither is a safe string to publish. Follow valid SPF syntax, not formatting artifacts. Relay example to interpret carefully, SPF syntax and evaluation
SPF checks the SMTP MAIL FROM domain, not the visible From address. A receiving system normally reports that identity as smtp.mailfrom; null-envelope mail uses the HELO identity. Check the actual message before assuming which DNS policy was evaluated. A policy at example.com does not automatically apply to bounce.example.com.
The reviewed Doppler setup documentation does not establish a universal custom Return-Path control. Therefore, do not promise SPF alignment merely because the branded domain contains the include. A provider envelope can pass SPF while remaining unrelated to the visible From domain. That makes branded DKIM validation essential rather than optional.
Keep the entire recursive SPF evaluation within the ten DNS-query-causing-term limit. Nested includes, a, mx, exists and redirect can contribute. Diagnose a permerror before adding further mechanisms. Removing an active mailbox provider to make room may trade a marketing problem for broken business mail.
Keep DMARC policy and reporting under domain-owner control
Inspect the From domain's existing DMARC policy and any applicable inherited policy before using a generated suggestion. Preserve established enforcement and report recipients. Do not publish a second DMARC policy, reset p=reject to p=none or create a subdomain exception just to make one new sender work.
For a domain without established or inherited protection, and only as an approved monitoring starting point:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example reporting mailbox with a working destination you control or your reporting service explicitly supplies. For example.com, use relative owner _dmarc in that zone. For a deliberate policy on news.example.com, use full owner _dmarc.news.example.com, or _dmarc.news in the parent zone and _dmarc in a separately delegated news.example.com zone.
DMARC requires a passing aligned SPF or DKIM identity. Relaxed alignment accepts a shared organizational domain; strict alignment requires an exact domain match. Changing Reply-To does not fix alignment to From. p=none requests monitoring, not rejection, and current DMARC removes the older pct tag. DMARC specification
Reports provide wider evidence than one test message. Before enforcement, inventory unknown sources, confirm legitimate routes and investigate failures over a representative sending period. External rua destinations require reporting authorization; ask the report receiver for its exact setup instead of assuming any mailbox can receive reports. Aggregate reporting requirements
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.
Verify and activate campaign authentication
Return to the authentication panel and run Verify. Doppler documents Pending, Verified, Verified with error and Not configured states, then a Doppler-team approval before the message test. Complete any approval shown for your account; DNS publication alone is insufficient. Verification and approval
When an error persists, compare the issued records with authoritative DNS. Correct a wrong owner or incomplete key before waiting on caches. If public DNS matches and approval remains unresolved, give support the domain, account context, timestamp and exact status, without sharing passwords or unnecessary recipient data.
Use the separate Relay workflow for transactional mail
In Doppler Relay, use Account Settings → Domain Manager → Add Domain. The domain's configuration icon supplies its DKIM selector/public key and SPF information. Publish the issued TXT records and confirm Relay's validation; obtain its DMARC suggestion from Domain Manager but reconcile it with existing policy as above. Doppler Relay authentication
Although the documented SPF include matches campaigns, the account, selector, key and transactional transport still need separate verification. Copy values from Relay for that account rather than assuming the marketing configuration is shared. Test the actual application connection and From identity used for receipts, password resets or other transactional messages.
A custom link or tracking domain is not proof of DKIM or SPF alignment. Likewise, a message client's “via” display is not a reliable technical acceptance test. Use receiver-authenticated identities rather than visual branding.
Validate public DNS and the delivered message
Replace every placeholder below before running these read-only checks. Obtain the selector from the relevant account, and use the actual envelope domain from the delivered message for the last query:
dig +short NS example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT actual-envelope-domain.example
Expect the exact issued public DKIM value, one SPF policy per evaluated owner and one intended DMARC policy at its owner. Unrelated TXT verification records are allowed. If a short lookup is blank, rerun without +short to distinguish a missing name from a timeout or server failure. Compare authoritative and recursive answers before attributing a discrepancy to caching.
Next generate a fresh message through each relevant route. Open the original headers at a receiver you control and identify its trusted Authentication-Results. Record spf and smtp.mailfrom, dkim and header.d, and dmarc with header.from; read the signature's s= selector as needed. An untrusted earlier authentication field is not proof. Receiver-result trust
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Acceptance requires the intended branded DKIM signature to pass and align, not just any dkim=pass, plus dmarc=pass for the intended From domain. Confirm whether SPF also passes and aligns. If SPF passes for a provider-owned envelope, record that as an alignment limitation. If it fails or returns an error, investigate the actual domain and result even when DKIM saves DMARC. A working SPF path does not excuse missing custom DKIM either.
Save the date, route, From domain and redacted results. Retest after sender changes, key changes or transport changes. Do not upload confidential bodies or full customer headers to public analysis tools.
Troubleshoot Doppler authentication
Ownership verified but DKIM absent: the code check and signing configuration are separate. Check the authentication panel, DNS publication and approval, then send a new sample.
Verified with error: compare the account's full names and values with the actual DNS zone. Look for doubled suffixes, TXT truncation, incorrect domain selection and two SPF policies. Do not regenerate keys to address a simple hostname typo.
SPF passes but DMARC fails: compare smtp.mailfrom and the passing DKIM header.d with From. Authentication and alignment are separate. Correct custom signing or the actual sender selection; another apex include cannot rewrite the envelope domain.
SPF returns fail or softfail: confirm the connecting sender and evaluated policy. Check whether an unexpected integration or forwarder was involved. For provider-owned envelope problems, escalate to Doppler with redacted evidence rather than editing a domain you do not control.
SPF returns permerror or temperror: trace duplicate policies, syntax and recursive lookup limits for a permanent error; investigate DNS availability and processing failures for a temporary error. A generic DMARC pass is not a resolution.
Campaigns pass but Relay fails: compare their account, sender domain, issued selector and approval/validation states independently. A shared include is not proof of a shared signing configuration.
Documentation and testing limits
No customer account, DNS zone, campaign or Relay transaction was configured or tested for this guide. Follow the account-specific steps and verify real delivered mail before treating your implementation as complete. Authentication cannot guarantee inbox placement.