Authenticate a Newsman campaign domain in three separate stages: confirm domain ownership by email, publish the current account-issued DNS packet, then validate DNS and check an actual campaign message. A green email check or “Use for sending” indicator does not prove SPF, DKIM and DMARC are configured correctly.
This guide covers native Newsman email campaigns using your own domain. It does not configure Newsman transactional REST/SMTP services, another product with a similar name or an external SMTP substitute. No universal tenant token, selector, key or CNAME target should be copied from a tutorial. Newsman’s domain-authentication procedure.
No customer account, DNS change, campaign send or recipient-header test was performed.
Prepare the exact domain and change approval
Identify the Newsman account, intended campaign/list, visible From address, domain owner and authoritative DNS zone. Confirm that the account administrator can access Sending domains. The reviewed public instructions do not establish a universal role or plan requirement; an absent control is a reason to check entitlement, not to invent an upgrade or bypass.
Have the DNS administrator inventory existing TXT policies, selectors, aliases, NS delegations and mail/website dependencies at every proposed owner. Save the current approved configuration. The registrar or website host is not necessarily the authoritative DNS operator.
Agree the exact routing and data-sharing consequences before publication. A domain-authentication packet can contain aliases used by a service for tracking or message handling. Confirm each alias’s purpose and exact destination with Newsman and the responsible owner. Do not repoint an existing website or tracking hostname, route mail to an unapproved service, or activate an unidentified destination merely because it appears in an account packet. Stop on any conflict or unexpected MX, nameserver or forwarding instruction.
Verify ownership and obtain the current packet
In Settings > Sending domains, choose Add domain and enter the intended domain. Use an accessible, authorized email address for Send code by email, then complete the matching code or verification-link check. Next open DNS settings and validation for that domain. Use the current values shown there, not a screenshot’s sample. Official ownership and DNS steps.
Treat the ownership code as an account-validation step, not a DKIM key. Use it only for the corresponding Newsman request. If someone else manages DNS, share the packet only with an approved administrator through an approved channel; a share-link control does not itself authorize disclosure.
The documentation’s prose names five categories, but the illustrated packet contains six rows: ownership TXT, DKIM TXT, SPF TXT, two CNAMEs and DMARC TXT. The visible table also shows email/use eligibility before the DNS columns pass. Follow every current issued row and its actual type rather than forcing a fixed five-record recipe. Do not reinterpret the two aliases as DKIM records. Newsman’s illustrated packet and status table.
Map each owner to the real DNS zone
In the account packet, distinguish the owner/host from the value/target. IN TXT or IN CNAME describes DNS class/type; it is not text to paste into the TXT content. Preserve the complete issued value, including DKIM tags, rather than copying a blurred example or only part of a public key.
For an illustrative full owner selector._domainkey.mail.example.com, a DNS host editing example.com may require selector._domainkey.mail; a separately delegated mail.example.com zone may require selector._domainkey. If _domainkey.mail.example.com itself is delegated, the responsible administrator must work at that actual authority. Use a full name only when the DNS editor supports it; avoid accidentally creating example.com.example.com. These names illustrate zone mapping, not Newsman-issued selectors. DNS zones and delegation.
Ownership TXT and SPF TXT can coexist as separate TXT records at the same owner, but there must not be two SPF policies there. A TXT value split by the DNS editor into quoted character strings must remain the complete logical value; do not insert spaces into the key or omit its tags. Never publish a private signing key.
A CNAME owner cannot also hold ordinary TXT, A, AAAA, MX or another CNAME record. Do not delete an existing dependency to make space. Confirm a supported non-conflicting hostname with Newsman if necessary. Preserve delegated namespaces and working selectors used by other services. DNS record representation.
Reconcile SPF instead of replacing it
SPF evaluates the SMTP MAIL FROM domain, not automatically the visible From address. A provider-issued record at the sending domain and an actual message’s envelope identity are separate facts. Validate both; do not assume a universal Newsman Return-Path.
At each applicable SPF owner, retain one v=spf1 TXT policy. If one already exists, the mail administrator must reconcile Newsman’s current authorization with legitimate existing senders and the policy’s qualifiers. Do not paste a second policy, blindly replace the apex or copy an old include from a screenshot. An SPF policy at a parent domain does not automatically authorize a child domain.
The budget is ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. An all mechanism means redirect is ignored; additions after all cannot provide the intended authorization. A policy’s failure qualifier is not a guarantee of how every recipient will deliver or reject mail. Validate the resulting policy before sending. SPF standard and lookup limits.
Publish DKIM and the approved aliases correctly
Use the exact current Newsman DKIM TXT owner and full public value. Do not convert it to a CNAME just because another sender’s guide uses aliases. Preserve other selectors and shared dependencies, and do not rotate or delete a working key merely to rerun validation.
For each of the two illustrated CNAME rows, verify the actual current owner, destination and approved function. Do not infer that every alias handles DKIM, bounces or tracking from its name. If the current packet differs, stop and confirm the account-specific requirements rather than silently omitting rows or guessing a substitution.
Newsman instructs Cloudflare users to leave the CNAMEs unproxied. Also inspect applicable flattening behavior: per-record, zone-wide, apex and same-zone settings can conceal the literal CNAME answer a validator expects. Where required aliases must remain visible, turn the relevant per-record Flatten option off when available and ensure applicable zone settings preserve those answers. Do not change unrelated zone settings broadly. If mandatory apex or same-zone behavior prevents the required alias answer, coordinate a supported configuration instead of inventing a switch or removing a delegation. Cloudflare’s current flattening controls.
Preserve DMARC protection and reporting choices
Review the direct and any applicable inherited policy before applying the packet’s DMARC row. An empty lookup at one _dmarc name does not prove no policy applies. Preserve existing protection and approved recipients. Never overwrite quarantine or reject with a monitoring policy, add a duplicate policy, introduce a child override or copy someone else’s report address merely to satisfy a green status.
If the issued packet conflicts with the approved policy, ask Newsman and the domain owner to resolve it before activation. Do not quietly omit the row and declare validation complete.
Only when no direct or applicable inherited policy exists, the owner approves and a monitored introduction is appropriate, an initial TXT policy may be v=DMARC1; p=none. For From example.com, its full owner is _dmarc.example.com; for From mail.example.com, it is _dmarc.mail.example.com. The latter is _dmarc.mail relative to the parent zone or _dmarc within a separately delegated mail.example.com zone. This minimal policy does not request reports. Do not use the obsolete pct parameter as a rollout mechanism. Current DMARC policy standard.
Report sharing needs separate owner approval. If the destination’s Organizational Domain differs from that of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted. DNS authorization does not replace the privacy/data-sharing decision. RFC 9990 section 4.
Validate DNS, then test the actual campaign route
After the approved records are published at the real authority, return to Newsman and use Validate. Resolve all required DNS status failures; email ownership, sending eligibility and DNS validation are different checks. Do not invent an additional Enable switch. Newsman validation.
For a persistent failure, compare the exact issued owner/type/value with authoritative answers, then check the resolver’s cached view. Confirm that the change was made in the active zone, the suffix was not appended twice, the TXT value is complete and the CNAME answer remains visible. Allow for the relevant cache lifetime, but do not keep waiting on an incorrectly published record.
Once the account and DNS checks are correct, use an approved tiny controlled audience for an actual native campaign from the intended From address. A preview or an unrelated transactional SMTP test does not certify that campaign path. Do not import a customer list, re-enable unsubscribed recipients or release a scheduled campaign as a casual test.
Obtain original received-message evidence from the receiving service’s known processing boundary. Consult its documented treatment of externally supplied Authentication-Results or ask its administrator for a trace. A familiar authserv-id, header position or copied result is not sufficient proof of trust. Ignore externally injected result fields. Authentication-Results trust rules.
Record the actual From, SMTP MAIL FROM, intended Newsman DKIM d= domain and s= selector, and trusted SPF, DKIM and DMARC results. For this setup, require the intended signature to pass and align with the intended brand From, plus dmarc=pass. A rewritten provider From or unrelated passing signature is not successful brand authentication.
DMARC itself can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires the exact domain. A child envelope domain can align relaxed but fail strict alignment. A DMARC pass through SPF does not prove DKIM works. See raw DKIM versus aligned DKIM results.
Investigate SPF fail, temporary lookup errors and permanent policy/lookup-budget errors separately even when DKIM provides the DMARC pass. Keep message evidence private. Authentication success is not an inbox-placement or delivery guarantee.
Troubleshooting and safe recovery
Email is green but DNS is red: ownership validation is complete, not authentication. Open the current DNS packet and reconcile its required rows rather than sending because an eligibility column is green.
DKIM is missing after validation: confirm the actual campaign From and selected domain, then have Newsman check the signing configuration. DNS presence alone does not prove a signature was applied.
DKIM exists but fails: check the intended selector/key and downstream content modification. Preserve required security and compliance controls while the responsible administrators investigate.
SPF is a permanent error: look for multiple SPF policies, invalid syntax or an exceeded evaluated lookup budget. Do not flatten into guessed IP addresses or remove unrelated senders to make a checker pass.
DMARC fails despite raw DKIM pass: compare the passing signature’s domain with From under the actual alignment policy. Do not accept a provider-domain signature as proof of branded signing or weaken the policy.
A message is rejected for another reason: inspect the actual diagnostic response; a DMARC failure alone does not establish the cause. Suppressions, recipient limits, consent and reputation need their own investigation, not a DNS workaround.
If a change disrupts existing service, pause the affected workflow where operationally safe and coordinate restoration to the last approved state. Retain old keys and records until queued-message and shared-route dependencies are understood. Give support only the necessary redacted domain, selector, status and diagnostic evidence through an approved channel, not credentials, private keys or customer correspondence.