Identify Netcore CE or Netcore Email API first
A Netcore account label is not enough to choose a DNS recipe. Netcore publishes separate domain-setup instructions for its Customer Engagement platform (CE) and Email API. The product login page identifies Email API as formerly Pepipost. Record which product, tenant or subaccount sends the message and whether the application uses SMTP, an API integration or a CE campaign. Do not apply an old Pepipost article to a CE screen simply because both carry the Netcore name. Netcore product login, CE domain setup, Email API verification.
Inventory the real customer-facing flows before adding a sending domain. A receipt, login link and marketing campaign may have different application owners and From domains. For each, preserve a baseline message or submission failure, the configured sender, the current domain status and who controls authoritative DNS. The steps below describe documented branches; account-generated hostnames and values take precedence over examples.
Email API: separate DNS verification from approval
The retained Email API setup guide describes publishing the dashboard-provided SPF TXT and unique DKIM TXT record, then using Check DNS Records. If a policy already exists at the SPF owner, merge the required authorization into that policy rather than adding another candidate SPF record. Do not paste a complete sample policy over permissions for other legitimate senders. After DNS verification, the domain enters an approval process that can include automated checks and manual review. A verified DNS record does not by itself establish that the domain is approved to send. Email API domain verification and approval.
Keep the two outcomes in separate worksheet fields. If DNS is correct but approval remains pending, investigate the account's review status and requested business information. Repeated DNS edits can obscure a working configuration without addressing approval. Conversely, an active account does not prove that the specific sender domain or subaccount is ready.
Netcore's explanatory guide also describes a revised SPF value that the operator must publish when an existing policy is detected. Compare that proposed value with the current authoritative record: another team might have changed DNS since the dashboard first read it. Preserve intentional permissions and assess the complete lookup path. For DKIM, use the hostname and value associated with the selected domain. Separate selectors can serve different services, but conflicting values at one selector are not solved by stacking arbitrary keys. Email API SPF and DKIM explanation, SPF processing rules.
CE: verify every generated DNS row
The CE documentation specifies Settings → Email domain → Add domain. After entering the domain, the DNS Configuration screen supplies each record's purpose, type, hostname, value and status. Record types can include TXT, CNAME and MX; copy the rows actually supplied for the tenant rather than imposing the Email API two-TXT model. The guide says all generated records must be configured and verified. Use Verify, then complete the flow when successful. CE Add Email Domain.
The same CE guide distinguishes Success, Pending, Error and Migrated. Pending and Error do not permit sending. It also warns that editing a hostname after verification makes the domain inactive and requires re-verification of all records. Treat hostname edits as a controlled change with an interruption risk. The availability of Download DNS Settings is useful for an evidence handoff; it is not proof that the records were published or that a receiver has authenticated a message.
Do not repoint the organization's ordinary inbound MX records merely because a generated row uses MX. First identify the exact owner and purpose shown by the tenant. A sending or bounce subdomain can have its own DNS configuration. The reviewed public text does not justify a universal CE hostname, MX target or DKIM selector.
Custom envelope: publication and activation are different steps
Netcore Email API separately documents a custom Return-Path process. It describes choosing a subdomain, publishing the supplied CNAME mapping and asking the delivery team to enable the custom envelope/Return-Path and DKIM for the account. That documented process means a published CNAME alone is not evidence that messages have switched identity. Confirm the current tenant instructions and activation state before relying on this option. The article retains Pepipost-era naming, so do not generalize its target or support process to CE. Email API custom Return-Path.
Decide why the custom envelope is needed. It can provide an aligned SPF path only if the actual envelope domain meets the From-domain alignment requirement and SPF passes. A related subdomain can meet relaxed alignment, while strict alignment requires exact domain equality. A verified, aligned DKIM signature may already supply the DMARC path. Do not remove provider-required DNS records merely because DMARC needs only one aligned passing mechanism. DMARC alignment rules.
Fill in the product-specific Netcore worksheet
Use one copy per tenant/subaccount and sending domain. Copy each generated DNS row into a separate numbered entry rather than collapsing several purposes into one.
- Product: CE / Email API. Tenant/subaccount: ______. Application or campaign: ______.
- Intended From domain: ______. Current configured sender: ______. DNS authority and operator: ______.
- Generated row number: ______. Purpose: ______. Owner: ______. Type: ______. Exact value evidence: ______. Authoritative result and UTC time: ______.
- Existing SPF permissions retained: ______. Complete DNS-lookup assessment: ______.
- Domain DNS state: ______. API approval state, if applicable: ______. Evidence date: ______.
- CE hostname change planned? ______. Re-verification and interruption owner: ______.
- Custom envelope requested? ______. Published owner: ______. Provider activation confirmation: ______. Received envelope identity: ______.
- Test workflow and message ID: ______. From domain: ______. SPF domain/result: ______. Every DKIM
d=/s=/ result: ______. - Receiver DMARC result: ______. Alignment mode and passing path: ______.
- Bounce-handling check: ______. Rollback route: ______. Release approver: ______.
Diagnostic rule: missing authoritative data is a publication problem; a pending API approval is a service-approval problem; a different envelope after publication is an activation or routing problem. Assign the failure to the correct owner before making another change.
Fictional worked diagnosis: verified DNS, old envelope
Fictional training example, not a Netcore test result. An application sends receipts from receipts.example. Its owner has published the account's DKIM record and requested a custom envelope at bounce.receipts.example. The received message still uses an unrelated service envelope, but DKIM passes with d=receipts.example. The trusted receiver reports DMARC pass.
The worksheet explains both findings: DKIM supplies the aligned passing path; the custom-envelope cutover is still unproven. The administrator checks whether provider activation occurred and whether the application uses the intended tenant. Adding more SPF permissions to receipts.example would not change the service-owned envelope in that message. After activation is confirmed, a fresh receipt must show the expected envelope and successful bounce handling.
In a second fictional CE case, a verified hostname is edited during a campaign launch and the domain becomes inactive. The correct response is to complete the required re-verification and keep sending paused until CE permits it. An Email API approval ticket would address the wrong product workflow.
Acceptance and recovery
Query exact record owners at authoritative DNS, then compare recursive results with timestamps. Inspect received signatures as well as the dashboard. A published DKIM key proves availability, not that the application used that key; a successful API submission proves acceptance by a service, not inbox placement. Use a controlled transaction and recipient, with no real reset tokens or customer data in the review bundle. DKIM verification.
Save pre-change DNS and application settings. If the new route fails, pause the affected sender, restore only the changed configuration and test a fresh message. Check queued sends before switching transports to avoid duplicates. Keep unrelated domains and campaigns outside the change.
No live Netcore tenant, DNS change or received message was tested for this manuscript. The worksheets and examples are preparation material. Current product/tenant applicability, activation and approval evidence, authoritative DNS, live message tests, visual review and human SME approval remain required before release.