Email Authentication Guide

Email authentication in plain English

Get SPF, DKIM and DMARC working together so your domain is harder to spoof and your legitimate email is more likely to land where it should.

In this guide you'll learn:

  • What SPF, DKIM and DMARC actually do (and what they don't)
  • A safe, staged approach to implementation
  • The mistakes that cause breakage (and how to avoid them)
  • What "good" looks like for real-world organisations
Validate your SPFBook a free consultation
Email Authentication

Why the "From" address isn't proof of who sent an email

Email was designed in a simpler era. By default, any attacker can put your domain in the visible "From" address and try their luck.

Email authentication is the set of controls that let receiving mail systems validate:

  • Is this sender allowed to send for this domain? (SPF)
  • Has the message been tampered with, and is it signed by the domain? (DKIM)
  • If checks fail, what should the receiver do and where should the reports go? (DMARC)

It's not a silver bullet, authentication mainly stops direct domain spoofing, protecting your legitimate email from being marked as spam and gives you visibility and control.

Real-world examples: what happens when trust is easy to fake

Domain spoofing is a common attack vector, one that we see all the time, for example:

DPRK actors abusing weak DMARC to spoof trusted senders

In May 2024, a joint advisory from the FBI, NSA and U.S. Department of State warned that North Korean threat actors (linked to Kimsuky) were actively targeting domains with weak or non-enforced DMARC policies and then sending spearphishing emails designed to look like they came from legitimate, trusted sources (for example journalists, academics, or policy experts). The aim was simple: make the email feel credible enough that a target would open it, follow a link, or share sensitive information.

Why email authentication matters here:

If the impersonated domains had implemented DMARC properly and moved to enforcement (quarantine / reject) once legitimate senders were aligned, exact-domain spoofed emails would be far more likely to be quarantined or rejected by receiving systems that honour DMARC — forcing attackers toward noisier tactics (lookalike domains, compromised accounts, or non-email channels).

What "good" looks like (so you know what you're aiming for)

A healthy email authentication posture usually means:

  • SPF exists, is valid, and stays within lookup limits
  • DKIM signs all outbound streams that can be signed (including third parties where possible)
  • DMARC exists with reporting enabled with a reject policy (p=reject)
  • You can answer, quickly:
    "Who is sending as us?" "Is it authorised?" "What will receivers do if it fails?"

SPF, DKIM, DMARC: the simple mental model

SPF: "Which servers are allowed to send for this domain?"

SPF is a DNS record that lists which systems are permitted to send mail using your domain in the envelope-from / return-path sense.

SPF is good at:

  • Blocking obvious spoofing from unauthorised sending infrastructure

SPF struggles with:

  • Forwarding and indirect mail flows
  • Complexity and lookup limits
  • The fact it doesn't protect the visible "From" by itself

Common SPF mistakes

  • Multiple SPF records (only one should exist)
  • Too many include: statements (lookup limit trouble)
  • Using +all or ~all forever without a plan to tighten

💡 Tip: Validate SPF any time you change email providers, add marketing platforms, or adopt new ticketing systems.
Use our SPF Validator →

DKIM: "Was this message signed by the domain, and unchanged?"

DKIM attaches a cryptographic signature to the email. Receivers check the signature using a public key you publish in DNS.

DKIM is good at:

  • Proving the message wasn't altered in transit
  • Supporting DMARC alignment even when SPF is complicated (e.g., forwarding)

Common DKIM mistakes

  • Not signing all outbound sources (your main platform is signed, your marketing platform isn't)
  • Old selectors left behind (harder to manage and rotate keys)
  • DNS hosting limits causing truncated DKIM keys

DMARC: "How should receivers treat failures, and where should reports go?"

DMARC ties SPF and DKIM together and adds two critical things:

  1. Alignment: checks must relate to the domain in the visible "From"
  2. Policy: what to do when checks fail (none, quarantine, reject)

DMARC also gives you reporting so you can see:

  • Legitimate senders you forgot about
  • Misconfigurations
  • Unauthorised sources attempting spoofing

A safe, staged implementation plan (works for most organisations)

This is the approach we use when we want progress without breaking legitimate mail.

1) Inventory your domains and your senders

You need a list of:

  • All domains that send email (primary domain, subdomains, brand domains)
  • All platforms that send "as you" (M365, Mimecast, CRM, HR systems, ticketing, marketing tools)

DMARC only helps if you know what needs to keep working.

2) Get SPF to a clean, stable baseline

  • Ensure one SPF record
  • Remove obsolete includes
  • Prefer hard fail (-all) only when you're confident in coverage
  • Watch the lookup limit (common cause of intermittent deliverability problems)

3) Turn on DKIM signing everywhere you reasonably can

  • Enable DKIM on your primary mail platform(s)
  • Where third parties support DKIM, switch it on
  • Use a sensible selector strategy and plan for key rotation

