Plesk DKIM, SPF, and DMARC Setup: Complete Email Authentication Guide

If your Plesk server's outbound emails are ending up in spam folders or getting rejected outright, email authentication is almost certainly the problem. DKIM, SPF, and DMARC are three DNS-based protocols that, together, verify that your emails are genuinely coming from your domain — and when they're missing or misconfigured, even legitimate emails look suspicious to receiving mail servers.

This guide covers the complete Plesk DKIM SPF DMARC setup process: what each protocol does, the correct order to implement them, step-by-step configuration in Plesk's interface, and how to troubleshoot common authentication failures that Plesk sysadmins encounter.

Why Email Authentication Matters for Plesk Servers

Email authentication isn't optional anymore. Google and Yahoo's 2024 sender requirements made DKIM, SPF, and DMARC mandatory for bulk senders, and inbox providers increasingly apply the same standards to all outbound email. Here's what each protocol does and why all three are needed:

SPF (Sender Policy Framework) — A DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks your domain's SPF record to see if the sending server's IP is authorized.

DKIM (DomainKeys Identified Mail) — A cryptographic signature attached to outgoing emails. Your Plesk server signs each email with a private key; receiving servers verify the signature using your domain's public key published in DNS. This proves the email wasn't modified in transit and genuinely came from your server.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) — A policy record that tells receiving servers what to do when an email fails SPF or DKIM checks: monitor only (p=none), quarantine to spam (p=quarantine), or reject outright (p=reject). DMARC also enables aggregate reporting so you can see authentication pass/fail rates across all servers sending on your domain's behalf.

The key insight most guides miss: implement in order — SPF first, then DKIM, then DMARC. Jumping to DMARC before SPF and DKIM are working and verified will cause legitimate email to be rejected.

Step 1: Configure SPF Records in Plesk

Plesk can manage SPF records automatically for domains hosted on the server, or you can manage them manually in DNS if using external nameservers.

Enable SPF in Plesk Mail Settings

Navigate to Tools & Settings → Mail Server Settings → SPF spam protection. Enable SPF checking for incoming mail and configure the spam filter to flag or reject SPF failures. This controls how Plesk handles incoming mail — it doesn't directly create your domain's SPF records.

Create SPF DNS records for your domains

In Plesk, go to Domains → your domain → DNS Settings. Look for an existing SPF TXT record — Plesk may have created one automatically. A standard SPF record for a Plesk server sending mail from its own IP looks like:

v=spf1 ip4:YOUR.SERVER.IP.ADDRESS include:spf.yourdomain.com ~all

SPF mechanism breakdown:

• ip4:YOUR.SERVER.IP.ADDRESS — authorizes your server's IP to send mail
• include: — if using a third-party email service (Mailchimp, SendGrid, Google Workspace), add their SPF include here
• ~all — softfail (mark suspicious but deliver) — use -all (hardfail — reject) only after confirming all your sending sources are listed
• ?all — neutral — avoid this; it effectively disables SPF enforcement

Critical SPF rules to avoid common errors:

• Maximum 10 DNS lookups — each include:, a:, and mx mechanism counts toward a 10-lookup limit. Exceeding this causes SPF to fail permanently with a "PermError"
• One SPF record per domain — multiple TXT records starting with v=spf1 invalidate both records
• Don't use ptr mechanism — it's slow and deprecated; use ip4 or ip6 instead

Test your SPF record:

dig TXT yourdomain.com | grep spf
# Or use: nslookup -type=TXT yourdomain.com

Step 2: Enable DKIM Signing in Plesk

Plesk's built-in DKIM support handles key generation and DNS record creation automatically, making this the most straightforward step of the three.

Enable DKIM for all mail on the server

Navigate to Tools & Settings → Mail Server Settings. Scroll to DKIM spam protection and enable Allow signing outgoing mail. This activates DKIM signing at the server level.

Enable DKIM per domain

DKIM must also be enabled for each individual domain. In Plesk, go to Domains → your domain → Mail → Mail Settings. Enable Use DKIM spam protection system to sign outgoing email messages. Plesk automatically:

• Generates a 2048-bit RSA key pair
• Stores the private key on the server (used to sign outgoing emails)
• Creates a DNS TXT record with the public key for receiving servers to use for verification

Verify the DKIM DNS record was created

