Plesk Obsidian DMARC Setup Guide for Web Hosting Administrators
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, orreject). - 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
- Log into your Plesk Obsidian control panel as an administrator or domain owner.
- In the navigation sidebar, click on Domains and select the target domain name (e.g.,
example.com). - 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
- Inside the DNS Zone management screen, click the Add Record button at the top of the list.
- In the Record type dropdown menu, select TXT.
- 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). - 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
- 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.cominvalidates 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=rejectinstead ofp=rejectwill cause receiving servers to ignore your policy entirely. - External Reporting Mailbox Validation: If your
ruaemail 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=noneand 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
digor PowerShell. - Review aggregate XML reports over a 14-day period to identify all valid message sources.
- Incrementally step up your policy from
p=nonetop=quarantineand finallyp=reject.