Why Every Mail Setting Has To Be Right

Every name your machine looked up today, it believed, and I wrote a whole post about that. This one is about what happens to the mail after the lookup. The short version: it is sent to a server chosen by DNS, over a channel that is encrypted only if nobody objects, carrying a message anyone on the path can read and change, and almost none of the protections that were invented to stop that are switched on.

That is not one broken thing. It is seven of them, each designed so that when it is wrong, the mail goes through anyway. No error. The invoice arrives. The password reset arrives. They just also arrive at, or through, somebody who should never have seen them, and nothing anywhere says so.

This post is the argument for getting every one of those settings right, with the evidence for what each is worth. The three posts after it build it on real servers: Postfix, Microsoft 365, and Stalwart. This one is why.

The Attack The Standard Describes And Then Forbids

Start with the pipe between two mail servers, because it is the one most people think is already solved. STARTTLS is the command that upgrades an SMTP connection to TLS. Most mail servers support it, most mail is encrypted in transit, and that sounds like a solved problem until you read how the upgrade is offered.

The receiving server advertises STARTTLS in its greeting. The sending server sees the offer and takes it. Nothing signs that offer, and nothing protects it. So a machine on the path between them can delete the line, and here is the result, captured in a lab from a sender set to the ordinary opportunistic default:

 ~> EHLO client.test
[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
 -> Please pay invoice 1042 to sort code 20-00-00, account 12345678.
<-  250 2.0.0 Ok: queued as D6A84132069C

The sender did not see STARTTLS offered, so it did what opportunistic means: it sent anyway, in the clear. The machine in the middle read the whole thing, invoice and bank details included. The mail was delivered. No error reached anybody.

I did not invent that attack. RFC 3207, the standard that defines STARTTLS, describes it precisely in its own Security Considerations:

A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session.¹

The same section gives the defence, and it is the obvious one: be able to require TLS. “both clients and servers MUST be able to be configured to require successful TLS negotiation … for selected hosts before messages can be successfully transferred.”¹ So configure the receiver to require it, and the stripped session is refused:

[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
<** 530 5.7.0 Must issue a STARTTLS command first

Except you cannot, not on a public MX, because the same standard forbids it:

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.²

Read those two quotes together. The standard describes a man-in-the-middle attack, tells you the defence is to require TLS, and then tells you that your public mail server is not allowed to require it. Read that twice. That rule was written in 2002 to keep the mail flowing between servers that could not all do TLS yet. It is still in force, and it is why most of the internet still accepts mail in the clear, and why stripping STARTTLS still works today.

There is a competent version of the attacker, too. A receiver that requires TLS does not save you, because the attacker does not have to pass the session on in the clear. It can read the sender’s downgraded cleartext and open its own perfectly valid TLS connection to the receiver, which sees a good certificate and is satisfied. I showed both halves in the lab: the strip that exposes the sender, and a plain TLS client that the strict receiver accepts without complaint. The receiver’s policy cannot stop this. Only the sender refusing to send without authenticated TLS stops it, and that is the whole case for DANE³ and MTA-STS,⁴ which come later in this post.

Seven Settings, And How Each One Fails Open

The pipe is one of two problems. The other is identity: a message that arrives encrypted is still only claiming to be from whoever it says. So there are seven settings in play, split across those two jobs, and the thing they have in common is the thing worth learning first.

Here is each one: what it protects, and what it does when it is set wrong. Note the last column. It almost always says the mail still goes.

Six of those seven, set wrong, still deliver the mail. DANE is the exception. It is the only setting in the whole list that fails closed: get it wrong and your mail stops rather than leaking. Hold that thought, because it turns out to be the reason people are scared of it, and the reason it is the one worth most.

A word on each of the identity three, because the rest of this series leans on them. SPF lists the servers allowed to send for a domain, and ends in a rule: -all means “nobody else”, ~all means “nobody else, but deliver it anyway”. DKIM adds a cryptographic signature over the message, so any change shows, as long as the domain actually published a key to check it against. DMARC ties the two together and tells the receiver what to do when they fail, and whether they line up with the From: address the reader actually sees. These are RFCs 7208, 6376 and 7489, and they are each worth a post of their own.^{6 7 8}

DMARC alone lets a tampered invoice through

The identity layer has a gap exactly where it costs the most, and it is worth showing because “we have DMARC at reject” is the thing people say when they think they are covered.

DMARC passes if either SPF or DKIM passes and lines up with the From: domain. Either, not both. So take a real signed message from a domain, change the bank details in the body, and send it on from the same place:

SPF still passes, because it came from an authorised server. The DKIM signature now fails, because the body was changed. But DMARC only needs one aligned pass, and SPF gave it one, so DMARC passes and the message with the new account number is delivered looking exactly like the original. I captured this in the lab: Rspamd scored it R_SPF_ALLOW, R_DKIM_REJECT and DMARC_POLICY_ALLOW, and on its own it would have delivered. The only thing that stopped it was a rule that rejects outright on a broken signature. A domain at p=reject is not protected against the tampering that signature was there to catch. That is worth knowing before you call the job done.

DANE Is Only As Good As The DNSSEC Under It

Now the transport settings that actually stop the competent attacker, because they move the decision to the sender. DANE is the strongest of them. It lets a domain publish, in DNS, a fingerprint of the key its mail server will present in a TLSA record, so a sending server can refuse anything that does not match.⁹ No certificate authority involved, no trusting whoever answered the TLS handshake. The domain owner says “this is my key”, and that is the end of it.

Except DNS answers are forgeable, so a fingerprint published in plain DNS is worth nothing: the same attacker who strips STARTTLS can hand you a fake fingerprint to match a fake key. DANE only means anything when the DNS it lives in is signed with DNSSEC, so the fingerprint itself cannot be forged. That is the whole chain, and it is why this post sits in a series that started with DNSSEC. If you have not met it, the groundwork is in /en/dns/dnssec-the-root-is-signed-you-are-not/, and the one-line version is: the root is signed, every TLD worth naming is signed, and then it stops dead at the names people actually use.

The diagram shows two domains that both publish a TLSA record. One sits in a signed zone, with an unbroken chain of signatures from the root down to the fingerprint, so a sender can trust it. The other sits in an unsigned zone, so its fingerprint is just bytes anyone could have written, and a correct sender ignores it entirely and gets no DANE protection at all. Same record, published two ways. Only one of them can prove it is real.

The record to publish is 3 1 1: the server’s own key rather than a CA’s, the public key rather than the whole certificate, hashed with SHA-256. The middle number is the one that pays off operationally, because pinning the key rather than the certificate means the record survives every renewal as long as you keep the same key. The Postfix post has the full procedure and the trap that catches people, which is that the usual way of renewing certificates makes a new key every time and silently breaks the record. For here, the thing to carry is that 3 1 1 plus key reuse is a record you publish once and leave alone.

The House Rules, And What Each One Costs

Everything above turns into a short list of rules, and the next three posts hold real servers to them. They are not softened, and they are not free. Here they are with the bill attached, because a rule whose cost you are hiding is a rule you have not really decided to keep.

The forwarding cost is the one that bites, and it is real: reject on SPF alone and a message forwarded from somewhere not in the sender’s SPF record gets refused, because to the receiver a forwarder looks exactly like a forger. There are fixes, SRS and ARC,¹⁰ and the Postfix post shows the failure. The honest position is that these rules bounce some mail that a looser server would have delivered. That is the point of them. Some of that mail should have been bounced, and the rest is telling you about a forwarding setup that was relying on nobody checking.

It Fails Open, And Here Is The Proof

The claim this whole post rests on is that these settings fail open, quietly, so you cannot tell a working one from a broken one by looking. That is not a theoretical worry. Building the Postfix server for the next post, every one of these failures happened, and each was a setting that looked configured and did nothing.

Six real settings, each one from building the Postfix server for the next post. Five failed open: they delivered the mail, with no error, looking for all the world like they were working properly. The sixth, the stale DANE record, failed closed. It is the one everybody is frightened of, and it is the only one that protected the message instead of leaking it. The lesson sits right there in the last column of the diagram: the setting people avoid because it might stop their mail is the only one that behaves the way a security control is supposed to.

Every row of that is a capture, not a reading of a manual. The way you tell a working setting from a broken one is to send the message it is supposed to stop and watch what comes back, and I will say it once here and prove it three times across the rest of the series.

So Who Actually Does Any Of This?

It is one thing to say the settings matter. It is another to ask whether the organisations whose mail matters most have turned them on. So I did, with nothing but read-only DNS and a validating resolver, on 22nd October 2026: twenty-six domains that receive mail, the banks, the big providers, the German specialists and the certificate authorities, each checked for the seven things in this post.¹¹

Read down the DMARC column first, because it is the one that is mostly filled in. Most of these publish a DMARC policy, and most of the banks are at reject. DMARC is the setting that gets done, because it is the one an auditor asks about and the one a supplier can sell you, and it is visible: you can look it up and tick a box. It is also, on its own, the setting that let a tampered invoice through earlier in this post.

Now read the DANE column, the one setting here that cannot be downgraded and cannot be forged. Five domains out of twenty-six. Every one of them is a German provider or Proton. Not one UK bank. Not one of the certificate authorities, the companies whose entire business is vouching for keys. The strongest protection against the exact attack this post opened with is done by a handful of people who care, and by nobody who is merely compliant.

The banks are the sharpest row. Eight of them, every one at DMARC reject, and between them: no DANE, no enforced MTA-STS, and a single one, Monzo, reachable over IPv6. Two of the four certificate authorities publish no SPF record at their own apex. HMRC and NatWest have none either. These are not small outfits that never got round to it. These are the organisations that send you the mail you are most afraid of someone faking, and the protection they have is the badge that looks strongest and does least.

The IPv6 column is its own small scandal. Twenty of the twenty-six have no AAAA record on their mail server at all, so a sender running on an IPv6-only network cannot reach them, and that number is going one way. I wrote /en/networking/we-never-ran-out-of-addresses/ about the industry’s refusal to finish that job, and here it is again, in the mail path this time. It is the same shape as the gov.uk census in /en/dns/dnssec-the-root-is-signed-you-are-not/: the hard part was done years ago, the registries give it away, and the people who should most obviously use it have not. Central gov.uk is not even in the table, because it publishes no MX at all. It does not receive mail. That is one way to pass the test.

If You Are Still Not Doing This, Can You Call Yourself A Professional?

Every standard named in this post, and the census underneath it, point one way: this is not a research problem, it is a switching-on problem, and the switching-on is not being done by the people best placed to do it. When the evidence is that lopsided, the question stops being academic and becomes one you have to answer about your own servers. If you run mail for an organisation that handles other people’s money or other people’s health, and your MX does no DANE, enforces no MTA-STS and cannot be reached over IPv6, can you call that a professional job?

There are three honest answers, and only the first two hold up. Yes, with a reason written down and a date against it: you are on a platform that does not offer DANE yet, you have raised it, and there is a line in next year’s plan. That is a professional managing a real constraint, and it is fine. Yes, because you did not know, and now you do, and you are going to go and find out where your server stands this week. Nobody started knowing this. And no: you knew enough to be uneasy, you have read this far, and you will close the tab and change nothing, because the mail is flowing and no error is being thrown and nobody is making you. That last one is not a knowledge gap. It is a decision to let a thing you are responsible for stay broken because broken is quieter.

The standard does not make you do it. That is the entire problem, and it is also the entire point. Knowing is not something that happens to you, and nobody is going to come and tell you your mail server has been quietly sending in the clear for two years. As such, making sure you know is the job, and it is nobody else’s.

A Standard Is A Promise You Keep When Nobody Is Watching

The parts of this were all finished years ago. STARTTLS is from 2002, SPF and DKIM and DMARC are a decade old or more, DANE for mail was specified in 2015, MTA-STS in 2018. None of it is behind a licence, none of it needs a vendor, and the registries that would carry the DNSSEC records give them away. The hard engineering is done. What is left is the easy part, the part that is only easy if somebody bothers: turning it on, and checking it is actually on, and keeping it on when the certificate renews and the record has to follow.

That last part is the whole of it, really. A standard is not the document. The document has existed for twenty years and the mail still goes in the clear. A standard is a thing you keep when there is no error message making you keep it, when the mail would flow just the same if you quietly let it lapse, when the only person who would ever know is you. Every one of these settings fails open precisely so that nobody is forced to care. Which means caring is the entire job.

You do not get a reward for it. The invoice that was not altered looks exactly like the invoice that was. The password reset that nobody read in transit looks exactly like the one somebody did. The only difference is on the days something tried, and on those days the person who turned it all on and checked it was working never finds out they were attacked, because it did not work. That is what doing the job properly looks like from the outside: nothing happening, for reasons nobody can see.

So get every setting right anyway. Not because anyone is checking, because nobody is. Do it because you are the one who said the mail was safe, and round here that still counts for summat.