Does clicking Apply finish DKIM?

It saves the signing setting, but the documented flow also requires both issued external-DNS records. Verify those records and a newly delivered message before accepting the deployment.

Should I disable mail service to edit DKIM?

No. The adjacent mail-service controls are unrelated and can disrupt or delete mailboxes. Change only the intended signing setting.

Do I need to move DNS to Yourhosting?

No. The official RealHosting procedure supports external DNS publication. Keep the existing authority and use that provider's supported record editor.

Yourhosting SPF, DKIM & DMARC Setup: Step-by-Step Guide

For the RealHosting mail branch documented by Yourhosting, use the RealHosting SPF policy, then enable DKIM in Plesk's domain mail settings, click Toepassen (Apply), and publish both account-issued records shown under How to configure external DNS. Do not substitute another Yourhosting brand's SPF recipe or copy a sample DKIM key. Verify a new message from the actual RealHosting mail route before calling the setup complete. Official SPF brand table, RealHosting DKIM instructions.

Confirm that this is your RealHosting mail service

RealHosting is now part of Yourhosting. The transition FAQ identifies 23 March 2023 as the change date and explains that existing credentials continue to work. More importantly for authentication, current Yourhosting documentation contains a RealHosting-specific section with a Plesk workflow and a distinct SPF value. This guide follows that section, not a presumed universal Yourhosting backend. RealHosting transition, Transition FAQ.

Use this procedure only when your domain's mail service is the documented RealHosting Plesk product. It is not a recipe for every Yourhosting account, Argeweb, SoHosted, Neostrada, Microsoft 365, a separate marketing sender or an arbitrary self-managed Plesk server. A registrar or brand-name change does not prove that mail servers, SPF authorizations or account keys changed.

You need authorized access to Mijn Yourhosting, the relevant Plesk domain and its mail settings, plus permission to edit the authoritative DNS. The reviewed branch does not define a universal named administrator role or plan entitlement for every legacy contract. If your dashboard lacks the documented controls, confirm the product and access rather than enabling a different mail service to make them appear.

Identify which applications and mailboxes actually send through this service. A website can be hosted by RealHosting while its forms use an external SMTP relay. A Microsoft 365 mailbox is another sender even if Yourhosting manages the domain. Keep such routes separate during setup and acceptance testing.

Inventory DNS before editing the brand-specific SPF record

Save the relevant existing TXT records, active DKIM selectors, authoritative nameservers, direct and inherited DMARC policies, and a list of authorized senders. Record the current Plesk signing state. You need a recoverable change record, not a screenshot of someone else's recommended configuration.

Find the authoritative zone before editing. Domain registration, the location of a website and the DNS authority are separate facts. Yourhosting's RealHosting instructions explicitly allow external nameservers and direct external-DNS assistance to that DNS provider. Keep working MX, nameservers, DNSSEC, website records and mailbox routing unchanged for this authentication-only task. External DNS boundary.

The current official SPF table gives this RealHosting-specific value:

v=spf1 mx a include:spf.spamservice.nl ?all

Do not replace it with include:_spf.yourfilter.nl merely because the account now carries the Yourhosting name. The same official article lists different records for different brands. Confirm the RealHosting branch still matches your actual sending product before adopting its policy. RealHosting SPF entry.

The mechanisms authorize the relevant MX hosts, address records and the included service as evaluated by SPF. Check whether the a and mx authorizations are appropriate for the domain's real architecture; a website or unrelated inbound server should not be authorized blindly. ?all produces neutral for unmatched senders, not pass, fail or guaranteed acceptance. Do not silently change that qualifier to a stricter or weaker value as an incidental tutorial step.

SPF evaluates the SMTP MAIL FROM domain, normally reported as smtp.mailfrom, rather than the visible From header; HELO is relevant when the return path is empty. A child envelope domain does not inherit the apex SPF policy. These RealHosting sources do not establish a universal Return-Path or a customer control to change it. Verify the actual identity, and do not edit your apex to fix SPF evaluated at a provider-owned domain. SPF identity rules.

Publish one reconciled SPF policy

Locate the existing TXT record beginning v=spf1 at the owner actually being configured. If one exists, reconcile the required RealHosting authorizations with all other legitimate senders before saving. Do not concatenate complete policies, create a second SPF record, delete unrelated TXT records, or replace Microsoft 365 or another service's authorization without an intentional change plan.

