Field notes · 27 October 2026 · Network and segmentation

Email was built to trust everyone: TLS, SPF, DKIM and DMARC, and what each one breaks

In plain words: Email was built so anyone could sign a letter with any name; several add-ons now check the sender owns the address, but none can tell if they are honest. Network and segmentation, explained simply

In short

• SMTP, the protocol servers use to pass email to each other, was designed in 1982 for a network where everyone knew everyone. It has no built-in encryption and no check on who a message says it is from. Everything since has been bolted on.
• The bolt-ons do different jobs. Opportunistic TLS (STARTTLS) hides mail from people watching the wire, and MTA-STS or DANE make that encryption compulsory. SPF says which servers may send for a domain, DKIM signs the message, and DMARC ties both to the From address a person actually sees and tells receivers what to do when it does not match.
• Most of the pain comes from mail that is forwarded, rewritten or sent by a supplier on your behalf. The rest comes from expecting these controls to do what they cannot: none of them says whether the sender is honest, only whether they own the domain.

Why email needed patching at all

When one mail server hands a message to another, it says who the message is from, who it is for, and then sends the message. Nothing in the original protocol checks any of that. The envelope sender that servers use for bounces and the From line that appears in your mail client are two different fields, and the sender can write whatever it likes in both. That is the whole of phishing's home advantage in one sentence.

The message itself travelled as plain text. Anyone on the path, an internet provider, a hotel network, a state, could read it.

Nobody could replace SMTP, because every mail server in the world would have to change on the same day. So each fix had to be optional, published in DNS or negotiated between servers, and safe to ignore by a server that did not understand it. That design choice explains most of what follows.

Opportunistic TLS: encryption if both sides offer it

Why it exists. STARTTLS (RFC 3207, 2002) lets a sending server ask "do you speak TLS?" at the start of a conversation and, if the answer is yes, switch to an encrypted connection. If either side says no, the mail goes in the clear anyway. That is what "opportunistic" means: it never stops mail from flowing.

Who uses it. Almost everyone now. The large mailbox providers encrypt the great majority of their traffic, and Google publishes the share in its transparency report. Governments set it as a floor: the US Binding Operational Directive 18-01 of 2017 told federal agencies to offer STARTTLS on every mail server, and UK government guidance expects TLS 1.2 or later with valid certificates.

What it breaks, or fails to stop. Three things.

1. It can be stripped. The offer of TLS travels unencrypted, so anyone on the path can remove it and both servers will shrug and carry on in plain text. The EFF documented internet providers doing exactly that in 2014.
2. Certificates are rarely checked. Because failing would mean losing mail, most servers accept any certificate, including a self-signed one or one for the wrong name. That keeps out passive eavesdroppers, not someone who can sit in the middle.
3. It is per hop, not end to end. Each server on the way decrypts, stores and re-encrypts the message. Your provider, theirs and any filtering service in between can read it. If the content itself must stay private, that is a job for S/MIME or a secure portal, not for TLS.

MTA-STS and DANE make it compulsory. Both let a receiving domain say "only deliver to me over TLS, to a server with a valid certificate for this name". MTA-STS (RFC 8461, 2018) publishes that policy on a web server at mta-sts. plus the domain, which a sender fetches over HTTPS and caches. It was written by the large mailbox providers and works without DNSSEC, at the price of trusting the first fetch. DANE for SMTP (RFC 7672, 2015) puts the certificate details in DNS instead, so it needs DNSSEC on the receiving domain. It is common in parts of Europe and Microsoft made inbound DANE generally available in Exchange Online in October 2024. TLS reporting (RFC 8460) is the piece people skip and should not: senders email you a daily summary of failed TLS connections, which is how you find out a policy is breaking delivery before your customers do.

Their problem is the mirror image of opportunistic TLS: they can stop mail. An expired certificate, an MX record that changed without the policy, or a supplier's mail server behind a different name, and mail to you is refused instead of being delivered unencrypted. That is the point, but it means certificates on mail servers now need the same automated renewal as on websites.

SPF: which servers may send for this domain

Why it exists. SPF (RFC 7208) lets a domain publish, in a DNS text record, the list of servers allowed to send mail for it. A receiving server compares the address that connected to it with that list.

Who uses it. Nearly every domain that sends mail, because the large mailbox providers have made it a condition of delivery.

What it breaks, or fails to stop.

• It checks the wrong address. SPF looks at the envelope sender, the bounce address, not the From line a person reads. An attacker can pass SPF for their own domain while showing yours in From. DMARC exists largely to close that gap.
• Forwarding fails it. When a university or a club forwards your mail to someone's personal mailbox, the message now arrives from the forwarder's server, which is not in your list.
• It runs out of room. An SPF check may make at most ten DNS lookups. A typical organisation sends through its mail platform, a marketing service, a ticketing tool, an HR system and an invoicing service, each with its own include:, and the record quietly breaks the limit. The result is a permanent error that many receivers treat as a fail.
• Shared senders share the pass. Including a large provider's range allows every server in it. Whether another customer of that provider can then pass SPF as you depends on how carefully the provider checks who is sending.

DKIM: a signature on the message

Why it exists. DKIM (RFC 6376) has the sending server sign the headers and body with a private key. The public key sits in DNS under the sending domain, at a name called a selector. A receiver checks the signature and knows the message was sent with that domain's authority and was not changed on the way. Unlike SPF, it survives forwarding as long as nobody edits the message.

Who uses it. All the large mail platforms sign by default for their own domains and will sign for yours once you publish their key, so most organisations have it for their main mail service and miss it for everything else.

What it breaks, or fails to stop.

• Anything that edits the message breaks the signature. Mailing lists that add a footer or a tag to the subject, security gateways that rewrite links, and disclaimers added on the way out all do it.
• Keys are rarely rotated. In 2012 a mathematician, Zachary Harris, found that Google and other large companies signed with keys short enough to factor; he could have sent mail that passed as theirs. Keys of 1024 bits are still common and many have never changed. A selector belonging to a supplier you stopped using years ago may still be live.
• A good signature can be replayed. A message signed by a reputable domain can be sent again, unchanged, to millions of people, and it still passes. Spammers have done this with mail from large providers.
• The signing domain need not be yours. DKIM proves which domain signed, not that it matches the From line. Again, DMARC is what joins them.

DMARC: tying it to the name people see

Why it exists. DMARC (RFC 7489 in 2015, revised as RFC 9989 in May 2026, now on the standards track) does three things. It requires alignment: SPF or DKIM must pass for the same domain that appears in the From line. It lets the domain owner publish a policy for mail that fails, p=none (report only), p=quarantine (send to spam) or p=reject. And it asks receivers to send daily aggregate reports, so the owner can see every server in the world sending as their domain.

Who uses it. Since February 2024, Gmail and Yahoo require anyone sending more than about 5,000 messages a day to their users to have SPF, DKIM and at least a p=none DMARC record, along with one-click unsubscribe and a low spam complaint rate. Microsoft applied similar rules to Outlook.com from May 2025. Governments went further and earlier: BOD 18-01 required US federal agencies to reach p=reject, and UK public bodies are directed to the NCSC's Mail Check service, which reads their reports for them.

What it breaks, or fails to stop.

• Mailing lists, again. When Yahoo and AOL moved to p=reject in April 2014, after their users' address books were stolen and used for spoofing, mail from their users to lists everywhere started bouncing, and some list members were unsubscribed for it. Lists now rewrite the From address or avoid editing messages. ARC (RFC 8617) lets a forwarder vouch for the results it saw before it changed the message, but receivers decide for themselves whether to believe it.
• Most organisations stall at p=none. Moving to reject means finding every system that sends as you: the marketing platform, the payroll provider, the facilities system that emails invoices, the scanner in the post room. The aggregate reports find them, but someone has to read the reports and chase each owner. That work, not the DNS record, is the project.
• Subdomains and parked domains. An unused domain is the easiest one to spoof. A domain that sends no mail should say so, with an SPF record of v=spf1 -all, a DMARC policy of reject and a null MX record (RFC 7505). DMARC policy is inherited by subdomains unless they set their own; MTA-STS is not, which catches people out.

What none of this fixes

DMARC at reject stops someone sending as example.com. It does nothing about examp1e.com, example-payments.com, a display name that says "Finance team" over a free webmail address, or a real account whose password was phished. Those are now where most fraud lives. The FBI's Internet Crime Complaint Center recorded about 2.77 billion US dollars lost to business email compromise in 2024, across 21,442 complaints, and much of it came from lookalike domains or compromised mailboxes that pass every check above.

BIMI, which shows a brand's logo in the inbox, needs DMARC enforcement and a certificate for the logo first. It rewards the work but does not add protection of its own.

So I treat sender authentication as hygiene: it removes the cheapest attack, protects the domain's reputation and keeps mail flowing to the large providers. The defence against fraud is elsewhere, in payment processes that confirm changes of bank details out of band, phishing-resistant sign-in on mailboxes, and alerts for newly registered domains that look like yours.

What to do on Monday

• Look up your own records: dig txt yourdomain, dig txt _dmarc.yourdomain. If DMARC is still p=none after a year, ask who reads the reports.
• List every service that sends as your domain, and check each has its own DKIM key published, not a borrowed SPF include.
• Count the lookups in your SPF record. If it is near ten, move some senders to a subdomain such as mail.yourdomain or news.yourdomain.
• Publish a reject policy, -all SPF and a null MX on every domain that does not send mail.
• Turn on TLS reporting, then MTA-STS in testing mode for a few weeks before enforcing it. If your domain is already signed with DNSSEC, consider DANE as well.

Sources

• IETF, RFC 3207: SMTP Service Extension for Secure SMTP over TLS (2002).
• IETF, RFC 7208: Sender Policy Framework (2014) and RFC 6376: DomainKeys Identified Mail Signatures (2011).
• IETF, RFC 7489: DMARC (2015), revised as RFC 9989 (2026), with a summary of the changes by Red Sift.
• IETF, RFC 8461: SMTP MTA Strict Transport Security, RFC 8460: SMTP TLS Reporting (2018) and RFC 7672: SMTP Security via Opportunistic DANE TLS (2015).
• IETF, RFC 8617: Authenticated Received Chain (2019) and RFC 7505: A "Null MX" No Service Resource Record (2015).
• Google, Email sender guidelines FAQ.
• Microsoft, Strengthening email ecosystem: Outlook's new requirements for high-volume senders (April 2025), and the Exchange Online message centre post on inbound SMTP DANE with DNSSEC (general availability October 2024).
• CISA, BOD 18-01: Enhance Email and Web Security (October 2017).
• UK Government Security Group, Email security standards: MTA-STS and TLS-RPT, and the NCSC's Email security and anti-spoofing guidance.
• FBI IC3, 2024 Internet Crime Report, as summarised by Proofpoint.

• Earlier on this topic: IP address or identity: what should actually let someone in?
• Later on this topic: DNSSEC: why it exists, who uses it and what it has broken

Follow with the feed

Personal work and my own view, not my employer's. Sources are public.