Must I move DNS to METANET Plesk?

No. The provider documents an External DNS Configuration link for publishing the required account records elsewhere. Preserve the existing authoritative service unless a separate migration is explicitly approved.

Is there a universal METANET DKIM key?

No. Use the complete public key and owner issued for the intended domain. The shortened sample in documentation cannot authenticate your account’s signature.

Does enabling DKIM cover all mail from my domain?

No. This guide covers the documented authenticated native Plesk route. Marketing services, external mailboxes and application paths require their own scope and real-message checks.

Should I buy the advertised DNS configuration service?

It is optional paid assistance, not an authentication prerequisite. If the owner wants that service, agree its scope and charges separately. Do not treat a support request for information as acceptance of paid DNS work.

What should I retain after validation?

Keep the domain, route, public selector, evaluated SPF owner, approved record changes and trusted receiver evidence with timestamps. Exclude passwords and private keys. Retest after planned signing or routing changes, and retain old public selectors until queued mail, TTLs and shared dependencies have been assessed.

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

For an existing METANET domain using native, authenticated Plesk email, enable outbound DKIM in the domain’s Email Settings and save it. Plesk adds the public key to its local DNS zone. If your authoritative DNS is elsewhere, copy the complete account-issued records from External DNS Configuration to that service. Maintain the applicable METANET SPF authorization in one policy, then validate an actual message through the intended native route.

This is not the activation procedure for METANET Business Mail, which uses a separate support-led DKIM workflow. It also does not configure Microsoft 365, another external mailbox provider, arbitrary application-generated mail or a newly provisioned server. Confirm the service actually sending before changing anything.

On this page: Confirm the native Plesk route · Enable outbound DKIM for the intended domain · Copy the full public packet when DNS is external · Map the exact DNS owner correctly · Maintain the applicable METANET SPF policy · Preserve DMARC while fixing the sender · Validate an actual authenticated native message · Troubleshoot without broadening the change · Frequently asked questions

Confirm the native Plesk route

METANET’s Plesk DKIM instructions explicitly describe the domain-level signing control, local DNS publication, external DNS instructions and signing of authenticated outgoing messages. That supports this narrow mailbox workflow, not every service sold under the METANET name.

Before beginning, have the owner approve the exact domain and signing change. You need access to its Plesk Email Settings and to the authoritative DNS zone, or a DNS administrator who can publish the approved records. Confirm that the native mail service and intended mailbox already exist and that the message is submitted through the authenticated native route.

Record the intended visible From domain and actual SMTP MAIL FROM domain. Save current SPF, DKIM selectors, relevant delegations, TTLs, and the applicable direct or inherited DMARC policy. Inventory other legitimate senders sharing the SPF owner. Preserve approved report destinations and working authentication for those services.

A domain registered with METANET does not necessarily use Plesk’s authoritative nameservers. Likewise, an externally registered domain can delegate DNS to a METANET service. Determine actual delegation rather than relying on the registrar name or where the website is hosted.

Do not change MX, nameservers, DNSSEC, mailbox credentials, mail routing or TLS settings merely to reproduce a documentation screenshot. Those are separate operational decisions. If the domain sends through Business Mail, follow its support process instead of looking for a Plesk checkbox.

Enable outbound DKIM for the intended domain

Follow the product’s documented sequence:

In Plesk, open Email Addresses for the intended domain.
Select the Email Settings tab.
Select the checkbox for using DKIM to sign outgoing email messages. The illustrated German interface labels it DKIM-Spamschutzsystem zum Signieren ausgehender E-Mail-Nachrichten verwenden.
Review that the selected domain and proposed change are correct, then click OK.
Reopen the settings and confirm that outbound signing remains enabled.

METANET states that this enables signing and adds a public-key record to the domain’s local DNS zone. Its source screenshot also shows unrelated mail-service, certificate and automatic-discovery controls. Do not change those controls or copy a screenshot’s certificate selection as part of DKIM setup.

Signing activation and publicly resolvable DNS are separate checkpoints. With external DNS, the server can begin signing before the receiver can find the key. Coordinate the activation and publication window with the mail administrator, publish the exact generated packet promptly and do not consider the route accepted until receiver verification succeeds. Do not invent a separate unpublished staging mode or assume external DNS is updated automatically.

