The conversation usually starts like this: "we sent the proposal on Monday, the client says they never received it". Or: "the invoice was sent, but it ended up in spam, and now payment is three weeks late".
People who hear these phrases tend to treat them as accidents. They are not. In the overwhelming majority of cases, they are the predictable result of a missing configuration. And the good news is that the fix is quick, cheap and permanent.
This article explains, without jargon, what lies behind it. You will not need to configure anything. You will need to know what to ask.
The problem these three acronyms solve
Email was designed in the 1980s, on a network where everyone knew each other. So it was born with a built-in weakness: any computer in the world can send a message saying "I am your bank", "I am your supplier" or "I am your company's finance director". The protocol does not ask for credentials. It accepts the claim.
For decades, the answer was filtering. Receiving systems learnt to be suspicious, to analyse patterns and to send anything that looked suspicious to spam. The side effect is familiar to any business: legitimate messages get caught in the net too.
SPF, DKIM and DMARC tackle this problem at the root. Instead of guessing who can be trusted, they allow each organisation to declare publicly who is authorised to send on its behalf, and allow receiving systems to check that declaration.
The three, in plain language
Imagine a letter arriving at a reception desk.
SPF is the list of who can send. The company publishes, in a public record for its domain, which servers are authorised to send messages on its behalf. When a message arrives, the receiving system checks the list and verifies whether the sender is on it. It is the equivalent of keeping a list of authorised couriers at the front desk.
DKIM is the wax seal. Every message sent carries a cryptographic signature that only the organisation can produce. The recipient checks the signature and learns two things: that the message really came from whoever claims to have sent it, and that no one tampered with it along the way. It is the seal on the envelope.
DMARC is the instruction on what to do when something fails. Without it, each system decides for itself. With it, the organisation says explicitly: if a message claims to be from me and fails the checks, ignore it, quarantine it or reject it. And, crucially, DMARC sends back reports: it becomes possible to see who is trying to send messages in the company's name.
The three work together. On their own, each solves half the problem.
What changed in 2024 and 2025
For years, this was treated as a technical recommendation. Not any more.
In February 2024, Google and Yahoo started requiring SPF, DKIM and DMARC from anyone sending more than five thousand messages a day to their consumer mailboxes, with a spam complaint rate below 0.3% and a one-click unsubscribe mechanism. In May 2025, Microsoft adopted equivalent requirements and began rejecting non-compliant messages on its consumer services.
Translated into management language: the world's largest email operators stopped treating authentication as a preference and started treating it as a condition for delivery. An organisation without these settings is not just risking the spam folder. It is risking outright rejection.
What it costs when it is not done
The damage rarely shows up on an invoice, which is why it goes unnoticed.
| Symptom | Real cost |
|---|---|
| Sales proposals landing in spam | Deals lost without ever knowing why |
| Invoices that do not arrive | Late payments and finance time spent resending |
| Clients asking "is this email really from you?" | Hours of customer support, and distrust in the brand |
| Third parties using the domain for phishing | Reputational damage, and a degraded domain reputation |
| Campaigns with extremely low open rates | Communication spend with no return |
The last point deserves special attention from anyone who communicates regularly. A newsletter with a very low open rate is almost always seen as a content failure. Often it is an authentication failure: the message did not reach the main inbox, it landed in the promotions or spam folder, and no one saw it to open it.
One step further: making the brand appear in the inbox
When all three are properly configured, an extra possibility opens up: BIMI, which lets the organisation's logo appear next to its messages in the recipient's inbox.
It is not a cosmetic detail. In a list of thirty black and white messages, the one with a logo stands out before it is read. And it works as a sign of legitimacy: systems that support BIMI only show the logo to senders with authentication in order, which makes its presence a small guarantee that the message is genuine.
What to ask whoever manages your email
You do not need to know how to configure it. You need to ask five questions, and demand clear answers:
- Does our domain have SPF, DKIM and DMARC configured? If the answer is "I think so", it does not.
- What policy is our DMARC set to? The options are do nothing, quarantine or reject. Many organisations stay for years on the first, which is useful for observing but does not protect.
- Who receives and reads the DMARC reports? They are what reveal attempts to misuse the domain. Without someone reading them, the mechanism is only half working.
- Are all the services that send on our behalf authorised? Newsletter platforms, invoicing systems, CRM, online shops. This is where surprises almost always turn up.
- Who takes ownership of this configuration, and maintains it? Domains change, providers change, new services come in. A configuration that was correct in 2023 may be incomplete today.
The conclusion, in two lines
This is not a technical matter that management can delegate and forget. It is the difference between the organisation's communications arriving or not, and between the brand being used or not to deceive clients.
Configuring it takes hours. Not configuring it costs business every month, without anyone being able to count it.