Define the outreach identity first
A press campaign can look correct in the editor while leaving through an unexpected sender identity. Before changing DNS, record the organization, intended From address, person responsible for the outreach, and whether the route is a campaign or an individual pitch. Include existing drafts and integrations in this inventory. Their sender choice is part of the acceptance test, not a detail to infer from the appearance of the newsroom.
Prezly provides a ready-to-use prezlymail.com address and supports verified company-domain addresses. Its sender-address guide describes adding the address, selecting the domain, publishing three or four issued CNAME records, and running the status check. Use the values displayed for the selected domain. The examples in a public article identify the design of the service; they are not records to copy into another organization's zone.
Keep website and email configuration separate
A working newsroom hostname is not evidence that campaign email authenticates. Prezly explicitly separates website custom-domain setup from sender-domain readiness in its developer guide. Give the DNS change a specific purpose: authorize the approved outreach domain, rather than repair every branded hostname in one operation.
Capture the current zone values at each proposed record owner. Record whether the DNS editor expects a relative label or a fully qualified name. Ask the administrator to compare the resulting public owner name with the instruction before proceeding. Repeated suffixes, a record placed in the wrong zone, or an existing CNAME at an incompatible owner can all produce a plausible-looking entry that fails the intended check. Preserve ordinary business-mail records and unrelated TXT values.
For an organization with more than one public brand, prepare one change row per domain. Do not assume that validating the agency's own domain authorizes all client identities. The account owner should approve which people may use each identity and which mailbox receives replies. That operational decision should be recorded before selecting a new default.
Publish the issued delegation without widening it
Prezly documents a return-path subdomain and CNAME-based authentication delegation. It also says an existing DMARC record does not need to be recreated, and Cloudflare records must use DNS-only mode for this setup. Review the existing DMARC policy before adding anything at its owner. Do not replace a stronger approved policy with an example monitoring policy merely to make a wizard match. The sender-address instructions also require the sender domain to have MX records; confirm that replies reach the intended mailbox rather than redirecting inbound mail casually.
Treat each CNAME as an ongoing delegation. Keep its provider target, business purpose, owner, and recovery instructions together. A future DNS cleanup must distinguish an unused website alias from a mail-authentication dependency. If a proposed owner conflicts with another service, stop that record change and seek instructions for the exact account. Guessing a new selector or target is not a safe conflict-resolution method.
SPF evaluates the SMTP identity used for the message, rather than the friendly display name. Where an SPF policy is actually required, retain one policy at that owner and review its complete DNS-lookup cost. See RFC 7208. Do not add a broad authorization to the root domain solely because a test message mentions an external delivery platform.
Check readiness in the interface and integrations
Save the domain status check with a timestamp and the instruction revision used. A green application state should be followed by a controlled send. It confirms one part of the configuration, while the received message supplies evidence about what the service actually used.
For integrations, inspect the intended sender ID, address, approval state and domain validity. Prezly warns that its serialized is_verified field is currently always true and is not evidence of approval or DNS readiness. Its API guidance also recommends explicit sender IDs rather than assuming a default change rewrites existing drafts. Have the integration owner confirm the selected identity without exposing API credentials in screenshots or review files.
If a default is changed, test a newly created campaign and the relevant existing draft separately. A saved object may retain its own identity. Keep any recovery procedure precise: restore the approved sender selection or pause the affected outreach, rather than delete all authentication records while diagnosing an application setting.
Read the message that the recipient received
Send a harmless campaign and a harmless pitch to controlled external mailboxes. Include an internal mailbox as a separate test when internal distribution matters. Capture Message-ID, UTC time, From, Return-Path, DKIM signing domain and selector, and the final receiver's trusted authentication results. Redact recipient details and campaign content that are unnecessary for review.
A DKIM pass proves validation for the signing domain. DMARC additionally requires an aligned passing SPF or DKIM identity relative to the visible From domain. RFC 6376 defines the signature fields, and RFC 9989 defines DMARC alignment. Record the alignment mode in force; a related subdomain is not automatically sufficient under strict alignment.
Do not use an inbox-placement result as the entire authentication verdict. A message can authenticate and still receive unfavorable filtering because of reputation, recipient rules, content, or sending behavior. Conversely, an allowlisted message may appear in an inbox without proving that the public authentication route is correct.
Prezly acceptance worksheet
Complete separate rows for campaigns, pitches and any integration-driven route:
- Organization, domain, business owner and route: ____.
- Intended From, reply mailbox and explicit sender ID where applicable: ____.
- Existing draft or newly created test: ____; default selection checked: ____.
- Issued CNAME owners and target references: ____; conflicts resolved: ____.
- Existing DMARC policy preserved or approved change reference: ____.
- Public DNS answers, application status and verification times: ____.
- Controlled recipient, Message-ID and UTC send time: ____.
- Return-Path, DKIM d= and s=, trusted SPF/DKIM/DMARC results: ____.
- Observed aligned mechanism and internal-filtering result: ____.
- Release owner, recovery action and next verification trigger: ____.
An empty identity or receiver field leaves the route unverified. Expand beyond the pilot only when the communications owner and mail administrator agree that the tested identity is the one intended for real outreach.
Fictional diagnosis of a failed internal test
Fictional example only: Alder Press sees its internal test in junk and proposes replacing the domain's SPF policy. The external copy has aligned DKIM and a DMARC pass. The internal receiver identifies the message as externally originated mail using an internal From address. Prezly's deliverability guidance discusses this internal-test pattern. The team investigates that receiver's policy before changing public DNS.
A narrow, reviewed receiver exception might be appropriate for a documented business route, but it must not be presented as an authentication repair or a guarantee of external delivery. The team also checks suppression and bounce evidence when an address receives nothing. This diagnosis is illustrative; no Alder account, DNS zone or message was observed.
Keep the acceptance boundary visible
Recheck after sender changes, DNS migrations, integrations changing identity selection, or a lost verification state. Keep the record inventory and redacted headers together so another administrator can reproduce the conclusion. Public documentation supports this procedure, but live tenant inspection, account-issued values, DNS tests, received-message evidence, rendered visual review, human SME approval and publication remain pending.
Make the integration handover explicit
For an integration-driven campaign, retain the numeric sender ID with the release record. Approval and domain validity are separate fields; neither a successful object creation nor is_verified=true is a substitute. An integration operator should record those states without exporting credentials, then inspect the actual selected identity on a controlled campaign. This is a proposed acceptance check, not an API call performed for this article.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.