Keep mechanisms before the terminal all and preserve the intended qualifier. Check the full evaluated budget of ten DNS-dependent SPF terms, including nested includes and other lookup-causing terms. Ten visible includes is not the rule. Never use +all to suppress failures. If all is present, redirect is ignored. SPF processing and publication.

Publish SPF as a TXT record, not an obsolete separate SPF resource-record type. At the root of the example.com zone, an editor may use a blank host or @; follow that DNS editor's documented convention. At a child owner such as bounce.example.com, use bounce in the parent zone or the zone-root convention in a separately delegated child zone. These are owner-mapping examples, not evidence that RealHosting offers a custom bounce-domain feature.

The Yourhosting SPF article describes a blank subdomain and a 3600-second TTL in its addition workflow. External DNS editors can label those fields differently. Save the approved complete policy at the correct owner, and verify the resulting authoritative answer rather than relying on how the form displays it. Do not paste typographic quotation marks around the policy unless the DNS interface explicitly requires a quoted representation.

Enable RealHosting DKIM in the documented Plesk branch

Follow the RealHosting section of Yourhosting's DKIM article:

Open Yourhosting's website, choose Inloggen, then Mijn Yourhosting.
Sign in with the authorized account and open Mijn diensten.
Open Plesk, then Mail in the left menu.
Select Mailinstellingen and the relevant domain.
Find the checkbox for using DKIM to sign outgoing messages, enable it, and click Toepassen (Apply).
Open How to configure external DNS and retrieve the two records supplied for this domain.

The official screenshot labels the signing option Bescherm tegen spam door het DKIM-systeem uitgaande berichten te ondertekenen and shows the Apply button. The external-DNS link may appear in Dutch in the interface. Official RealHosting steps and illustration.

Do not change the neighboring mail-service radio buttons. The screenshot includes controls that disable incoming mail or remove the domain's mail service; one warns that mailboxes and their contents will be permanently deleted. Those controls are not DKIM settings. Leave webmail, SSL, routing and other adjacent options alone.

The documented order enables signing before showing the external DNS packet. Coordinate the change so that both issued records can be published promptly and verified; until the correct key is publicly available, a new signature may fail. If you cannot complete publication safely or existing selector ownership is unresolved, stop before changing the signing state and coordinate with the service administrator. No manual account operation was performed for this guide.

Copy both issued records without inventing a template

Copy both records from the current domain's external-DNS instructions, including their exact types, full owners and complete public values. The public article does not justify hardcoding a universal selector, key, second-record value or TTL for every customer. An account-issued packet is the authority for those details. Do not invent a default selector from another Plesk tutorial, omit the second record, or publish a generic generator's unrelated public key.

Only public DNS data belongs in the zone. Never paste a private key. For a TXT public key, retain the complete tagged value and the full p= data; do not copy a screenshot key or truncate a long value. DNS tools may display one TXT record as multiple quoted chunks, which together represent the value. That is different from creating separate conflicting key records. DKIM key records.

Translate the issued full owner into the DNS editor's convention. An illustrative owner SELECTOR._domainkey.example.com becomes SELECTOR._domainkey in an editor that appends example.com. For SELECTOR._domainkey.news.example.com, use SELECTOR._domainkey.news in the parent zone or SELECTOR._domainkey in a separately delegated child zone. Do not append the domain twice.

Inspect existing selectors and any _domainkey delegation before saving. Do not remove NS delegations or replace records shared by another active sender. A TXT record cannot coexist with a CNAME at the same owner. If the current packet differs from the expected record structure, have the provider resolve that difference before improvising a conversion. A CNAME target and a TXT public key are not interchangeable.

If you encounter an account-issued CNAME in a different or changed product workflow, do not flatten it into an address record or proxy it as website traffic. Stop and obtain that workflow's supported DNS-host instructions, including any per-record or zone-wide flattening constraints, rather than treating this two-record RealHosting procedure as proof of an undocumented CNAME setup.

Retain DMARC policy and reporting permissions

DMARC requires a passing, aligned SPF or DKIM result. Relaxed alignment compares Organizational Domains; strict alignment requires the exact domain. Thus news.example.com and example.com can align in relaxed mode but not strict mode. Check the effective aspf and adkim settings and actual envelope/signing identities. Do not promise strict alignment from this control-panel checkbox alone. Current DMARC specification.

