Reconcile the Pepipost name with the actual account
A Pepipost label in an old integration or DNS note is not enough to choose today’s setup procedure. The retained Netcore Email API documentation still contains Pepipost references while describing Netcore Email API domain verification. Identify the account, application endpoint, sending domain and documentation version before changing DNS. This article covers account-issued authentication for that documented product family; it does not promise that every legacy account uses identical records or interfaces.
Start with the application owner’s evidence. Record whether the application submits through an SMTP configuration or an API integration, which account or subaccount owns it, and which From addresses it can use. Preserve the current working endpoint and credentials in their approved secret store. Authentication research does not require copying API keys into a worksheet or attaching them to support requests.
Resolve the documented record type conflict
The Netcore SPF and DKIM guide describes two TXT records. Another first-party domain verification article introduces two CNAME records, yet also discusses replacing an existing SPF TXT policy. These pages do not establish a single unambiguous record recipe for every account. Treat that conflict as a reason to obtain the live account’s full issued records, not permission to choose a type by guesswork.
In the intended account, collect the record owner, type and value for the exact domain. Netcore’s Get Domain API reference documents retrieval of SPF, DKIM and custom-envelope DNS records for a domain belonging to the requesting client. It also distinguishes requests made for a subaccount. The dashboard or an authorized administrator can provide equivalent account evidence without disclosing credentials in the change record.
If the issued data contradicts the public guide or an existing record, ask verified Netcore support which configuration applies. Retain the answer and do not publish both incompatible types at one owner. Confirming account identity is particularly important when a legacy integration and a new subaccount use the same business domain.
Publish without replacing unrelated authorization
Prepare a change ticket containing the complete issued record set and a before-state export. Review owner names against the DNS editor’s relative-name behavior. For a CNAME, check that its owner is not already occupied by incompatible data. For TXT-based SPF, keep one SPF policy at that owner and preserve other legitimate sending services. Never replace the organization’s mail authorization solely because a dashboard displays a simplified example.
Evaluate the full SPF policy, including nested includes, against RFC 7208. The DNS lookup limit applies to evaluation, so counting the visible words in the top-level record is insufficient. If the new authorization would exceed the limit, resolve the design with the domain owner before activation. Do not convert provider-maintained authorization to a hard-coded IP list as an unreviewed shortcut.
Check authoritative DNS answers for each issued record. Keep the observed full owner, type, answer and time with the change revision. A public resolver can still return a cached value after the authoritative record changes, so distinguish publication errors from caching. Avoid promising a fixed propagation time that the available evidence does not establish.
Separate DNS verification from permission to send
Netcore’s authentication guide describes a DNS check and a separate domain-approval process, including manual review for some domains. Record those states separately. An authenticated domain that is awaiting provider approval should not be diagnosed as a DNS failure merely because sending is not yet available. Conversely, an approved account does not prove every From domain is verified.
Once the account permits the intended route, send a harmless controlled message from the real application path. Compare the configured From with the received From, Return-Path, DKIM d= and s=, and the receiver’s trusted authentication results. Do not infer a custom-envelope feature from the presence of a tracking CNAME or assume that provider-owned SPF automatically aligns with your domain.
A passing aligned SPF or DKIM result can satisfy DMARC under the applicable alignment mode. RFC 6376 supplies the signature semantics and RFC 9989 supplies the alignment framework. Record the mechanism that actually passed rather than reporting a generic green status from domain verification.
Pepipost and Netcore acceptance worksheet
Create one entry for each account or subaccount and sending domain:
- Account identifier and current product label: ____; application and owner: ____.
- Submission route and endpoint reference: ____; credentials excluded from evidence: ____.
- From domain and approved addresses: ____; legacy instructions still in use: ____.
- Account-issued record set and revision: ____; TXT or CNAME conflict resolved by: ____.
- Existing DNS collisions: ____; SPF preservation and lookup review: ____.
- Authoritative DNS evidence: ____; dashboard verification state: ____.
- Domain approval state and provider reference: ____.
- Test Message-ID, time and receiver: ____; From and Return-Path: ____.
- DKIM d= and s=: ____; trusted results and aligned mechanism: ____.
- Business pilot decision, recovery owner and unresolved exceptions: ____.
Keep verification and approval in different fields even if the interface displays both close together. This makes escalation specific: the owner can say whether the problem concerns records, provider review or the message actually transmitted.
Fictional diagnosis of an approved domain with failing mail
Fictional example only: Alder Billing confirms its new Netcore domain is verified and approved, yet an invoice test still carries the old route’s signing identity. The application owner discovers that the production job uses a different account configuration from the dashboard being inspected. The team stops treating the dashboard’s green state as evidence for that job, reconciles the actual submission route and repeats testing with the correct account-issued records.
If the route matches but the signature fails, investigate the published selector and message handling before changing DMARC. If authentication passes but the message is rejected, retain the SMTP response and investigate that specific rejection separately. No Alder account, endpoint, production job or received invoice was tested here.
Scope and remaining gates
The public TXT-versus-CNAME discrepancy and legacy-account applicability remain explicit scope holds until resolved for the intended tenant. This is a configuration and acceptance method, not a universal selector or include recipe. Live account inspection, issued-record confirmation, DNS checks, provider approval, receiver testing, rendered review, human SME approval and publication remain pending.
Resolve a documentation conflict in a written decision
The proposed resolution should identify the account or subaccount, sending domain, source-document versions, full issued owner/type/value set and provider confirmation of the applicable branch. Keep the contradictory public example as context, not an extra record to publish. If current account evidence is unavailable, leave the conflicting row on hold. The existing worksheet is preparation material and contains no newly retrieved account records.