Why email authentication matters
Email was designed without a way to prove who sent a message. Anyone can put your address in the "From" line. Spammers and fraudsters do, which damages your name and can land your genuine mail in spam folders. SPF, DKIM and DMARC are three checks that let receiving servers tell a real message from a forgery.
They also matter for delivery. Since February 2024 Google and Yahoo have required senders of more than 5,000 messages a day to their users to authenticate with all three, and the checks count in spam filtering for smaller senders as well. See Google's email sender guidelines (opens in a new tab).
The UK's National Cyber Security Centre also recommends these controls in its email security and anti-spoofing guidance (opens in a new tab).
SPF: who may send for your domain
Sender Policy Framework is a list, published in DNS, of the servers and services allowed to send email for your domain. When a message arrives, the receiving server checks that the sending server is on your list.
Name: example.co.uk (or @, depending on your DNS screen)
Type: TXT
Value: v=spf1 include:_spf.your-mail-provider.example ~all- Have one SPF record per domain. Two records make SPF fail. If you use several services, put them all in the same record, each with its own
include:. - The record may trigger at most ten DNS lookups. Too many
include:entries can break it, so remove services you no longer use. - End with
~all(soft fail) while you are testing and-all(hard fail) when you are sure. Never use+all, which allows everyone.
DKIM: a signature on every message
DomainKeys Identified Mail adds a digital signature to each outgoing message. Your email provider holds the private key and signs. You publish the matching public key in DNS under a name such as selector1._domainkey.. The receiving server fetches the public key and checks that the message has not been changed since it was sent.
Name: selector1._domainkey.example.co.uk
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(a long public key)...You do not make this key yourself: your email provider generates it and shows you the record to publish. Ask for a 2048-bit key where there is a choice.
DMARC: what to do when checks fail
DMARC builds on SPF and DKIM. It asks the receiving server to check that the domain in the visible "From" address matches the domain that passed SPF or DKIM (this is called alignment), and it publishes your policy for mail that fails. It also lets you receive reports about who is sending mail as your domain.
Name: _dmarc.example.co.uk
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk| DMARC policy | What receiving servers do with mail that fails | When to use it |
|---|---|---|
| p=none | Deliver it as normal, but send you reports | The first few weeks: watch before you enforce |
| p=quarantine | Treat it as suspicious, usually the spam folder | Once the reports show your real mail passing |
| p=reject | Refuse it | When you are confident every legitimate sender is covered |
A safe roll-out: publish p=none with a reporting address and leave it for a few weeks. Read the reports (many free tools turn the XML into charts), fix any legitimate sender that fails, then move to p=quarantine, and later p=reject.
Set it up in three steps
- Find where your DNS is managed. It is wherever your domain's nameservers point: your registrar, your host, or a service such as Cloudflare. The records must be added there.
- Publish SPF, DKIM and DMARC. Cloud Cabin's email hosting includes DKIM, SPF and DMARC wizards that show you the records to publish. Copy the values it shows into whichever service manages your DNS. In cPanel, the Email Deliverability page shows whether SPF and DKIM are valid for each domain.
- Test. Send a message to a Gmail address, open it, choose "Show original" from the three-dot menu and look for
SPF: PASS,DKIM: PASSandDMARC: PASS.
DNS changes usually show within minutes, and can take up to the old record's TTL to reach everyone.
Common mistakes
- Two SPF records on one domain, often because a second service was added by someone who did not look for the first.
- Forgetting a sender. Newsletter tools, CRMs, invoicing systems and website contact forms all send email as your domain, and each needs to be covered.
- Jumping straight to p=reject. Legitimate mail you forgot about is then refused. Watch the reports first.
- No reporting address. Without
rua=you cannot see what is failing. - Records in the wrong place. After a move, old DNS at the previous registrar is ignored. Edit the DNS your nameservers actually point to.
What these records do not do
They protect your domain from being forged. They do not filter the spam you receive, and they do not make a message safe: a criminal can still authenticate mail from a domain they own. Inbound filtering and malware scanning are separate features, and our email hosting includes both.
Frequently asked questions
Yes, ideally. Each covers a gap in the others. SPF and DKIM are the checks, and DMARC is what makes the receiving server act on them and sends you reports.
Some forged mail is still caught, but forwarded messages often fail SPF, and without DMARC receiving servers decide for themselves what to do with failures. DKIM and DMARC close those gaps.
No. It is best practice, and Google and Yahoo require it from bulk senders. It also protects your brand from being used in phishing.
Usually minutes, and up to the previous record's TTL (often a few hours) to reach everyone.
No. These records protect your outgoing mail and your domain's name. Filtering what reaches your inbox is done by the mail server's spam and malware scanning.
Sources and further reading
- Google: email sender guidelines (SPF, DKIM, DMARC requirements) (opens in a new tab)
- NCSC: email security and anti-spoofing (opens in a new tab)
- RFC 7208: Sender Policy Framework (SPF) (opens in a new tab)
- RFC 6376: DomainKeys Identified Mail (DKIM) signatures (opens in a new tab)
- DMARC.org: overview of DMARC (opens in a new tab)
