Email Authentication & Security: A 101 Guide (And How We Manage It For You)

Email Authentication & Security: A Complete Guide

Understand SPF, DKIM, DMARC, MTA-STS, and BIMI — and why they matter for your organisation's email security and deliverability.

Quick check: Want to see where your domain stands right now? Run a scan with our free domain scanner: https://www.wickedsick.com/domain-scanner

Why email authentication matters

Email is still the backbone of business communication, but it was never designed with modern security in mind. Without proper authentication, anyone can send messages that appear to come from your domain — opening the door to phishing, spoofing, and deliverability problems.

The good news is that a mature stack of open standards now exists to address this. When implemented correctly, these protocols dramatically improve both security and deliverability. This guide covers the five key technologies and how they work together.

SPF — Sender Policy Framework

What it does

SPF acts as a guest list for your domain's mail servers. You publish a DNS record that declares which servers are authorised to send email on your domain's behalf.

How it works

When a receiving mail server gets a message claiming to be from your domain, it checks whether the sending server's IP address appears in your SPF record. If the IP is listed, SPF passes. If not, the receiving server can reject the email, quarantine it to spam, or flag it as suspicious.

Why it matters

• First line of defence against basic spoofing — without SPF, anyone can trivially send email "from" your domain
• Protects your brand reputation and reduces successful phishing attempts

Limitations to be aware of: SPF only checks the envelope sender (MAIL FROM), not the visible "From" address that users see in their inbox. It also breaks when emails are forwarded, because the sending IP changes. SPF is necessary, but not sufficient on its own.

DKIM — DomainKeys Identified Mail

What it does

DKIM uses cryptography to prove that an email genuinely came from an authorised server and hasn't been altered in transit.

How it works

When your mail server sends an email, it creates a digital signature of selected headers and content using a private key, then adds that signature to the email headers. The corresponding public key is published in your DNS. The receiving server fetches the public key and verifies the signature — if it matches, DKIM passes. If the content has been altered or the signature is invalid, DKIM fails.

Why it matters

• Proves the message hasn't been tampered with in transit
• Survives email forwarding (unlike SPF)
• Contributes to your domain's long-term reputation with mailbox providers
• Especially important for transactional emails, receipts, and invoices where tampering could cause real-world damage

DMARC — Domain-based Message Authentication, Reporting & Conformance

What it does

DMARC ties SPF and DKIM together by adding two critical capabilities: alignment and policy enforcement.

How it works

Alignment — DMARC checks whether the domain in the visible "From" header matches the domain authenticated by SPF or DKIM. This closes the gap where an attacker could pass SPF with their own infrastructure while spoofing your domain in the "From" field.

Policy — You publish a DMARC record in DNS that tells receiving servers what to do when authentication fails:

• p=none — Monitor only; collect reports but take no action on failures
• p=quarantine — Treat failures as suspicious (typically routed to spam)
• p=reject — Block failing messages entirely

Reporting — DMARC sends you daily XML reports showing who is sending email using your domain, whether they're passing or failing SPF/DKIM, and what actions receiving servers are taking.

Why it matters

• Closes the alignment gap that SPF and DKIM leave open
• Gives you visibility into your entire email ecosystem
• Provides a clear path from monitoring to full enforcement
• Major mailbox providers (Google, Microsoft, Yahoo) now effectively require DMARC for bulk senders

MTA-STS — Mail Transfer Agent Strict Transport Security

What it does

MTA-STS ensures that email sent to your domain is encrypted in transit using TLS — and prevents attackers from silently downgrading the connection to unencrypted delivery.

How it works

Standard email TLS is opportunistic: servers will use encryption if available, but fall back to plaintext if it isn't. MTA-STS changes this by letting you publish a policy that says: "You must use TLS to deliver email to my domain, and here's what a valid certificate looks like." Compliant sending servers fetch and cache your policy, then refuse to deliver over unencrypted or invalid connections.

Why it matters

