Why email gets treated as suspicious
Anyone can write any "from" address on an email, which is exactly how phishing works. So mail providers such as Gmail and Outlook look for proof that a message really comes from the domain it claims. That proof comes from three records you publish in your domain's DNS: SPF, DKIM and DMARC. Without them, genuine mail is more likely to land in spam, and since 2024 Google and Yahoo require them from anyone sending large volumes.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a list of the servers allowed to send email for your domain. It's a single TXT record on the domain itself, for example:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
This says: Google Workspace and SendGrid may send for us; treat anything else as suspicious.
Common mistakes:
- Two SPF records. A domain must have exactly one. If you add a new email service, add its
include:to the existing record rather than creating another. - Too many lookups. SPF allows at most 10 DNS lookups. Every
include:counts, and some count several times. Past 10, SPF fails for everyone. - Forgotten senders. Your website's contact form, your booking system and your newsletter tool all send email too. Each needs to be in the record.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a digital signature to each email. The receiving server checks it against a public key you publish in DNS, at an address like selector._domainkey.yourdomain.com. If the signature checks out, the message really came from an approved sender and wasn't changed on the way.
You don't write DKIM records by hand: your email provider (Microsoft 365, Google Workspace, your newsletter tool) gives you the record to add, and you switch signing on in its settings. Each service that sends for you should have its own DKIM record.
DMARC: what to do when checks fail
DMARC ties SPF and DKIM together and tells receiving servers what to do with mail that fails them. It's a TXT record at _dmarc.yourdomain.com, for example:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The p= part is the policy:
| Policy | What happens to failing mail |
|---|---|
p=none |
Delivered as normal; you just receive reports. The safe place to start. |
p=quarantine |
Sent to spam. |
p=reject |
Refused outright. The strongest protection against people faking your domain. |
The rua= address receives daily reports of who is sending mail in your name, which is how you find senders you'd forgotten.
Setting them up safely
- List every service that sends email as your domain: mailbox provider, website forms, booking or shop system, newsletter, invoicing.
- Publish one SPF record that includes them all.
- Switch on DKIM in each service and add the records it gives you.
- Publish DMARC with
p=noneand a report address. - After a few weeks of clean reports, move to
p=quarantine, thenp=reject.
Rushing straight to p=reject before every sender is covered is the classic way to stop your own invoices arriving.
Keeping them right
These records break quietly: someone adds a second SPF record, a new tool never gets its DKIM key, a DNS change wipes a record. TideStat checks SPF, DKIM, DMARC and your mail servers every day, alerts you when DNS changes, and gives the exact record to fix each problem.