SPF, DKIM and DMARC get the most attention, but a hardened UK email setup actually consists of nine protocols working as layers — from DNSSEC beneath the DNS, through MTA-STS and DANE in transit, to BIMI showing your logo in the recipient's inbox. This article walks through every layer, what it protects, how the pieces interact, and what a production-grade configuration looks like end-to-end.
SPF, DKIM and DMARC together answer a single question — "did this message really come from the domain it claims?" — but they say nothing about whether the DNS records they depend on are authentic, nothing about whether the message was encrypted on the wire, nothing about what happens when it is forwarded through a mailing list, and nothing about how the recipient visually distinguishes your real mail from a clever lookalike. Each of those gaps has its own layer, and each layer depends on the one beneath it.
Run any single layer on its own and an attacker can bypass it by attacking a different layer. Publish perfect SPF/DKIM/DMARC but leave your DNS unsigned, and a state-level attacker can poison DNS and serve a fake SPF record that allows their own infrastructure. Encrypt every hop with TLS but skip MTA-STS, and a downgrade attack can strip encryption in transit without you noticing. Publish DMARC p=reject but ignore ARC, and your own legitimate mail will fail the moment a customer forwards it through their university or local-authority mail gateway.
The stack, from the bottom up, looks like this:
| Layer | Protocols | What it protects |
|---|---|---|
| 0 — Foundation | DNSSEC | The authenticity of every other DNS record in this stack |
| 1 — Identity | SPF, DKIM, DMARC | Who is allowed to send, and whether the message has been tampered with |
| 2 — Transport | STARTTLS, MTA-STS, DANE/TLSA | Encryption in transit and defence against TLS downgrade |
| 3 — Forwarding & Reporting | ARC, TLS-RPT | Preserving authentication across forwarders; visibility into TLS failures |
| 4 — Visual trust | BIMI (with VMC) | Verified brand logo shown next to authenticated mail |
DNSSEC (DNS Security Extensions), defined across RFC 4033, 4034 and 4035, adds cryptographic signatures to DNS responses. When DNSSEC is enabled on your domain, a resolver that looks up your SPF, DKIM, DMARC, MX or TLSA records can verify that the data was not modified between your authoritative name servers and the resolver. Without DNSSEC, any attacker who can influence the path between a receiving server and your DNS can serve a forged record — a fake SPF authorising their servers, a fake DKIM public key matching their signatures, or a fake TLSA pointing at their certificate.
DNSSEC is signed using a two-key hierarchy — a Key Signing Key (KSK) that signs a Zone Signing Key (ZSK) that signs every other record. Modern deployments use Algorithm 13 (ECDSA P-256 with SHA-256), which produces signatures small enough to fit comfortably in UDP responses and is universally supported by resolvers.
.uk, .co.uk and related namespaces, has supported DNSSEC since 2010. Enabling it on your domain typically requires publishing a DS record through your registrar and turning on signing at your DNS provider. Many modern DNS platforms (Cloudflare, Route 53, Azure DNS, Gandi LiveDNS) support this in two clicks.
The three identity protocols are covered in depth in How Email Authentication Works and in the dedicated articles for each. A short summary here is enough to place them within the stack:
From: header. Publishes one of three policies (none, quarantine, reject) and requests RUA (aggregate) and optionally RUF (forensic) reports.At the identity layer, the receiver writes results into an Authentication-Results header. A passing header for a UK mail flow looks like:
Authentication-Results: mx.google.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=firm.co.uk;
spf=pass [email protected];
dkim=pass [email protected] header.s=2026q2;Layer 2 protects the message as it travels between mail servers. Three protocols cooperate:
STARTTLS is a command that upgrades a plaintext SMTP connection to TLS. The sending server issues EHLO, the receiving server advertises STARTTLS in its response capabilities, and the sender issues STARTTLS before transmitting the message. By default STARTTLS is opportunistic — if the upgrade fails or is stripped, the sender falls back to plaintext rather than refusing to deliver the message. This is the ancient weakness that MTA-STS and DANE were built to close.
MTA-STS (RFC 8461) lets a receiving domain publish a policy declaring that senders must use TLS, must verify the recipient server's certificate against the policy, and must refuse to deliver if either check fails. The policy is discovered through a DNS TXT record at _mta-sts.domain and served as a plain-text file at https://mta-sts.domain/.well-known/mta-sts.txt.
_mta-sts.firm.co.uk. IN TXT "v=STSv1; id=20260423;"
https://mta-sts.firm.co.uk/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.firm.co.uk
max_age: 1209600
The three modes are none (disable), testing (log failures but still deliver), and enforce (refuse to deliver when TLS or certificate validation fails). Start in testing, watch TLS-RPT reports for a few weeks, then progress to enforce.
DANE (RFC 6698), implemented as TLSA records in DNS, lets a domain publish a cryptographic fingerprint of the certificate (or of the public key, or of the CA) that senders should expect. Because the TLSA records are signed by DNSSEC, they cannot be forged by a network attacker. A typical TLSA for a mail host is:
_25._tcp.mail.firm.co.uk. IN TLSA 3 1 1 <SHA-256 hash of the server's SubjectPublicKeyInfo>The three numbers mean DANE-EE (end-entity cert), SubjectPublicKeyInfo selector, SHA-256 matching. This pattern — 3 1 1 — is overwhelmingly the most common deployment and the one published on epost.plus, the email platform powering SmartXHosting services.
MTA-STS and DANE solve the same problem — preventing TLS downgrade and validating the receiver's certificate — but in complementary ways. MTA-STS uses HTTPS plus a cached policy; DANE uses DNSSEC-signed DNS. Best practice in 2026 is to run both.
ARC (Authenticated Received Chain, RFC 8617) lets intermediate servers — mailing lists, university relays, corporate gateway forwarders — record the authentication results they observed before they modified or re-wrapped the message. Each intermediary adds an ARC-Seal, an ARC-Message-Signature and an ARC-Authentication-Results header. The final receiver can follow the chain backwards, verify each ARC seal, and trust the original DKIM/SPF results even though the current envelope and body hashes no longer match.
ARC is the reason a message that passes DMARC when it leaves your server continues to pass DMARC even after a customer forwards it through their local council's mail gateway that rewrites From: headers and adds a disclaimer footer.
TLS-RPT (RFC 8460) lets a domain request daily JSON reports on TLS connection failures from sending servers. Without TLS-RPT you have no visibility when another mail server downgrades to plaintext, refuses your certificate, or encounters an MTA-STS policy mismatch. With TLS-RPT, Google, Microsoft, Fastmail and several other large receivers will tell you every day how often TLS succeeded, how often it failed, and why.
_smtp._tls.firm.co.uk. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"Use a processor like Mail Hardener, parsedmarc's TLS extension, or a hosted dashboard to aggregate the JSON reports; trying to read them by hand is a poor use of anyone's time.
BIMI (Brand Indicators for Message Identification) lets a domain publish an SVG logo that supporting mail clients — Gmail, Yahoo, Apple Mail, Fastmail — display next to authenticated messages. BIMI has two preconditions: the domain must have DMARC at p=quarantine or p=reject (so that only authenticated mail can ride the logo), and for the major UK and US receivers the logo must be attested by a VMC (Verified Mark Certificate) issued by DigiCert or Entrust at roughly USD 1,500 per year.
default._bimi.firm.co.uk. IN TXT "v=BIMI1; l=https://firm.co.uk/assets/bimi/logo.svg; a=https://firm.co.uk/assets/bimi/vmc.pem"For organisations that cannot justify a VMC (small UK charities, local practices, sole traders), a BIMI record without a= is still valid and is displayed by Fastmail and a growing list of European receivers. Gmail and Yahoo require a VMC before they will show the logo.
To see the stack in action, consider a realistic UK scenario: a Leeds accountancy firm sends a VAT return reminder from [email protected], which is signed by their mail server at mail.firm.co.uk, relays through the Axigen platform, and arrives at a customer on Gmail.
firm.co.uk over DNSSEC. Layer 0 done.3 1 1 matching the server's public key SHA-256, and the DNSSEC chain is valid, Gmail accepts the certificate. Layer 2 transport done.From: [email protected], performs SPF lookup, verifies the DKIM signature with selector 2026q2, and evaluates DMARC alignment. Layer 1 done.p=reject; adkim=s; aspf=s is published. Both SPF and DKIM pass alignment — the message is accepted.default._bimi with a VMC and a passing DMARC policy — the firm's logo is attached to the display record. Layer 4 done.Later that afternoon, the customer forwards the reminder to their bookkeeper. The forwarding server adds ARC headers preserving the original authentication results. When the bookkeeper's mail server evaluates DMARC, it sees SPF and DKIM fail (because the forwarder's IP and signature-breaking footer change things) but ARC validates the original chain — the mail is accepted. Layer 3 done.
| Layer | Record / setting | Example |
|---|---|---|
| DNSSEC | DS at registrar, signing at DNS host | Algorithm 13 (ECDSA P-256) |
| SPF | TXT at root | v=spf1 mx include:... -all |
| DKIM | TXT at selector._domainkey | RSA-2048 or Ed25519 |
| DMARC | TXT at _dmarc | v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:... |
| MTA-STS | TXT at _mta-sts + HTTPS policy file | mode: enforce, 14-day max-age |
| DANE/TLSA | TLSA at _25._tcp.mail | 3 1 1 <SHA-256> |
| TLS-RPT | TXT at _smtp._tls | v=TLSRPTv1; rua=mailto:... |
| ARC | Enabled at mail server / forwarder | Managed platforms handle this automatically |
| BIMI | TXT at default._bimi | SVG Tiny 1.2 logo + optional VMC |
| Organisation | Minimum baseline | Mature target |
|---|---|---|
| Sole trader / micro-business | SPF -all, DKIM, DMARC p=quarantine | DMARC p=reject; MTA-STS enforce; TLS-RPT |
| Bristol SME, 10-50 staff | The above plus DNSSEC and DANE | BIMI (SVG only) and ARC via managed mail platform |
| UK charity / school | SPF, DKIM, DMARC p=quarantine, MTA-STS testing | Full stack with NCSC-aligned documentation |
| Mid-size UK firm, 100-500 staff | Full stack through Layer 3 with DANE and DNSSEC | BIMI with VMC; quarterly DMARC review |
| Public sector body | NCSC mail check compliance (DMARC p=reject, TLS in transit, DNSSEC) | Full NCSC Email Security guidance and GOV.UK mail policy |
Across hundreds of UK domains we see the same handful of misconfigurations return month after month. The stack is only as strong as its weakest layer, and the weakest layer is almost always the one that was deployed in a hurry before the rest.
include: chain counts, and nested includes in provider macros silently push you over the limit. Monitor with a lookup-count checker; flatten only when necessary.p=reject without monitoring first. The classic mistake. A UK retailer once blocked its own transactional mail from six SaaS platforms for three days before noticing. Start at p=none, read reports, progress gradually._mta-sts TXT record and the https://mta-sts.domain/.well-known/mta-sts.txt endpoint with curl after deployment.dig +dnssec).p=quarantine or p=reject. If you publish a BIMI record while still at p=none no logo is shown, and you spend a year wondering why.Every production deployment should pass all of the following checks end-to-end:
| Check | Expected result |
|---|---|
dig +dnssec TXT yourdomain | RRSIG records present, AD flag set |
dig TXT yourdomain | grep spf | Single SPF record ending -all or ~all, under 10 lookups |
dig TXT selector._domainkey.yourdomain | Valid DKIM record, p= present |
dig TXT _dmarc.yourdomain | DMARC record, policy set, rua= included |
dig TXT _mta-sts.yourdomain | MTA-STS TXT with version and id |
curl https://mta-sts.yourdomain/.well-known/mta-sts.txt | Policy file with mode: enforce and one MX |
dig TLSA _25._tcp.mail.yourdomain | At least one TLSA record, DNSSEC-signed |
dig TXT _smtp._tls.yourdomain | TLS-RPT record present |
| Send-and-inspect | Authentication-Results header shows dmarc=pass, dkim=pass, spf=pass |
SmartXHosting operates a UK Axigen-based email platform at epost.plus. Because it is easier to show the stack than describe it, here is the full live configuration of that domain as a reference target for UK deployments:
| Layer | Record |
|---|---|
| DNSSEC | Algorithm 13 (ECDSA P-256), KSK and ZSK |
| SPF | v=spf1 ip4:217.149.241.18 ~all |
| DKIM | Rotating selector, RSA-2048 |
| DMARC | v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected] |
| MX | 10 mail.epost.plus. |
| PTR / FCrDNS | 217.149.241.18 → mail.epost.plus |
| MTA-STS | mode: enforce; mx: mail.epost.plus; max_age: 1209600 |
| TLS-RPT | v=TLSRPTv1; rua=mailto:[email protected],mailto:[email protected] |
| DANE / TLSA | 3 1 1 (DANE-EE, SPKI, SHA-256) |
| BIMI | v=BIMI1; l=https://epost.plus/img/epost-icon.svg (no VMC) |
Q: Is it safe to deploy the whole stack at once?
A: Mostly, but not the policy parts. DNSSEC, SPF (discoverable but not enforcing), DKIM signing and MTA-STS testing can be enabled in one go — they have no enforcement effect. DMARC p=reject and MTA-STS enforce must be introduced gradually after weeks of monitoring. BIMI should wait until DMARC is already at quarantine or reject.
Q: Do I need a dedicated IP address to deploy this stack?
A: Not strictly. Shared IPs can support every layer except BIMI (where the logo will show for any passing sender on the IP, which is an acceptable outcome). Dedicated IPs help with reputation but are not a hard prerequisite.
Q: How often should I rotate DKIM keys?
A: Quarterly is the emerging norm — rotating selector naming such as 2026q1, 2026q2 makes this easy. At minimum rotate annually. Retire old selectors by publishing an empty-p record or removing them after enough time has passed that no signed messages are still in transit.
Q: Does MTA-STS replace DANE?
A: No — they complement. MTA-STS works without DNSSEC (policy fetched over HTTPS) but relies on a trusted HTTPS certificate to establish the policy. DANE requires DNSSEC but is stronger because the policy is signed by the domain owner's DNS keys. Deploy both if you run DNSSEC.
Q: Can I rely on my hosting provider to configure the whole stack?
A: Partly. Managed email platforms (including the one smartxhosting.uk runs on Axigen) configure SPF, DKIM, MTA-STS and DANE for you. DNSSEC is owned by whoever hosts your domain's DNS — frequently the same provider, sometimes a different one. DMARC is always your call — the policy must match your actual sender landscape, which only you know.
Q: What is the highest-impact single record I can add today?
A: Publish DMARC at p=none with rua=. You learn who is sending as your domain within 24 hours, with zero risk of blocking legitimate mail. Every subsequent step depends on the information you gather from those aggregate reports.
Q: How do I test the stack end-to-end?
A: Send a test message to an address at [email protected] or run your domain through the NCSC Mail Check service (for gov.uk and accredited domains), Hardenize, or MXToolbox. These tools confirm every layer is present and signed correctly.
Q: Will the stack protect me against attackers using lookalike domains (for example, firm-co-uk.com)?
A: No. Authentication protects the exact domain name you publish records for. Defending against lookalike domains is a separate discipline — register common typosquats, monitor certificate transparency logs, and train staff to verify the full sender address before acting on financial or identity requests.
Q: Does ARC require any local configuration?
A: If you run your own mail server you must enable ARC signing so that when you forward mail you preserve the upstream results. Most modern platforms (Axigen, Postfix with OpenDKIM + OpenARC, Exchange 2019+) support this. Managed providers — including smartxhosting.uk email plans — handle it by default.
Q: How many records does the full stack add to a domain's DNS?
A: A typical UK production setup publishes around a dozen records — one each for SPF, DMARC, _mta-sts, _smtp._tls, BIMI, plus a TLSA per mail host, plus one or more DKIM selectors, plus DNSSEC key and DS records. Modern DNS platforms handle dozens of records without any performance concern.