Enable DKIM on your primary mail platform(s):

4) Publish DMARC in monitoring mode first

Start with a policy that gathers insight:

  • p=none + rua= reporting address

Run this long enough to see real traffic patterns (often 2–4 weeks).

Example DMARC policy for monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Replace dmarc-reports@yourdomain.com with your RUA aggregator email address.

5) Fix alignment issues (this is where most time goes)

Typical fixes:

  • Third-party platforms sending with your domain but failing SPF alignment
  • DKIM not enabled on a marketing system
  • Subdomains behaving differently than you assumed

6) Move to enforcement gradually

Progression we usually recommend:

p=none → p=quarantine → p=reject

We generally recommend avoiding intermediate pct= values (e.g. pct=25/50/75). They only apply quarantine/reject to a subset of failing messages, which means some spoofed mail can still get through, and the mixed outcomes can make it harder to judge the real-world impact of moving to full enforcement.

The deliverability reality: mailbox providers increasingly expect authentication

Google's bulk sender requirements (effective February 1, 2024) explicitly require authentication controls like SPF and DKIM (and a DMARC policy for bulk senders), and Yahoo introduced similar standards. If you send at volume and aren't meeting these requirements, deliverability issues are a predictable outcome.

What we see most often in real-world environments

Most customers we work with usually have one or more of these situations:

  • Multiple mail streams (M365 + Mimecast + third parties) and no single owner
  • Configuration drift over time: old includes, legacy domains, forgotten sending systems
  • Acquisitions / domain changes creating new subdomains and shadow IT mail flows
  • Parked (non email sending) domains that have no email authentication records

The fix is rarely "add a record and forget it". It's closer to email operations hygiene: inventory, baseline, monitor, enforce, review.

A customer example (anonymised)

A UK-based organisation (c. 1,800 users) had a DMARC policy set to quarantine for years, but with no rua= reporting address defined. In practice, they had no visibility into how much legitimate email was being quarantined, or which sending systems were causing it.

We helped them:

  • Select a DMARC reporting approach that matched their objectives and budget
  • Update their DMARC record so reports were collected and analysed
  • Confirm that 38% of their outbound email was failing DMARC and being quarantined, creating deliverability issues they weren't aware of
  • Identify the misconfigured sending systems and define the remediation actions
  • Reduce DMARC failures from 38% down to 1.8% over a six-week period, improving deliverability and restoring confidence in outbound email

A practical checklist you can use today

Baseline checks

  • SPF record exists, is valid, and there is only one
  • DKIM enabled on primary mail platform
  • DMARC record exists and includes rua= reporting
  • You know who receives and reviews DMARC reports

Before moving to enforcement

  • All major third-party senders either DKIM sign or use aligned SPF
  • Subdomains are accounted for (or explicitly set via DMARC sp=)
  • You've reviewed at least 2–4 weeks of DMARC aggregate reports
  • You have a rollback plan for unexpected breakage

FAQs (quick answers)

Do I need all three: SPF, DKIM and DMARC?

Yes, in practice. SPF and DKIM provide the signals; DMARC provides alignment, policy and reporting.

Will DMARC stop phishing?

It will reduce direct spoofing of your domain. It won't stop lookalike domains or compromised accounts. Pair it with good controls for phishing resilience (user training, reporting mechanisms, secure access).

What's the safest DMARC policy to start with?

p=none with reporting enabled. It gives visibility before you enforce.

How long does it take?

If you have a simple setup: days.
If you have many third-party senders and multiple domains: typically weeks, because you're discovering and fixing real operational complexity.

Where Cydaura can help

If you want authentication that holds up in the real world (not just "a record that exists"), we can help you:

  • Inventory mail streams and rationalise ownership
  • Fix SPF/DKIM issues without breaking legitimate mail
  • Move to DMARC enforcement safely, with ongoing review
Book a free consultationSPF Validator