How to set up SPF, DKIM and DMARC for your domain

Anyone can put your domain name in the "From" line of an email. SPF, DKIM and DMARC are three DNS-based checks that let receiving mail servers tell real messages from forged ones. Without them, mail from your domain is more likely to land in spam or be rejected, and criminals can impersonate you. All three are just DNS records, so you set them up where your domain's DNS is managed.

Why you need them

Big mail providers now expect authentication, particularly from anyone sending more than a trickle of email. If you run a website that sends order emails, a contact form or a newsletter, set up all three. Even if you send nothing, publishing a strict policy protects your domain from being forged.

If you are new to DNS, read DNS records explained first.

SPF: who may send

SPF (Sender Policy Framework) is a TXT record listing the servers allowed to send mail for your domain. A receiving server checks whether the sender is on the list.

A simple example for a domain that sends through its own server and a mail service:

v=spf1 ip4:203.0.113.10 include:_spf.mail-provider.example ~all

How to read it:

v=spf1 marks it as an SPF record.
ip4: allows a specific address.
include: allows everything your mail provider says it uses.
~all means "treat everything else as suspicious (soft fail)". -all means reject it, which is stricter. Start with ~all, and move to -all when you are confident the list is complete.

Rules to remember:

Only one SPF record per domain. Two records break SPF entirely. Merge them.
A limit of 10 DNS lookups. Each include: costs lookups, and going over fails the check.
List every service that sends mail as you: your server, your newsletter tool, your help desk.

DKIM: a signature on each message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The receiver finds your public key in DNS and verifies that the message was not altered and really came from your system.

The setup:

Your mail software or provider generates a key pair.
You publish the public key as a TXT record at a name like selector._domainkey.example.com.
The sender signs messages with the private key.

If you use a hosted provider, it gives you the exact record to paste, usually a CNAME or TXT. If you run your own mail server on a VPS, a tool such as OpenDKIM creates the keys. Keep the private key private, readable only by the signing service.

Long keys exceed the length of one DNS string. Many DNS panels split them automatically, but some need you to cut the value into quoted chunks. If verification fails, check that no characters were lost.

DMARC: what to do with failures

DMARC ties the two together. It tells receivers what to do when a message fails SPF and DKIM alignment, and where to send reports. It is a TXT record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The policy tag p has three values:

Policy	Meaning
`none`	Monitor only. Take no action, just send reports
`quarantine`	Treat failures as suspicious, typically spam
`reject`	Refuse failures outright

A safe path:

Start with p=none and read the reports for a few weeks.
Fix anything legitimate that fails, such as a forgotten sending service.
Move to quarantine, then reject.

"Alignment" means the domain in the visible From address must match the one authenticated by SPF or DKIM. This catches services that send "on your behalf" but sign with their own domain, which is why you must set up their DKIM for yours.

Test your setup

After publishing, check with:

dig example.com TXT +short
dig default._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short

Then send a message to a mailbox you control, open the full headers and look for spf=pass, dkim=pass and dmarc=pass. Free online checkers can also read your records and highlight mistakes. Allow time for DNS caches to expire after changes.

Common problems

Two SPF records. Merge into one.
Too many lookups. Reduce includes or remove services you no longer use.
Forgetting a sender. Your website's contact form may send through a different system from your newsletter.
A strict policy too early. Jumping to reject can silently block your own legitimate mail.
Mail that is forwarded can break SPF. DKIM survives forwarding, which is one reason to use both.
Reverse DNS. If you send directly from a VPS, ask your provider about a matching reverse DNS (PTR) record, and be aware that many providers restrict outgoing mail on port 25.

Should you run your own mail server?

Running a trustworthy mail server is hard work. Deliverability depends on IP reputation, careful configuration and constant monitoring. For most small sites, a reputable transactional or business mail provider is far less trouble, and you still publish SPF, DKIM and DMARC for your domain as above.

Summary

Record	Where	Purpose
SPF	TXT on the domain	Lists allowed senders
DKIM	TXT on `selector._domainkey`	Verifies message signatures
DMARC	TXT on `_dmarc`	Sets policy and reporting

Once these pass, your domain is much harder to forge, and your legitimate mail is far more likely to arrive. Keep the policy under review as you add or remove sending services. If your domain is hosted with us and you need DNS help, see How to connect a domain to your server.

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.