On this page: Identify your sending scope first · Understand what SPF, DKIM and DMARC will establish · Review the Delivra SPF authorization safely · Generate and publish the domain’s DKIM key · Enable signing after the record is valid · Decide whether a custom return path fits the whole site · Preserve DMARC and use reporting deliberately · Verify DNS and a real campaign independently · Troubleshoot the step that actually failed · Frequently asked questions
To authenticate Delivra campaigns, review the documented SPF authorization, generate a DKIM record for each sending domain, publish its exact public value, and enable signing in Delivra. Verify the actual campaign at a trusted receiver. If you need a custom return path, review its site-wide scope before asking Delivra to activate it.
This guide is based on current public documentation, not an authenticated Delivra walkthrough. No account settings, customer DNS or delivered messages were tested or changed.
Identify your sending scope first
This guide covers Delivra-managed marketing campaigns. Do not apply its DNS values to an unrelated SMTP server simply because that server sends similar content. For transactional applications, integrations or a customer-managed SMTP route, establish the actual delivery service and its authentication requirements before reusing campaign settings. The retrieved documentation does not establish a general bring-your-own-SMTP workflow.
Employee mail through Microsoft 365 is a separate route; use the Microsoft 365 authentication guide for that service rather than assuming these campaign records configure it.
Delivra says account settings depend on the licensed feature set and user permissions in Finish setting up your account. Have your site administrator confirm access to Domain Keys and the scope of the site. Do not confuse a plan requirement for branded click-tracking domains with a DKIM requirement. Authentication, link tracking and hosted-content domains are separate functions.
Inventory every visible From domain, account and sending route. Include subdomains and other brands under the same site. A local-part change from news@example.com to events@example.com does not change the domain, but moving to events@another.example does. Delivra’s linked authentication instructions support multiple sending domains and require a unique DKIM selector and key for each domain.
Use a domain you control, with permission to edit its authoritative DNS. Owning an address at a public mailbox provider does not give you DNS control of that provider’s domain. Verify which DNS zone is authoritative and save existing records before any change.
Understand what SPF, DKIM and DMARC will establish
SPF authorizes servers for the envelope MAIL FROM identity. It does not directly authenticate the visible From field. DKIM authenticates a signature’s signing domain, recorded as d=, using the selector s= to find a public key. DMARC ties a passing SPF or DKIM identity to the visible From domain.
Under RFC 9989, a single passing aligned path is enough for DMARC. Relaxed alignment permits a shared organizational domain; strict alignment requires an exact match. A passing SPF result for a Delivra-controlled bounce domain may be unaligned while your custom DKIM signature supplies the aligned pass.
Neither a green setup indicator nor a public DNS record demonstrates that the actual message used the expected identity. You need a newly received campaign and its trusted receiver-added results. Authentication does not establish that content is safe or guarantee inbox placement.
Review the Delivra SPF authorization safely
The official Email Authentication Instructions, linked by Delivra’s current help center, specify include:ne16.com. When adding the documented authorization to your domain’s SPF, merge it into the existing policy before the final all mechanism. Preserve approved staff-mail, billing and other senders. If there is no policy, inventory those senders before creating one.
The vendor’s sample also contains mx. Do not add mx automatically: inbound mail exchangers are not necessarily authorized outbound senders. Likewise, do not replace your established final qualifier just to resemble a tutorial.
The mx mechanism authorizes the applicable A/AAAA addresses of the resolved mail exchangers, not the mailbox names alone. Compare those addresses with the approved outbound-sender inventory before retaining or adding that authorization. SPF mx evaluation.
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed redesign. SPF qualifiers describe authentication results, not guaranteed receiver delivery or rejection decisions. SPF all and redirect processing.
Validate the actual envelope identity after sending. Adding include:ne16.com at the root does not make a provider-owned MAIL FROM domain align with your From domain. Domain authorization and envelope alignment solve different problems.
SPF’s standard, RFC 7208, allows one SPF policy per owner. Ten evaluated DNS-querying terms is the limit, including nested includes and other applicable mechanisms or modifiers. It is not a ten-vendor allowance. A TXT record may contain several quoted character-strings; the 255-octet limit applies to each string, not the entire logical SPF policy. Never split one SPF policy into two separate v=spf1 records to work around a DNS editor limit.
Generate and publish the domain’s DKIM key
Follow the current linked setup instructions:
- Open Settings in the left-hand navigation.
- Under Account, choose Domain Keys.
- Select Create Domain Key.
- Enter the intended sending domain, select the supported key size, and choose Save & Next.
- Copy the Domain Name, DKIM TXT Record Address and DNS TXT Record value for the DNS administrator.
- Publish a TXT record using that exact owner and generated public value.
Do not publish the example selector shown in documentation. Do not generate a key in an unrelated online tool and expect Delivra to possess the matching private key. Only public material belongs in DNS.
Use a supported 2048-bit RSA option where available. If a DNS editor appears to truncate the value, investigate its multi-string TXT handling and consult the DNS provider before replacing or weakening the key. A controlled rotation should preserve the ability to verify messages already signed with an old selector until they have cleared delivery queues.
For an editor that appends the zone name, enter only the relative portion, such as selector._domainkey; if it expects a full owner, use the generated fully qualified name. Confirm the actual public answer, including every character of the concatenated key. Keep other providers’ selectors intact.
For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use SELECTOR with that zone's administrator. A full-name field takes the complete owner. Use the actual account selector, not this placeholder. Preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. Do not change nameservers, DNSSEC, mailbox MX or forwarding merely to publish a key. DNS zone boundaries.
Enable signing after the record is valid
Return to Settings > Account > Domain Keys. The official instructions say Enable Signing becomes available when the key is present and valid in DNS. Use that control. Publication and activation are separate steps; the presence of a public key does not mean Delivra is using it.
Delivra’s current authentication overview also describes SPF, DKIM and DMARC indicators beside Sender Name and Address during campaign setup. Resolve warnings, but do not treat green indicators as a delivered-message acceptance test. Delivra says incomplete authentication does not itself prevent sending; that is not a recommendation to send unauthenticated campaigns.
The official setup guidance allows up to 48 hours for DNS changes to become visible. Compare authoritative DNS first: a wrong owner or truncated value needs correction, while a correct new answer may still be hidden by an older cached response.
The linked instructions also describe separate Yahoo complaint-feedback enrollment, using the domain’s DKIM selector and postmaster-mailbox verification. Treat this as its own feedback-loop process, not another DKIM DNS row. Confirm the current process and approved complaint-routing destination with Delivra before enrollment; do not substitute a DMARC reporting address or disclose verification codes to unrelated parties.
Decide whether a custom return path fits the whole site
Delivra’s Custom Return Path for SPF Alignment is a site-wide configuration, not a separate per-account setting. Its instructions require all accounts to use sending domains aligned with the same root domain. Review multi-brand sites before making this change.
The documented DNS step is an unused bounce subdomain under your sending domain, with a CNAME target of lists.n-email1.net. The source uses bounces.example.com as an example owner. Choose your own approved owner and confirm the current target with Delivra before implementation. After DNS is live, supply that subdomain to Delivra Support; its team verifies DNS, changes the site configuration and sends a test. Delivra continues handling bounces.
The optional bounce CNAME needs the following alias controls; these do not apply to Delivra's direct-TXT DKIM public key. Where literal CNAME answers are required, use DNS-only aliases returning the exact issued targets, without HTTP proxying or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
Do not add a TXT record alongside that CNAME at the same owner. Do not reuse a subdomain already hosting a different service. A bounce subdomain can align with the root under relaxed SPF alignment, but does not exactly match the root under strict aspf=s. An enforcement policy such as p=reject is not the same as strict alignment. Custom DKIM can still provide the aligned DMARC path without SPF alignment.
Preserve DMARC and use reporting deliberately
Retain the domain’s established DMARC policy and any applicable inherited subdomain policy. Do not replace enforcement with p=none when onboarding Delivra. First make its actual messages authenticate and align.
Only if there is no applicable established policy, the domain owner may begin a monitoring rollout after inventorying legitimate sources and confirming their authentication. For a fictional From domain example.com, create one TXT record at _dmarc.example.com containing v=DMARC1; p=none. A DNS editor that appends the zone suffix would use _dmarc as the owner. This is a conditional example, not a change to make on every domain.
For an approved child-domain policy, _dmarc.news.example.com is relative _dmarc.news in zone example.com, or _dmarc in a separately delegated news.example.com zone. A full-name field uses the complete owner. These naming examples do not authorize a child override of inherited protection.
The minimal record requests no reports. Add rua=mailto: only with the exact approved aggregate-report destination. Assign someone to review the reports and protect the data; do not copy a reporting mailbox from a vendor screenshot.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is 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 the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.
Move toward quarantine or reject only after reviewing legitimate senders, subdomains and normal sending cycles. Under RFC 9989, pct is obsolete; it is not a current percentage-rollout control. RFC 9990 governs aggregate reports and RFC 9991 governs failure reports. Failure reporting needs separate privacy review because it can disclose message-related information. Monitoring policy does not override a receiver’s spam or security decisions.
Verify DNS and a real campaign independently
These read-only commands use fictional names. Replace the nameserver, domain, selector and bounce owner with your actual configuration:
dig @ns1.example.net TXT selector._domainkey.example.com +noall +answer
dig TXT selector._domainkey.example.com +noall +answer
dig TXT example.com +noall +answer
dig CNAME bounces.example.com +noall +answer
dig TXT bounces.example.com +noall +answer
dig TXT _dmarc.example.com +noall +answer
The DKIM TXT must match the generated public key at the exact owner. SPF should be a single policy for the evaluated envelope domain. If a custom return path is configured, its CNAME should match the approved target and resolve correctly; the alias owner itself should not also contain TXT data. DMARC should match the approved policy. Compare authoritative answers with a recursive resolver after caches expire. Empty answer sections require a full query to distinguish missing data from DNS errors or timeouts.
Send a controlled campaign from each sending domain and relevant account. Use Authentication-Results only from the receiving system within the RFC 8601 trust boundary, not a similarly named header supplied by an untrusted sender. Record the receiver identity, visible From, smtp.mailfrom, SPF result, DKIM header.d and selector, DKIM result and DMARC result.
Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
For completion of this DKIM setup, require the intended Delivra custom-domain DKIM signature to pass and align with the unchanged approved branded From under the effective alignment policy, as well as a trusted receiver’s dmarc=pass for that From. A rewritten provider From or an unrelated passing signature does not complete this branded setup. SPF-only DMARC success is valid protocol behavior but does not prove that the DKIM work succeeded.
Diagnose SPF independently even when aligned DKIM carries DMARC. For fail or softfail, compare the actual connecting source and envelope domain with the approved authorization and sending route. For permerror, inspect duplicate SPF policies, syntax and the nested DNS-dependent term budget. For temperror, investigate DNS availability or resolution failures and retest after recovery. Record the cause and repair the applicable route before treating SPF as complete. SPF result definitions.
A good evidence worksheet includes account, campaign, From domain, return-path mode, public key owner, signing activation status, DNS check time and receiver verdicts. Direct delivery and forwarding should be tested separately. One successful message does not establish that every account on a site or every legitimate sender under the domain is ready for enforcement.
Troubleshoot the step that actually failed
Public key exists but DKIM is absent: confirm Enable Signing was completed for the actual From domain and account. Query the selector in the received signature rather than an unrelated working selector.
DKIM mismatch in Delivra: compare the account’s exact public value with concatenated DNS text. Check truncation, inserted whitespace, wrong owner and a duplicated domain suffix. Do not immediately delete a live selector or downgrade the key.
SPF passes but does not align: identify the envelope domain. A root-domain include cannot rewrite a provider bounce domain. Review aligned DKIM first and evaluate a custom return path only after checking the whole site.
One brand works after the site-wide change but another fails: compare organizational domains across all accounts. A bounce domain under one brand does not align with an unrelated brand. Coordinate with Delivra rather than weakening both brands’ DMARC policies.
Campaign indicator is green but delivery fails: examine receiver results, bounce details and the actual message route. DNS presence and provider-side checks do not establish recipient acceptance.
Authentication passes but recipients cannot find the mail: investigate receiving quarantine, complaints, list hygiene, message content and reputation. Do not bypass recipient security controls as a substitute for diagnosing the failure.