Diadem Web Hosting Knowledgebase
Search:     Advanced search

DKIM and DMARC configuration in Plesk

Article ID: 898
Last updated: 07 Dec, 2017
Add comment
Views: 62
Comments: 0

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.

1. Login to your Plesk account. Select the domain that you'd like to add the DomainKey.


      

2. 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.

                                

3. Now we can found two records automatically added in website DNS panel. Wail for DNS propagation

      

4. If the website DNS running from other Domain control panel then we have to add two TXT record with Public key.

    

5. After propagation we will check from online DKIM checking tools as mention below.

   

DNS Checking link:

http://dkimcore.org/tools/

 

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:

_dmarc.diademtest.diadem-tech.com  

TXT

v=DMARC1; p=none; rua=mailto:test@diademtest.diadem-tech.com; 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.

http://mxtoolbox.com/SuperTool.aspx?action=dmarc%3a_dmarc.diademtest.diadem-tech.com&run=toolpage#

                  

Description:

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 user@example.com would be rejected but mail from user@a.example.com or user@b.a.example.com or user@anything.example.com 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 user@example.com will pass from either adkim = r or adkim=s, however, mail from user@a.example.com 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:dmarc-admin@example.net

A comma delimited list of URI(s) to which aggregate mail reports should be sent. DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone

                       

ruf= mailto:user@example.com

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:user@example.com (implicit in the draft RFC)

                        

Ref:

http://www.webfusion.co.uk/support/answers/Plesk/Email/setting-up-dkim-and-spf-records-4683/

https://www.siteground.com/kb/what_is_domainkeys_and_how_to_use_it/

http://www.zytrax.com/books/dns/ch9/dmarc.html 

Spoof Testing Websites:

https://spf.guru/en/

https://www.wormly.com/

https://emkei.cz/

This article was:  
Add comment
Prev   Next
How to install or Renew Lets Encrypt SSL     How to download website backup using plesk control panel