Copy the full public packet when DNS is external

Use the (?) External DNS Configuration link shown beside the DKIM signing control. Obtain the complete record types, owners and public values generated for this account and domain. METANET specifically supports this external-DNS path; moving nameservers to Plesk is not a prerequisite.

The provider’s article contains a shortened sample key. It is illustrative, not a usable public key for your account. Do not paste that sample, choose a universal selector from memory, or copy only the visible first part of a long value. Publish the complete account-issued public TXT record, including its tags and full p= data.

Only the public key belongs in DNS. Never copy or send a private DKIM key to a DNS host, public validator or support ticket. If the interface does not provide the expected public records, stop and ask METANET to confirm the supported packet for your domain; do not generate a replacement through an unrelated tool.

For Plesk-authoritative DNS, inspect the public answer rather than assuming local automatic creation guarantees resolution. For external DNS, add the approved records in the service that is actually authoritative. A matching record in a nonauthoritative local zone cannot satisfy a receiver’s lookup.

If the packet includes any record whose purpose is unclear, resolve that with the administrator before applying it. Do not accept new routing, delegation or unrelated policy changes simply because they appear alongside authentication instructions.

Map the exact DNS owner correctly

A DKIM lookup normally has the form SELECTOR._domainkey.SIGNING-DOMAIN. Use the full owner actually issued for the account, then adapt only the DNS editor’s name format.

For example, if the issued full name is SELECTOR._domainkey.mail.example.com:

In the authoritative example.com zone, a relative-name editor may require SELECTOR._domainkey.mail.
In a separately delegated mail.example.com zone, it may require SELECTOR._domainkey.
If _domainkey.mail.example.com is itself delegated, its DNS administrator controls publication there.

These are mapping examples, not production selector values. Check whether your editor appends the zone name or expects a fully qualified name with a trailing dot. Avoid accidentally publishing a doubled suffix.

Preserve existing selectors and NS delegations used by other systems. A CNAME cannot coexist with a TXT record at the same owner. If an issued TXT owner conflicts with an existing alias, stop and coordinate a supported selector or namespace arrangement instead of deleting the alias blindly.

Long TXT values can be represented by multiple quoted character strings within one DNS record. Ensure their concatenated value matches the complete public packet. Do not create several separate TXT records containing fragments, truncate the key or add literal formatting characters that change its data.

Check the authoritative response first, then a recursive resolver after the relevant positive or negative cache expires. Keep the actual TTL and validation time in your change notes. A successful lookup establishes publication at that moment; it does not prove that every resolver has refreshed or that a delivered message passed DKIM.

Maintain the applicable METANET SPF policy

METANET’s SPF DNS Record guide gives a network example containing this mechanism:

include:_spf.sui-inter.net

This is an authorization mechanism, not a complete second SPF record. Confirm it applies to the actual native sending route. The source example also contains +mx and +a; these authorize additional infrastructure and should not be added blindly. Retain or add them only where the domain owner’s sender inventory requires them.

SPF normally evaluates the SMTP MAIL FROM domain, not automatically the visible From address. A null reverse-path uses the applicable HELO identity. Determine the domain actually evaluated for the native route before editing apex DNS. If the envelope is provider-controlled, ask METANET which customer-domain authorization is applicable rather than assuming a record at the visible From domain creates SPF alignment.

At the appropriate authoritative owner:

Find the existing TXT policy beginning v=spf1, even if its first mechanism is not an include.
Preserve legitimate existing sender authorizations and approved qualifiers.
Integrate the applicable METANET mechanism into that single policy, where it can be evaluated before a terminating all mechanism.
Validate the complete policy, including nested DNS-dependent terms, before saving.

Do not publish two v=spf1 records at one owner. Do not append an authorization after all, where it cannot be reached. If the policy uses redirect=, have the administrator deliberately integrate the new sender: an all mechanism anywhere in the policy causes redirect to be ignored.

SPF permits at most ten evaluated DNS-dependent terms, counting nested mechanisms and redirects, not merely ten top-level includes. If no policy exists, construct one from the complete approved sender inventory and final qualifier. The absence of a record is not evidence that METANET is the only legitimate sender. Do not copy the source’s generic complete example over a multi-sender policy.

