Anyone can send email as your domain
Email was designed with no way of checking the sender. As with the return address on the back of an envelope, whoever sends a message can write any address they like: if the domain is not protected, a fraudster can send your customers an email from accounts@yourdomain.it, with your name prominently displayed and an invoice with a different IBAN. The customer pays, the money disappears, and the angry phone call comes to you.
Three checks published in the domain's DNS let anyone receiving your email tell genuine messages from forged ones. You do not need to change email provider, but the checks have to be switched on methodically.
The three checks, without jargon
SPF (Sender Policy Framework): a list, published in the DNS, of the servers authorised to send email for your domain. The receiver checks whether the server that delivered the message is on the list.
DKIM (DomainKeys Identified Mail): a digital signature added to every message by the server that sends it. The receiver verifies it with a public key published in the DNS: if the message has been altered, or does not come from whoever holds the key, the signature does not match.
DMARC (Domain-based Message Authentication, Reporting and Conformance): the rule that tells recipients what to do with messages that fail the checks, and asks them to send you a report on what they have received in your name.
DMARC adds a requirement that is often overlooked: alignment. It is not enough for a message to pass SPF or DKIM for any domain at all; the verified domain must match the one the recipient sees in the From field. This is what stops a fraudster from passing the checks with their own domain while displaying yours.
The three DMARC policies
| Policy | What it asks the receiver to do | When to use it |
|---|---|---|
| p=none | No action: deliver as usual, but send reports | At the start, to see who is sending in your name |
| p=quarantine | Treat messages that fail as suspicious, usually by moving them to spam | Once the legitimate senders have been fixed |
| p=reject | Reject messages that fail | The end goal: fake messages are not delivered |
Since February 2024, Google and Yahoo have required SPF, DKIM and DMARC from anyone sending large volumes of email to their users. Even if you do not send newsletters to thousands of people, this is the direction of travel: a legitimate invoice from a domain that has not been configured risks ending up in spam just like a fake one.
The first step: who sends in your name
The real work is knowing who needs to appear in the records. Almost every company sends email in its own name from more places than you would expect:
- business email, for example Microsoft 365;
- the ERP that sends invoices, payment reminders and order confirmations;
- the newsletter platform;
- the CRM used by the sales team;
- the website, with its contact forms and online orders;
- the phone system that forwards faxes and voicemails by email.
When authorising them in SPF, there is a technical limit you need to know about: the SPF standard (RFC 7208) allows at most 10 DNS lookups to check a record. Every service added with an "include" uses at least one, the limit is reached sooner than you might think, and once it is exceeded SPF fails even for legitimate messages.
The process, one step at a time
- Inventory: every service that sends email in the domain's name, with the provider of each one.
- SPF and DKIM configured for each service, staying within the lookup limit.
- DMARC at p=none, with an address that receives the reports. For a few weeks you read them: they show who is sending in your name, who passes the checks and who does not. Often a service turns up that nobody had listed.
- Fixing the senders that fail, one by one, working with their respective providers.
- Moving to quarantine, while continuing to read the reports.
- Finally, moving to reject, once the reports show that only fake messages are failing.
Common mistakes
- Going straight to reject. The invoices from the ERP, sent from a provider's server that was never authorised, are rejected by your customers' mail servers. You find out when a customer phones to ask where they are.
- Stopping at p=none. The record is there, the reports arrive, nobody reads them. The domain can be spoofed just as before.
- Forgetting the domains that do not send email. The old brand, the domain bought defensively: if they do not send email, you declare this with an SPF record that authorises no servers and a DMARC record set to reject. Otherwise they become the perfect sender for a scam.
- Nobody responsible for DNS. In the story Seven suppliers, no one in charge, email was down for three days, most of them spent working out whose job it was. Put in writing who is allowed to change these records, as we explain in the guide on IT that lives in one person's head.
These checks protect your domain from people who forge it, but they do not stop someone who registers a domain similar to yours with one letter changed. For that you need people trained to recognise phishing.
In short
SPF says which servers can send for your domain, DKIM signs the messages, DMARC decides what to do with those that fail the checks and sends you reports. You start with an inventory of who sends in your name, observe at p=none, fix the senders and only then move to reject, without forgetting the domains that do not send email.