Authentication Archives - DeliverNow

Gmail’s wide deployment of TLS

When talking about authentication and encryption technologies —such are SPF, DKIM, DMARC—, Gmail has always been at the cutting edge of the topic. After having implemented Google Postmaster (read our related article), it is therefore possible to monitor the percentage of Google’s outgoing and incoming emails TLS encrypted or not.

Announced by Google last week, this topic concerns directly TLS. Let’s not forget that TLS (Transport Layer Security) is the successor of SSL (Secure Sockets Layer). TLS ensures the veracity, confidentiality and content integrity of all the exchanged data through the network. When 2-email servers communicate between them through this protocol, it becomes possible to exploit this technology to get safer email exchanges.

Visual aids for users.

Gmail deploys TLS as of several years from now. However, the huge change comes from the fact that Google highlights the lack of this technologies. Indeed, when incoming emails get into Google’s webmail without being authenticated by TLS, these emails are red-chained displayed to the user.


In the same way, if a user is trying to send an email to a non-TLS domain, he will then be alerted by the same visual displays.

Adopting TLS as the encryption process.

Through these enhancements, Google manifests its will to boost TLS deployment for all email exchanges. Visual aids should encourage advertisers — who are not yet encrypting their emails — to do so by fear of thrust decrease on customer and prospects.

Keep on highlighting SPF and DKIM authentication procedures.

The other big enhancement implemented by Google is the modification of the sender’s icon when experimenting email-authentication issues (using SPF and DKIM). On the other hand, given the stringent policy applied by Gmail regarding authentication matters, it is quite rare to bump into this icon with a question mark, since emails who fail authentication end up quickly in the spam folder.


DeliverNow migrating all clients to TLS.

Having acknowledged these measures, DeliverNow started as of several weeks ago the migration to TLS of all its PowerMTA clients in order to render their emails completely TLS-friendly. Feel free to contact us if you want some hand-in-hand advice regarding this topic.

DMARC: 3 years and a half from now. What much has been done?

DMARC-2015-logo-small-202x110It has been almost 4 years since the DMARC procedures were first launched, as well as our first publication of an article regarding this topic. As a reminder, DMARC is a Spoofing-fighting validation system. It relies on technologies such as SPF and DKIM, empowering email senders to provide receivers servers with the procedures of what actions are to be deployed if authentication has not been achieved. DMARC allows the original sender to remain updated about any failure occurring during the SPF and DKIM authentication mechanisms.

If you want to know the technical details about the DMARC mechanism, please read our article dating back to 2012.

DMARC deployed by ISPs.

Before talking about advertisers’ techniques, we will aim to explain how do ISPs and Webmails operate. This can be split into 2 major problematics.

On one hand, we find DMARC deployment on ISPs and Webmails outgoing emails. In April 2014, Yahoo! published the DMARC ‘Reject Policy’ (p=reject), through which it will reject any mail from if it came from a non-authored SMTP server.

This was a rather harsh measure, specially if we consider that plenty of users used to send emails from other email servers such as Outlook or Thunderbird, using their ISP’s SMTP connectors. In the same manner, the great deal of minor advertisers sending their newsletters through a routing platform, were no longer enabled to use a A few days later, AOL and many others continued to follow this path.

Here below a brief analyze of the most representative domains in France:

  • – v=DMARC1; p=none; – No reject policy, however it implements an error monitoring strategy.
  • – v=DMARC1; p=none; pct=100;;; fo=1 – No reject policy, however it implements an error monitoring strategy.
  • – No DMARC records.
  • – No DMARC records.
  • – No DMARC records.
  • – v=DMARC1; p=quarantine;,;,; rf=afrf; – Error quarantine and monitoring.

The hard works comes when it comes to determine DMARC management. For instance, it comes to evidence to think that the PayPal domain would request for a reject policy. However it would be also necessary that ISPs and Webmails receiving scam emails duly comply to PayPal procedures, leading to a final rejection of these emails.

Here below a list of what we currently know about the beforesaid ISPs:

  • Gmail : Emails are properly filtered according to the DMARC machanisms.
  • Hotmail/ : Emails are properly filtered according to DMARC machanisms.
  • Orange : No actions are deployed.
  • SFR : No actions are deployed.
  • Free : No actions are deployed.
  • : No actions are deployed.

According to this, it comes to evidence that the French market has been quite neglected — it is impossible to claim that the major open-public sending servers have the cutting-edge technologies. Work has not been relevant, other that the actions deployed at

DMARC, universally accepted by advertisers?

Among the enterprises deploying DMARC mechanisms we may find Bank of America, JPMorganChase, PayPal, LinkedIn and Facebook, the social medias and finances big boys who are often victims of Spoofing and Phishing.

So, what about France? Are public institutions operating properly? (who had never received an email signed on behalf of the CAF or the Tax Department offering money refunds). Have the major financial institutions taken actions to improve risk-management measures?

