Diadem Technologies Support Knowledgebase

DKIM and DMARC configuration in Plesk

Article ID: 898
Last updated: 25 Jul, 2018

Enable DKIM and DMARC server wide.

DomainKey configuration

DomainKeys is closely related to DKIM (DomainKeys Identified Mail), which is a result of merging DomainKeys and Identified Internet Mail. In many cases, however, the two terms are used interchangeably.

DomainKeys is an email authentication method through which emails are digitally signed on a domain basis. Unlike other methods, DomainKeys offers end-to-end integrity of the message, i.e. it can verify that an email has not been modified in transit.

Step 1: Enable DKIM

To enable the DKIM and DMARC server wide Tools and Setting > Mail Server settings .

To enable DKIM for outgoing mails we need to check the option for Allow signing outgoing mails.
To verify incoming mails check the option Verify incoming mail.
To enable DMARC for incoming mails check the option Enable DMARC to check incoming mail.

Step 2: Enable DKIM for the particular subscription

Step 3: Enable DKIM for the domain or subscription

Go to domain Mail settings and enable DomainKey Spam Protection for outgoing email message. Before enabled DomainKey the domain should enable DNS in the same panel.

Step 4: Records automatically added in website DNS panel. Wait for DNS propagation

Step 5: Adding TXT record for external DNS zones

Step 6: DKIM checking

DNS Checking link:


DMARC Configuration:

DMARC is designed to fit into an organization’s existing inbound email authentication process. The way it works is to help email receivers determine if the purported message “aligns” with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, assuming that a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:

At a high level, DMARC is designed to satisfy the following requirements:

  • Minimize false positives.

  • Provide robust authentication reporting.

  • Assert sender policy at receivers.

  • Reduce successful phishing delivery.

  • Work at Internet scale.

  • Minimize complexity.

It is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications that are currently being developed within the IETF. DMARC is designed to replace ADSP by adding support for:

  • wildcarding or subdomain policies,

  • non-existent subdomains,

  • slow rollout (e.g. percent experiments)

  • SPF

  • quarantining mail

DMARC DNS record:



v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=s; pct=20; rf=afrf; sp=quarantine

Add the DMARC record in DNS panel as showing below given screen short.

DMARC Check:

After DNS record add it will take 24 to 48 hours to propagate the record properly. We can check DMARC record from below given link.



The following section describes the supported filed for common DMARC implementations. 


v= DMARC1;      

Mandatory. This must be the first supplied tag=value within the dmarc specific text and, while DMARC tag=value pairs are not case sensitive, this one must have the explicit upper-case value DMARC1.

p= none, quarantine or reject;

Advises the receiving MTA to treat any email that fails any DKIM and/or SPF checks as suspicious and perform additional checks or mark the mail as suspected SPAM or whatever local policy is in operation. Mandatory and must be the second tag=value pair. Defines the policy the sending MTA advises the receiving MTA to follow.

sp= reject, quarantine, none;

Optional. If not present the p= policy is assumed to cover the domain.name and all its subdomains. If sp= is present it indicates the defined policy that applies to subdomains of the domain.

Then failed mail from [email protected] would be rejected but mail from [email protected] or [email protected] or [email protected] would be quarantined.


adkim= r (relaxed - default) or s (strict) mode;

Optional (if omitted defaults to adkim=r). In strict mode the sender domain name must exactly match the corresponding d=name (in the DKIM mail headers). In relaxed mode any subdomain of d=domain (in the mail headers) will also be accepted. Thus if d=example.com in the mail header then mail from [email protected] will pass from either adkim = r or adkim=s, however, mail from [email protected] will fail if adkim=s but pass if adkim=r.


aspf= r (relaxed) or s (strict) mode

Optional (if omitted defaults to aspf=r). In strict mode the domain.name in the MAIL FROM command (in SMTP) and the from: header (in the mail item) must match exactly. In relaxed mode any valid subdomain of domain.name is acceptable.


pct=       value from 0 to 100

Optional. Defines the percentage of mail to which the DMARC policy applies. If omitted defaults to pct=100 (100%) - all mail is subject to DMARC processing. This parameter allows mail senders to experiment with a small percentage of mail being subject to DMARC action. Problems can be progressively eliminated from the system before turning DMARC on for all mail.


fo=  0, 1, d or s;

Optional. May take one or more of the following values:

0              Generate report to the sending MTA if all underlying checks failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL NOT be sent.

1              Generate report to the sending MTA if any underlying check failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL be sent.

d             Generate a report if DKIM checks fail.

s              Generate a report if SPF checks fail.


rf= afrf or iodef

May take one or more of the following values:

afrf         Message format for error reporting (Abuse Report format) is defined by RFC 5965.

iodef     Message format for error reporting (Incident Object Description Exchange Format) is defined by RFC 5070.


ri= 86400

Optional (if omitted defaults to ri=86400 - 24 hours). Defines the time in seconds between reports requested from the receiving MTA


rua=mailto:[email protected]

A comma delimited list of URI(s) to which aggregate mail reports should be sent. DMARC TXT RR contains the parameter rua=mailto:[email protected] this lies inside the sending zone


ruf= mailto:[email protected]

A comma delimited list of URI(s) to which detailed failure reports should be sent. Optional. If not present detailed failure reports will not be sent from the receiving MTA. URIs must be of the format mailto:[email protected] (implicit in the draft RFC)






Spoof Testing Websites:




This article was:  
Report an issue
Article ID: 898
Last updated: 25 Jul, 2018
Revision: 21
Views: 2104
Comments: 0