• Prevents man-in-the-middle and downgrade attacks on email in transit
• Particularly important for sectors handling sensitive information (healthcare, finance, legal)
• Demonstrates a serious commitment to security to partners and regulators

BIMI — Brand Indicators for Message Identification

What it does

BIMI lets you display your brand logo next to your emails in supported inboxes — but only once you have DMARC at enforcement level (p=quarantine or p=reject).

How it works

You publish a BIMI record in DNS that points to your logo (in a specific SVG format) and optionally obtain a Verified Mark Certificate (VMC) from an authorised certificate authority. Supported mailbox providers then verify your DMARC status, retrieve your logo, and display it alongside your messages.

Why it matters

• Gives recipients a visual way to confirm an email is genuinely from your brand
• Makes phishing harder, even for attackers who pass basic checks
• Improves recognition, trust, and engagement in the inbox
• Acts as an incentive for maintaining strong DMARC enforcement

How these protocols work together

Each protocol addresses a different part of the email security picture. Together, they form a comprehensive framework:

• SPF — Verifies that the sending server is authorised for your domain
• DKIM — Proves the message hasn't been tampered with and is cryptographically signed
• DMARC — Enforces alignment between SPF/DKIM and the visible "From" address, with policy and reporting
• MTA-STS — Encrypts email in transit and prevents downgrade attacks
• BIMI — Rewards proper authentication with brand visibility and user trust

For senders, this stack protects your brand, improves deliverability, and reduces successful impersonation. For recipients, it provides a powerful filter against phishing and spoofing. This is now the baseline expectation for any organisation sending email at scale.

Common challenges with implementation

While the standards themselves are well-defined, implementing them properly is where most organisations run into trouble:

• Technical complexity — SPF syntax is unforgiving, DKIM requires key management and DNS changes, and DMARC reports arrive as machine-readable XML by the thousand.
• Discovering all senders — Most organisations don't have a complete picture of every service sending email on their behalf: marketing platforms, CRMs, support desks, HR tools, billing systems, and more.
• Risk of breaking legitimate email — Move to enforcement too quickly and you can block real messages. Move too slowly and you stay exposed.
• Ongoing maintenance — Your email ecosystem isn't static. Vendors, tools, and sending services change constantly, and authentication records need to keep pace.
• Lack of visibility — Without the right tooling, it's difficult to know what's actually happening with your email authentication.

Tip: Start with DMARC in monitoring mode (p=none) and collect data for a few weeks before making any enforcement changes. This lets you discover all legitimate senders and fix issues before they affect real email delivery.

Getting started: a recommended approach

A typical path to full email authentication follows these stages:

1. Discovery & assessment (Month 1)

Implement DMARC in monitoring mode and collect data for 2–4 weeks. Use the reports to identify every service sending email on your behalf, review SPF/DKIM pass and fail rates, and flag any unauthorised senders or spoofing attempts.

2. Implementation & configuration (Months 2–3)

• SPF: Build and optimise your SPF records, manage the 10-DNS-lookup limit, and implement flattening where needed.
• DKIM: Generate key pairs, configure signing on your mail servers and third-party tools, and publish records in DNS.
• DMARC: Gradually move from p=none to p=quarantine to p=reject, testing at each stage.
• MTA-STS: Create and host your policy file, configure DNS, and monitor enforcement.
• BIMI: Prepare logo files to specification, obtain a VMC if appropriate, and publish your record.

3. Ongoing monitoring (Month 4 onwards)

Email authentication is not a set-and-forget project. Continuously monitor for new senders, policy failures, and configuration drift. Update records as you add or change email services, and track compliance against mailbox provider requirements.

Need a hand?

We offer managed email authentication as a service — from initial assessment through to full enforcement and ongoing monitoring. If you'd rather not manage DNS records and XML reports yourself, we're here to help.

Scan your domain: https://www.wickedsick.com/domain-scanner Get in touch: https://www.wickedsick.com/contact