What this guide helps you do
Improve domain email trust by understanding the records cPanel can publish and the records your external mail provider may require. Email deliverability is an identity and DNS problem as much as a mailbox problem. SPF says which systems may send for a domain, DKIM signs messages, and DMARC tells receiving systems how to handle messages that fail alignment. cPanel can expose Email Deliverability diagnostics, but the authoritative records must match the actual service sending your mail. This guide is written for production-minded administrators and site owners: make a backup before material changes, keep credentials private, and prefer the controls supplied by your own hosting provider when its environment differs from a generic example.
Before you begin
Record the domain, server or station you are changing and the current working state. If the task touches DNS, SSH, firewall rules, databases, stream credentials or application configuration, make sure you have a recovery path first. Screens and menu names can vary between cPanel, AzuraCast, VDO Panel and Linux releases, so follow the purpose of each step rather than forcing an old screenshot onto a newer version.
Step 1: Open Email Deliverability and inspect the domain. If cPanel marks SPF or DKIM as invalid, read the suggested record and compare it with the DNS zone that is actually authoritative for the domain.
Open Email Deliverability and inspect the domain. If cPanel marks SPF or DKIM as invalid, read the suggested record and compare it with the DNS zone that is actually authoritative for the domain.
Step 2: If DNS is hosted elsewhere, copy only the necessary records to that provider. Do not blindly create duplicate SPF TXT records; a domain should normally have one SPF policy that includes all authorised senders.
If DNS is hosted elsewhere, copy only the necessary records to that provider. Do not blindly create duplicate SPF TXT records; a domain should normally have one SPF policy that includes all authorised senders.
Step 3: Send a test message to a mailbox you control and inspect the message headers. Confirm SPF and DKIM pass for the real sender, not merely that records exist in DNS.
Send a test message to a mailbox you control and inspect the message headers. Confirm SPF and DKIM pass for the real sender, not merely that records exist in DNS.
Step 4: Add DMARC after SPF and DKIM are understood. Start with a monitoring policy where appropriate, collect reports, then tighten the policy once legitimate sending sources are known.
Add DMARC after SPF and DKIM are understood. Start with a monitoring policy where appropriate, collect reports, then tighten the policy once legitimate sending sources are known.
Step 5: For website forms, use authenticated SMTP or a reputable transactional mail service rather than relying on unauthenticated PHP mail. This creates more predictable identity and delivery behaviour.
For website forms, use authenticated SMTP or a reputable transactional mail service rather than relying on unauthenticated PHP mail. This creates more predictable identity and delivery behaviour.
Verification checklist
Check that DNS has a single coherent SPF policy, DKIM signatures pass, DMARC aligns with the From domain, reverse DNS is appropriate on systems you control, and application mail is sent through a known authenticated path. Always test from the user side as well as the administrator side. A control panel saying “active” is useful evidence, but it is not the same as an external browser, player or SSH client proving that the full path works.
Troubleshooting method
When the result is not what you expected, avoid changing several unrelated settings at once. Identify the last known-good point, collect the exact error message and determine which layer is failing: DNS, network, authentication, service process, application configuration, web/stream delivery or browser/player. Check timestamps and logs around the failure. If you need to escalate to hosting support, include the affected hostname or station, the time of the test, what you expected, what happened instead and the checks you already completed. Do not include passwords, API keys or private stream keys in a public ticket or screenshot.
Keep the system maintainable
Document the final configuration after it works. Note the important URLs, service names, backup locations, renewal/expiry dependencies and any change that would surprise another administrator. Revisit the setup after major platform upgrades because defaults, supported runtimes and interface labels evolve. A reliable environment is not one that was configured once; it is one whose current state is understood, monitored and recoverable.
Where to go next
Use the related guides below to expand the setup rather than solving the same problem from scratch. If the platform has outgrown shared hosting or you need managed implementation, the service recommendation at the bottom of this guide links to the most relevant hosting, streaming, development or optimisation option on this site.
Interface labels and supported versions can change. Use the controls and documentation supplied with your current hosting environment, and keep a backup or recovery path before material changes.