Get your Email Service Provider (ESP) implement DomainKeys Identified Mail (DKIM) for your bulk mail server!

DKIM (DomainKeys Identified Mail) is a possibility to make an email sender more easily identifiable for the email service providers (ESPs) who receive and filter email. The message is identified by the domain it is sent from, that is, the part of the address after the @.

If the delivery address differs from that that has been registered with the DNS server (Domain Name Server), there is an increased likelihood that the email will be classified as Spam by the email service provider.

Why it is needed?

It is because ISPs like yahoo, gmail, hotmail dictate it!  Look at their bulk mailing guidelines, which must be followed by all email marketers and their email marketing solution providers.




If your bulk or mass email marketing solution provider doesn’t provide it, it is time for you to ask for it. If they are unable to do it, look for other email service providers who can provide it.


What is a DomainKeys Identified Mail (DKIM) Signature? Why it is required for your mailing server infrastructure?

DKIM (DomainKeys Identified Mail) is a possibility to make an email sender more easily identifiable for the email service providers (ESPs) who receive and filter email. The message is identified by the domain it is sent from, that is, the part of the address after the @.

If the delivery address differs from that that has been registered with the DNS server (Domain Name Server), there is an increased likelihood that the email will be classified as Spam by the email service provider.

DKIM signatures are created, in consultation with you, when your Kenscio mailing system is first set up. The DKIM signatures may differ from the actual domains of your Kenscio mailing system.


The domain of your Kenscio mailing system is:

You send email messages using the domains:

The sender domains @mybrand.com and @mybrand.in must be registered with the DNS server. The registered domains should be the domains used for sendout.

This means that, if possible, all domains that will be used for email sendout should receive DKIM signatures.

The part of the address before the @ can be freely set (eg. newsletter@mybrand.com, orders@mybrand.com). This part of the address is not a part of the DKIM signature.

If you would like to add a DKIM signature to more sendout domains, or if you need information about which of your domains already have the DKIM signature, please contact your Kenscio representative.

The sendout process with a DKIM signature (simplified):

The sender (that is, the domains) are registered with the DNS server. A special encrypted signature is created that makes these domains clearly identifiable.

During email sendout, the signature and sender information are embedded in the email header.

When an email provider receives an email that contains a DKIM signature, it obtains the key to decipher the signature from the DNS server.

If the sender is correctly identified by the DKIM signature, this increases the chances of delivery in the inbox.

If the DKIM signature does not match the sender identity, the email is probably marked as Spam.


The primary advantage for e-mail recipients is it allows the signing domain to reliably identify a stream of legitimate email, thereby allowing domain-based blacklists and whitelists to be more effective. This is also likely to make some kinds of phishing attacks easier to detect.

Use with spam filtering

DKIM is a method of labeling a message, and it does not itself filter or identify spam. However, widespread use of DKIM can prevent spammers from forging the source address of their messages, a technique they commonly employ today. If spammers are forced to show a correct source domain, other filtering techniques can work more effectively. In particular, the source domain can feed into a reputation system to better identify spam. Conversely, DKIM can make it easier to identify mail that is known not to be spam and need not be filtered. If a receiving system has a whitelist of known good sending domains, either locally maintained or from third party certifiers, it can skip the filtering on signed mail from those domains, and perhaps filter the remaining mail more aggressively.


DKIM can be useful as an anti-phishing technology. Mailers in heavily phished domains can sign their mail to show that it is genuine. Recipients can take the absence of a valid signature on mail from those domains to be an indication that the mail is probably forged. The best way to determine the set of domains that merit this degree of scrutiny remains an open question; DKIM will likely have an optional feature called ADSP that lets authors that sign all their mail self-identify, but the effectiveness of this approach remains to be tested.

Working with eBay and PayPal, Google has effectively utilized DKIM in GMail in such a way that any e-mail that claims to be coming from ebay.com or paypal.com will not be accepted at all if they cannot be verified successfully with DKIM. Such messages won’t even appear in the Spam folder.

Feedback Loops (FBLs)

Most of the Internet Service Providers (ISPs) like gmail, yahoo, hotmail and etc. now demand the Email Service Providers (ESPs) to set up DKIM for the sending mailing infrastructure in order that they receive a copy of a message that one of their subscribers has reported as spam — usually by hitting a “report spam” button in that ISP’s mail interface. Feedback Loop recipients are generally expected to remove any subscriber from their mailing lists to prevent similar “spam complaints” — but the core requirement is simply that they fix whichever problems within their network caused the complaints.


