How to detect if your domains are being abused for phishing attacks

By on 7 Jul 2020

Category: Tech matters

Tags: , , ,

Blog home

At the Dutch Tax and Customs Administration, we’ve worked for years to build a strong relationship with taxpayers based on trust.

We believe improving and sustaining this relationship will help us to collect taxes in an improved and sustained way, and supporting initiatives such as #NoMorePhishing is one important way we continue to do this.

As a high-profile public-sector organization, we deal with phishing emails, like the one below, every day.

Van: Belastingdienst
Datum:23-08-2015 11:05:10 CEST
Onderwerp: Belastingaangifte 2014 Bij controle van onze
administratie hebben wij geconstateerd dat er een
betalingsachterstand is ontstaan van uw belastingaangifte 2014.
Wij hebben geprobeerd om het openstaande bedrag te incasseren,
helaas is dit niet gelukt op het rekeningnummer dat bij ons
bekend staat. Het huidige openstaande bedrag bedraagt 83,04
euro. U ontvangt ook een schriftelijke herinnering die vandaag
per post is verstuurd. Thans  verzoeken wij u vriendelijk om
dringend het openstaand bedrag van ...
Te betalen u kunt het bedrag overmaken naar bankrekeningnummer
NL62ABNA XXXXXXXXX tnv  belastingdienst" onder vermelding van
betalingskenmerk BTW038372293N Als u deze betaling heeft
voldaan kunt u de brief als niet verzonden beschouwen. Als u
binnen acht dagen deze rekening niet heeft voldaan dan
verzenden wij geen aanmaning en hierbij worden incasso kosten
gerekend Ik hoop u voldoende geinformeerd te hebben. Wij zien
uw betaling graag tegemoet en danken u voor uw medewerking.
Met vriendelijke groet,
Robert Versteegen
Directeur Belastingdienst
N.B. Dit is een automatisch verzonden e-mail, het is niet
ogelijk deze e-mail te beantwoorden.

Figure 1 — An example of a real-life phishing email. 

In the above real-life example, a targeted Dutch taxpayer received an email stating they had to pay a tax installment of €83.04 via a money transfer to a bank account (which was that of a money-mule) or extra collection costs would be charged.

Normally the first giveaway of this being a phishing email would be the email address, but in this instance it is the same as the Dutch Tax and Customs Administration — Because we had not yet implemented the standards below it was possible to misuse our email address.

By using best current practices such as RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email — we have developed a universally applicable technique to identify phishing attacks that are carried out under the guise of the Dutch Tax and Customs Administration. This technique — a precondition is access to DNS logging — can provide insights into where the phishing emails are sent from and to whom the phishing emails are sent.

In this post, we will discuss the freely available standards, policies and protocol we used, including STARTTLS, SPF, DKIM, DMARC, DANE and MTA-STS. We firmly believe that if these techniques are used everywhere, it will lead to a significant decrease in phishing emails.


STARTTLS is a method of upgrading a plain text communication channel to a secure, encrypted communication channel. It makes it possible to create a secure, encrypted Simple Mail Transfer Protocol (SMTP) connection between mail servers.

STARTTLS makes it possible to create a secure, encrypted SMTP connection between mail servers.
Figure 2 — STARTTLS makes it possible to create a secure, encrypted SMTP connection between mail servers.

However, there is a serious issue with STARTTLS — it is vulnerable to Man-in-the-Middle (MITM) attacks. This issue can be mitigated by using either DNS-Based Authentication of Named Entities (DANE) for SMTP or SMTP Mail Transfer Agent Strict Transport Security (MTA-STS).


DANE is an alternative to Public Key Infrastructure (PKI) Certificate Authorities. It complements Domain Name System Security Extensions (DNSSEC) by which you must implement DNSSEC before using DANE. Without DNSSEC there is no DANE.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using DNSSEC.
Figure 3 — DANE is an Internet security protocol to allow X.509 digital certificates, commonly used for TLS, to be bound to domain names using DNSSEC.

As a standard, it allows you to associate a fully qualified domain name (FQDN) with an X.509 certificate securely making a Transport Layer Security (TLS) connectionless, vulnerable to MITM attacks. 

In the case of SMTP, the authoritative mail servers for a domain are stored in mail exchanger (MX) records. The X.509 certificate of the mail server is also stored in the DNS zone file as a TLS Authentication (TLSA) record. By comparing the X.509 certificate used during the STARTTLS negotiation with the one stored in the DNS zone file, the sending email server can detect MITM attacks. 

DANE for SMTP solves the problem that TLS is entirely optional with SMTP. Because of DNSSEC, self-signed X.509 certificates may be used.


MTA-STS can be seen as a way to implement HTTP Strict Transport Security (HSTS) for SMTP. 

SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers.
Figure 4 – MTA-STS is a mechanism that makes it possible to indicate that STARTTLS should be used.

It is a mechanism to declare the ability to support TLS for SMTP and to specify whether sending mail servers must refuse to deliver an email to an authoritative receiving mail server that does not offer TLS with a trusted X.509 certificate. 

MTA-STS solves the problem that TLS is entirely optional with SMTP. With MTA-STS, DNSSEC is not required but is, of course, highly recommended. A valid X.509 certificate is required. Self-signed certificates are not allowed to be used in combination with MTA-STS. As mentioned before, DANE allows users of self-signed certificates, but a full DNSSEC implementation is required. 

SMTP TLS Reporting is also a relatively new standard. It defines a reporting mechanism and a format by which sending mail servers can share information about the TLS connection with the recipient domain. The reporting schema covers misconfiguration in your MTA-STS implementation, failures in email routing, DNS resolution, TLS negotiation and policy validation errors for both DANE and MTA-STS. Recipient domains can then use the information to both detect unintentional misconfigurations and also potential attacks. One of the potential attacks could be a MITM attack.


Sender Policy Framework (SPF) is a method for email authentication and is designed to detect fraudulent mail servers. SPF allows the recipient’s mail server to check that an authorized mail server sent the email.

Sender Policy Framework (SPF) is designed to detect fraudulent mail servers.
Figure 5 – SPF is designed to detect fraudulent mail servers.

It is a robust and safe protocol. Nevertheless, when you implement SPF incorrectly the receiving mail server cannot query the DNS server for a list of authorized mail servers, meaning your domains can be abused for sending phishing emails and even worse, you will lose legitimate emails. 

Furthermore, it is possible to add macros to the SPF record. 

SPF with macros

SPF has a rarely used feature to implement an advanced email track-and-trace system based on configuring macros in your SPF records. 

Macros are used in DNS records by wrapping them between delimiters. For SPF, there are several macros defined — see RFC 7208 for the full list and instructions on how to implement them. 

By using macros in the SPF TXT resource records, you get visibility on:

  • %s Complete sender email address
  • %h HELO/EHLO of the sending email server
  • %l Local-part of the sending email address
  • %o Domain-part of the sending email address
  • %i IP address of the sending email server

Two important things to note when you’re %l or %s:

  1. You will be collecting and storing sensitive information in the resolver logs, including valid email addresses that may cause privacy issues. There is work in progress to overcome this privacy issue. RFC 7816 is about DNS Query Name Minimization of resolver logs. This RFC was published in March 2016. However, the implementation rate is shallow. So please ask your Internet Service Providers (ISPs) to implement RFC 7816. 
  2. You will have to either create a DNS record for every valid email address or use a wildcard. However, the wildcard doesn’t work well in combination with DNSSEC.

Below are two example implementations of SPF with macros:

  •   The SPF redirect resource record: IN TXT "v=spf1"

The SPF exists resource record and macros: IN TXT "v=spf1 \
      exists:_i.%{i}._h.%{h}._o.%{o} -all"\ IN A\ IN A 

As mentioned, this functionality is used rarely on the Internet — according to research done by and, less than 0.1% of 240M domains have implemented macros in their SPF record — but is compelling. Below is how we implemented it as part of our phishing identification technique.

How we’ve implemented SPF macros

First, we created a SPF redirect record — we recommend using a redirect modifier from a management perspective. With this redirect modifier, it is possible to share a SPF policy between multiple domains, and changes to the SPF policy only need to be implemented in one place. 

The redirect modifier points to The DNS record is a SPF record with macros. In our case, the macros represent the IP address of the sending mail server, and the HELO string and domain name of the sender email address. 

