For mail sent through Neostrada hosting, review the existing SPF policy for include:spf.totaalholding.nl and any required hosting-server IP. Obtain the domain’s unique DKIM public record in cPanel under Email Deliverability, then publish it at the authoritative DNS host. Verify the intended branded signature and the actual envelope-domain SPF result on a delivered message before calling the setup complete.
This guide covers Neostrada’s documented cPanel hosting-mail route and its customer-panel DNS workflow. It does not apply unchanged to a domain that merely uses Neostrada DNS while Microsoft 365, Google Workspace or another service sends its mail. Confirm that the documented workflow still applies to your account before using its record values or editor-specific workarounds. No customer settings, DNS changes or messages were tested.
On this page:
- Overview
- Confirm which application and server send the mail
- Review Neostrada SPF without copying a sample server IP
- Obtain the correct DKIM public record
- Publish in the authoritative DNS zone
- Interpret cPanel status without ignoring real errors
- Add DMARC reporting without weakening an existing policy
- Verify DNS publication and real mail
- Diagnose common Neostrada failures
- Frequently asked questions
- Is the IP in the Neostrada SPF example my server IP
- Should I use default as the DKIM selector everywhere
- Should I add the backslash at another DNS host
- Can I ignore a red Email Deliverability warning
- Does DMARC passing mean both SPF and DKIM work
Confirm which application and server send the mail
List the mail streams you need to authenticate: hosted mailbox messages, website contact forms, order notifications and any separate newsletter system. Record the outgoing SMTP/API service for each. A successful mailbox test cannot establish that a PHP application takes the same route.
Before you start, have access to the correct Neostrada hosting account, its cPanel domain, the authoritative DNS zone and an external mailbox for controlled tests. Save the current DNS zone and the proposed changes. Do not share mailbox passwords or DKIM private keys in a support worksheet.
If the website and staff mail use different providers, retain both routes in your inventory. The WordPress mail-route guide helps distinguish local hosting mail from an SMTP plugin or API integration. cPanel itself directs users of external email services to those providers’ authentication instructions. cPanel Email Deliverability
Review Neostrada SPF without copying a sample server IP
Neostrada’s SPF article identifies include:spf.totaalholding.nl as its managed authorization. Its hosting example also contains a, mx and a hosting-server ip4 mechanism. Crucially, the IP varies with the server hosting the account. Do not copy the address in a documentation screenshot or replace the entire current policy with an include-only template. Obtain the actual service’s requirements from the account or Neostrada. Neostrada SPF documentation
For a website that sends locally while a separate provider handles staff mail, inspect both routes. Keep the external provider’s authorization and any verified Neostrada authorization required by the website. Conversely, if the website uses that external provider’s authenticated SMTP service, do not authorize the website server merely because it hosts the application.
SPF evaluates the SMTP MAIL FROM identity, not the visible From address. A policy for the apex does not automatically cover a different envelope subdomain. Use the actual message’s envelope identity to decide which owner to check. Maintain one v=spf1 TXT policy per evaluated owner, retain unrelated TXT data and merge required mechanisms into that one policy. SPF identity and record rules
The literal mechanism used to authorize Neostrada is:
include:spf.totaalholding.nl
That is a mechanism, not a complete record to publish on its own. Add it only when required for the actual route, between the existing v=spf1 and final all mechanism. Use ip4: or ip6: for verified addresses, never ipv4: or ipv6:. The provider’s older prose contains those invalid spellings; the standards-defined syntax governs.
Check the complete evaluated policy, not just the new text. SPF allows at most 10 evaluated DNS-query-causing terms, including nested includes and redirects. An unnecessary a or mx can both broaden authorization and consume budget. Do not remove an existing mechanism without checking what relies on it. SPF processing limits
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Keep the current final qualifier unless you are intentionally reviewing policy. Neostrada’s page shows -all in an example but refers elsewhere to a neutral default; that is not evidence of your domain’s actual setting. ~all is softfail, -all is fail and ?all is neutral for unmatched senders. None guarantees whether a receiving service accepts, rejects or puts a message in spam.
Obtain the correct DKIM public record
Open cPanel → Email → Email Deliverability, choose the domain and select Manage. Copy the suggested DKIM Name and Value. Neostrada documents a unique key per domain and a TXT owner of default._domainkey for this workflow. Use the account’s displayed name if it differs. For its own customer-panel DNS, Neostrada specifies the Full view. Neostrada DKIM workflow
If no key exists, current cPanel documentation offers Generate Local DKIM Key where enabled. If the feature or domain is absent, ask Neostrada to confirm that the hosting product supports the interface and signing for the required route. Do not generate an unrelated key in an online tool as a substitute. A matching private key must be installed and used by the outgoing service. Current cPanel key controls
Keep these two things distinct:
- Signing configuration: the outgoing server must sign the message with the domain’s configured private key.
- DNS publication: receivers must be able to retrieve the matching public key at the selector’s exact DNS name.
The public Neostrada workflow does not describe a separate universal customer “enable signing” switch after publication. Do not invent one. Publish the generated public value, complete any actual account-required activation, and confirm signing with a message. If mail remains unsigned, have Neostrada verify the outgoing configuration for that mailbox or application.
Neostrada says subdomains in this workflow use the top-level domain’s DKIM record. Treat this as a description of its hosted signing arrangement, not a DNS inheritance rule. Read d= and s= from the delivered signature. Under strict DKIM alignment, a parent-domain signature does not align with a subdomain From address; ask the provider about the required signing identity rather than silently weakening DMARC.
Publish in the authoritative DNS zone
Check the active nameservers first. In Neostrada’s customer panel, the documented path is Services → domain pencil → DNS-records → beheren. Use @ for the zone apex and relative hostnames for subdomains. The provider recommends retaining the usual TTL of 3600 seconds. Edit an existing row with its pencil and save with the green check mark; new rows use the panel’s save action. Neostrada DNS management
For a domain zone named example.com, the following is a mapping worksheet. It is not a complete record set to copy.
| Purpose | DNS owner | Name in Neostrada DNS | Type and value |
|---|---|---|---|
| Apex envelope SPF | example.com |
@ |
TXT, existing reviewed policy with required senders preserved |
| Hosted DKIM | default._domainkey.example.com |
default._domainkey |
TXT, the account’s complete public value |
| Subdomain selector if specifically issued | selector._domainkey.news.example.com |
selector._domainkey.news |
Account-issued type and public value |
| Apex DMARC | _dmarc.example.com |
_dmarc |
TXT, the domain owner’s policy |
Do not paste default._domainkey.example.com into a relative-name field and accidentally create default._domainkey.example.com.example.com. If the DNS host is external, use its own owner-name and TXT-entry conventions instead.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
Neostrada’s DKIM page documents a special customer-panel input rule: when the generated Full value ends in a semicolon, prefix that final semicolon with a backslash, producing \; in that editor. It also warns that a WHM split-display value needs normalization for its Full-format input. These are Neostrada-editor instructions, not universal DKIM syntax. Do not add backslashes to records at another DNS provider. Compare the public TXT answer’s reconstructed value with the generated key; do not treat an escape character accidentally stored as key data as correct. If today’s editor behaves differently, stop and ask Neostrada rather than repeatedly altering the key. Neostrada format caveats
A long key may be displayed as several quoted strings in a single TXT resource record. The strings are concatenated without added spaces during DKIM processing. That is different from publishing several separate TXT records at one selector. DKIM DNS representation
Preserve other selectors. If another service occupies the same owner with a CNAME or a different key, coordinate an alternative selector or transition; do not overwrite it or add conflicting data. Avoid the customer panel’s Gmail/Office365 preset buttons for a narrow authentication change. Those presets affect mail DNS, not merely one key.
Interpret cPanel status without ignoring real errors
Neostrada’s article warns that its customer-panel DNS and cPanel are separate, so the panel can show a misleading local status. Current cPanel documentation also distinguishes locally installed records from publication at an external authority. A local Repair action cannot repair a zone the server does not control. Neostrada panel caveat · cPanel authoritative-DNS limitation
Use a three-part decision:
- If the authoritative public answer is wrong, correct publication at that authority.
- If public DNS is right but messages are unsigned or fail verification, investigate signing, the selected key and the actual outbound route.
- Only when both DNS and delivered-message evidence are correct should an incompatible local-panel warning be treated as a panel discrepancy.
Do not apply the article’s “ignore” advice to actual SPF permerrors, missing public keys or failed receiver results. Preserve the warning text and your evidence when asking support to reconcile it.
Add DMARC reporting without weakening an existing policy
DMARC compares the visible From domain with authenticated identities. A passing aligned SPF result or a passing aligned DKIM signature is sufficient for DMARC. Relaxed alignment uses the organizational domain; strict alignment requires exact domain equality. An authentication pass for an unrelated hosting domain is not an aligned pass. RFC 9989
Check the existing _dmarc policy and any applicable parent policy. Preserve established enforcement and reporting destinations. Never add a second competing DMARC record to satisfy a provider setup guide.
Only for a new monitored rollout approved by the domain owner, with an appropriate monitoring plan and no existing direct or applicable inherited policy, this is an illustrative starting value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Publish the new value as TXT at _dmarc.example.com: in the example.com zone, the relative Name is _dmarc. For a policy specifically covering a From domain of news.example.com, the full owner is _dmarc.news.example.com. Enter _dmarc.news in the parent example.com zone, or _dmarc if news.example.com is a separately delegated authoritative zone. Follow the DNS host’s full-name convention if it does not use relative names. Do not add a child policy merely to replace an applicable inherited policy. DMARC policy publication
Use an authorized mailbox or reporting service that accepts reports, not the example address. For an external reporting domain, complete its destination authorization before expecting reports. DMARC aggregate reporting
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
Review reporting data for hosted mail, website mail and external services together before increasing enforcement. A report can reveal a PHP route that your mailbox test missed. The DMARC report investigation guide explains how to prioritize those failures. The current DMARC standard removes the old pct tag, so do not rely on percentage enforcement as a new rollout plan.
Verify DNS publication and real mail
These are read-only command templates, not results from a customer domain. Replace all example hostnames and use the envelope domain, signing domain and selector actually supplied or observed. Repeat authoritative checks against every active nameserver.
dig +short NS example.com
dig @ns1.dns-host.example example.com TXT +noall +answer
dig @ns1.dns-host.example default._domainkey.example.com TXT +noall +answer
dig @ns1.dns-host.example _dmarc.example.com TXT +noall +answer
dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com
Expect one SPF policy at the actual evaluated owner, the complete public DKIM key at the correct selector and a single applicable DMARC policy. A key lookup should not return a truncated public key, literal split-format artifacts or a competing CNAME. When a direct authoritative answer is correct but recursive results differ, compare TTLs and wait for caches rather than regenerating the key. Neostrada’s older timing estimates are not a guaranteed worldwide deadline.
Once configured, test each real route separately: a mailbox message, a contact-form notification and any other application that sends locally. Use an external mailbox you control and inspect the raw source. Record the trusted receiving system’s Authentication-Results; sender-supplied headers cannot prove a receiver’s decision. Header trust boundary
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Acceptance requires more than dmarc=pass:
| Check | Expected evidence |
|---|---|
| Route | The tested mailbox or application used the intended outgoing service |
| Branded DKIM | dkim=pass for the intended d= and selector, aligned as required, not merely an unrelated infrastructure signature |
| Actual SPF | Direct mail passes SPF at smtp.mailfrom; any fail, softfail, none, temperror or permerror is investigated |
| DMARC | dmarc=pass for the visible From domain with a demonstrated aligned path |
| Outcome | The message reaches the controlled test destination; no promise of universal inbox placement |
DKIM can make DMARC pass while SPF is broken. Fix an invalid SPF policy anyway. Conversely, valid SPF that is intentionally unaligned can coexist with aligned DKIM; document the identity difference instead of labeling it an SPF authentication failure. The Return-Path guide helps identify which domain was actually evaluated.
Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.
Diagnose common Neostrada failures
| Symptom | Likely investigation |
|---|---|
| Mailbox passes but website mail fails | Compare SMTP/API route, envelope identity, signing domain and hosting-server IP; do not assume one test covers both |
| Public DKIM key exists but mail is unsigned | Ask Neostrada to check signing for the actual application route; cPanel documents PHP-handler cases that can affect signing |
| DKIM public value does not match | Check Full versus Split presentation, copying damage, editor-specific escaping and whether the key was regenerated |
| SPF permerror | Check for two SPF policies, invalid ipv4/ipv6 spellings and lookup-limit failures |
| SPF passes but DMARC fails | Compare MAIL FROM and DKIM d= with the visible From domain; check strict versus relaxed requirements |
| DNS changes seem ineffective | Confirm nameserver authority and that you edited the customer-panel zone rather than an inactive local cPanel zone |
| A record is greyed out | Check whether a mail preset owns it; do not undo the preset without reviewing all affected records |
For a rollback, restore only the affected known-good records where possible. Keep the old and new key identities and publication times, especially if signing has already switched. Restoring an old public key while the server signs with a new private key will not repair DKIM. Coordinate both halves with Neostrada and retest. Avoid whole-zone resets that remove other senders or change incoming mail.