Email spoofing – A Bigger Problem Than You May Think

The first thing to note is that unless you have bought a domain and logged on to its administrator functions to set some of the configurable items away from the defaults that most domain hosts leave in place, its fairly safe to say that there will be certain records in the DNS (Domain Name System) settings that you should focus on to ensure that the domain your controlling has some unique features. The most obvious setting, but one often ignored, is the domain admin password which could be set to something as unique as “password”!

We are going to focus down in this blog on the opportunities bad actors find in domain records related to email transmission and receipt, so look for our other blogs dealing with security to find out more about more general security practices.

You can find our free reference guides here:

Guides – Vissensa IT Services

The holy trinity of email authentication

In the arsenal of every IT systems administrator should be the understanding of how three powerful components, that are present in every domain, can be used in conjunction to lock down how email systems can operate and identify the legitimate email traffic from the spoofing attacks.

These three components play a pivotal role in mitigating this risk. Together, they help verify sender identity, ensure message integrity, and protect domain reputation. Implementing these authentication mechanisms is not only important for reducing the risk of email spoofing, but also for fostering trust and security in the email communication ecosystem. Organisations should prioritise the adoption of SPF, DKIM, and DMARC to safeguard their email infrastructure and the trust of their recipients.

Let’s discuss SPF, DKIM and DMARC at a high level before delving into how to implement them in a DNS record.

SPF (Sender Policy Framework)

SPF is a key email authentication mechanism used to verify a sending mail server’s identity by checking the DNS records of the sender’s domain. It does this by allowing a domain owner to specify which mail servers can send emails on their behalf. The result is when an email recipient’s server receives an email, the sending servers SPF record is checked to verify it’s on the authorised list. If not, it may treat the email as suspicious or reject it altogether, which may not be the desired outcome. This is where DKIM and DMARC act in consort with the SFP mechanism to focus the scrutiny down further.

Implementing SPF will help reduce the likelihood of legitimate emails being marked as spam or phishing attempts as the recipient servers can use SPF records to differentiate between authorised and unauthorised senders, improving email deliverability.

DKIM (DomainKeys Identified Mail)

DKIM is the second part of the email authentication mechanism that digitally signs the headers of email messages. This is an important component as intercepting emails and modifying the header records is a tired and tested approach by the bad actors to infiltrate an organisations email ecosystem. By using cryptographic signatures, DKIM verifies that an email message has not been tampered with during transmission or altered in any way.

DKIM provides a strong form of sender authentication. It associates the email with the domain from which it claims to originate, making it difficult for malicious actors to impersonate trusted senders.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC is the third leg of the holy trinity of email authentication, acting like an umbrella policy that works in combination with SPF and DKIM, allowing domain owners to specify how email authentication should be handled for their domain. Importantly, DMARC also reports back to the domain owner information regarding authentication failures against their email servers and domains so attack vectors can be identified and mitigation put in place to safeguard users from further attack.

Key to any preventative measure is usability in the real world, if it’s too difficult or too restrictive, human behaviour shows that we will just reject or turn off even the things that are there to keep us safe.

This is where DMARC policy enforcement saves the day. It enables the system admins, or owners of the email domain (DNS), the ability to specify policies for handling emails that fail SPF and DKIM checks. So, it’s not a case of rejecting a legitimate email that hasn’t been verified but that could be vitally important to the business or individual, the policy could be configured to monitor emails and either quarantine or reject if positively identified as a known threat. Control on how unauthenticated or suspicious emails are handled remain the domain owner’s prerogative.

Implementing these authentication mechanisms is not only important for reducing the risk of email spoofing, but also for fostering trust and security in the email communication ecosystem. Organisations should prioritise the adoption of SPF, DKIM, and DMARC to safeguard their email infrastructure and the trust of their recipients.

Let’s move on to how to make use of these records in your email system.

Modifying SPF, DKIM and DMARC records

Firstly, it’s important to understand that modifying any records within your Domian or DNS (Domain Names System) can severely damage the integrity of the domain and should only be carried out by people who have knowledge of these systems. It will require access to the domain administrator user logon and password to make changes to the SPF, DKIM and DMARC records.

Modifying SPF Records:

Sender Policy Framework (SPF) records specify which mail servers are authorised to send emails on behalf of your domain. To modify SPF records:

1. Log in to your domain registrar or DNS hosting provider’s control panel. This is where you manage your domain’s DNS settings.

2. Locate the DNS management section, usually under the domain settings or DNS settings.

3. Locate the existing SPF record. If you can’t locate one it is likely not to have been created and you will need to create a new TXT record with the following format:

– The SPF version identifier (v=SPF1)

– An include statement defining the email domain associated with this DNS (your domain-name.com)

