Email validation and security explained
SPF, DKIM, DMARC, and MTA-STS
Email remains one of the most common ways attackers impersonate organisations, distribute malware, and carry out fraud. Many attacks rely not on technical exploits, but on abusing trust in familiar domain names.
To address this, several email validation and security mechanisms exist, including SPF, DKIM, DMARC, and MTA-STS. These technologies work together to help receiving mail servers decide whether an email claiming to come from a domain should be trusted.
This guide explains what each mechanism does, how they relate to one another, and what it means in practice when they are only partially implemented.
Why email validation exists
When an email is sent, the receiving server cannot automatically trust the sender address shown to the user. Without validation, anyone can send an email that appears to come from any domain.
Email validation mechanisms exist to answer three key questions:
-
- Is this server allowed to send email for this domain
- Has the message been altered in transit
- What should happen if validation fails
Each mechanism addresses a different part of that problem.
What SPF does
SPF, or Sender Policy Framework, allows a domain owner to specify which mail servers are authorised to send email on behalf of their domain.
This information is published in DNS records.
When an email is received, the receiving server checks whether the sending server is listed as authorised. If it is not, the message may be marked as suspicious or rejected.
SPF alone does not authenticate the visible From address that users see. It only checks the technical sending path. Because of this, SPF must be combined with other mechanisms to be effective.
What DKIM does
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing email.
This signature allows receiving servers to verify that:
-
- The message was authorised by the sending domain
- The content has not been altered during delivery
DKIM relies on public keys published in DNS. If the signature does not validate, the message fails DKIM checks.
DKIM provides message integrity, but on its own it does not instruct receiving servers what to do when validation fails.
What DMARC does and why policy matters
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, ties SPF and DKIM together and adds policy and reporting.
DMARC allows a domain owner to state:
-
-
Whether SPF or DKIM must pass and align with the visible From address
-
What receiving servers should do if authentication fails
-
Where reports about email authentication should be sent
-
DMARC policy states
-
-
p=none
Used for monitoring only. It does not block or divert messages and provides no protection against domain impersonation. -
p=quarantine
Instructs receiving servers to treat failing messages with suspicion. Behaviour varies by provider and does not reliably prevent spoofing. -
p=reject
Instructs receiving servers to reject failing messages outright. This is the only policy state that actively prevents domain impersonation.
-
An important distinction
DMARC was created to prevent attackers from sending email that appears to come from your domain. That goal is only fully achieved when DMARC is set to reject.
Policies such as none or quarantine are transitional deployment states. They are useful while identifying legitimate senders and correcting alignment issues, but they do not provide full protection.
Why many organisations do not reach DMARC reject
Despite its importance, many organisations stop short of enforcing DMARC.
Common reasons include:
-
-
Legacy systems sending email without proper authentication
-
Third-party services not correctly aligned with the domain
-
Incomplete SPF or DKIM configuration
-
Fear of disrupting legitimate email delivery
-
These concerns are valid during deployment, but remaining permanently in a non-enforcing state leaves the domain open to abuse.
What MTA-STS is used for
MTA-STS, or Mail Transfer Agent Strict Transport Security, protects email while it is being transferred between mail servers.
It does this by:
-
-
Enforcing encrypted connections using TLS
-
Preventing downgrade attacks during delivery
-
MTA-STS does not authenticate senders or prevent spoofing. It addresses a different risk, namely interception of email in transit.
Because it operates independently of SPF, DKIM, and DMARC, it is often misunderstood or incorrectly assumed to provide the same protection.
How DNS fits into email security
All of these mechanisms rely on DNS.
DNS records are used to publish:
-
-
SPF authorisation lists
-
DKIM public keys
-
DMARC policies and reporting addresses
-
MTA-STS policies
-
Misconfigured or incomplete DNS records are one of the most common causes of email authentication failure.
Changes to DNS should always be approached carefully, as errors can affect email delivery across an entire domain.
Using the NCSC email security checker
The UK National Cyber Security Centre provides a free tool to check email security configuration.
You can access it here:
https://checkcybersecurity.service.ncsc.gov.uk/email-security-check/form
The checker identifies whether SPF, DKIM, DMARC, and related records are present and highlights common weaknesses.
It is important to understand that this tool:
-
- Reports on configuration
- Does not fix issues
- Does not guarantee full protection if DMARC is not enforced
A passing result does not necessarily mean a domain is protected against impersonation.
When to seek help
Email security mechanisms interact with DNS, mail providers, and third-party services. Changes made in isolation can unintentionally disrupt legitimate email flow.
If reports indicate alignment issues, or if DMARC enforcement is being considered, it is usually advisable to review the full email ecosystem rather than making piecemeal changes.
Evening Computing can assist with assessing email validation and security settings and advising on safe, staged improvements where appropriate.