dig TXT default._domainkey.yourdomain.com

You should see a TXT record starting with v=DKIM1; k=rsa; p= followed by the public key. If using external DNS (not Plesk DNS), you'll need to manually copy this record to your DNS provider — Plesk will show you the record under DNS Settings for the domain.

Test DKIM signing is working

Send a test email to check-auth@verifier.port25.com or use Google's message header inspector (send an email to a Gmail address and view the original message headers). Look for dkim=pass in the Authentication-Results header.

Step 3: Implement DMARC Policy

Only add DMARC after verifying both SPF and DKIM are passing. Adding DMARC before authentication is working correctly will cause legitimate email to be quarantined or rejected.

Start with DMARC monitoring mode (p=none)

The safest approach is to deploy DMARC in monitoring-only mode first, collect reports for 2–4 weeks, then tighten the policy once you're confident all legitimate sending sources are authenticated.

Add a TXT record for _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1

Parameter breakdown:

• p=none — monitoring only; no action taken on failures
• rua=mailto: — aggregate reports sent daily; shows pass/fail statistics across all sending sources
• ruf=mailto: — forensic reports sent per-failure; detailed individual message failure reports
• fo=1 — generate forensic report if either SPF or DKIM fails (not just both)

Analyze DMARC reports

DMARC aggregate reports arrive as XML files — use a DMARC report analyzer (MXToolbox, Postmark, or dmarcian have free tiers) to read them. Look for:

• Unknown sending sources (third-party services sending on your domain's behalf that aren't in your SPF record)
• SPF failures from your own server (indicates SPF misconfiguration)
• DKIM failures (indicates key rotation issues or misconfigured signing)
• Forwarded messages failing (email forwarding breaks SPF — expected behavior)

Tighten DMARC policy progressively

Once DMARC reports show 95%+ of your legitimate email is passing authentication:

# Step 2: Quarantine policy (failed emails go to spam)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

# Step 3: Full quarantine
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com

# Step 4: Reject policy (failed emails are rejected at the gateway)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

The pct=25 parameter applies the policy to only 25% of failing messages — useful for gradual rollout to catch unexpected impacts before going to 100%.

Advanced Scenarios: External DNS, Subdomains, and Email Forwarding

External DNS (domain not using Plesk nameservers)

If your domains use external DNS (Cloudflare, Route 53, GoDaddy), Plesk won't be able to automatically publish DKIM records. You must manually copy records from Plesk DNS Settings to your external DNS provider each time DKIM keys are rotated. Set a calendar reminder to check DKIM records after any Plesk updates that might trigger key regeneration.

Subdomain email authentication

Each subdomain that sends email needs its own SPF record and DKIM configuration. A common mistake is configuring authentication only on the root domain, then sending marketing emails from newsletter.yourdomain.com without subdomain-specific records. Subdomains inherit DMARC policy from the parent domain unless they have their own _dmarc record.

Email forwarding and SRS

Email forwarding breaks SPF because the forwarded message arrives from the forwarding server's IP, which isn't in the original sender's SPF record. Solutions:

• Sender Rewriting Scheme (SRS) — Plesk supports SRS on Postfix; enable it to rewrite the envelope sender for forwarded messages
• DKIM-based DMARC alignment — since DKIM survives forwarding (the header signature is preserved), ensure DKIM is properly configured and DMARC policy allows DKIM alignment alone (adkim=r — relaxed, the default)

Troubleshooting: email still going to spam after DKIM/SPF/DMARC setup

Authentication passing doesn't guarantee inbox placement. Additional factors that affect deliverability:

• IP reputation — check your server IP at MXToolbox Blacklist Check and Spamhaus; a listed IP overrides good authentication
• Content scoring — spam-trigger words, excessive links, and image-only emails score poorly regardless of authentication
• Sending volume patterns — sudden volume spikes from a new IP trigger spam filters; warm up new IPs gradually
• Reverse DNS (PTR record) — your server IP's PTR record should match its hostname; mismatched PTR records are a common spam signal

If you're managing email authentication across multiple Plesk servers or struggling with persistent deliverability issues after implementing DKIM, SPF, and DMARC, CloudHouse's managed server team specializes in email server configuration and deliverability — including full authentication setup, IP reputation monitoring, and ongoing DMARC report analysis.