Email remains a critical part of business communication — but it's also one of the most common attack vectors.

Threats like phishing and spoofing often succeed because recipients trust what they see in the “From” address. Without technical safeguards, any attacker can send an email appearing to come from your organisation’s domain.

To counter this, three email authentication standards have become the backbone of email security: SPF, DKIM, and DMARC. Each one addresses a different part of the trust equation, and when combined, they provide robust protection against impersonation and domain abuse.

SPF – Authorising Sending Servers.

Sender Policy Framework (SPF) allows domain owners to define which mail servers are permitted to send email on their behalf. It works by publishing a DNS TXT record containing a list of authorised IP addresses or hostnames.

For example:

v=spf1 include:spf.protection.outlook.com -all

This record tells the recipient’s mail server to accept email only from Microsoft 365 infrastructure. If a message is sent from an unauthorised server, SPF validation will fail.

How easy is it to implement?

SPF is relatively simple to set up. You add a single TXT record to your public DNS zone. Most major providers — like Microsoft 365, Google Workspace, and others — provide clear SPF configuration guidance and the required syntax. It’s worth reviewing all your legitimate email senders (e.g. marketing platforms, CRMs) to ensure they’re included.

However, SPF on its own has limitations. It verifies the envelope sender, not the visible "From" address, and it can break when emails are forwarded unless SRS (Sender Rewriting Scheme) is supported by the forwarding service.

DKIM – Protecting Message Integrity.

DomainKeys Identified Mail (DKIM) uses public-key cryptography to verify that an email’s content has not been altered in transit and that it was sent by an authorised source.

When DKIM is enabled, the sending server signs selected parts of the message (such as headers and body content) with a private key. The receiving server then retrieves the public key from a DNS TXT record and verifies the signature.

A DKIM DNS record looks like this (simplified):

selector._domainkey.yourdomain.com

The "selector" is a label used to differentiate keys, especially useful when rotating them.

How easy is DKIM to set up?

Setup complexity varies by email provider. With Microsoft 365 or Google Workspace, DKIM can be enabled via the admin portal, and the required DNS records are generated for you. You then add two TXT records to your DNS (one per signing domain/selector) and enable DKIM signing in the admin console.

Once configured, messages sent from your domain will include a DKIM-Signature header, and compliant receiving servers will validate that the message has not been tampered with.

DMARC – Alignment, Enforcement, and Visibility.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the protocol that ties everything together. It tells receiving mail servers what to do when messages fail SPF and/or DKIM checks — and it ensures that either SPF or DKIM aligns with the domain in the “From” header (the part users see).

A DMARC record is published as another DNS TXT record. A basic example might look like:

_dmarc.example.org IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.org; adkim=s; aspf=s; fo=1"

The p= tag sets the policy (none, quarantine, or reject), while the rua= tag defines where to send aggregate reports.

Explanation of each tag:

_dmarc.example.org — The subdomain used to publish the DMARC record via DNS.
v=DMARC1 — Required version tag (always DMARC1).
p=reject — Policy: reject messages that fail both SPF and DKIM and fail alignment.
rua=mailto:dmarc-reports@example.org — Aggregate reports will be emailed here in XML format.
adkim=s — DKIM alignment mode is strict (the domain in the DKIM signature must exactly match the "From" domain).
aspf=s — SPF alignment mode is strict.
fo=1 — Failure reporting option: generate reports if either SPF or DKIM fails.

Is DMARC hard to configure?

DMARC is simple to publish, but it requires SPF and DKIM to be properly configured first. It’s recommended to start with a p=none policy to monitor authentication activity without affecting mail flow. Once you’re confident all legitimate senders are aligned, you can move to quarantine or reject for full protection.

DMARC also provides detailed reporting, which helps you see who’s sending email on your behalf — whether authorised or not. These reports can be interpreted manually or through free and commercial tools like dmarcian, Postmark, or Microsoft’s Defender for Office 365 reports.

Why All Three Matter — Together.

SPF checks that the sending IP is allowed. DKIM ensures the message hasn’t been tampered with. DMARC enforces that either SPF or DKIM aligns with the domain in the visible From address — and allows the domain owner to instruct how to handle failures.

Each protocol addresses a specific gap. Using just one leaves room for abuse:

SPF alone doesn’t protect against message tampering.
DKIM without DMARC leaves enforcement weak.
DMARC without properly configured SPF and DKIM won’t function effectively. Without DMARC, attackers can still spoof the visible “From” domain, even if they fail SPF and DKIM, because recipient mail servers don’t know how to handle the failure.

When used together, these protocols form a layered defence that blocks most domain-spoofed email, improves deliverability of legitimate messages, and provides much-needed visibility into how your domain is used.

Getting Started.

SPF: Add a TXT record with authorised sending IPs or include mechanisms (e.g. include:spf.protection.outlook.com for Microsoft 365).
DKIM: Enable signing through your email provider, generate DNS key(s), and publish the two DKIM TXT record(s).
DMARC: Start with a p=none policy and monitoring address (rua), then gradually move to quarantine or reject.

Make sure to test each configuration using tools like MXToolbox, Google Admin Toolbox, or Microsoft's Remote Connectivity Analyzer.

Final Thoughts.

SPF, DKIM, and DMARC are not difficult to implement — but they do require attention to detail and ongoing monitoring. Each one contributes a vital layer to email authentication, but the real strength comes from their combined use.

In today’s threat landscape, failing to implement these standards exposes your domain to impersonation and users to risk. Done properly, these DNS-based defences help secure your brand, protect your users, and stop attackers before the message even hits the inbox.