SPF, DKIM, DMARC: Email Authentication

The base email protocol contains no authentication: anyone can put anything in the From field. Three DNS records (SPF, DKIM, DMARC) fill that gap, and together they stop outsiders sending mail in your company's name.

The trouble is that in many organisations they are configured but do not work.

What each record does

SPF lists which servers may send mail for the domain. The recipient checks whether the sending IP appears on the list.

DKIM applies a cryptographic signature to the message. The recipient verifies it with a public key fetched from DNS, confirming the message was not altered in transit and genuinely originated from the domain.

DMARC ties the two together: it states what should happen when checks fail, and where to report it. This is the most important one, because SPF and DKIM alone only signal, they do not block.

The most common mistake: DMARC left in monitoring mode

The p=none setting blocks nothing and merely requests reports. It suits the first step of a rollout, but in many organisations it stays there for years because nobody dares move on.

Two levels of enforcement:

• p=quarantine: failing mail goes to the junk folder
• p=reject: failing mail is refused by the recipient

Until p=reject is in place, anyone can send mail in your company's name and it will arrive.

Rollout order

1. Sender inventory. Which systems send mail for the domain? Besides your own mail platform there is typically a newsletter tool, invoicing, CRM, HR system, monitoring. All must be added to SPF, otherwise you will block your own mail.

2. Configure SPF. Mind the ten DNS lookup limit: too many include entries make SPF invalid. This is a common problem with many services.

3. DKIM on every sender. The main platform is not enough: every system sending in your name needs its own signing key.

4. DMARC p=none with reporting. Within a few weeks it becomes clear which senders fail and which failures are legitimate.

5. Gradual tightening. p=quarantine at a partial percentage, then full, finally p=reject.

Worth configuring too

BIMI. Displaying your logo beside the message in the recipient's client. It requires enforced DMARC, so it only arises once the above is done. Brand value and a trust signal.

MTA-STS. Enforces encrypted transport for mail. Without it, encryption is optional and can be downgraded.

External sender marking. Not a DNS record but a rule in your own platform: externally originating mail carries a visible marker. Against executive-instruction phishing this is one of the most effective controls.

What it does not solve

Email authentication prevents mail being sent in your domain's name. It does not prevent:

• mail from a lookalike domain (arl1tech.hu),
• technically flawless mail from a compromised partner account,
• deception through the display name.

Training, process and technical filtering together answer those. We covered this in detail in our phishing article.

Verification

The configuration can be checked in minutes: send a message to an external mailbox and look at the Authentication-Results header. It shows whether SPF, DKIM and DMARC passed.

If any shows fail or none, there is work to do. Reviewing the full mail architecture is part of our IT security services.