Preserve any direct or applicable inherited DMARC policy and approved report destinations. Do not downgrade quarantine or reject to none, duplicate the policy, or adopt obsolete percentage-based rollout advice as part of this setup. If no direct or applicable inherited policy exists and the owner approves a monitored first-policy rollout, this minimal example illustrates the placement:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

Use _dmarc in the example.com zone. For a deliberately chosen child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in the delegated child zone. A monitoring plan requires an approved report destination or another defined monitoring arrangement; the example intentionally does not invent a recipient.

Compare the Organizational Domain of the aggregate report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted. Different hostnames alone do not establish external reporting. This protocol authorization does not replace the owner's separate privacy and data-sharing approval for the recipient. RFC 9990 section 4.

Verify the DNS packet and an actual RealHosting message

Replace these placeholders with your real authoritative nameserver, SPF owner and each issued record owner. The TXT query illustrates a TXT record; query the actual record type if the provider's current packet differs. These commands are examples, not observed test results.

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example TXT FIRST_ISSUED_OWNER.example.com +noall +answer
dig @ns1.dns-host.example TXT SECOND_ISSUED_OWNER.example.com +noall +answer
dig @1.1.1.1 TXT FIRST_ISSUED_OWNER.example.com +noall +answer
dig @1.1.1.1 TXT SECOND_ISSUED_OWNER.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Check every authoritative nameserver and a public resolver. Expect the reconciled single SPF policy, both exact issued records and the unchanged applicable DMARC policy. NXDOMAIN means the queried name is absent; SERVFAIL, timeouts and conflicting authoritative answers require investigation. DNS caching, including negative caching, can delay visibility, but waiting does not correct a wrong owner. Apply in Plesk and successful DNS publication are not delivered-message proof.

Send a newly authorized test to a controlled valid recipient using the actual RealHosting mailbox or application path and intended branded From address. Repeat for each materially different production route. A test sent through Microsoft 365 instead does not validate RealHosting signing. If that is another sender, keep its own setup and testing separate; see the Microsoft 365 authentication guide.

Open the received original message using the receiving service's documented tools. Establish which Authentication-Results fields that service produced within its known processing boundary and how it removes or treats externally supplied result fields. If you cannot establish this, ask the receiving administrator. A familiar authserv-id or header position alone is not proof; ignore attacker-supplied or otherwise untrusted results. Authentication-Results security.

Record the actual visible From, smtp.mailfrom, DKIM d= and s=, and individual results. Acceptance requires the intended RealHosting signature to pass DKIM and align with the branded From under the effective policy, plus trusted dmarc=pass. A rewritten provider From, an unrelated passing signature, or DMARC passing only through SPF does not prove the intended DKIM change works.

Assess SPF independently. Investigate fail, softfail, neutral, none, temperror and permerror even if aligned DKIM supplies DMARC pass. With the documented ?all, neutral means the sending address did not match a passing mechanism, not successful authorization. Authentication success still does not guarantee inbox placement.

Troubleshooting and rollback

The interface differs: confirm the RealHosting Plesk branch. Do not use another brand's cPanel or DirectAdmin instructions without establishing that they apply.
The key exists but DKIM is absent: verify that the signing checkbox was saved with Apply and that the test actually used this domain's RealHosting service.
Only one issued record is present: retrieve the current two-record packet again and reconcile both owners. Do not guess the missing value.
SPF is neutral: identify the actual MAIL FROM domain and sending IP, then compare the evaluated policy with the intended route. Do not replace ?all with +all.
DKIM passes but DMARC fails: compare d= with the visible From under the effective alignment mode and preserve the existing policy while fixing the sender.
A record is visible only in a dashboard: check delegation, full-name expansion and the authoritative DNS provider before waiting for caches.

For rollback, restore only the affected records or signing setting after checking for intervening legitimate edits. Do not revert an entire zone, change MX or disable the domain's mail service. Preserve old keys needed by queued messages and other senders. Coordinate the signing state and published key together so a rollback does not leave the signer using an unavailable public key. Repeat checks on unaffected mail routes.

Source dates and verification limits

That date does not establish a new update for every transition page or account. The relevant primary bodies and Plesk screenshot were reviewed; no customer account was accessed, DNS changed or test message sent. Live deployment, visual CMS rendering, links/status/canonical behavior, indexing, ranking and inbox placement remain untested.

Yourhosting SPF, DKIM and DMARC setup, step by step