Email has no built-in way to prove who sent a message. Anyone can put you@example.com in the From field. SPF, DKIM and DMARC are the three DNS records that fix this, and since 2024 Gmail, Yahoo and Microsoft reject or junk bulk mail from domains that lack them. This is what each does and the records to add.
SPF — which servers may send for your domain
A TXT record on the bare domain listing the IPs and hosts allowed to send mail from example.com:
example.com. TXT "v=spf1 a mx include:_spf.google.com -all"Reading it: a — the domain's own A record IP may send; mx — so may the mail servers in the MX records; include: — and everything Google's SPF lists; -all — anyone else fails.
For a Plesk server that sends its own mail, v=spf1 a mx -all is usually complete. If a newsletter tool or CRM also sends as you, add their include: — they document it. Rules:
- Exactly one SPF record. Two records means SPF fails for everyone.
- At most 10 DNS lookups across all the
includes. Exceed it and SPF fails silently; check with a validator. - Use
-all(hard fail) once you are sure the list is complete,~all(soft fail) while you are finding out.
DKIM — a signature proving the message was not altered
The sending server signs each message with a private key; the public key sits in DNS so receivers can verify it. The record lives under a selector:
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."You never write the key by hand. In Plesk: Mail → Mail Settings → the domain → tick "Use DKIM spam protection system to sign outgoing email". Plesk generates the key and, if it hosts your DNS, adds the record. If DNS is elsewhere, copy the record Plesk shows into that provider. For Google Workspace it is under Apps → Google Workspace → Gmail → Authenticate email, selector google.
Check it published:
dig default._domainkey.example.com TXT +shortDMARC — what to do when SPF or DKIM fail, and where to report
A TXT record at _dmarc:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"p=is the policy:none(just report),quarantine(junk folder),reject(bounce).rua=is where receivers send daily aggregate reports. You will get XML files; a free service such as dmarcian or Postmark's DMARC tool turns them into a readable dashboard.adkim/aspfr(relaxed) allows subdomains to align;s(strict) requires an exact match.
Start at p=none for two weeks, read the reports to find any legitimate sender you forgot (the office printer, the invoicing app), add them to SPF, then move to quarantine and finally reject.
The complete set for a Plesk mail server
example.com. TXT "v=spf1 a mx -all"
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<from Plesk>"
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Plus the two records that are not yours to add but must exist: a PTR (reverse DNS) for the server IP that matches the mail hostname, and an A record for that hostname. Your hosting provider sets the PTR; see reverse DNS and why email needs it.
Testing
Send a message to a fresh Gmail account and open Show original. It shows SPF: PASS, DKIM: PASS, DMARC: PASS — or exactly which one failed. For a fuller report, send to the address that mail-tester.com gives you and read the score breakdown.
From a terminal, check all three records exist:
dig example.com TXT +short | grep spf1
dig default._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +shortWhat each failure looks like
| Symptom | Likely cause |
|---|---|
| Mail from the website contact form is junked, mail from Outlook is fine | The web server's IP is not in SPF |
| Everything to Gmail lands in spam since a date | No DMARC, or DKIM stopped after a Plesk reinstall |
| Forwarded messages fail DMARC | Expected: forwarding breaks SPF; DKIM survives if the forwarder does not alter the body |
| "SPF PermError" | Too many lookups, or two SPF records |
Every VPSPioneer plan creates SPF and DKIM automatically when a domain is added, and the mail server IPs have matching PTR records. Why emails go to spam covers the reasons beyond authentication.