Dinahosting SPF, DKIM and DMARC setup, step by step

For native Dinahosting hosting mail with Dinahosting already authoritative for the domain’s DNS, open Hosting > Correo > Sobre este correo and use the documented DKIM On control. Dinahosting says this automatically configures the corresponding domain DNS records. Its hosting setup also provisions default SPF, but the current public instructions do not establish a universal SPF string or DKIM selector to paste into every account. Inspect the actual records and verify an externally received native-mail message. DKIM activation and DNS restriction and default hosting DNS records.

This guide covers existing Dinahosting-hosted mailboxes using that native mail service and its documented automatic DNS path. It excludes external authoritative DNS, self-managed VPS or dedicated mail servers, independent website/PHP mail, and third-party SMTP or marketing platforms. It does not transfer a domain, move DNS, replace MX records or reset a zone.

The main control-panel article has a recorded modification date of October 19, 2026; other linked pages have their own dates. No customer account, DNS modification or live message test was performed for this article.*

Confirm the native route and change authority

Use the account’s Información del correo section to identify the actual outgoing Host and supported ports. Dinahosting tells users to configure the secure mail host and ports shown there. Its linked screenshot shows SMTP authentication, SMTPS/STARTTLS and a Webmail link. The screenshot’s example server is not your account’s hostname. Keep existing approved secure-client settings; do not change credentials or relax transport security for an authentication test. Mail-service information.

The DKIM control is explicitly valid only when the domain uses Dinahosting DNS. Verify the actual authoritative nameservers, not just the registrar or hosting invoice. A separately delegated child zone or _domainkey namespace may be controlled elsewhere even when the parent is at Dinahosting. If the automatic setup cannot publish at the needed authority, stop and reconcile the route with the domain administrator and provider. This guide does not establish an external-DNS workaround.

Before activation, record:

• The hosting account, native mailbox domain, approved visible From addresses and actual outgoing transport.
• Every other sender using the domain, including billing services, website applications and bulk-mail tools. Do not assume that web hosting and mailbox hosting mean identical sending infrastructure.
• Existing SPF TXT records, observed DKIM selectors, DNS delegations, TTLs and the direct or inherited DMARC policy.
• The mail/application owner and DNS owner, and who may approve changes, pause the affected stream or restore specific prior records.

Use authorized access to the actual Hosting panel and its DNS controls. The sources do not establish a universal named role or identical entitlement across all Dinahosting products. If a control is unavailable, confirm service applicability rather than purchasing an upgrade, granting broader access or changing mail routes.

For independent Microsoft 365 mail, follow the Microsoft 365 SPF and DKIM guide. Dinahosting’s native mailbox control does not enable another provider’s signing.

Inspect the provisioned SPF policy

Dinahosting says creating a hosting service creates default SPF at the domain’s SOA/root alongside TXT records. That describes provisioning, not a complete policy for every present-day multi-sender domain. Its defaults page also lists a separate “SPF” record type, terminology that must not be treated as a modern publication recipe: SPF policy is retrieved from TXT. Inspect the actual effective TXT policy before changing anything. Provider defaults and SPF DNS record type.

The provider’s educational article labels v=spf1 a mx ~all as a basic example. It is not a verified universal Dinahosting account value. The same article contains an IP-authorization example that incorrectly uses include with a loopback IP; do not copy it. An include evaluates another domain’s SPF policy, whereas literal IP authorization uses the appropriate IP mechanism. Provider examples and DKIM control.

For your actual native route:

1. Identify the SMTP MAIL FROM domain from trusted receiving evidence, commonly reflected in Return-Path. It can differ from the visible From. For a null reverse-path, the relevant HELO identity applies.
2. Query TXT at that evaluated domain. Keep one applicable record beginning v=spf1, not a second SPF record alongside the first. Unrelated TXT verification records can remain.
3. Compare the policy’s authorizations with the real connecting source and all legitimate senders at that owner. If the native policy is missing, conflicts with another policy or cannot be identified, ask Dinahosting and the DNS owner to reconcile the actual configuration. Do not invent an include, server IP or generic replacement.
4. Preserve the approved qualifier and other legitimate senders. Remove obsolete authorizations only after confirming that the affected service is no longer needed.

SPF does not inherit from a parent domain. For example, mail evaluated at bounce.example.com requires the applicable policy there, even if the visible From is at example.com. If the actual envelope belongs to a provider-owned domain, you cannot repair that policy by editing your own apex. SPF identity evaluation.

