How to configure SPF, DKIM and DMARC correctly in Plesk

In this guide, I will show you step by step how to SPF DKIM and DMARC in Plesk so that your emails are reliably authenticated. You will learn clear procedures for DNS records, Plesk switches and test methods to increase deliverability and block abusive senders.

Key points

• SPF determines which systems are allowed to send mails for your domain.
• DKIM signs outgoing messages and protects against manipulation.
• DMARC links SPF/DKIM with guidelines and reports.
• Plesk provides wizards and DNS templates for a quick start.
• Monitoring of DMARC reports sharpens your policy in operation.

Check prerequisites in Plesk

Before I make any settings, I check the mail server used in Plesk and DNS management. On Linux I usually work with Postfix, on Windows with SmarterMail, as these services provide SPF, DKIM and DMARC functions. I also check whether the domain has its DNS zones in the Plesk DNS or with an external provider, because I can then manage the entries outside of Plesk must be added. For smooth operation, I keep the host name, reverse DNS and valid TLS certificates clean, as delivery servers check these points. A clean starting point saves a lot of time later on and strengthens the Reputation.

Setting up SPF in Plesk - step by step

To get started, I open "Tools & Settings" → "DNS Settings" and search for a TXT record that starts with v=spf1 begins. If it is missing, I put it on, for example: v=spf1 a mx include:yourmailprovider.de -allso that authorized systems are allowed to send and all others are blocked. If the domain uses additional senders such as Microsoft 365, Google Workspace or newsletter services, I add the appropriate include-mechanisms from their documentation. After saving, I allow up to 48 hours for the change to take effect globally and test the record with an SPF checker via a test email to a selected mailbox. You can find a compact classification of the interaction of the mechanisms in the compact guidewhich explains the most important scenarios.

Activate DKIM in Plesk - this is how you proceed

For DKIM I go to "Tools & Settings" → "Mail server settings" and activate the option to sign outgoing emails. I then open "Websites & Domains" at domain level → Domain → "Mail" → "Settings" and check whether signing is activated for each domain. If I manage DNS externally, I export the data from Plesk generated DKIM public keys and enter these as TXT records with the DNS provider (note the selector name). After a maximum of 24-48 hours, recipients should validate the DKIM signatures, which I confirm by sending a test mail to a DKIM check mailbox or a header check. A valid signature strengthens the Deliverability noticeable.

Define DMARC policy and use reports

Now I set DMARC as TXT record on _dmarc.yourdomain.tld with the value v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. The tags p, rua and call control policy and reporting, while adkim/aspf define the strict alignment (strict). In practice, I often start with p=noneevaluate reports for two to four weeks and then move on to quarantine or reject on. The reports show which systems are sending mails on your behalf and where SPF or DKIM fail, allowing direct corrections to be made. A more detailed sequence of steps describes the DMARC implementation with concrete examples.

DNS propagation, tests and best practices

Every DNS change takes time, so I plan up to 48 hours for global DNS changes. Propagation on. In this phase, I send test mails to external mailboxes and check the authentication results in the header for spf=pass, dkim=pass and dmarc=pass. If a mail receives a softfail or NeutralI check the SPF mechanisms, the DKIM selectors and the envelope-from (return path) for alignment with From:. When using redirects, I monitor DMARC results, as SPF often breaks there; DKIM usually compensates for this. I avoid ~all permanently and consistently rely on -all.

DMARC tags and values - compact table

I use the following overview to DMARC quickly and reliably and to avoid misinterpretations. I keep the values consistent across main and subdomains and document changes in a traceable manner. For productive domains, I set strict alignment and always activate aggregate reports. Forensic reports (call) I plan in compliance with data protection regulations. Setting clear guidelines stabilizes the Reputation of the domain sustainably.

