Email validation and security explained

When an email arrives claiming to come from a domain, the receiving mail system has to answer a simple question.

Is this message genuinely allowed to use that domain, or is someone trying to make the email look as if it came from a trusted organisation?

Email validation and security controls help answer that question. SPF checks whether a sending server is authorised. DKIM helps show whether a message has a valid signature. DMARC tells receiving systems what to do when SPF or DKIM does not align with the visible sending domain. MTA-STS helps protect mail delivery between mail servers where supported.

These controls do not stop every phishing attempt, but they help reduce unauthorised use of a real domain and make it harder for attackers to misuse familiar names.

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.

This guide explains how email validation works, including SPF, DKIM, DMARC, and MTA-STS, how they relate to each other, and what they mean in practice. Use the links below to jump to the sections most relevant to your question.

• Why email validation exists
• What SPF does
• What DKIM does
• What DMARC does and why policy matters
• Detailed guide to DMARC records and policy settings
• Why many organisations do not reach DMARC reject
• What MTA-STS is used for
• Video explaining SPF, DKIM, DMARC and MTA-STS
• How DNS fits into email security
• Why DNS hygiene and monitoring still matter
• Using the NCSC email security checker
• When to seek help
• Need help with something covered in this guide?
• Further Guidance and Support

The sender name and address shown to a user are not enough to prove that an email is genuine.

Without validation, a message can be made to appear as if it came from a familiar organisation, supplier, manager, colleague or known contact. That can support invoice fraud, payment redirection, fake login alerts and other impersonation attempts.

Email validation exists because receiving mail systems need practical checks they can apply before deciding how much trust to place in a message.

The main questions are:

Is this sending server allowed to send email for this domain?

Has the message been signed in a way that links it to the domain?

What should happen if the checks fail or do not match the visible sending address?

SPF, DKIM and DMARC answer different parts of that problem. MTA-STS addresses a separate but related issue: how mail servers protect the connection used to deliver email between them.

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.

The safer approach is to treat DMARC enforcement as a staged process, where legitimate senders are identified, alignment problems are corrected, and stricter policy is applied only when the email environment supports it.

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.

In simple terms, SPF, DKIM and DMARC help receiving systems decide whether an email is authorised to use a domain. TLS and MTA-STS help protect the message while it travels between mail servers. Both are useful, but they are not the same control.

It shows how these email authentication and transport security mechanisms work together to reduce unauthorised use of a domain, support safer mail handling, and make direct domain spoofing harder where the receiving system enforces the relevant checks.

The video is provided as a visual reference to support the written explanation rather than a replacement for it.

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.

Because email authentication relies on DNS, wider DNS integrity and DNS security practices also matter.

Publishing SPF, DKIM, DMARC and MTA-STS records is only part of the work. Email security also depends on those records staying accurate as systems, providers, and third party services change over time.

DMARC works by bringing SPF and DKIM together and checking alignment against the visible From domain. In practice, that means changes to sending services, relay paths, forwarding behaviour, or DNS records can affect how mail is authenticated and how safely stricter policies can be enforced.

Where legitimate sending services are properly configured and aligned, DMARC can also support more reliable handling of genuine email by helping receiving systems distinguish authorised mail from unauthorised use of the domain.

This is why DMARC is not best treated as a record that is published once and forgotten. Reports should be reviewed, legitimate sending services should be confirmed, and DNS records should be checked periodically so that outdated or conflicting entries do not cause delivery problems or weaken protection.

This is also relevant for parked or non sending domains. Where a domain is not meant to send email, a stricter DMARC policy can help reduce the risk of domain spoofing, provided the wider DNS and mail configuration has been reviewed properly.

The UK National Cyber Security Centre provides a free tool to check email security configuration.

You can access it here:

Check your cyber security

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.

A configuration check is useful, but it is not the same as a full review of the organisation’s live email ecosystem. A domain may publish the expected records and still need further work on alignment, third party senders, forwarding behaviour, or older DNS entries before stricter DMARC enforcement is applied safely.

A guide can explain the issue and outline useful checks, but some situations need the actual device, account, service, website, network or supplier arrangement to be reviewed. Evening Computing can help review what is happening and advise on suitable next steps before changes are made.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

Related guide: DMARC records and policy settings

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
10 June 2026