These rules follow RFC 7208. -all produces an SPF fail for unmatched senders; it does not guarantee a particular receiver’s delivery or rejection decision.

Preserve DMARC while fixing the sender

Enabling DKIM is not authorization to replace the domain’s DMARC policy. Inspect the current direct policy and any applicable inherited protection before and after the change. Preserve authorized report destinations and do not add duplicate DMARC records.

The METANET source describes a default monitoring record for newly created domains and recommends quarantine after signing is enabled. Do not apply that recommendation automatically to an existing domain. One checkbox or one successful test does not establish readiness for every legitimate sending service. Likewise, do not overwrite a working enforcement policy with p=none to hide a sender failure.

DMARC is not merely a requirement that every message contain DKIM. It evaluates passing SPF or DKIM authentication together with alignment to the visible From domain. A monitoring policy is still DMARC, not “disabled.” This guide preserves policy rather than creating a new reporting arrangement, authorizing data sharing or prescribing an enforcement rollout.

Validate an actual authenticated native message

After the public records resolve, send a non-sensitive message from the intended mailbox through the normal authenticated METANET Plesk route to a controlled, valid external recipient, with the owner’s permission. Keep the intended branded From. Do not substitute an external SMTP provider, bypass the normal route, or send private customer material to public testing inboxes.

Use results generated inside the receiving service’s known processing boundary, following that service’s documented handling of externally supplied Authentication-Results. A familiar authserv-id, position near the top of the message or a copied “pass” string does not establish trust. Ignore untrusted injected fields; ask the receiving administrator when the authoritative receiver result is unclear. RFC 8601 explains this boundary.

Accept the newly configured route only when all the following are established:

The visible From remains the intended branded address rather than a rewritten provider identity.
The intended native DKIM signature passes. Check its actual d= signing domain and s= selector against the published account key, even when the message has other signatures.
That intended passing signature aligns with the visible From under the applicable DMARC alignment mode.
The trusted receiver reports dmarc=pass for the intended identity.
SPF is checked separately against the actual MAIL FROM domain, with any failure or error investigated.

Under relaxed alignment, the relevant DKIM d= domain or SPF MAIL FROM domain shares the visible From domain’s Organizational Domain. Under strict alignment, that respective domain must exactly equal the visible From domain. A child envelope domain does not automatically meet strict SPF alignment. RFC 9989 defines these relationships.

A DMARC pass achieved through SPF does not prove that the desired DKIM signature works. Conversely, aligned DKIM may allow DMARC to pass while SPF remains broken. EmailAuth’s raw DKIM results versus aligned DKIM policy results explains why signature verification and policy alignment must be checked separately.

Troubleshoot without broadening the change

The signing checkbox is unavailable. Confirm the product and domain permissions. Business Mail uses a different procedure, and external mailbox services do not inherit this native Plesk workflow. Ask support rather than enabling an unrelated server service.

Plesk shows a key but public DNS does not. Check authoritative nameservers, the external-DNS packet, owner formatting, delegation and cache state. Local DNS creation does not publish into an external provider’s zone.

The record resolves but the intended signature is absent. Confirm the saved signing setting and that the message used the authenticated native path. An application or unauthenticated local script may be a different route. Do not change credentials or server security settings simply to force a result.

DKIM fails. Compare actual d= and s= with the full public key, look for conflicting records and stale caches, and investigate modifications to signed headers or body. Do not regenerate a key before identifying the fault, as queued messages may still need the previous public key.

SPF fails. Check the receiver’s connecting IP, actual evaluated domain, complete policy and reachable authorization. A record at the wrong owner cannot fix the evaluated identity.

SPF reports temperror. Investigate transient DNS availability and retest. permerror instead requires resolving structural issues such as multiple policies or too many evaluated DNS-dependent terms. Diagnose both separately from an ordinary fail, even if DKIM currently gives a DMARC pass.

DMARC fails despite authentication passing. Compare actual identities and strict or relaxed alignment, not just green SPF/DKIM indicators. Preserve policy while repairing the sender.

Mail still lands in spam. Investigate the actual receiver response, reputation, content and recipient policy. Authentication does not guarantee delivery or inbox placement. Do not weaken inbound filters or add blanket allowlists.

Metanet SPF, DKIM and DMARC setup, step by step