– The mechanism to prevent all other non-listed servers to fail authentication (-all)

Only include the domain name, do not include https:// or any other protocol

An example of the syntax for the TXT files should look like this:

v-spf1 include:domain-name.com -all

If the SPF record needs to contain multiple authorised domains, then additional “include:” statements are added to the record separated by a space as shown in the example below:

v-spf1 include:domain-name.com include:domain-name.co.uk -all

NOTE: After saving the changes it may take a number of hours for DNS changes to propagate across the internet and become active.

Modifying DKIM Records:

DomainKeys Identified Mail (DKIM) uses cryptographic signatures to verify the authenticity of email messages. To modify DKIM records:

1. You will need logon and password access to your email service provider’s dashboard or control panel, where DKIM keys are generated and managed.

2. Generate a new DKIM key pair if necessary. This typically involves providing a selector name (a unique identifier for the key) and generating the public and private keys.

2.a If you need to generate a DKIM key par then follow the instructions here before continuing to step 3.

1. Locate the DKIM settings or email authentication settings within your email service providers dashboard and look for the option to generate a new DKIM key pair.

2. Click the generate or create button to generate the DKIM key pair. The system will generate both a public and private key to your DNS records as a TXT record which you will need for the Value statement in the format example below.

3. In your DNS management interface or dashboard, create a new TXT record with the following format.

Type: TXT
Name: Selector._domainkey.domain-name.com
Value: DKIM_public_key (this is the key generated in step 2 above)

4. Save the changes to your DNS records

NOTE: After saving the changes it may take a number of hours for DNS changes to propagate across the internet and become active. It is important that the DNS record is checked to ensure the DKIM record has been published correctly.

Once the DKIM key pair is generated and the public key is added to your DNS records, your domain’s outgoing emails will be signed with the private key, and recipients’ email servers can use the public key to verify the authenticity of those emails.

3. If you have located an existing DKIM record it can be modified using the same process as in step 2a.

Type: TXT Name: selector._domainkey.domain-name.com Value: DKIM_public_key Replace “selector" with your chosen selector name, “domain-name.com" with your actual domain name, and “DKIM_public_key" with the DKIM public key generated in step 2.

4. Again, save the changes in your DNS settings and wait for them to propagate across the internet.

Modifying DMARC Records:

Domain-based Message Authentication, Reporting, and Conformance (DMARC) records specify how email receivers should handle messages that fail SPF and DKIM checks. To modify DMARC records:

1. Log in to your DNS hosting provider’s control panel.

2. Create a new TXT DNS record with the following format:

Type: TXT

Name: _dmarc.domain-name.com (this is your actual domain name)

Following this “name” statement that identifies the domain the DMARC is associated with the additional control statements are required or advisable.

p=quarantine or p=reject This is the policy you are creating. If quarantine (recommended to start with) is coded, then emails that do not pass the SPF/DKIM record vetting will be quarantined so that the sender’s details can be reviewed. The information is sent in an email report to a specified address than is defined in this record. If reject is chosen the messages are not forwarded or quarantined and the email will not be delivered. A separate failure report will also be issued to an email address as above. Start with p=quarantine for monitoring before moving to a stricter policy like p=reject when you’re confident.

rua=mailto:your_reports@email.com: This is the email address where aggregate DMARC reports will be sent. These reports provide information about email authentication results. Replace your_reports@email.com with the email address you wish to monitor emails from.

ruf=mailto:your_forensics@email.com: This is the email address where forensic DMARC reports will be sent. Forensic reports provide detailed information about individual email failures. Replace your_forensics@email.com with the email address you want these detailed reports to be sent.

fo=1: This instructs email receivers to send forensic reports for failed authentication. It’s recommended to set this to 1 to receive detailed information for troubleshooting.

adkim=r and aspf=r: These settings specify that both the DKIM (DomainKeys Identified Mail) and SPF (Sender Policy Framework) alignment must pass for DMARC to pass. Alignment ensures that the domains in DKIM and SPF records match the “From" header domain. (see SPF and DKIM information above).

The syntax of the DMARC TXT record should appear as in this example below:

Type: TXT

Name: _dmarc.domain-name.com

Value: v=DMARC1; p=quarantine; rua=mailto:email_reports@domain-name.com; ruf=mailto: forensic _email_reports@domain-name.com; fo=1; adkim=r; aspf=r;

NOTE: The p= value can be set to “reject” to reject rather than quarantine emails. The rua and ruf= should be set to an email in your system that you would like reports delivered to.

3. Save the changes to the DNS record. Again, remember that these records take time to propagate fully across the internet, so it is important that the successful completion of the record change is checked regularly until the changes have been confirmed.