Adding SPF, DKIM and DMARC records: the typical mistakes at every DNS provider
SPF, DKIM and DMARC are quickly explained – and yet adding them often goes wrong. Every DNS provider labels the fields differently, sometimes appends the domain automatically and sometimes not, and long keys don't fit into one field. This article shows the pitfalls that are the same at every provider.
The fields of a DNS record
Whether Cloudflare, GoDaddy, Namecheap, Route 53, IONOS, Hetzner or Plesk: every record consists of the same parts, even if they're named differently.
| Field | Other names | Example |
|---|---|---|
| Name | Host, hostname, subdomain, prefix | _dmarc |
| Type | Record type | TXT |
| Value | Content, target, data | v=DMARC1; p=none; rua=mailto:… |
| TTL | Time to live, cache duration | 3600 |
The name: the most common source of errors
Almost all interfaces automatically append your domain to the name. If you enter the full name there, you end up with a doubled record:
| Wanted | Input in the “Name” field | Wrong (common) |
|---|---|---|
example.com (the domain itself, e.g. SPF) | @ or leave empty | example.com → often results in example.com.example.com |
_dmarc.example.com | _dmarc | _dmarc.example.com → _dmarc.example.com.example.com |
s1._domainkey.example.com | s1._domainkey | s1._domainkey.example.com |
Some interfaces, on the other hand, expect the full name, often with a trailing dot (_dmarc.example.com.). A look at an existing record, such as the one for www, shows you which notation your provider uses.
Tip: the underscore at the start of _dmarc and _domainkey is part of the name. Some older interfaces reject it – then usually only support or switching DNS provider helps.
TXT records: quotation marks and long values
- Quotation marks: most interfaces add them themselves. If you enter them as well, they sometimes end up in the value and the record is invalid. If in doubt, enter the value without quotation marks and check afterwards.
- Long DKIM keys: a single text string in DNS may have at most 255 characters; a 2048-bit key is longer. Good interfaces split it automatically. With others, you have to split it into several quoted strings:
"v=DKIM1; k=rsa; p=MIIBIj…" "…IDAQAB". Receivers join the parts back together without spaces. - Only one SPF record: if there's already a
v=spf1record, extend it instead of creating a second one. Two SPF records make SPF invalid. - Invisible characters: when copying from PDFs or chat apps, typographic quotation marks (“”) or non-breaking spaces often slip in. Copy values directly from the source whenever possible – at Postwacht via the “Copy” button.
CNAME instead of TXT for sending services
Many newsletter and sending services give you a CNAME record for DKIM instead of a TXT record, for example:
s1._domainkey.example.com. CNAME s1.domainkey.u12345.sending-service.example.
The advantage: the service can rotate its key without you having to change anything. It's important to create exactly the type the service specifies. A CNAME also must not exist alongside another record with the same name.
TTL and waiting time
The TTL defines how long other servers cache an answer. A new record is usually visible within minutes. If you changed an existing record, the old version can live on for as long as the old TTL – with 86400, up to a day. If you plan changes, set the TTL to 300 to 3600 seconds beforehand.
A lookup that returned “nothing found” before you added the record is also cached. If a test still shows an error right after adding the record, wait a few minutes and test again.
How to check the result
On the command line:
dig TXT example.com +short dig TXT _dmarc.example.com +short dig TXT s1._domainkey.example.com +short
On Windows, nslookup -type=TXT _dmarc.example.com works. The easiest way, though, is with a real email: the test on the home page immediately shows whether SPF, DKIM and DMARC are found and valid – and suggests the matching value to copy for every missing record.