Day	Meaning	Possible values	Recommendation
p	Policy for main domain	none, quarantine, reject	Start with none, then increase to reject
sp	Policy for subdomains	none, quarantine, reject	sp=reject for productive setups
rua	Aggregate reports	mailto:adresse	Use your own reporting address
call	Forensic reports	mailto:adresse	Activate only if necessary
adkim	DKIM alignment	r (relaxed), s (strict)	adkim=s for clear assignment
aspf	SPF alignment	r (relaxed), s (strict)	aspf=s for fewer false alarms
pct	Percentage of application	0-100	Step-by-step tightening with pct

Integrate external senders: Microsoft 365, Google, newsletter services

If a domain uses additional shipping paths, I add the SPF includes for Microsoft 365, Google Workspace, Mailgun, SendGrid or newsletter tools exactly as documented. For each service, I check whether a separate DKIM key is active and whether the from domain is really signed. I avoid duplicate or too many include-cascades, as SPF is limited to ten DNS lookups. If the budget for lookups is not sufficient, I consolidate senders or move individual streams to subdomains with their own DMARC policy. This is how I keep SPF lean and secure the Signatures from.

In-depth checks and server selection

For incoming mails I activate in Plesk checking SPF, DKIM and DMARC so that the server filters spam at an early stage. On Linux, these checks are available by default, while on Windows they are implemented with SmarterMail. I make sure that the mail server is updated properly so that signature routines and parsers remain up to date. If there are problems with false positives, I adjust the scoring thresholds, but never the Policy of your own domain. This way I keep protection high and ensure that legitimate senders are delivered.

Common errors and quick solutions

Meets "SPF permerror", there is usually a syntax error or the lookup limit has been exceeded. If DKIM fails, I check the selector, public key record and the termination of the TXT value with correct quotation marks. If DMARC fails failI first check the alignment: From-Domain, Return-Path and DKIM-d= must match perfectly. If SPF breaks with redirects, I rely on DKIM and keep the signature status stable. I use this sequence to solve most delivery problems without a long search.

DNS templates and automation in Plesk

If I manage many domains, I set the DNS template in Plesk and store standard records for SPF, DKIM and DMARC there. New domains immediately receive solid defaults that I only need to fine-tune. I also implement planned changes such as stricter DMARC domain-wide using templates and scripts. For rotations of the DKIM keys, I work with two selectors so that I can make gradual changes. This keeps the operation consistent across dozens of domains and maintainable.

Evaluate DMARC reports and tighten policy

After the go-live, I evaluate aggregate reports on a daily basis and identify Sourcesthat send on behalf of the domain without authorization. I block unexpected IPs and clean up outdated tools before I tighten the policy. The change from p=none at quarantine and later on reject I carry out with pct in stages so that I can measure effects in a controlled manner. If legitimate senders appear in the failed report, I correct SPF includes or activate my own DKIM key. This routine strengthens the Reputation visible and reduces spoofing.

Understanding alignment correctly

So that DMARC I consistently ensure correct alignment. With SPF is the domain in the envelope from (return path) or the HELO/EHLO identity, which must match the visible from domain (strict: identical, relaxed: same organizational domain). With DKIM I check the d=-attribute of the signature: It must point to the same domain (strict) or to the same organizational domain (relaxed). In practice, I make sure that:

• the bounce path used (return path) uses a domain that matches the from domain or is deliberately outsourced to a subdomain with its own DMARC policy,
• all third-party providers the From domain sign (DKIM), not just their own shipping domain,
• the DKIM signature remains intact during forwarding to compensate for SPF breaks.

If alignment is missing, DMARC receivers report an error despite valid SPF/DKIM dmarc=fail. That's why I check the fields in the e-mail headers Authentication results, Return path and the DKIM parameters. This allows me to quickly recognize whether SPF or DKIM is providing the alignment and where I need to make improvements.

Key management and DNS parameters

For robust DKIM-setups, I used 2048-bit keys. In Plesk I can set the key length per domain; I turn up older 1024-bit keys promptly. If necessary, I split long DKIM TXT records into several quotation mark segments so that the DNS server delivers them correctly. I also define meaningful TTL-values: In rollout phases I go to 300-900 seconds, productively I use 1-4 hours. This allows me to react flexibly to changes without overloading the caches.

The Rotation I do this without failure with two selectors:

1. Create a new selector in Plesk and publish the public key as TXT in the DNS.
2. Change the sender to the new selector and observe the monitoring (show headers) s=new selector).
3. Once all flows have been converted, remove the old selector in the DNS and deactivate it in Plesk.

I use third-party providers where possible, delegated DKIM records (e.g. CNAME to the provider selector). This allows me to maintain control in my zone and rotate keys without risking operational breaks.

Special cases: Forwarding, mailing lists and gateways

In real environments, I regularly see redirects, mailing lists or security gateways that rewrite emails. I pay particular attention to the effects here:

• ForwardingSPF often breaks because the forwarding IP is not in the SPF of the sender domain. I rely here on DKIMwhich provides the content protection. If the signature remains unchanged, DMARC exists via DKIM alignment.
• Mailing listsMany lists change subjects or footers and thus break the DKIM signature. In such cases, I plan relaxed alignment and check whether the list uses SRS/ARC or its own signatures. If possible, I use a subdomain with its own DMARC policy for lists.
• Security gatewaysGateways that re-sign messages or rewrite the envelope-from must be correctly aligned with the sender domain. I document their role and anchor them in the SPF (ip4/ip6) or via include so that the alignment is maintained.

Meet mails with spf=fail through a forwarding, this is not automatically critical as long as dkim=pass is present and the DKIM alignment is correct. I evaluate the entirety of the authentication results instead of individual signals in isolation.

Shared IPs, HELO/EHLO and rDNS

If several domains share the same outgoing IP, I rely on clean rDNS and consistent HELO/EHLO names. The reverse pointer points to an FQDN (e.g. mail.hosting-example.tld), whose A-record points back to the same IP. The MTA responds with exactly this name. I make sure that the SMTP TLS certificate matches the HELO name (SNI if multiple names are served). For each sender domain, I also ensure that SPF/DKIM/DMARC are fully and correctly aligned - the shared IP alone does not affect DMARC as long as authentication is effective.

For dedicated senders (e.g. transactional mail vs. marketing), I like to separate them via subdomains and optionally their own IPs. This helps with Reputation managementsimplifies the evaluation of DMARC reports and minimizes mutual interference.

Monitoring and rollout in practice

To ensure smooth operation, I combine continuous DMARC analysis with clear rollout steps:

• Baseline: 2-4 weeks p=nonecollect all aggregate reports (rua), identify sources of error.
• CleanupRemove unauthorized senders, clean up SPF includes, activate DKIM on all legitimate systems.
• DressingWith pct gradually to quarantine, later on reject increase, measure effects as a percentage.
• AlertingDefine threshold values (new IPs, fail rate per provider, new from domains) and set up notifications.
• DocumentationKeep selectors, TTL, key runtimes, SPF budget and responsibilities under version control.

I check the SPF lookup budget (max. 10 mechanisms with DNS queries) and consolidate includes. Critical mechanisms such as ptr or +all I generally do not use them; ip4/ip6, a, mx and targeted include remain the means of choice. This is how I keep the setup stable and auditable.

Quick check for each domain

At the end of each installation, I run a fixed Check through: SPF record available, lookup budget under ten, mechanisms correctly sorted, -all Active. DKIM signature valid, selector documented, key length sufficient, rotation planned. DMARC with valid TXT record, strict alignment, reporting mailboxes accessible and archived. Show test mails spf=pass, dkim=pass and dmarc=pass in the header. I use this sequence to keep setups reproducible and low error.

Practical summary for quick success

I start every project with clear StandardsKeep SPF lean, activate DKIM for each sender and roll out DMARC with reporting. This is followed by two to four weeks of monitoring to close blind spots and tighten guidelines. I integrate external services in a controlled manner, document includes and keep the lookup budget under control. I use DNS templates for several domains and plan rotations of DKIM keys to keep the signatures fresh. I summarize useful practical ideas and troubleshooting tips in my Plesk tips 2025 together so that you can maintain a strong Deliverability reach.