Start with the Delivra account and domain inventory
Delivra's public authentication help page links to detailed Email Authentication Instructions. Those instructions describe a site administrator coordinating with the domain's DNS operator, a unique DKIM selector and key for each sending domain, and a separate Enable Signing step. This guide covers that documented workflow. It does not establish a particular account's feature access, generated values or completed configuration.
Identify every domain intended for campaign sender addresses and map it to the relevant account and site. Multiple mailboxes under the same domain do not automatically require separate domain keys, while a different domain must not inherit another domain's key by assumption. Keep the administrative scope explicit before changing any records, especially if one site serves multiple brands or independently governed business units.
The detailed public instructions do not expose a reliable publication date in the captured article text. Current account applicability and any changes to the interface remain open. Use the actual displayed records and current administrator confirmation when implementing the plan. A sample selector from a screenshot is not an account-generated value, and the manuscript has not generated a key or accessed any tenant.
Merge the documented SPF authorization
The instructions specify include:ne16.com for an existing SPF policy and offer a complete example for domains without one. Review that mechanism within the domain's full legitimate-sender inventory rather than replacing existing employee or application authorizations. The example's mx term, soft-fail qualifier and TTL are not universal settings for every domain. Keep the exact approved difference visible in the change request. Delivra authentication instructions
RFC 7208, section 3.2 prohibits multiple selected SPF policies at one owner. Preserve a single coherent TXT policy, and review evaluated DNS-dependent terms under section 4.6.4, including nested work. Counting only the visible includes or observed DNS packets is insufficient. A policy may be present and syntactically valid without authorizing the actual sender on a particular evaluation path.
Do not treat 255 characters as the maximum total SPF policy length. Section 3.3 describes multiple character strings within one TXT record and their concatenation without added spaces. This differs from multiple competing SPF records. When an editor splits a long value, verify the resulting logical record instead of deleting authorizations merely to fit a presentation limit. This is a protocol distinction, not a claim that every DNS editor supports the same input format.
Create the domain key and publish its exact value
The documented administrator route is Settings, Account, Domain Keys, then Create Domain Key. The administrator enters the domain, selects a key size and saves to obtain the DNS instructions. The handoff includes the Domain Name, DKIM TXT Record Address and DNS TXT Record value. These belong together: a correct key at the wrong owner cannot support the intended selector lookup. Delivra authentication instructions
The DNS operator publishes a TXT record using the issued address and value. The guide notes that many providers expect only the selector._domainkey portion in their host field, but this is editor-dependent. Confirm the full resulting owner rather than universally stripping or appending the domain. Do not reuse the screenshot's long selector: the source explicitly identifies those values as examples unique to the account and sending domain.
For a mismatch, compare the entire generated public key with the published logical value, including accidental spaces, truncation and line breaks. The instructions suggest generating a smaller key for some legacy DNS limitations, but this guide does not recommend automatic deletion or downgrade as a first response. Establish current DNS-provider support, organizational key requirements and the effect on active signing before authorizing a replacement. A representation problem and a cryptographic-policy decision are separate issues.
Enable signing after publication
The documented next step is to return to Settings, Account, Domain Keys and use Enable Signing when the key is present and valid in DNS. Preserve this activation step in the acceptance plan. A completed DNS ticket is not proof that the account is signing, and the presence of the button is not evidence that it was used. Record actual administrator confirmation when an authorized implementation occurs. Delivra authentication instructions
The same instructions describe authentication indicators beside Sender Name and Address in the campaign workflow. Treat those as provider checks, separate from a receiver's results on a message. Green indicators are useful evidence of the account's view, but they do not prove every campaign route, recipient decision or future signature. The source also says incomplete authentication does not itself prevent sending; the absence of a platform block is therefore not an acceptance criterion.
Review custom return path at site scope
Delivra's custom return-path guide describes a site-wide configuration, not a per-account option. It says all accounts should send from the same root domain for that shared arrangement. The documented DNS step uses a bounce subdomain CNAME to lists.n-email1.net; support then verifies and configures the site and sends a confirmation test. These are prerequisites and provider steps, not actions performed here.
Before approving a shared change, record each affected business owner and unresolved exception. Keep the decision pending when the inventory is incomplete.
A policy of quarantine or reject is not the same as strict identifier alignment. RFC 9989, section 4.4 defines the alignment relationship independently of the requested disposition. A bounce subdomain can support relaxed alignment with a related author domain without establishing exact equality for strict alignment. Do not promise strict-alignment compatibility or removal of every receiver's “on behalf of” display based only on the documented CNAME.
Assess the message rather than the setup screen alone
A proposed authorized acceptance exercise should use harmless content and record the actual author domain, envelope identity, signing domain and selector. RFC 6376, section 3.5 defines the signature fields used to connect a received message to its DNS key. Compare the trusted receiver's results with the approved identities and the intended route. Do not upload real subscriber information or confidential campaign content to an external checker without authorization.
DMARC can pass through an aligned passing SPF result or aligned passing DKIM result. It does not certify that the message is harmless, and authenticated mail can still be filtered. A public policy example is not permission to replace the organization's enforcement policy or add a reporting recipient. Keep domain-wide policy decisions and data-sharing approval separate from copying issued public DNS records.
Fictional diagnosis and blank acceptance worksheet
A fictional education publisher, Maple Folio, publishes a generated key but never returns to Enable Signing. Its DNS change record looks complete, while message readiness remains unproved. The review also discovers that a proposed return path would cover a shared site with a second brand. The team separates the pending activation from the site-wide design decision and asks authorized owners to resolve both before release. This fictional scenario contains no actual account action or message result.
- Site, accounts, sending domains and current workflow applicability: ______
- Existing SPF policy and approved include change: ______
- Unique DKIM owner, public key and publication evidence: ______
- Enable Signing confirmation and campaign indicator observations: ______
- Site-wide return-path compatibility and provider completion, if used: ______
- Actual message identities, trusted results and alignment mode: ______
- Policy owner, unresolved exceptions and release decision: ______
Original implementation evidence, human review, current applicability, production routes, visual accessibility and owner release remain open. No key, DNS entry, support request, test message or publication was created.