XiaTools

Plesk Obsidian DMARC Setup Guide for Web Hosting Administrators

By Rohit, founder of XiaTools · Updated 21 Oct 2026

Configuring a DMARC record on your Plesk Obsidian server is the single most effective way to protect your domain from email spoofing, phishing, and domain-based abuse. By combining Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) with a Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy, you instruct receiving mail servers on exactly how to handle messages that fail authentication checks. Whether you manage a single client site or hundreds of domains on a dedicated server, getting your DNS records right ensures your legitimate emails land cleanly in the inbox rather than the spam folder.

To jumpstart your implementation, you can use the DMARC Record Generator tool to quickly build, validate, and customize a robust DMARC policy string tailored to your specific email volume and reporting requirements.

Understanding DMARC Basics for Plesk Administrators

DMARC works by aligning the From: address header seen by your recipients with the domain names authenticated by SPF and DKIM. When an email arrives at a destination mail server, it checks your domain's DNS for a TXT record located at _dmarc.yourdomain.com.

Your DMARC record specifies two crucial parameters:

  • p (Policy): Tells the receiving server what to do with failing emails (none, quarantine, or reject).
  • rua / ruf (Reporting): Tells the receiving server where to send XML aggregate reports (rua) or forensic reports (ruf).

Before diving into Plesk configuration, make sure your domain already has valid SPF and DKIM records enabled. Without both underpinning protocols, a strict DMARC policy will inadvertently block your own legitimate outbound mail.

Step-by-Step Plesk Obsidian DMARC Record Configuration

Plesk Obsidian makes managing DNS records straightforward, whether you use the built-in Plesk DNS server or rely on an external DNS provider. Follow these steps to configure your DMARC record directly inside the Plesk interface.

Step 1: Access Domain DNS Settings

  1. Log into your Plesk Obsidian control panel as an administrator or domain owner.
  2. In the navigation sidebar, click on Domains and select the target domain name (e.g., example.com).
  3. On the domain dashboard, locate the DNS Settings card under the Mail or Dev Tools section and click it.

Step 2: Create the DMARC TXT Record

  1. Inside the DNS Zone management screen, click the Add Record button at the top of the list.
  2. In the Record type dropdown menu, select TXT.
  3. In the Domain name or Enter domain name field, type _dmarc (or _dmarc.example.com. depending on your Plesk layout; Plesk usually auto-appends your base domain).
  4. In the TXT record or Value box, paste your generated DMARC policy string.

Here is a safe, standard initial monitoring policy you can use:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100
  1. Click OK or Update to save the new DNS entry.

Step 3: Apply DNS Changes

If your Plesk server is the primary authoritative name server for the domain, the record is published immediately. If you see an orange warning banner at the top of the DNS Settings page stating that changes have not been applied, click Update to commit the zone file modifications.

Validating Your Configuration

Never assume a DNS record works without testing it. Use standard command-line tools to verify that your DMARC record propagates globally and is syntactically correct.

Using dig on Linux and macOS

Open your terminal and query the TXT record for your domain:

dig TXT _dmarc.example.com +short

Expected output:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"

Using PowerShell on Windows

Open PowerShell and run the following command to check the TXT record:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

Sample output:

Name             : _dmarc.example.com
QueryType        : TXT
Strings          : {v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100}

DMARC Policy Progression Strategy

Moving straight to a strict reject policy can break your email flow if legitimate third-party services send mail on your behalf. Follow this phased progression:

Phase DMARC Policy (p=) Percentage (pct=) Primary Goal Recommended Duration
1 none 100% Collect aggregate XML reports and discover all legitimate and unauthorized senders. 2 to 4 weeks
2 quarantine 10% to 100% Route failing emails to the recipient spam/junk folder to test impact. 2 weeks
3 reject 100% Completely block unauthorized emails from being delivered. Permanent production state

Common Mistakes and How to Fix Them

Even experienced administrators run into pitfalls when deploying DMARC across multiple domains on a Plesk server. Keep these common issues in mind:

  • Duplicate DMARC Records: Having more than one TXT record at _dmarc.example.com invalidates the policy. Ensure Plesk only contains a single record for the host.
  • Missing Subdomain DMARC Policies: By default, DMARC applies to subdomains unless overridden. If your marketing emails originate from mail.example.com, make sure your SPF/DKIM covers them or add a separate subdomain policy (_dmarc.mail.example.com).
  • Typos in Tag Names: Tags are case-sensitive and must follow strict syntax. A typo like policy=reject instead of p=reject will cause receiving servers to ignore your policy entirely.
  • External Reporting Mailbox Validation: If your rua email points to an external domain (e.g., admin@externaldomain.com), that domain must explicitly publish a DNS record allowing your reports, otherwise receiving servers will drop the reports due to domain mismatch security policies.

Plesk DMARC Deployment Checklist

  • Ensure valid SPF records are published for your domain and all sending IPs (e.g., 192.0.2.10).
  • Verify that DKIM signing is enabled and active for all mail domains in Plesk.
  • Generate a monitoring DMARC policy with p=none and a valid reporting email address.
  • Add the TXT record under Plesk DNS Settings for _dmarc.example.com.
  • Confirm propagation using command-line query tools like dig or PowerShell.
  • Review aggregate XML reports over a 14-day period to identify all valid message sources.
  • Incrementally step up your policy from p=none to p=quarantine and finally p=reject.

Frequently asked questions

What happens if I skip the `p=none` phase and go straight to `p=reject`?

Going straight to a reject policy without monitoring logs first is risky. If you have third-party marketing tools, customer service platforms, or contact forms sending mail that lacks proper SPF or DKIM alignment, those legitimate emails will be permanently dropped by receiving servers, disrupting your business communications.

How long does it take for Plesk DMARC changes to take effect globally?

The update takes effect immediately on your local Plesk DNS server. However, global propagation depends on the Time-To-Live (TTL) value set in your DNS zone settings. Typically, external mail servers recognize the change anywhere from 5 minutes to 24 hours.

Should I use the same email address for rua and ruf tags?

It is best to use separate email addresses or dedicated mailbox aliases for aggregate reports (rua) and forensic reports (ruf). Aggregate reports arrive in high volume as XML attachments, while forensic reports contain snippets of failing user messages that may trigger privacy concerns.

Why am I not receiving any DMARC XML reports after setting up my rua tag?

Receiving mail servers generate and send DMARC reports asynchronously, often only once per 24-hour cycle. Additionally, some major providers like Google and Microsoft only send reports if they observe actual inbound traffic hitting their mail infrastructure from your domain.

How do subdomains handle DMARC records in Plesk?

By default, a DMARC record placed at the root domain (example.com) automatically covers all subdomains. However, if you need a stricter or looser policy for a specific subdomain, you can create a separate TXT record specifically at `_dmarc.subdomain.example.com`.

Related articles

Free tools