To sum up, here below a list of the institutions put under the spotlight:

  • Crédit Agricole – No DMARC record.
  • – No DMARC record.
  • – No DMARC record.
  • – No DMARC record (nor on the domain).
  • : No DMARC record.
  • – DMARC record in ‘none’ policy.
  • – No DMARC record.

We analyzed a great deal of domain names, however, it was sadly within the public institutions or within the banking-insurance arena that we found few domains protected.

With this in mind, the one possible question is if these major institutions — which are easy-target for phishing — are aware of their vulnerable situation? On the other hand, ISPs are also highly vulnerable to phishing. However, being aware of this condition, very little has been done to implement DMARC mechanisms.

DMARC implementation is a rather simple though. If the deployment of quarantines and reject policies might seem quite scary, it is not always the first step to start with. Most enterprises implement firstly a ‘none’ policy in order to enable alert monitoring, and it is only after a several-week analyze that the good policy is finally set up.

DeliverNow has implemented a DMARC-based email monitoring suiteIn such way, error reports sent by providers are analyzed and rendered available on our deliverability dashboards. Hence, we receive data from IP addresses that are not authorized to send emails using our customer’s domain name. We are empowered thus to detect any upcoming authentication issue on legitimate emails. An alert system enhances real-time pop-up alerts of any relevant problem.

Few of the latest DMARC updates:

Within the framework of the 35th M³AAWG General Meeting, we were informed about the new DMARC mechanisms deployed by some operators including:

  • As of early November, Yahoo! will first start to extend its reject policy to the and, domains, before doing so to some other domains in the upcoming months.
  • Google has announced the implementation of a more stringent policy in order to protect its domains. Gmail should move towards a reject policy as of June 2016.

Here below an example of the DMARC procedure deployed by DeliverNow’s deliverability monitoring suite.


DMARC: A new standard for domain protection

SMTP protocol is old and easy to use. It was invented before 1980 to enable email sending to private networks.
Thanks to the native SMTP protocol, it is possible to send an email using the desired sender address, but this option has also created electronic communication reliability issues as , in particular, the development of phishing campaigns. To address this problem, the operators have implemented a new concept allowing senders to authentify their messages.

Email authentication should ensure that senders are truly who they pretend they are.

In practice, it resulted in 4 standards:

  • SPF and SenderID, place a TXT record in the domain DNS to specify which ISPs are authorised to send emails from this domain. SPF being the common standard based on SMTP dialog MAIL FROM and the in the Reverse DNS domain of sending IPs. SenderID is the Microsoft version based on the “PRA” address domain for which Microsoft has patented the algorithm restricting its use.
  • DomainKeys andDKIM, which principle is based on a public/private key encryption system applied to some fields of the mail header. DomainKeys was invented by Yahoo and DKIM by the internet community, as for the previous case, DKIM is  gradually becoming the most popular .

But these schemes were missing something that would allow senders who correctly authentify their emails to inform receivers, so they can, on their side, filtrate more strictly the unauthenticated messages that often happen to be phishing. A group of important players like Google, Facebook, Microsoft, Yahoo and AOL joined together to develop a new scheme that would fill this gap, creating the DMARC standard which they tried to get approved from IETF.

DMARC (Domain-based Message Authentication, Reporting & Conformance) allow the advertisers to protect their brand et their domain, stating explicitly to the ISP how they want to process unauthenticated messages.

DMARC  allows the advertisers to protect their domains by clearly indicating to the ISP the policy they want to adopt regarding mails whose SPF and or/DKIM signatures have failed. Which, in case of a perfect implementation,will stop any phishing attempt on the advertiser’s domain for good.. In my opinion, this represents a significant step forwards in terms of domain protection and anti-phishing fight. Another DMARC interesting option for an advertiser is the possibility to receive reports from ISP that show the proportion of authenticated and unauthenticated messages sent to his domain. Which can give him an idea of the phishing volume on his domain.

As sender, in order to implement DMARC, you have to ensure that the correct SPF and DKIM implementation has been performed, then you have to publish a DMARC record in DNS as a TXT record for the zone

Practical example with domain:

Domain Type Record TXT « v=DMARC1; p=none; sp=none; pct=100;;; »

p= Processing policy based on the domain to be applied to emails for which authentication has failed. possible value: none, quarantine or rejected

sp= Processing policy based on subdomains to be applied to emails for which authentication has failed. possible value: none, quarantine or rejected

pct= percentage of mails to filter

rua= address where aggregated reports from ISP are received

ruf= address where authentication error reports will be received each time such an error occurs(AFRF)

There are additional attributes for DMARC registration, available in detailed specifications.

At this stage, only Gmail uses DMARC to protect its incoming messages, but you can expect more implementations this year, with , probably Yahoo, AOL and Microsoft.

Please visit DMARC site at:

See DMARC Comprehensive specifications:

See a simplified presentation on DMARC: