andras marton personal site
~/ | ctf | projects

Secure Non-Email Sending Domains

Written: 2021/10/07

Not all sites and domains will be utilized to send emails, yet the possibility to use the domain to send emails is left open when the necessary DNS records are not set, which would help prevent spoofing. These records can help close the door on a malicious actor from being able to use your domain to carry out phishing and spam attacks.

The headers in question are:

This article only covers configuring these records to prevent spoofing on non-email sending domains as opposed to drilling down on how to set up these records to work with and help protect domains, which are utilized for email delivery.

Scenario: No records

For this example, I am going to use the domain It currently does not have any of the above mentioned records, which we can verify with a quick dig query:; echo -e "\n==Checking for email related DNS records=="; echo -e "SPF Record:"; dig  TXT +short; echo -e "\nDKIM Record:"; dig TXT +short; echo "\nDMARC Record:"; dig TXT +short

==Checking for email related DNS records==
SPF Record:

DKIM Record:

DMARC Record:

To note: With DKIM records, a unique selector is used, which will serve as the DNS record as well. In the above example, the selector is called test.

To demonstrate sending an email from a third party source and spoofing, I have created a simple PHP script to use the mail() function:

$to = '[email protected]';
$subject = 'This is a test';
$message = 'There are no SPF, DKIM or DMARC records and this email will be delivered.';
$headers = 'From: [email protected]' . "\r\n" .
	'Reply-To: [email protected]' . "\r\n" .
	'X-Mailer: PHP/' . phpversion();

mail($to, $subject, $message, $headers);

I tested this with both ProtonMail and GMail:

GMail did not flag this as spam, however did flag that it was sent via a different mail server. However this may not necessarily be something thatthe recipient would either check or even realize when opening a possible phishing email.

ProtonMail on the other hand did not even flag that there was a different mail server in the middle and no indication that this may be a malicious email.

Hitting Reply on both of the above providers would accurately fill out the return address of [email protected]. As we can see in this scenario, a malicious actor could very easily spoof emails from your site and carry out phishing attacks.

Scenario Two

In this scenario, we are going to create the three records, SPF, DKIM and DMARC on the DNS level. You will need access to the DNS records of your domain in order to accomplish this.

SPF The hostname will vary between DNS provider. Some will accept @ to signify the root domain or you will need to enter the domain itself. Since we are not spacifying any IPs or domains for our mail servers between the two values below, the emails will fail the SPF record.

Type: TXT
Hostname: @ or
Value: v=spf1 -all

DKIM We will be using a wildcard for DKIM records to capture any record a receiving mail server may check.

Type: TXT
Hostname: *._domainkey
Value: v=DKIM1; p=

DMARC A simple policy is used to check all emails (pct=100), and we will be rejecting all emails which fail either SPF or DKIM (p=reject).

Type: TXT
Hostname: _dmarc
Value: "v=DMARC1; p=reject; pct=100; sp=reject; adkim=s; aspf=s;"

Once setup, we can use the same script we did earlier to check that they are coming through on the DNS level:; echo -e "\n==Checking for email related DNS records=="; echo -e "SPF Record:"; dig  @ TXT +short; echo -e "\nDKIM Record:"; dig TXT +short; echo "\nDMARC Record:"; dig @ TXT +short

==Checking for email related DNS records==
SPF Record:
"v=spf1 -all"

DKIM Record:
"v=DKIM1; p="

DMARC Record:
"v=DMARC1; p=reject; pct=100; sp=reject; adkim=s; aspf=s;"

Re-sending the test emails yield us with a slightly different result. GMail has outright blocked the email due to the DMARC policy in place and checking the mail server logs, we can confirm this:

On the other hand, ProtonMail allowed the email through and delivered it, however adding a noticable banner, flagging the email as possible spam due to an authentication requirement. They provide additional information on this page:


As seen with ProtonMail, while a banner is added and the email is flagged as spam, it still gets through. This is because while the SPF, DKIM records and DMARC policy tell a receiving web server what to do and help authenticate the email, it is still down to the mail server to act on the information it receives.

However as seen, these steps can help either block or flag emails coming from your domain, when there should be no emails being sent out.