If the real provisioned policy contains a, it authorizes addresses returned for the applicable name; mx authorizes the addresses of the applicable mail exchangers. Check whether those web and inbound-mail systems are actually authorized to send. Do not change A or MX records to satisfy a generic SPF example, or assume that every inbound exchanger should be an outbound sender.

Evaluate the full nested SPF path. The limit is ten evaluated DNS-query-causing terms, including nested include and redirect processing, not ten includes or ten DNS packets. Also, the presence of all causes redirect to be ignored. Appending a new suffix to a redirect-based policy can disable its existing authorization path. Have the DNS owner reconcile a complex policy deliberately. SPF lookup limit and redirect rule.

Enable the documented automatic DKIM path

First inspect the current state. If DKIM is already On and the intended native signature passes, do not turn it off and on or replace keys merely to follow a tutorial.

For an eligible domain needing activation:

1. Open the correct hosting service in the control panel.
2. Go to Hosting > Correo > Sobre este correo.
3. Confirm the current DNS and signing-record inventory. Resolve an existing conflicting owner, shared selector or delegated namespace before allowing an automatic configuration change.
4. With the owners’ approval, set DKIM to On.
5. Inspect the resulting DNS and test the actual native mail route. Do not assume the switch proves successful signing or alignment.

The educational article documents On, and the current control-panel article says it configures the domain’s corresponding DNS records automatically. Neither establishes an additional Save, Generate or Verify button for this operation. The screenshot includes Clave, but the public procedure does not explain a key-export workflow behind it. Do not infer an external-DNS recipe or private-key operation from that button. Documented On control and automatic DNS behavior.

The sources do not publish a fixed selector, generated record tuple or universal key for this managed path. Preserve the actual provider-created records and inspect the intended message’s s= selector and d= signing domain. A verifier locates the public key using s=._domainkey.d=, with the actual values substituted. Do not paste another account’s key, convert a generated record’s type, or treat an unfamiliar existing selector as disposable. DKIM key lookup.

If On does not result in the expected public key and native signature, stop at diagnosis and request clarification of that account’s configuration. There is no documented universal manual record in these sources to use as a fallback.

Check authoritative DNS and owner names

Dinahosting documents DNS inspection and editing in Hosting > Zonas DNS and the domain’s Zonas DNS section. The domain section supports exporting records for a reference copy and warns that changes can affect web and mail services. Use it to inspect the actual records and apply only separately approved corrections. Hosting zones and domain zones.

Do not use Zonas DNS > Restaurar zonas for this task. Dinahosting describes it as returning the hosting zones to their defaults, a broad change that can overwrite unrelated routing and service configuration. Authentication repair does not authorize a reset, MX change or nameserver migration.

These illustrative mappings help verify names; issued-selector is a placeholder, not a Dinahosting selector:

• Full DKIM owner issued-selector._domainkey.example.com is relative issued-selector._domainkey within the example.com zone.
• If the actual service signs as news.example.com, full owner issued-selector._domainkey.news.example.com is relative issued-selector._domainkey.news in the parent zone, or issued-selector._domainkey in a separately delegated news.example.com zone.
• Inside a separately delegated _domainkey.news.example.com namespace, that full owner is relative issued-selector. Preserve the NS delegation. A parent-zone record below it does not replace the delegated authority’s answer.
• An SPF TXT at full owner news.example.com is relative news in the parent zone or the root label in its own child zone. Use the actual editor’s root-name convention, not an assumed literal @ or duplicated suffix.

If these mappings expose a delegation outside the documented automatic Dinahosting scope, coordinate a supported configuration before continuing. They do not establish eligibility for a new sending subdomain or external signing control.

Query the authoritative service and an independent recursive resolver. Replace the example domain and selector with actual values:

dig TXT example.com
dig TXT issued-selector._domainkey.example.com
dig TXT _dmarc.example.com

Compare the complete answers, not merely the existence of any TXT record. SPF must be checked at the actual envelope owner. DKIM must be checked at the owner derived from the intended signature. A long TXT record can contain multiple quoted character strings that concatenate into one value; this is not a reason to create separate records or truncate the public key. Record authoritative publication time and allow relevant cached answers to expire before repeatedly editing.

Keep DMARC policy and reporting deliberate

Inspect DMARC at the visible From domain and determine whether a parent policy applies. Preserve any existing direct or inherited policy, including p=none, and approved report recipients. Do not overwrite it with Dinahosting’s example quarantine policy or its sample reporting addresses. DMARC policy discovery.

Only if no applicable direct or inherited policy exists, and the domain owner approves a first monitoring policy plus an ongoing review plan, a starting TXT value can be:

v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS

Replace the whole address placeholder with a functioning approved destination. p=none requests monitoring rather than quarantine or rejection; it is not a downgrade instruction for an established policy.

