SPF, DKIM and DMARC are three email authentication records published in your domain's DNS. Together they let receiving mail systems check whether a message claiming to come from your domain was sent by a service you authorised, and what to do if it was not. Without them, anyone can send email showing your company's address in the From line.
Why email spoofing is a business problem
Email has no built-in proof of the sender. A fraudster can put accounts@yourcompany.com on a fake invoice or a "please update our bank details" request, and it looks genuine. Spoofing can also hurt your domain's reputation, so genuine quotes and booking confirmations are less likely to reach the inbox. See also our article on brand phishing and customer trust.
What each record does
SPF: which servers may send for you
SPF (Sender Policy Framework) is a TXT record listing the servers and services allowed to send email for your domain, such as your Microsoft 365 or Google Workspace mailboxes and your newsletter platform. The receiving server checks the delivering server against that list. SPF checks the technical "envelope" sender used during delivery, not always the address people see in the From line, and it often fails when mail is forwarded.
DKIM: a signature on each message
DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. The sending service signs with a private key, and you publish the matching public key in DNS. The receiver uses that key to confirm the signature and that the signed parts were not changed in transit. Each service that sends for you, such as your mailbox provider, CRM or booking system, normally needs its own DKIM key for your domain.
DMARC: the policy and the reports
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain. It ties the other two checks to the address people see. A message passes DMARC when SPF or DKIM passes and the domain that passed matches, or is "aligned" with, the domain in the From line. It also tells receivers how to handle failures and where to send reports.
DMARC policies: none, quarantine and reject
- p=none: monitor only; receivers handle failing mail as usual but send reports.
- p=quarantine: ask receivers to treat failing mail as suspicious, usually sending it to spam.
- p=reject: ask receivers to refuse failing mail.
Adding a rua address to the record requests aggregate reports. These machine-readable files, usually sent daily by receivers that support them, show which servers sent mail using your domain and whether it passed. A reporting tool can summarise them.
Why mailbox providers now expect them
Google's email sender guidelines require everyone sending to personal Gmail accounts to use SPF or DKIM, and senders of more than 5,000 messages a day to Gmail to use SPF, DKIM and DMARC with an aligned From domain (a DMARC policy of none is acceptable). Yahoo's sender requirements similarly ask all senders for SPF or DKIM, and bulk senders for both plus a DMARC policy of at least p=none. Mail that misses these may be marked as spam or rejected. Rules can change, so check each provider's current page.
A staged rollout
- List every sender: mailbox provider, website forms, newsletter tools, CRM, booking or e-commerce platforms, invoicing software and systems that send alerts.
- Set up SPF and DKIM for each one. Most services publish the exact records in their help pages.
- Publish DMARC with p=none and a report address. Read the reports for a few weeks to find legitimate senders that still fail.
- Move to quarantine, then reject. Tighten only when reports show your genuine mail passing.
- Keep monitoring. Add any new sending tool to SPF and DKIM before it goes live.
Common mistakes
- Two SPF records. A domain should have only one. Adding a second for a new service, instead of merging it into the first, makes SPF fail.
- Forgetting third-party senders. A newsletter, CRM or booking system that sends as your domain but is missing from SPF and DKIM will fail once DMARC is enforced.
- Going over the SPF lookup limit. The SPF standard allows at most 10 DNS lookups when a record is checked, and each include uses at least one. Too many includes can push a record over the limit and make SPF fail.
- Jumping straight to p=reject. Without monitoring first, you may block your own invoices or password resets.
- Treating DMARC as complete protection. It does not stop look-alike domains, misleading display names, or mail sent from a real mailbox whose password was stolen. Multi-factor authentication and staff awareness are still needed.
Frequently asked questions
Where do I add these records?
Wherever your domain's DNS is hosted, which may be your domain registrar, a CDN provider or your IT provider. Our guide to DNS explains how records and DNS hosting work.
We are a small company. Do we need DMARC?
The bulk sender rules mainly affect high-volume senders, but any domain can be spoofed. A monitoring policy is a relatively small task and shows who is sending as your domain.
How long should we stay at p=none?
There is no fixed period. Move on when reports show all legitimate senders passing and you understand what still fails.
For help reviewing your email authentication alongside other security controls, see our Cybersecurity and Compliance services.