Expomatik Trade Fair Data Platform

SPF, DKIM and DMARC Explained: A Set-up Guide

What SPF, DKIM and DMARC do, what the records look like and in which order to set them up so providers can verify email sent in your domain's name.

Deliverability 8 min read

SPF, DKIM and DMARC are three DNS records that prove an email sent in your domain's name really comes from you. SPF lists the servers allowed to send for the domain, DKIM adds a signature showing the message was not changed, and DMARC tells receiving servers what to do when those checks fail.

Why do you need email authentication?

Email dates from the early days of the internet, and by design the “From” field is easy to forge. Anyone can send a message that claims to come from your domain. Gmail, Outlook and other providers run every incoming message through authentication checks to filter out such forgeries. Without your records, even a legitimate message cannot be verified and is treated as suspicious.

SPF
Sender Policy Framework (RFC 7208). Which servers may send for the domain.
DKIM
DomainKeys Identified Mail (RFC 6376). A signature that ties the message to the domain and shows it was not altered.
DMARC
Domain-based Message Authentication, Reporting and Conformance (RFC 7489). The policy for failures, plus reports.

What is SPF?

SPF is a TXT record that names the servers allowed to send email for your domain. When a receiving server gets a message, it asks: is this IP address allowed to send for this domain? If it is not on the list, the SPF check fails.

In practice SPF is one TXT record that includes the servers of every service you send through. The most common mistakes are publishing more than one SPF record, forgetting a sending service, and exceeding the limit of ten DNS lookups set by the standard.

What is DKIM?

DKIM adds a digital signature to every outgoing message. The signature is created with a private key on the sending server; the receiving server checks it with the public key you publish in DNS. If the signature matches, two things are proven: the message comes from your domain and it was not changed on the way.

DKIM is also a DNS record, usually a TXT or CNAME under a selector name. Your sending service gives you the key or the record, and you add it to your domain's DNS.

What is DMARC?

DMARCis a policy layer on top of SPF and DKIM. It has two jobs. It tells receiving servers what to do when a message fails authentication (do nothing, put it in spam, or reject it), and it asks them to send you regular reports on the mail sent in your domain's name. DMARC also checks alignment: the domain that passes SPF or DKIM has to match the domain in the From address.

The usual path is to start with the monitoring policy, read the reports until you are sure all legitimate mail passes, then tighten the policy step by step.

What do the records look like?

RecordExample (illustrative, for example.com)
SPF: TXT on example.comv=spf1 include:_spf.sending-service.example ~all
DKIM: TXT on selector._domainkey.example.comv=DKIM1; k=rsa; p=(public key from your sending service)
DMARC: TXT on _dmarc.example.comv=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The exact values come from your sending service and DNS provider. Copy them character by character: a single missing character breaks the check.

In what order should you set them up?

  • 1. SPF: one TXT record with the servers of your sending services.
  • 2. DKIM: publish the key from your sending service in DNS and switch signing on.
  • 3. DMARC: start with p=none and read the reports.
  • 4. Check: send a test message to yourself and confirm that the headers show “pass” for all three.
  • 5. Then build reputation: once the records pass, start with low volume and raise it gradually.

The order matters

Building volume before the records are in place is wasted effort: a message that cannot be authenticated does not build reputation, however carefully the volume is raised. Authentication first, then the preparation period.

Should you set the records up by hand?

You can, but DNS syntax errors are common and hard to diagnose. That is why systems that send from separate domains usually set up SPF, DKIM, DMARC and a custom tracking domain automatically and do not treat a sending address as ready until DNS has been verified. In Expomatik, Secure Mail works this way.

The step after the records is the preparation period; how the two work together is explained in how to build sending reputation for a new domain. Other reasons for messages landing in spam are covered in why emails go to spam.

Frequently asked questions

Do I need all three of SPF, DKIM and DMARC?
Yes, for any regular sending. Gmail requires SPF or DKIM from every sender and all three from bulk senders, and DMARC only works on top of SPF and DKIM. Together they let receiving servers check that your messages are genuine.
Can a domain have more than one SPF record?
No. A domain must publish a single SPF record. If you use several sending services, list them all in that one record, and keep the total number of DNS lookups within the limit of ten.
Which DMARC policy should I start with?
Start with p=none, which only monitors, and read the aggregate reports for a few weeks. When all legitimate mail passes, move to quarantine and then to reject.

This article is general information. DNS panel steps differ between domain providers; back up your existing records before making changes.

← All articles

Trade fair exhibitor lists with verified contact details, in your panel

Browsing is free of charge; no credit card required.

Create a free account