Have you heard about Domain-based Message Authentication, Reporting, and Conformance (DMARC)?

Have you heard about DMARC?

Last week, a group of some of the largest email service providers (Gmail, Yahoo, AOL), together with organizations like Facebook and Paypal, jointly announced the release of a new method of email authentication. The new standard, called DMARC, is a way for email senders and receivers to better work together to increase email security by protecting email recipients from malicious phishing attacks and domain spoofing.

How does it work?

Essentially, email senders can now publish a DMARC record that indicates

1. which authentication tests they have in place (i.e. DKIM, SPF) and

2. what action the email service provider should undertake when an incoming email fails these tests (i.e. spam folder or outright rejection).

This provides the mailbox provider with greater certainty about the origin and identity of messages, thus taking the guesswork out of filtering incoming email. The mailbox provider sends a report back to the email sender containing information about all incoming emails claiming to be from that sender, and whether or not they were actually delivered to recipients.

What are the implications for Kenscio clients?

There are no immediate consequences for clients who do not yet have a DMARC record in place. However, given the size and importance of the players involved in the development of this standard (Gmail! Facebook!), its consequences on the email industry are likely to be of growing importance.

The new standard provides many clear benefits, especially for Kenscio clients where data security is a high priority, such as banks. However, in effect any company can benefit from publishing a DMARC record, if for no other reason than to receive the DMARC reports, which provide visibility and information about a domain’s email and any potential authentication issues.

We are currently beta-testing this with selected client systems, to get a better understanding about the impact this has. Also note, there are some circumstances in which it will not be possible to support DMARC (multi-domain systems, in some cases personalized from-addresses).

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. DMARC is a new  technical specification that was created in order to help reduce email abuse, especially Phishing attacks. DMARC standardizes how email receivers perform email authentication using the existing SPF and DKIM mechanisms.

When a sender publishes a DMARC policy, the sender clearly indicates to the mailbox provider whether the sender’s emails are protected by SPF and/or DKIM. The sender also specifically tells the mailbox provider what to do if an incoming email fails the SPF and DKIM authentication tests – i.e.  block the message or divert it to the spam folder. The mailbox provider  no longer has to guess how to respond to incoming mail that fails authentication tests, because DMARC clearly tells the mailbox provider  how to handle such messages. Furthermore, the mailbox provider can report back to the email sender about whether incoming emails pass or fail the evaluation process.

As a result of DMARC, email senders will experience consistent authentication results for their messages at AOL, Gmail, Hotmail, Yahoo! and any other email receiver implementing DMARC.

How does it work?


A DMARC policy for a particular sender is published in the DNS as text (TXT) resource records (RR).

When the mailbox provider receives an incoming mail, it checks the results of the SPF and DKIM tests. It also accesses the DMARC policy for that sender. This policy defines what an email receiver should do with incoming mail when that mail does not pass the SPF and DKIM tests.

If the mailbox provider  determines that the results of the SPF and DKIM authentication tests do not correspond to the standards of the published DMARC, it either rejects the incoming message or categorize it as spam, depending on the instructions of the sender as defined in the DMARC. In DMARC terms, this is referred to as a “non-aligned” email.

The mailbox provider reports back to the email sender about all non-aligned incoming emails.

Important Information

DMARC focuses its analysis on the domain in the “from address”. This identifier is used in conjunction with the results of the underlying authentication technologies (at the moment SPF and DKIM).

The most critical factor is that the domain used for DKIM and SPF must have the same “organisation domain” as the domain in the “from address”.

With DMARC, there is essentially no difference between an email signed with the wrong DKIM and an email with no DKIM signature! (For more information on DKIM, please see DKIM signature).

Using DMARC: Set-up steps

If you are interested in creating and publishing a DMARC policy for your Kenscio’s eC-m system, please contact your Kenscio representative. The DMARC policy for your system will be created together with our team of dedicated, in-house deliverability experts.

The basic steps for setting up a DMARC process for your system are:

1. It is first necessary to have DKIM and/or SPF policies in place!
2. Publish a DMARC record indicating which policies you use and requesting reports from mailbox provider.
3. Analyze the data and modify your mail streams as appropriate.
4. Gradually modify your DMARC policy flags from “monitor” to “quarantine” to “reject” to improve control.


Copyright © 2020 Kenscio Blog. All rights reserved.
iDream theme by Templates Next | Powered by WordPress