The provider’s documented DMARC input uses TXT, selects Subdominio and enters host _dmarc for the domain being managed. For From domain example.com, the resulting full owner must be _dmarc.example.com. For From domain news.example.com, full owner _dmarc.news.example.com is relative _dmarc.news in the parent zone or _dmarc in a delegated child zone. Verify what the actual editor appends before saving. Publish one policy at the intended owner. Dinahosting’s DMARC field instructions.

Compare the Organizational Domain of the report destination with the Organizational Domain of the domain where the policy was found. If those differ, the report-generating receiver must check DNS authorization for the destination. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone is not enough to make it external. RFC 9990 section 4. Separately approve report-data sharing, access and retention with the domain owner. Do not add ruf or send reports to a third party as an unnoticed side effect of copying a template.

Enforcement is a separate domain-wide decision. RFC 9989 section 7.4 requires valid DKIM signatures for messages from domains publishing p=reject and addresses interoperability with indirect mail. Review all legitimate senders, forwarding and mailing-list paths before tightening enforcement. One direct native-mail test is not that review. DKIM and indirect mail.

Prove signing and alignment with controlled messages

Use harmless synthetic content and controlled, valid external test recipients. Send through each native route actually used, such as the approved mailbox’s Webmail and authenticated mail client. Test an application only through its authorized native-mail configuration, without generating real customer notifications, purchases or password disruption. A message sent directly by another webserver or SMTP provider is outside this automatic mailbox workflow.

Retrieve the complete received message and establish which Authentication-Results fields were generated inside the receiving service’s known processing boundary. Consult the receiver’s documented handling of externally supplied result fields or its administrator if unclear. Neither a familiar authserv-id nor header position proves trust. Ignore attacker-supplied and other untrusted assessments. Authentication-Results security requirements.

For each route record the actual connecting source, MAIL FROM/Return-Path domain, unchanged approved visible From, intended DKIM d= and s=, SPF result, DKIM result and trusted DMARC result.

The acceptance gate is an intended Dinahosting native signature that passes and aligns with the intended branded From, together with trusted receiver dmarc=pass. A rewritten provider From, an unrelated passing signature or DMARC passing solely through SPF does not prove the intended DKIM setup. Under strict alignment the relevant domains must be identical; relaxed alignment compares their Organizational Domains. The public procedure does not guarantee a particular envelope identity or strict alignment. DMARC alignment.

Check SPF independently even if aligned DKIM supplies DMARC pass. Keep any untested or failing route open in the handover rather than treating one passing mailbox as evidence for every application.

Troubleshooting and approved recovery

DKIM On is absent or the domain uses other DNS: confirm the product and actual authority. Do not move nameservers, export a private key or invent another activation flow. The documented automatic route is limited to Dinahosting DNS.

DKIM is On but no signature appears: confirm the actual outgoing Host, account and route. Distinguish native mailbox submission from independent application sending. Request provider reconciliation if the eligible native route still lacks its intended signature.

DKIM lookup or verification fails: compare actual s=/d=, full owner, delegation, resulting public record and complete value. If DNS is correct, examine downstream changes to signed content. Do not regenerate or delete working keys as a first diagnostic step.

SPF fail or softfail: compare the real connecting source with the evaluated envelope policy and authorized route. SPF permerror: inspect duplicate policies, invalid syntax and the nested DNS-term budget. SPF temperror: investigate temporary DNS availability and retest before changing a correct policy. SPF none or neutral: confirm the evaluated owner and whether the missing policy or qualifier is intentional. These are distinct faults or states, not one generic instruction to add more mechanisms.

Authentication passes but DMARC fails: compare the passing identities with the unchanged From under the effective adkim/aspf requirements. The existence of a key or an SPF authorization does not establish alignment.

A change disrupted mail: use the recovery plan approved by the mailbox/application and DNS owners. Pause only the affected stream when authorized, restore only the approved prior configuration and retain unrelated concurrent changes. Keep selectors needed by shared services or queued mail until their owners and the provider approve retirement. Stop or migrate dependent routes before removing records. Retest after hosting, account, domain, DNS-authority, key or sending-route changes. Never substitute Restore zones for this narrow recovery.

Sources and verification limits

This guide uses the complete current first-party bodies for Sobre este correo, SPF/DKIM/DMARC, default records, Hosting zones and domain zones, plus the linked actual DKIM-control screenshot. The current automatic activation is supported; a fixed key, universal SPF value, external-DNS signing and unobserved account statuses are not established. Your actual DNS and received-message checks remain necessary.