Foundations
Part of SPF, DKIM and DMARC: records and UK rules
SPF, DKIM and DMARC: records and UK rules
Learn what SPF, DKIM and DMARC records do, how DMARC alignment works, and how UK PECR and UK GDPR marketing rules sit alongside authentication.
What to take away
- SPF lists the servers allowed to send mail for your domain, DKIM signs each message so tampering is visible, and DMARC tells the receiving mailbox what to do when those checks fail.
- All three are DNS TXT records, so your registrar or DNS host controls them.
- Start DMARC at p=none to collect reports, then move to quarantine and reject once your legitimate mail passes consistently.
- Authentication proves who sent a message; UK marketing rules still govern whether you may send it at all.
What each record proves
Authentication is a claim about identity rather than content. A receiving server asks three questions: was this IP allowed to send, was the message signed and left intact, and what does the domain owner want done when those checks fail?
SPF vs DKIM vs DMARC
SPF
- What it holds
- Permitted sending sources
- Typical shape
- v=spf1 include:... ~all
- Where it sits
- Root domain, TXT
- Question answered
- Was this IP allowed?
DKIM
- What it holds
- Public key per selector
- Typical shape
- v=DKIM1; k=rsa; p=...
- Where it sits
- selector._domainkey, TXT
- Question answered
- Was it signed and intact?
DMARC
- What it holds
- Policy and reporting address
- Typical shape
- v=DMARC1; p=none; rua=...
- Where it sits
- _dmarc, TXT
- Question answered
- What to do on failure?
| Record | What it holds | Typical shape | Where it sits |
|---|---|---|---|
| SPF | Permitted sending sources | v=spf1 include:... ~all | Root domain, TXT |
| DKIM | A public key for one selector | v=DKIM1; k=rsa; p=... | selector._domainkey, TXT |
| DMARC | Policy and reporting address | v=DMARC1; p=none; rua=... | _dmarc, TXT |
The Sender Policy Framework sits at the root of the domain and names the permitted sources. It moves with your infrastructure, so a new sending platform can quietly break it.
DKIM signs the message with a private key and publishes the matching public key at a selector. If the body changes in transit, the signature fails and the receiver can see it.
DMARC checks whether SPF or DKIM passes and aligns with the domain in the visible From address; at least one must pass and align for DMARC to pass. SPF alignment compares the authenticated MAIL FROM domain with the From domain, while DKIM alignment compares the signing domain in the DKIM d= tag with the From domain. Relaxed alignment accepts matching organisational domains; strict alignment requires an exact domain match. DMARC's policy tells the receiver what to do when neither check passes in alignment.
Where the records live
The DNS host is whoever runs your nameservers, which is often not the company that sold you the domain.
Adding records at your registrar
- Open DNS panel for the zone
- Add root TXT with SPF policy
- Add selector._domainkey TXT for DKIM
- Add _dmarc TXT with p=none
- Wait for TTL, query live DNS
- Tighten to quarantine, then reject
Where DNS hosting and sending platforms fit
Few UK businesses run a mail server these days. A shared host, a newsletter platform or a CRM sends on your behalf, and each one expects a different DNS arrangement.
Delegation is the tidier option. You publish CNAME records that hand authentication for a subdomain to the platform, so key rotation happens without a ticket to your DNS provider.
Authentication can pass and mail can still misfile. The causes then sit in reputation or list quality, which is why legitimate UK email still lands in spam.
Testing before your next campaign
Do not trust a green tick in a dashboard. Send a real message to a mailbox you control at a large provider and read the authentication results in the full headers.
Check all three at once. SPF should show pass for the sending IP, DKIM should show pass with the selector you published, and DMARC should show pass with the policy you set.
Aggregate reports arrive as XML at the rua address. They are dense, but they show which sources send as your domain and where alignment breaks.
Records and consent are separate questions
A tidy DNS zone says nothing about permission. The Privacy and Electronic Communications Regulations 2003 govern marketing by electronic mail to individuals, and UK GDPR governs the personal data you hold about them.
The ICO guidance on direct marketing and electronic communications explains consent, soft opt-in and the records you should keep. Authentication does not change any of it.
Keep the DNS change log beside the campaign log: who added which record, when, and who approved it. The UK rules that touch an email campaign cover the rest of the compliance layer.
Common questions
Do I need SPF, DKIM and DMARC together?
Yes for any domain that sends marketing mail. SPF and DKIM alone give receivers no instruction when a message fails both. DMARC is the record that carries that instruction.
Why does my DMARC report show failures from my own domain?
Usually because a third party sends as you: a booking system, an invoice tool or an old mailing list. Add their sources to SPF or delegate a subdomain, then re-check.
Can I set DMARC to reject straight away?
Technically yes, and practically no. If any legitimate source fails alignment, reject will bin that mail with no report trail to explain why. Collect for a few weeks first.
Does authentication replace consent?
No. DNS records govern whether a receiving server trusts the message. Consent, soft opt-in and suppression lists govern whether you may send it.
