A client calls you, furious: they received an invoice from your company with an account number that is not yours. The e-mail carried your address, your signature, your logo. You never sent anything, and no one broke into your mailbox.
This scenario requires no hacking at all. It exploits a flaw built into e-mail from the start, and three settings put an end to it. You still need to go all the way, because the most common configuration in French-speaking Switzerland gives the illusion of protection while blocking nothing.
Why can anyone write in your name?
E-mail was designed at a time when the handful of connected networks trusted each other. No one had anticipated fraud. As a result, the “sender” field of a message is plain text, filled in however the sender chooses.
The analogy holds in one image. On a postal envelope, you write whatever return address you like on the back. The post office checks nothing. It delivers the envelope, and the recipient reads whatever you wrote. E-mail works in exactly the same way.
A scammer can therefore send, from their own server, a message displaying
[email protected]. No access to your mailbox is needed at all. This
is what makes the technique so accessible, and so widely used both in
CEO fraud and in fake invoice e-mails.
SPF, DKIM and DMARC were bolted onto e-mail to fix this flaw. They let the server receiving a message ask a simple question: does this message really come from where it claims to?
SPF: the list of authorised senders
SPF answers a single question: which servers are allowed to send e-mails for your domain?
Imagine leaving at your building’s reception the list of people authorised to collect your mail. Anyone who shows up without being on the list is turned away. SPF is that list, published in your domain’s DNS zone, meaning the public directory that tells the internet where to find your website and your mailbox.
In practice, you declare there the servers of your mailbox host, those of your newsletter tool, those of your invoicing software. When a message arrives elsewhere claiming to come from you, the receiving server checks this list and notices that the actual sender is not on it.
SPF has a known limitation: it checks the sending server, not the content. And it breaks when a message is forwarded automatically, for example by a redirect. That is why it never comes alone.
DKIM: the signature that proves integrity
DKIM adds an electronic signature to the message, invisible to the reader, calculated by your server at the moment of sending.
The physical equivalent is the wax seal on a letter. It proves two things: that the letter really comes from whoever holds the seal, and that the envelope was not opened along the way. If anyone alters a single line of the message, the signature no longer matches.
The public key used to verify this signature is also published in your DNS zone. The receiving server retrieves it, redoes the calculation, and compares. In practice, your mailbox host generates these keys for you; your job is to publish them correctly, and to do the same for every third-party service that sends on your behalf.
DMARC: the decision, and above all the reports
SPF and DKIM only observe. They decide nothing. A message that fails both tests can perfectly well land in the recipient’s inbox, main folder included, if nothing states what should be done with it.
DMARC fills that gap. It is a record, again in the DNS zone, that answers two questions: what to do with messages that fail, and who should receive a report on what is happening.
| Policy | What happens | Use |
|---|---|---|
p=none | Nothing. The message is delivered normally | Observation phase only |
p=quarantine | The message goes to junk | Intermediate hardening step |
p=reject | The message is refused, it never arrives | Final goal |
The most useful part of DMARC is often ignored: the reports. By specifying a destination address, you receive every day, from the major mailbox providers, a summary of the messages sent worldwide with your domain as the sender, along with the test results. This is what lets you discover both impersonation attempts and your own misconfigured services.
The trap: a DMARC record that prevents nothing
Here is the most common mistake, and it is nearly universal among SMEs that have taken a first step.
A provider sets up the three records. The box is ticked, the owner considers
the matter settled. A quick test confirms that DMARC is indeed present.
Except the policy is set to p=none, the recommended starting value so as to
break nothing, and no one has ever come back to change it.
A fraudulent e-mail carrying your address fails both SPF and DKIM, and it is delivered anyway to your client. The none policy literally tells the receiving server to do nothing in particular. Having DMARC is therefore not the question; the question is which mode it is set to.
This observation phase has real value, but it is meant to last a few weeks, just long enough to read the reports. Left in place for three years, it produces only one thing: a false sense of security.
How to tighten up without blocking your own e-mails?
Why not jump straight to reject? Because the risk is real, and it can turn
against you.
Almost every company sends e-mails from more places than it realises: the main mailbox, the invoicing software that sends invoices on behalf of accounting, the newsletter platform, the CRM that follows up with clients, the website’s contact form, sometimes an e-signature or appointment booking tool. Each of them sends on your behalf.
If you tighten the policy having forgotten one of them, its messages will simply be refused. Your invoices will stop arriving. No one will warn you, because a rejection is silent from the business sender’s point of view. You will find out through clients following up because they never received anything.
First list in writing every tool that sends an e-mail in your company's name, by asking accounting, marketing and administration. Then publish DMARC at p=none with a reporting address, and read those reports for several weeks: they reveal senders no one had mentioned. Only then move to quarantine, keep watching, then to reject. The useful work is the inventory, not the configuration line.
This progression is within reach of any SME, and it costs nothing beyond attention. It simply requires not stopping at the first step, which is precisely where most companies stop.
What do SPF, DKIM and DMARC actually protect?
A strict policy has very concrete effects. It stops a scammer writing to your clients from your exact address to give them a fake account number. It removes the most credible variant of CEO fraud, the one where the message appears to come from management itself. It also reduces the damage of an e-mail compromise by limiting the channels that can be exploited.
It does not do everything. An attacker can register a domain that looks like yours, with one letter missing, and authenticate it perfectly for their own purposes. They can display your director’s name from a free address. And none of this protects your inbox, which relies on other measures detailed in the 10 essential measures.
To find out where you stand, our e-mail check tool queries your domain’s DNS zone and tells you whether the three protections exist, and which DMARC mode is set. It is an honest starting point.
Implementation remains. Editing a DNS zone is not difficult in itself, but it is an operation where a mistake costs you immediately, in messages that stop arriving. Mapping every sender, interpreting technical reports and choosing the right moment to tighten the policy requires knowing where to look. These settings form a solid foundation, they do not replace a review of your actual situation. Getting support on this specific step costs less than a week of blocked invoices.
The other priority measures are grouped in the Best practices pillar, and the cyber check-up situates you in a few minutes.