Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Establish the Plesk mail boundary
Plesk is a hosting control panel, so a domain appearing in Plesk does not establish that its messages leave through the Plesk mail server. Start with the installed Obsidian version, operating system, underlying mail server, domain mail settings, and the application that submits mail. This guide covers outgoing domain mail managed by Plesk Obsidian. A website using an external SMTP service needs that service's authentication configuration as well; a local Plesk DKIM checkbox cannot demonstrate what an external sender signs.
The administrator guide distinguishes Linux and Windows mail stacks. Its support table's SPF column refers to incoming checks, not whether an organization can publish an outgoing SPF policy. Record the actual supported mail server instead of treating every Plesk installation as identical. Server-wide permission to sign and per-domain signing are also different controls. Confirm that the server permits outgoing signing before diagnosing a missing domain option. Plesk administrator guide
Define the intended From address and the authoritative DNS service. A registrar, a Plesk zone editor, and the nameservers answering publicly can belong to different systems. Save current public answers, the domain configuration, and the change owner before editing. This makes recovery specific and prevents a mail change from becoming an unrelated website or MX migration.
Enable domain signing and publish its generated records
In the documented Obsidian customer flow, open Websites & Domains, select the domain, open its Mail tab, then Mail Settings. Enable the outgoing DKIM signing option and apply it. Plesk generates domain records, including the public-key record normally shown under default._domainkey and a domain-key policy record. Use the actual values displayed for this installation rather than a public key copied from another domain. Plesk domain DKIM setup
When Plesk hosts authoritative DNS, examine the generated published records. When DNS is external, use the How to configure external DNS hint and copy both displayed records to the authoritative host. The provider also instructs customers to add corresponding records for domain aliases used to send mail. Maintain a separate row for each alias domain so the main domain's success is not incorrectly extended to every address. Plesk domain DKIM setup
Query the finished owner names, not just the text entered in the DNS form. Check for an automatically appended zone name, an obsolete key, or edits made in an inactive zone. The DKIM private key stays with the signing system; DNS publishes the public key and the message carries a signature. The provider page's loose introductory language should not be interpreted as permission to publish or transmit a private key. DKIM RFC 6376 sections 3.5 and 3.6
Authorize the real outbound identity
An outgoing SPF policy needs to describe the servers authorized for the evaluated SMTP identity. Inventory direct delivery, a configured relay, and any other legitimate services before changing it. Plesk's DNS-template examples are not a universal record for all servers. An IP address, MX mechanism, or other authorization must correspond to the observed route. Preserve one SPF policy at an owner name and assess the lookup limit after any include changes. SPF RFC 7208 sections 3.2 and 4.6.4
Separate incoming protection from outgoing authentication. Changing Plesk's incoming SPF rejection mode does not publish an outgoing authorization for recipients elsewhere. Likewise, the local incoming DMARC checkbox does not prove the domain's external messages pass DMARC. Inspect the public domain policy rather than assuming a default from a documentation example or inherited server template.
DMARC requires a passing SPF or DKIM mechanism whose authenticated domain aligns with the visible From domain. Both mechanisms need not pass for a DMARC pass. Strict alignment requires the exact domain relationship defined by the standard, so a signature for a parent domain must not be treated as automatically sufficient for every subdomain. Preserve the actual alignment settings in the worksheet. DMARC RFC 9989
Test mailbox mail and application mail separately
Send harmless controlled messages through the real mailbox client and any separate application route in scope. Retain the receiver's trusted Authentication-Results, visible From, SMTP envelope or Return-Path domain, and each DKIM d= and s= pair. Match the selector and signing domain to the queried public key. If one flow is unsigned, determine how that flow enters and leaves the mail stack before regenerating keys.
Forwarding is a separate test case. Plesk documents ARC for supported Linux versions and mail stacks, with limitations, including no ARC headers for mailing-list traffic and no validation of incoming ARC headers in the documented implementation. ARC can inform a receiver's handling; it does not guarantee acceptance or replace the original sender's aligned authentication. Do not turn a successful direct-mail test into a forwarding assurance. Plesk ARC scope and limitations
Plesk acceptance worksheet
Complete these proposed fields for each route. No entries are live observations from a customer server.
- Installation: Obsidian version, OS, mail-server product, host administrator, and whether a relay is involved.
- Domain: intended From domain, mailbox or application path, sending aliases, and domain owner.
- Controls: server signing permission, domain signing state, and external DNS hint captured without private material.
- DNS: authoritative nameservers, generated owners and public values, actual answers, TTL, and collection time.
- Received evidence: test timestamp, receiver, From domain, envelope domain, each DKIM domain and selector, and authentication outcomes.
- Decision: observed aligned mechanism, untested routes, rollback trigger, change ticket, and approving owner.
Fictional diagnosis of an external DNS mismatch
This example is fictional. A company checks the domain signing box and sees DKIM records in Plesk, yet an external recipient reports a missing key. The team initially considers disabling its DMARC policy. The administrator instead compares the published nameservers with the Plesk zone and finds that DNS moved to another host months earlier. The mail server is signing, but recipients cannot find the new public key at the authoritative location.
The proposed repair is to publish the installation's generated records in the active zone, wait for applicable caches, and retest the same mailbox. A second test must cover a sending alias and the website's actual route. This scenario illustrates a diagnosis, not a performed fix or a guarantee of delivery. If the final message still fails, inspect the selected signing domain, key value, and downstream modifications before changing domain-wide policy.
Completion and review gates
The documentation supports this configuration workflow, but no Plesk tenant, authoritative customer zone, or received customer message was accessed. Live route testing, installation-specific support review, human SME approval, and rendered presentation review remain pending. Keep the guide unpublished until those editorial gates are resolved. A working DNS record alone is not evidence that every hosted application or alias is authenticated.