Almost every email problem that comes to me for an audit boils down to one thing: missing or wrong configuration of three sender authentication mechanisms. SPF, DKIM and DMARC are not admin esoterica, they are the basis of whether your emails even arrive and whether someone can impersonate you. I explain them one by one, and then show how to deploy them without shooting yourself in the foot.

Why this works at all

The email protocol was created at a time when no one assumed fraud. By default, any server can send mail on behalf of any domain. SPF, DKIM and DMARC are a trust layer added later, which lets the recipient’s server check whether a message really comes from an authorised source. Without them, a company domain is an easy target for impersonation, and emails land in spam because nothing confirms their authenticity.

SPF, or who may send on your behalf

SPF (Sender Policy Framework) is a list of servers authorised to send mail from your domain. You publish it as a TXT record in DNS. The recipient’s server checks whether the sender’s address is on the list.

A few rules that save you from typical mistakes:

  • One SPF record per domain. Two records is an error that invalidates both.
  • A limit of ten DNS lookups. Exceeding it causes SPF to fail. Watch out for include chains to many services.
  • How the policy ends. Use -all (hard fail) or ~all (soft fail). An open +all opens your domain to everyone.
  • Include all senders. Main email, sending systems, CRM, forms on the website.

DKIM, or the message signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the email. The sending server signs the message with a private key, and the recipient verifies it with a public key published in DNS. If the signature matches, the message has not been changed along the way and really comes from that domain.

In practice you enable DKIM in your email provider’s panel, which generates a key pair and gives you a record to enter in DNS. It is worth using keys of at least 2048 bits and remembering to rotate the key from time to time.

DMARC, or the rule and the reports

DMARC (Domain-based Message Authentication) ties SPF and DKIM into a single policy. It tells the recipient’s server what to do with a message that fails verification, and lets you collect reports on who is sending on behalf of your domain.

A DMARC policy has three levels, deployed gradually:

  1. p=none. You block nothing, you only collect reports. The starting point.
  2. p=quarantine. Suspicious emails go to spam.
  3. p=reject. Emails that fail verification are rejected. The end goal.

The biggest mistake I see is setting p=reject straight away without an observation stage. The company then cuts off its own sending systems it had forgotten about, and spends a week not understanding why invoices are not arriving. Always start with p=none and read the reports.

A deployment order that does not hurt

The order matters. Done in reverse, it can block company email for several days.

  1. Inventory all sending sources: email, CRM, newsletters, forms, invoicing systems.
  2. Configure SPF to cover them all, for now with ~all.
  3. Enable DKIM at every provider that supports it.
  4. Publish DMARC with p=none and a reporting address.
  5. For two to four weeks, analyse the reports and close off any missing senders.
  6. Tighten SPF to -all, and move DMARC through quarantine to reject.

If the company uses Microsoft’s cloud, part of this work is simplified by a Microsoft 365 deployment, because DKIM and SPF guidance are well documented there. For bulk sending, newsletters and transactional systems, it is worth relying on dedicated email servers that look after the reputation of sending addresses.

BIMI, the step after DMARC

Once DMARC is working in enforcement mode, the way opens to BIMI (Brand Indicators for Message Identification). This is a mechanism that lets your company logo appear next to your emails in the recipient’s inbox. It is not necessary for deliverability, but it works for credibility and brand recognition. The condition is exactly a correctly deployed DMARC with a quarantine or reject policy, and in some services also a verified brand certificate. Treat BIMI as a reward for order in authentication, not a starting point.

What else affects deliverability

Three records are the foundation, but not the whole puzzle. Even with correct configuration, emails can land in spam if you neglect the rest.

  • IP and domain reputation. It is built over months and ruined in days by sending to an outdated list.
  • Quality of the recipient list. Sending to dead addresses and spam complaints lower the sender’s reputation.
  • Message content. All capital letters, suspicious attachments and link shorteners raise the spam score.
  • PTR record. A reverse DNS entry for the sending server, whose absence immediately lowers trust.

Common traps

  • Adding a new sending system without updating SPF, so its emails land in spam.
  • A forgotten subdomain that also sends mail.
  • No monitoring of DMARC reports, so no one notices impersonation attempts.
  • Too low a DNS limit in SPF after adding more services.

SPF, DKIM and DMARC are a configuration you set up properly once and then just watch over when things change. The effect is measurable: better deliverability and a domain resistant to impersonation. If you want to be sure all three records are set correctly and cover every sender, we will help you go through a configuration audit and deploy DMARC without the risk of cutting off your own mail.