For email sent through Krystal’s hosting mail servers, open cPanel → Email Deliverability → Manage for the sending domain. Review the suggested SPF and DKIM records before installing them. Krystal’s documented outbound relay uses include:relay.k.io; external DNS customers must publish the records at their authoritative DNS host. Website hosting or domain registration alone does not make Krystal the sender. Krystal configuration guide and outbound relay instructions.
This guide separates mailbox mail, PHP application mail, authenticated SMTP and third-party services.
Establish which system actually sends
Inventory a normal mailbox message, contact form, password reset, order confirmation and any external newsletter or CRM. For each, note the From domain, submission server, envelope sender, DKIM signing domain if present, and administrator. One successful webmail test cannot certify a website application using another transport.
This procedure applies to the documented Krystal mail-server route. If you operate your own VPS mail stack, use another managed platform or submit directly to an external service, confirm its relay and signer separately. Do not assume that all products sold by the same hosting company share a mail configuration. Krystal’s own guide explicitly limits its instructions to domains using its mail servers. Official scope.
Before making changes, have the domain’s cPanel access, access to the authoritative DNS zone, a controlled test mailbox and a current zone export. Preserve current SPF authorizations, DKIM selectors, DMARC policy and TTLs. Identify delegated sending subdomains. MX controls incoming delivery; do not change it simply to configure outbound signing.
Review cPanel recommendations before using Repair
In cPanel’s Email section, choose Email Deliverability, then Manage beside the exact sending domain. Krystal documents suggested DKIM and SPF records and an Install the suggested record action. Its Repair action restores defaults, so compare the proposal with your complete sender inventory first. For DMARC, its guide uses Domains → Zone Editor → Manage, with an option to add a DMARC record or edit an existing one. Krystal cPanel steps.
Current cPanel documentation also exposes DMARC in Email Deliverability; the available interface depends on your installed version and hosting features. Where cPanel does not control authoritative DNS, a local record is insufficient. Copy the suggested public Name and Value to the authoritative provider. A disabled Repair button can reflect this authority boundary rather than broken mail. cPanel Email Deliverability.
Treat Repair as a proposed configuration change, not an all-purpose cure. For example, if Microsoft 365 sends employee mail while the Krystal server sends application notifications, restoring a single-service default could remove a legitimate authorization. Compare the old and new values before approving any replacement.
Configure SPF for the MailChannels relay route
Krystal’s current MailChannels documentation states that mail leaving its covered servers, whether PHP mail or SMTP, uses the relay. Its documented authorization is:
include:relay.k.io
For a previously absent policy covering only that route, the documented example is:
v=spf1 include:relay.k.io ~all
Krystal describes automatic DNS additions for its own nameservers and manual merging for third-party nameservers. The relay authorization does not additionally require the hosting server’s IP address. Do not remove existing IP authorizations without investigating their purpose, and do not downgrade an established -all merely because the introductory example uses ~all. Krystal MailChannels DNS requirements.
SPF checks the envelope MAIL FROM domain, not the visible From address. Confirm the domain in the received smtp.mailfrom result and Return-Path. A policy at example.com does not automatically cover bounce.example.com. At each evaluated owner, maintain exactly one SPF TXT record containing all required authorizations. Preserve unrelated verification TXT records.
The limit is ten evaluated DNS-querying terms across nested policies, not ten includes displayed in the editor. Count include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not use that budget. Exceeding the limit produces permerror. RFC 7208.
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.
Publish the domain’s generated DKIM public record
Copy the DKIM Name and Value from this domain’s Suggested DKIM TXT Record section. If a local key is missing, cPanel documents Generate Local DKIM Key. Publish the resulting public record, not a key from a tutorial or another hosting account. Do not use View the Private Key as the source for DNS. cPanel’s Full and Split views accommodate DNS interfaces with different TXT-string handling. cPanel DKIM controls.
Write down the complete owner before entering it. A DNS editor that appends the zone needs the relative label, not the domain twice. Preserve the public key’s characters; a long value may be stored as multiple character strings inside one TXT record without becoming multiple independent keys. If an owner already has a CNAME or a different service’s record, resolve the conflict with the mail administrator instead of deleting it blindly.
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.
After publication, recheck the panel’s status. Then inspect a newly delivered message for the expected signing domain and selector. A green DNS status proves neither that every application invokes the signer nor that an external relay preserves the signature. If a key exists but no signature appears on the failing route, ask Krystal to investigate that route’s signing configuration.
Use authenticated SMTP for important website messages
Krystal explains that default PHP mail can send using an identity based on the hosting account and server, whereas an authenticated SMTP mailbox gives the application a deliberate domain identity. It recommends SMTP for important flows such as orders, password resets and contact forms. PHP mail versus SMTP.
Retrieve SMTP settings for the actual mailbox rather than guessing a universal host from your website URL. Store the credentials securely in the application. Keep the customer or visitor’s address in Reply-To and use a controlled domain address in From. Do not put a visitor’s Gmail address in From and expect your domain’s DNS to authenticate it.
Retest each plugin and transactional workflow after changing transport. A contact-form SMTP setting may not govern a separate checkout extension. Keep PHP and SMTP test evidence separate, even when both eventually traverse the same outbound relay. Submission authentication, SPF authorization and DKIM signing answer different questions.
Keep DMARC policy and alignment separate
A message passes DMARC through either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment uses the same organizational domain; strict alignment requires exact domain equality. adkim and aspf choose alignment rules, not whether a failed message should be delivered. p requests handling of DMARC failures, subject to receiver policy. RFC 9989.
Read the existing _dmarc record and applicable inherited policy first. Keep established quarantine or reject protection while fixing the failing sender. If there is no policy, use a monitored first deployment with an approved reporting destination and an accountable reviewer. Do not add another DMARC record beside an existing one. Review the raw proposed value before saving it in any panel.
Krystal’s guide contains older pct rollout advice. Current RFC 9989 removed pct; do not rely on percentage enforcement. Instead, inventory senders, validate representative traffic, investigate failures and make an explicit enforcement decision. p=none alone does not produce reports. Configure an approved rua destination and its external authorization where needed. Aggregate reporting, RFC 9990. Leave failure reporting off unless a privacy-reviewed diagnostic need justifies it, since reports may expose message data. RFC 9991.
First DMARC policy when no policy already applies
Use this procedure only after confirming there is no existing or inherited DMARC protection for the From domain. Edit an existing policy rather than creating a duplicate. A monitoring policy is a starting point for a reviewed rollout, not a replacement for established enforcement.
- For From addresses at
example.com, create a TXT record at_dmarc.example.com. In theexample.comzone, the relative Name is_dmarc. - For From addresses at
news.example.com, the full owner is_dmarc.news.example.com. In the parentexample.comzone, use_dmarc.news; in a separately delegatednews.example.comzone, use_dmarcinstead. - Confirm your editor’s resulting full owner and publish this minimal value only for that genuinely new policy:
v=DMARC1; p=none
To request aggregate reports, first provision an approved reporting mailbox or service, then append a semicolon-separated rua tag with its actual destination. For example, the suffix ; rua=mailto:dmarc-reports@example.com is illustrative, not a working destination to copy. An external destination needs its authorization record under the destination’s DNS, as specified in RFC 9990 section 4. Validate the single published policy and arrange a report review before any move to enforcement.
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.
Verification: authoritative DNS, public resolvers and receiver headers
Replace all example domains, the nameserver and SELECTOR below. These commands are read-only checks, not ready-made Krystal DNS values.
dig +short NS example.com
dig @ns1.example.net example.com TXT +noall +answer
dig +short TXT bounce.example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
The authoritative server should return the intended current records. A public recursive resolver should converge after cached answers expire. Query the real envelope domain even when it differs from the root. Confirm one SPF policy, the exact generated public key at the selector owner, and one effective DMARC policy. A DNS lookup does not perform the SMTP transaction needed to establish a message’s SPF result.
Send fresh messages from webmail, the configured mail client and each application route to an independent mailbox you control. Inspect the receiving service’s own Authentication-Results; upstream headers can be forged. Record spf, smtp.mailfrom, dkim, header.d, dmarc, header.from, and the signature’s selector. RFC 8601.
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.
For acceptance, require the expected From identity, the intended transport, a valid signature on the DKIM-capable route, and DMARC pass with a demonstrably aligned mechanism. Log timestamp, receiver and message type. Test forwarding separately because it can change SPF and sometimes signed content. Successful authentication does not guarantee inbox placement or bypass MailChannels content and abuse checks.
Complete this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.
Diagnose the failing layer
- cPanel says valid but external lookups show old records: compare the actual authoritative nameservers with the local cPanel zone.
- SPF fails although the web-server IP is authorized: verify the outbound relay. For the documented MailChannels route, compare the policy with
relay.k.io, not only the server address. - Repair removes another sender: restore the known-good authorization from your backup, then review a combined policy rather than repeatedly applying defaults.
- Webmail signs but PHP mail does not: inspect the application identity and transport. Send through the intended authenticated mailbox and ask support about signing if the signature is still absent.
- DKIM passes but DMARC fails: compare signing domain with visible From under the configured alignment mode.
- DMARC reports never arrive: check
rua, report mailbox handling and external-destination authorization; reports are not guaranteed from every receiver.
Related authentication guide
If you separately administer a relay service rather than only using Krystal’s hosting route, see the MailChannels SMTP Relay authentication guide. Do not substitute that service’s account settings for Krystal’s documented relay authorization.