Next, for each mail server, two A records have to be created with the macros filled in. In our case, the mail server has the IP address and a HELO string of The second A record is needed because several mail server implementations use the HELO string derived from the SMTP headers, and in that case, the HELO string is

Below is a diagram showing the flow in the GOOD situation.

SPF with macros – a GOOD situation.
Figure 6 — SPF with macros — a GOOD situation.

It shows:

  1. Mail server A sending an email to Mail server B.
  2. Mail server B requesting the SPF record of the domain name belonging to the sender email address.
  3. DNS server A will then send a DNS response containing the SPF record.
  4. Mail server B will fill in the SPF macros.
  5. The next DNS query will be done by Mail server B. This DNS query contains the expanded A record.
  6. When there is an A record configured in the DNS zone, the DNS response will be an IP address. This should be interpreted by Mail server B as an SPF PASS. Any valid IP address is OK.

For comparison, Figure 7 shows the flow in a BAD situation.

SPF with macros – a BAD situation.
Figure 7 — SPF with macros — a BAD situation.

In this case, the perpetrator sends an email on behalf of The same flow as in the GOOD situation will be executed.

However, in this case, there is no match against an A record in the DNS zone file. The DNS result will be an NXDOMAIN. Mail server B must handle an NXDOMAIN as SPF FAIL because it knows that the mail server of the perpetrator is not an authorized mail server of domain This email should be handled as SPAM. The DNS queries and responses are stored and can be ingested in your log management and SIEM tooling for further processing.


Domain Keys Identified Mail (DKIM) is a method for detecting forged sender addresses in emails, a common technique used in phishing attacks.

Domain Keys Identified Mail (DKIM) detects forged sender addresses in emails.
Figure 8 — DKIM detects forged sender addresses in emails.

DKIM signs the body and selected parts of the SMTP header with a digital signature. The digital signature itself is transmitted in the DKIM-Signature header. Namespaces are available in the form of selectors, and you can have multiple DKIM signatures. The sender must use the secret key of the DKIM key pair to sign the email, and the receiver must use the public key to validate the digital signature.


Domain-based Message Authentication, Reporting and Conformance (DMARC) is designed to protect against direct domain spoofing.

Domain-based Message Authentication, Reporting and Conformance (DMARC) protects against direct domain spoofing.
Figure 9 — DMARC protects against direct domain spoofing.

The policy allows a sender domain to indicate that SPF and DKIM protect their emails. Furthermore, it tells a recipient what to do if neither of those authentication methods passes. It also specifies how the recipient’s mail server can report to the sender domain about how the policy is executed from the recipient side. 

We use the reporting feature of DMARC heavily in the implementation we have done in Splunk; you can ingest the DMARC report also in the ELK stack for further processing.

Be aware of the RUF-tag

A RUF report can contain a complete copy of the rejected email in Abuse Reporting Format and can lead to privacy issues.

Security is everyone’s responsibility, so do your part

As mentioned in the beginning, we firmly believe that if these techniques are used everywhere, it will lead to a significant decrease in phishing emails.

As such, we encourage everyone to talk to their ISP and mail provider and convince them to implement these standards. 

In the Netherlands: 

  • We are reaching out to ISPs to urge them to implement the standards in their infrastructure.
  • Government organizations need to comply with a number of these standards specified in the Dutch Standardisation Platform or explain the list. And yes, there are ways to avoid broken mailing lists and forwarding issues.
  • SIDN, which is the registry organization of the NL top-level domain, has a financial incentive that a registrar gets a discount on a domain when they implement DMARC and STARTTLS. DMARC gives a discount of €0.16 and STARTTLS €0.04. The wholesale price of an NL domain is €3.40 per year.

Further, we have created a Splunk Dashboard, which gives you visibility over these standards. There is also a wizard for generating the correct DNS records. The wizard can be found in the Splunk App we’ve also created.

These and other helpful tips will be found on and our soon to be launched website:

Finally, please reach out to us if you have any questions about our implementation and need advice about protecting you and your users from phishing.

Contributors: Arnold Hölzel, Senior Security Consultant, SMT.

Karl Lovink is the SOC technical lead of the Dutch Tax and Customs Administration.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *