SPF, DKIM and DMARC are the three protocols that prove an email genuinely comes from the domain it claims to represent. This article explains how each piece fits together, why UK businesses cannot afford to run without them, and what happens inside a receiving mail server the moment a message lands in the queue.
Business Email Compromise (BEC) is the single most expensive category of cybercrime reported to the National Cyber Security Centre (NCSC) and Action Fraud. The City of London Police, which runs the UK national fraud reporting centre, published figures showing that UK businesses lost more than £140 million to BEC-style invoice and CEO-impersonation frauds in a single reporting year — and those are only the incidents reported. The Information Commissioner's Office (ICO) records phishing as the leading cause of personal-data breaches requiring notification under UK GDPR.
Every one of those attacks shares a common root cause: the recipient trusted a From: address that the attacker did not actually control. Email authentication — the combination of SPF, DKIM and DMARC — is the only technical countermeasure that turns sender identity from a self-declaration into something a receiving mail server can cryptographically verify before the message reaches an inbox.
For UK SMEs in particular, authentication is no longer an optional refinement. It is the difference between your legitimate invoices reaching your customers and the same invoices being rewritten by an attacker, forwarded from a lookalike domain, and paid into a criminal's account before anyone notices. It is also, increasingly, a contractual and regulatory requirement: HMRC, NHS Digital and most local councils now require their suppliers to implement a published DMARC policy, and card-handling businesses must evidence email controls under PCI DSS 4.0.
The Simple Mail Transfer Protocol was specified in RFC 821 in 1982 and the revised RFC 5321 in 2008. It was designed in an era when the internet connected a few research institutions that trusted each other by default. The protocol contains no mechanism to verify that the address in the From: header — the address displayed to the recipient — has any relationship to the server sending the message. A laptop in Manchester can connect to a mail server and issue MAIL FROM:<[email protected]> without providing any proof whatsoever that the sender has any authority over nhs.uk. The receiving server, by default, accepts the claim.
This gap has been exploited at industrial scale for decades. Early phishing campaigns in the 2000s relied on it; modern BEC attacks, lookalike-domain fraud and supply-chain compromises still rely on it. The three authentication protocols — SPF, DKIM and DMARC — were introduced progressively to close different parts of the gap. They do not replace SMTP; they sit beside it as a layer of cryptographic and DNS-based attestation that receiving servers consult before accepting or rejecting a message.
SPF (Sender Policy Framework), defined in RFC 7208, lets a domain owner publish a DNS TXT record that lists every mail server authorised to send email on behalf of that domain. When an incoming SMTP connection is received, the mail server reads the IP address of the connecting server and checks it against the SPF record of the domain in the envelope sender — also called the Return-Path or MAIL FROM address.
MAIL FROM:<[email protected]>. This envelope sender address is separate from the From: header the recipient eventually sees.smartxhosting.uk), performs a DNS TXT query, and looks for a record starting with v=spf1.ip4:, include:, a, mx, -all and so on — is evaluated left to right. The first match determines the result.Pass, Fail, SoftFail or Neutral. The result is written into the Authentication-Results header of the received message.A Bristol law firm that sends staff email from its own mail server, transactional notifications from a hosted platform, and marketing newsletters from Mailchimp might publish:
firm.co.uk. IN TXT "v=spf1 mx include:servers.mcsv.net include:_spf.smartxhosting.uk -all"Every token has a meaning:
v=spf1 — protocol version, always first.mx — authorises the IP addresses listed in the domain's MX records (the firm's own mail server).include:servers.mcsv.net — authorises the Mailchimp sending infrastructure.include:_spf.smartxhosting.uk — authorises smartxhosting.uk platform senders.-all — a hard fail for any IP that did not match one of the above.| Qualifier | Result | Header value | Meaning |
|---|---|---|---|
+ (default) | Pass | spf=pass | Sending IP is authorised |
- | Fail (hard) | spf=fail | Sending IP is explicitly not authorised |
~ | SoftFail | spf=softfail | Sending IP is probably unauthorised |
? | Neutral | spf=neutral | No assertion made |
RFC 7208 Section 4.6.4 is strict: evaluating an SPF record must never cause more than 10 DNS lookups. Each include:, a, mx and redirect= token costs at least one lookup, and nested include:s cost more. Exceed 10 and the result is PermError — and SPF silently fails. The ip4: and ip6: mechanisms cost zero lookups, which is why SPF flattening (replacing include: with explicit IP ranges) is a common remediation for UK retailers who layer several SaaS tools on top of their own mail server.
From: header that users see in their mail client. A fraudster can spoof From: [email protected] while using a completely different envelope sender domain that has its own (perfectly valid) SPF record. SPF alone cannot stop this. That gap is exactly what DMARC alignment closes.
DKIM (DomainKeys Identified Mail), defined in RFC 6376, adds a cryptographic signature to every outgoing message. The sending server signs a selected set of headers (always including From:) and a hash of the message body using a private key. The corresponding public key is published as a DNS TXT record. When the message arrives at the receiver, the server fetches the public key, recomputes the hash, and verifies the signature.
selector._domainkey.domain. The private key is installed on the outbound mail server.DKIM-Signature header is prepended.s= (selector) and d= (domain) tags, fetches the public key from DNS, rebuilds the canonical form, recomputes the hash and verifies the signature. On success: dkim=pass.DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firm.co.uk;
s=2026q2; t=1712448000;
h=from:to:subject:date:message-id:content-type:mime-version;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
IEhY+sHo+QDSLLzc...The tags matter:
a=rsa-sha256 — signing algorithm. RSA with SHA-256 is standard; Ed25519 is the modern alternative.c=relaxed/relaxed — canonicalisation. Relaxed tolerates minor whitespace changes and header re-folding that happen during normal mail transport.d=firm.co.uk — the signing domain. DMARC checks whether this aligns with the From: header domain.s=2026q2 — the selector. Rotating selectors quarterly (for example, 2026q1, 2026q2) is a common UK practice to simplify key rotation.h= — the list of headers that are signed. The From: header must always be included per RFC 6376 Section 5.4.bh= — the body hash.b= — the actual signature.DKIM proves two things. First, message integrity: if any signed header or the body is altered after signing, verification fails and the tampering is detected. Second, domain authenticity: only the holder of the private key — which is installed on an authorised server and whose public counterpart was published in DNS by the domain owner — could have produced a valid signature.
DKIM does not encrypt the message. The body remains readable to any mail server that handles the message in transit. For encryption in transit, STARTTLS (ports 25 and 587) or implicit TLS (port 465) is used. For end-to-end encryption visible only to the sender and the recipient, S/MIME or PGP is required.
DMARC (Domain-based Message Authentication, Reporting and Conformance), defined in RFC 7489, sits on top of SPF and DKIM and solves three problems that neither protocol addresses on its own:
From: header that the user actually sees?This is DMARC's most important innovation. SPF validates the envelope sender. DKIM validates the signing domain. Neither automatically checks the From: header the recipient sees. DMARC closes that gap by requiring that the domain that passed SPF or DKIM aligns with the From: header domain.
Relaxed alignment (default, adkim=r / aspf=r): the organisational domains must match. For example, bounce.firm.co.uk aligns with firm.co.uk because they share the organisational domain firm.co.uk.
Strict alignment (adkim=s / aspf=s): the domains must match exactly. bounce.firm.co.uk does not align with firm.co.uk in strict mode.
DMARC passes if at least one of these is true:
From: header domain, ord=) aligns with the From: header domain.| Policy | What receivers do | When to use it |
|---|---|---|
p=none | No enforcement. Messages are delivered regardless of DMARC result. Aggregate reports still generated. | Initial deployment — observe who is sending as your domain without risking blocked legitimate mail. |
p=quarantine | Messages that fail DMARC are placed in the recipient's spam folder. | Intermediate step — you have confirmed all legitimate senders pass but want a safety net before full rejection. |
p=reject | Messages that fail DMARC are rejected at SMTP level (SMTP 550) or silently dropped. | Full enforcement — maximum protection against spoofing. All legitimate senders must already pass. |
DMARC's reporting mechanisms are the most useful thing about the protocol for a UK IT manager trying to bring a messy sender landscape under control:
An example DMARC record published in production for full enforcement:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]; pct=100"And a recommended initial monitoring record for a domain just starting its rollout:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Putting the three protocols together, here is what actually happens inside a receiving mail server at Gmail, Outlook or a UK hosting provider like the Axigen platform that powers smartxhosting.uk's email services, the moment a message arrives from firm.co.uk:
MAIL FROM:<[email protected]>, and transmits the message. The From: header reads From: [email protected].TXT firm.co.uk and verifies the connecting IP is listed. Result: spf=pass.DKIM-Signature header, fetches the public key from 2026q2._domainkey.firm.co.uk, recomputes the hash, verifies the signature. Result: dkim=pass._dmarc.firm.co.uk, finds p=reject, checks whether the SPF envelope sender domain or the DKIM signing domain aligns with From: firm.co.uk. Both do. Result: dmarc=pass.Authentication-Results header.A passing Authentication-Results header looks like this:
Authentication-Results: mx.google.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=firm.co.uk;
spf=pass (google.com: domain of [email protected] designates
203.0.113.25 as permitted sender) [email protected];
dkim=pass [email protected] header.s=2026q2 header.b=dzdVyOfA;UK domains that operate without SPF, DKIM and DMARC suffer a compounding set of consequences:
p=quarantine or p=reject. PCI DSS 4.0 explicitly references email authentication for card-accepting merchants.The UK-specific pressure to deploy email authentication comes from multiple directions and is tightening each year:
| Source | Requirement | Applies to |
|---|---|---|
| NCSC Email Security guidance | SPF, DKIM and DMARC with at least p=quarantine; TLS in transit | All public sector bodies and their suppliers |
| Cabinet Office & GOV.UK policy | DMARC p=reject on central government domains; mandated via the Gov.UK mail policy | gov.uk domains and subdomains |
| NHS Digital supplier requirements | Authenticated email for any supplier handling NHS data | NHS suppliers under the Digital Technology Assessment Criteria (DTAC) |
| Google / Yahoo bulk sender rules (2024) | SPF and DKIM required; DMARC record required for > 5,000 messages/day | Any UK business sending marketing or transactional mail to consumer inboxes |
| Microsoft bulk sender rules (2025) | Equivalent SPF/DKIM/DMARC requirements for Outlook.com and Hotmail | Same audience, broader reach |
| PCI DSS 4.0 | Email authentication controls as part of Requirement 5 | Card-accepting businesses |
| UK GDPR / ICO guidance | Appropriate technical measures against phishing and identity fraud | Any organisation processing personal data |
| Capability | SPF | DKIM | DMARC |
|---|---|---|---|
| Verifies sending server identity | Yes (by IP) | No | No (relies on SPF / DKIM) |
| Verifies message integrity | No | Yes (cryptographic hash) | No (relies on DKIM) |
Protects the From: header | No (envelope sender only) | No (signing domain only) | Yes (alignment) |
| Provides a policy for failures | No | No | Yes (none / quarantine / reject) |
| Provides reporting | No | No | Yes (RUA aggregate, RUF forensic) |
| Survives forwarding | No (IP changes) | Usually (if body unchanged) | Via DKIM alignment, plus ARC |
| Where published | TXT at domain root | TXT at selector._domainkey.domain | TXT at _dmarc.domain |
| RFC | 7208 | 6376 | 7489 |
| Published by | Domain owner (DNS) | Domain owner (DNS) | Domain owner (DNS) |
The three protocols must be rolled out in a specific order. Skipping steps or going straight to p=reject without preparation is the single most common cause of UK businesses blocking their own mail on the morning of a marketing campaign.
include: where the upstream provider supplies a macro; use ip4: ranges where they do not. Keep lookups under 10.p=none with rua=. Collect aggregate reports for at least two full weeks. Use a DMARC processing service (or at minimum a parsing script) to identify senders you missed.p=quarantine with pct=25. Ramp to pct=50, then pct=100. Watch the reports at each step.p=reject with strict alignment. This is the end state. At p=reject; adkim=s; aspf=s, spoofing of your exact From: domain becomes effectively impossible.A small UK business with a single mail server and one or two SaaS senders can typically complete this sequence in four to six weeks. An organisation with 30 or 40 sending services should plan for four to six months.
p=reject with strict alignment, MTA-STS in enforce mode, DANE/TLSA certificate pinning backed by DNSSEC, TLS-RPT reports, and a BIMI logo. When you order a Business Email or Private Email plan from smartxhosting.uk, SPF and DKIM are generated automatically for your domain, and DMARC is ready to publish as soon as your rollout is complete.
Q: Do I really need all three of SPF, DKIM and DMARC, or is one enough?
A: You need all three. SPF authorises sending servers by IP address but does not protect the visible From: header and breaks on forwarding. DKIM proves the message has not been tampered with but provides no policy instruction when it fails. DMARC ties them together with alignment, policy and reporting. Since 2024, Google and Yahoo require all three for senders exceeding 5,000 messages per day; Microsoft followed in 2025; UK public-sector supplier frameworks already require DMARC enforcement.
Q: What happens if I only set up SPF, without DKIM or DMARC?
A: SPF alone checks the envelope sender, not the From: header that users actually see. An attacker can send a message with From: [email protected] using a completely different envelope sender that happens to have a valid SPF record. Without DMARC alignment, that spoofing is trivial. You also have no visibility — no reports tell you anyone is impersonating you.
Q: Does DKIM encrypt my email messages?
A: No. DKIM signs the message so that any modification after signing breaks verification and any unauthorised signer cannot produce a valid signature. The body itself remains readable in transit. For transport encryption use STARTTLS or implicit TLS. For end-to-end encryption use S/MIME or PGP.
Q: Why do my forwarded emails fail DMARC even though I have SPF and DKIM set up?
A: Forwarding changes the sending IP (breaking SPF) and often modifies the message — adding a footer, rewriting the subject line, changing the To: address — which breaks DKIM. ARC (Authenticated Received Chain, RFC 8617) was designed to carry the original authentication results across forwarding hops; major receivers including Gmail and Microsoft now use ARC to override DMARC failures from trusted forwarders.
Q: How long does it take to reach p=reject safely?
A: A small UK business with one mail server and one or two SaaS senders can typically get to p=reject in four to six weeks. Organisations with many sending services — finance, marketing, CRM, HR, ticketing, monitoring — should expect two to six months. The time is spent at p=none identifying senders, fixing their SPF and DKIM, then ramping pct= through p=quarantine.
Q: Do SPF, DKIM and DMARC replace spam filtering?
A: No. They verify sender identity and protect domain reputation. Spam filtering is a separate set of content-based controls that look at wording, links, attachments and behavioural signals. Authentication is an input to spam filtering: properly authenticated mail is more likely to be delivered, but a genuinely spammy authenticated message will still end up in junk.
Q: Will DMARC break my mailing list?
A: It can, if the list software rewrites headers in ways that break DKIM. Most modern list managers (Mailman 3, Sympa) now rewrite the From: header to an address on the list's own domain and re-sign with their own DKIM key; this keeps DMARC passing even at p=reject. For legacy lists that cannot be upgraded, publish a neutral DMARC policy on the sub-domain used by the list and enforce only on the parent.
Q: Can I publish DMARC without any SPF or DKIM at all?
A: You can publish a record, but it will report every message as failing. There is a legitimate use case for this on parked domains you never send from — publish v=DMARC1; p=reject; rua=mailto:... with an empty SPF (v=spf1 -all) and a null DKIM so that any message pretending to come from the domain is rejected everywhere.
Q: How do I read DMARC aggregate reports?
A: They arrive as XML files wrapped in email attachments. Do not try to parse them by eye. Either use a DMARC processing service, or run an open-source parser such as parsedmarc into a local database with a dashboard. A UK IT team managing more than one or two domains will save days of time by paying a small monthly fee for a dedicated DMARC service.
Q: What is the smallest safe DMARC record for a UK domain I do not actively send from?
A: If the domain has no mail flow at all, publish three records: an empty SPF (v=spf1 -all), a null DKIM (*._domainkey.domain IN TXT "v=DKIM1; p="), and a rejecting DMARC (_dmarc.domain IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"). This locks the domain against spoofing for as long as it is not used for mail.