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:
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:
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:
DMARC DNS record:
Add the DMARC record in DNS panel as showing below given screen short.
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.
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 firstname.lastname@example.org would be rejected but mail from email@example.com or firstname.lastname@example.org or email@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 firstname.lastname@example.org will pass from either adkim = r or adkim=s, however, mail from email@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.
Optional (if omitted defaults to ri=86400 - 24 hours). Defines the time in seconds between reports requested from the receiving MTA
A comma delimited list of URI(s) to which aggregate mail reports should be sent. DMARC TXT RR contains the parameter rua=mailto:firstname.lastname@example.org this lies inside the sending zone
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@example.com (implicit in the draft RFC)
Spoof Testing Websites: