The basics

DMARC, SPF and DKIM explained

Three abbreviations that together decide whether an email carrying your domain name really was sent by you. Below you can read it in plain language, and after that the technical detail.

In one sentence

Imagine that anyone in the world could send letters on your letterhead and with your signature, and the postal service never checked whether that was right. That is how ordinary email works. SPF and DKIM are two ways of adding a mark of authenticity, and DMARC is the rule that tells the receiving mail server what to do when that mark is missing or does not add up.

Part 1

SPF: who is allowed to send on your behalf?

SPF (Sender Policy Framework) is a list in your DNS naming the mail servers that have permission to send email on behalf of your domain. Think of a guest list at the door: if a server is not on the list, it may not present itself as a sender for your domain.

Every system that sends mail for you, your own mail server, your newsletter service, your accounting package, has to appear in this record. Forget one, and mail from that system can be seen as forged.

Example DNS record (TXT)
v=spf1 include:_spf.google.com include:servers.invoicingtool.com -all

-all means: anything not on this list is not allowed. This is the strictest setting, and the one we recommend.

Example header in a sent email
DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; s=selector1;
h=from:to:subject:date;
b=Gh8s0aQm...(digital signature)

The receiving server recalculates the signature and compares it with the public key in your DNS. If they match, the content was not altered on the way.

Part 2

DKIM: was the email altered on the way?

DKIM (DomainKeys Identified Mail) puts a digital signature in every outgoing email, based on a secret key that only your mail server knows.

The receiving server fetches the matching public key from your DNS and checks whether the signature adds up. That proves two things: the email really came from a server with the right key, and the content was not changed on the way.

Part 3

DMARC: the rule that brings SPF and DKIM together

DMARC (Domain based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do when an email fails both SPF and DKIM, and sends you a daily report of what happened.

p=none

Monitor only

Email is always delivered, even when the check fails. You still receive the reports. An ideal starting point.

p=quarantine

Send to spam

Email that fails the check is marked as suspicious by the recipient, and usually moved to the spam folder.

p=reject

Reject

Email that fails the check is refused and never delivered. This is the end goal for a protected domain.

Example DMARC DNS record (TXT on _dmarc.example.com)
v=DMARC1; p=quarantine; sp=quarantine; pct=100; fo=1; rua=mailto:rua+1453@reports.duzmarc.nl; ruf=mailto:rua+1453@reports.duzmarc.nl; adkim=s; aspf=s;
v= the version of the protocol, always DMARC1.
p= the policy for your main domain: none, quarantine or reject.
sp= the policy for subdomains specifically, separate from p=.
pct= the percentage of email the policy is applied to, handy for building up gradually.
fo= when a forensic (ruf) report is sent, for instance on every failed check.
rua= where the daily summary reports (aggregate) are sent.
ruf= where forensic reports about individual failed emails are sent.
adkim= / aspf= strict (s) or relaxed (r) alignment between domain names.

Alignment: SPF or DKIM must not only pass, it also has to belong to the same domain as the sender address in the "from" field. Only then does the email count as trustworthy for DMARC.

Forensic reports: DuzMarc processes forensic (ruf) reports too, as soon as they arrive. Note that not every mailbox provider sends these by default; the daily summary reports (rua) are available everywhere.

Subdomains: alongside your main domain you can add and monitor individual subdomains in DuzMarc, each with its own policy and its own reporting.

Bonus part

TLS RPT: is the connection itself secure?

Where DMARC, SPF and DKIM are about the sender, TLS RPT (SMTP TLS Reporting) is about the connection your email is delivered over. It reports when a receiving server could not set up an encrypted (TLS) connection with your mail server.

Without this reporting you often never notice that email was sent unencrypted, or that a connection failed because of an expired certificate. DuzMarc processes these TLS reports just like DMARC reports, automatically and clearly, available from the Pro subscription onwards.

Example TLS RPT DNS record (TXT on _smtp._tls.example.com)
v=TLSRPTv1; rua=mailto:rua+1453@reports.duzmarc.nl

As with DMARC, rua= decides where the daily reports about failed TLS connections are sent.

Step by step to reject

Why you should not jump straight to reject

If you forget a legitimate sender in your SPF record, p=reject can block it immediately. That is why you build up calmly.

Step 1

p=none

Just watch, and map every sender through DuzMarc.

Step 2

Finish SPF & DKIM

Add every legitimate sender and get them passing.

Step 3

Raise pct

Apply quarantine or reject to a larger share of the traffic, gradually.

Step 4

p=reject

A fully protected domain, with spoofing actively refused.

DuzMarc shows you at any moment whether you are ready for the next step.

More questions about DMARC, SPF or DKIM?

The knowledge base answers the questions we hear most, from beginner to specialist.

Go to the knowledge base Create account