Quick answer
SPF lists which servers may send mail for your domain, DKIM adds a signature that proves a message was not altered, and DMARC tells receivers what to do when checks fail. Set them up in that order: SPF, then DKIM, then DMARC at p=none with reports, and tighten only after reviewing the reports.
Key Takeaways
- Set up in this order: list your senders, then SPF, then DKIM, then DMARC at p=none with reporting.
- Copy DNS values only from each sender's own help page, because they differ by vendor and change over time.
- Keep one SPF record per domain and stay under the 10 DNS lookup limit.
- Read DMARC reports for a few weeks before moving to quarantine or reject.
- Authentication supports deliverability but does not guarantee inbox placement.
What SPF, DKIM and DMARC each do
If your quotes and invoices land in spam, or someone sends scam mail that appears to come from your domain, the cause often sits in three DNS records. This guide covers spf dkim dmarc setup for a small business: what each record does, and the order that avoids breaking your real email.
SPF (Sender Policy Framework) is a published list of the servers and services allowed to send mail for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message, so the receiver can check it came from an authorised sender and was not changed on the way. DMARC sits on top. It tells receiving servers what to do when a message fails both checks, and it asks them to send you reports.
Mailbox providers expect this now. Google publishes sender guidelines that require authentication, and the rules are stricter for senders who send in bulk to Gmail addresses. Rules change, so check the current guidelines linked in the sources. Even if you send only a few hundred emails a month, these records help receivers trust your mail and make it harder to impersonate your business.
- SPF: who may send for your domain
- DKIM: a signature that proves the message is genuine and unaltered
- DMARC: the policy and the reporting that tie the two together
Before you touch DNS: list every system that sends as you
The most common way DMARC causes trouble is a forgotten sender. Before you change anything, write down every tool that sends email using your domain in the From address. Typical ones are your mailbox provider (Google Workspace or Microsoft 365), a newsletter tool, a CRM, an invoicing or accounting app, website contact forms, an online store platform and a helpdesk.
Then find out where your DNS is hosted. It might be your domain registrar, your web host or a service like Cloudflare. Make sure you have login access, and save a copy of the existing records before you edit anything. Check whether an SPF record already exists, because a domain must have only one.
Contact forms deserve special attention. If form notifications from your site sometimes go missing, the sending setup may be part of the problem, as covered in our post on why a website may not be getting enquiries. Sending form emails through an authenticated mail service is usually more reliable than letting the web server send them directly. If you are still choosing tools, our email marketing guide for small businesses is a good companion.
Step 1: Publish one SPF record
SPF is a TXT record at the root of your domain. It starts with v=spf1, then lists the services allowed to send, then ends with an instruction for everything else. A simplified, placeholder-only example looks like this: v=spf1 include:_spf.example-sender.com ~all. Do not copy that. Each sender platform publishes its own include value, and you should copy it from that vendor's help page, not from a blog post, including this one. Vendors do change their values.
If you use several services, merge them into a single record, for example one v=spf1 line with several include entries. Two separate SPF records on the same domain cause SPF to fail. That is one of the most frequent mistakes we see described in help forums.
Watch the 10-lookup limit. The SPF standard (RFC 7208) allows a maximum of 10 DNS lookups while a receiver evaluates your record. Mechanisms such as include, a, mx, exists and redirect count, and includes nested inside other includes count too. Go over the limit and receivers can treat the record as an error, so SPF fails even though it looks correct. Remove vendors you no longer use, avoid the ptr mechanism, and use an SPF checker to count lookups after each change. Be wary of flattening, which swaps includes for raw IP addresses, because vendors change their IPs and your record goes stale.
For the ending, start with ~all (soft fail). The stricter -all (hard fail) is fine once you are sure every sender is listed, but DMARC gives you better control, so there is no rush.
Step 2: Turn on DKIM for every sender
DKIM works with a key pair. The sending platform keeps a private key and signs each message. You publish the matching public key in DNS under a name like selector._domainkey.yourdomain.com. The platform tells you the exact host name and value. Depending on the vendor, it is a TXT record or a CNAME record. Again, copy it from the vendor's help page and paste it exactly.
Do this for each sender on your list, not only your main mailbox. In some platforms, such as Google Workspace, publishing the record is not enough. You also generate the key in the admin console and then start authentication there. Read the vendor's steps to the end.
DNS panels can be fussy. Some automatically append your domain to the host name, so you end up with the domain twice. Long keys may need to be entered as one string even if the panel wraps the display. After saving, use the vendor's verify button, then send a test email to a Gmail address, open the message, choose Show original, and look for DKIM: PASS. Allow time for DNS changes to propagate, which can take anywhere from minutes to several hours depending on the record's TTL.
Step 3: Add DMARC at p=none, read the reports, then tighten
DMARC is a TXT record at _dmarc.yourdomain.com. A starting record looks like v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The p tag is the policy. With p=none, receivers take no action on failing mail; they only send you aggregate reports. A message passes DMARC when SPF or DKIM passes and the domain used in that check aligns with the domain in the visible From address. This is why a vendor that signs with its own domain, not yours, can still fail DMARC.
We took this exact first step ourselves. In October 2026 we set the Quavento domain to DMARC p=none with reporting turned on. At that stage nothing is blocked, and the aim is simply to see who is sending mail as your domain. We would not move to a stricter policy until the reports show that every legitimate sender passes.
DMARC reports arrive as XML files, usually daily, from large mailbox providers. They are hard to read raw, so many small businesses use a report-reading tool. Check the current pricing and free tiers yourself, as they change. Use a shared mailbox for the rua address, not one person's inbox, so reports survive staff changes.
Wait a few weeks so the reports cover your full sending cycle, including monthly invoices and occasional campaigns. Fix any legitimate sender that fails, by adding it to SPF or enabling its DKIM. Then move to p=quarantine, which asks receivers to treat failures as suspicious, and later to p=reject if you want failing mail refused. Some businesses stay at quarantine; it is a judgement call based on how much impersonation risk you face and how well you control your senders.
Common mistakes and how to check your work
The usual problems are predictable: two SPF records, an SPF record over the 10-lookup limit, DKIM enabled for the main mailbox but not for the newsletter tool, jumping straight to p=reject, and leaving old vendors in the record long after you stopped using them. Another is forgetting that subdomains may send mail too. A DMARC policy applies to subdomains unless you set a separate one, so check whether any subdomain is used for sending.
To check your work, send test messages from every system on your list to a Gmail address and a second provider if you can. Open the original message headers and look for SPF, DKIM and DMARC results. Then watch the DMARC reports for unexpected sources. Unfamiliar senders may be old tools you forgot, or someone spoofing your domain.
Be realistic about what this achieves. Authentication is a foundation for deliverability, not a guarantee of inbox placement; content, list quality and sending behaviour still matter. If you run newsletters, automations or CRM follow-ups, this setup is groundwork for marketing automation that works as intended. If you would rather have someone handle the DNS and sender audit, our email marketing team can help, or you can contact us with a list of your sending tools.
Frequently Asked Questions
Do I need all three of SPF, DKIM and DMARC?
Yes, they work as a set. SPF and DKIM authenticate the message, and DMARC tells receivers how to treat failures and gives you reports. Major mailbox providers expect authentication, so having only one leaves gaps.
Can I set up DMARC first and do SPF and DKIM later?
It is better not to. DMARC relies on SPF or DKIM passing with alignment. If you publish DMARC before those are working, the reports will mostly show failures and you will not know which are real problems. Do SPF and DKIM first.
Can I do this with a free Gmail or Outlook address?
No. These records live in the DNS of a domain you own, such as yourbusiness.com. Free addresses on gmail.com or outlook.com are managed by the provider. To control authentication you need your own domain with a business mailbox.
Will p=none hurt my email or block anything?
No. With p=none, receivers do not reject or quarantine mail because of DMARC. It only enables reporting. That is why it is the safe starting point for every domain.
How long do DNS changes take to work?
It depends on the record's TTL and your DNS provider. Often it is minutes to a few hours, but allow up to a day before assuming something is wrong. Verify with the sender's own check tool and a test email.
Will this guarantee my emails reach the inbox?
No. Authentication removes a common reason for spam placement and protects your domain from easy impersonation, but inbox placement also depends on your content, list quality, complaint rates and sending history.
