An SPF DKIM DMARC setup is three DNS records that tell the rest of the internet which email really comes from your domain. Get them right and your mail is trusted, your domain is harder to spoof, and you meet the sender rules that Gmail, Yahoo and Microsoft now enforce. Get them wrong and legitimate mail lands in spam or bounces outright.
Most companies set these up once for their main mailbox provider and stop there. The trouble starts later, when marketing adds HubSpot or Mailchimp, sales connects Salesforce, support turns on a ticketing tool and someone wires the website form to send notifications. Each of those tools sends mail as your domain, and each one needs to be authenticated on its own. This guide explains how the three records work and how to handle every sender, not just the obvious one.
What each record does
SPF: who is allowed to send
SPF (Sender Policy Framework) is a TXT record at the root of your domain that lists the servers allowed to send mail for it. A receiving server looks at the connecting IP address and checks it against your list.
example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"
Two details matter. First, a domain may have only one SPF record. If you add a second one instead of editing the first, both are treated as broken. Second, SPF checks the envelope sender (the Return-Path or bounce address), not the From address your recipient sees. That distinction becomes important when we get to DMARC.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending service signs with a private key, and you publish the matching public key in DNS under a "selector" name, such as selector1._domainkey.example.com or google._domainkey.example.com. The receiver fetches the key and confirms the message was not altered and was signed by someone authorized for that domain.
DKIM survives forwarding far better than SPF, and the signing domain (the d= value in the signature) can be your own domain even when a third party sends the mail. That makes it the stronger of the two for anything sent through outside tools.
DMARC: the policy that ties it together
DMARC is a TXT record at _dmarc.example.com. It tells receivers what to do when a message fails authentication and where to send reports.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The key idea is alignment. A message passes DMARC only if SPF or DKIM passes and the passing domain matches the domain in the visible From address. A message can pass SPF for a vendor's bounce domain and still fail DMARC, because the vendor's domain is not yours. Alignment is what stops a spammer from passing SPF on their own domain while putting your name in the From line.
The policy (p=) has three settings: none (monitor only), quarantine (send failures to spam) and reject (refuse them). You start at none, fix what the reports show, then tighten.
Why this is no longer optional
Since February 2024, Google requires anyone sending more than 5,000 messages a day to personal Gmail accounts to authenticate with both SPF and DKIM, publish a DMARC record of at least p=none, align the From domain with SPF or DKIM, and offer one-click unsubscribe on marketing mail. Yahoo publishes the same core requirements for bulk senders. Microsoft began enforcing similar rules for high-volume senders to Outlook.com, Hotmail and Live addresses in May 2025, and non-compliant mail is rejected with a 550 5.7.515 error.
Even if you never hit those volumes, all three providers expect at least SPF or DKIM from every sender, and authentication is one of the first signals filters check. You can read the source rules in Google's email sender guidelines and Yahoo's sender best practices.
Third-party senders: where most setups break
Here is the pattern we see constantly. The company's mailboxes run on Microsoft 365 or Google Workspace, and those pass. Then the newsletter goes out through Mailchimp with From: news@example.com, the CRM sends sequences from sales@example.com, the helpdesk replies from support@example.com, and the contact form emails forms@example.com. None of those were set up, so they fail DMARC, and as soon as someone tightens the policy they disappear.
Each tool gives you one of two ways to authenticate.
Option 1: add the tool to SPF
Many tools ask you to add an include: to your SPF record. This works, but it has two real limits.
The first is the 10-lookup limit. The SPF standard caps the number of DNS lookups an SPF check can trigger at 10. Every include, a, mx, exists and redirect counts, and includes can contain their own nested includes. Google Workspace and Microsoft 365 alone use several. Add HubSpot, a helpdesk, a billing tool and a form service and you can quietly pass 10. When that happens the SPF result becomes a permanent error, which means SPF fails for every message, including your normal mailbox mail.
The second limit is alignment. SPF is checked against the envelope sender, and most marketing platforms use their own bounce domain by default. So even with a perfect include, SPF passes for the vendor's domain, not yours, and does nothing for DMARC unless the tool supports a custom return path on a subdomain you control.
Option 2: DKIM CNAMEs (usually better)
Most serious platforms let you authenticate your domain with DKIM. They give you two or three CNAME records to publish, which point to keys the vendor hosts and rotates. Once those are live, the platform signs mail with d=example.com, DKIM aligns with your From address, and DMARC passes regardless of what SPF does.
CNAME-based DKIM costs you zero SPF lookups and keeps working when the vendor rotates keys. For that reason we treat it as the default for every third-party sender, and only add SPF includes where a tool requires them.
How the common tools handle it
| Tool | What you publish | Notes |
|---|---|---|
| Microsoft 365 | Two DKIM CNAMEs (selector1 and selector2), SPF include |
Enable DKIM signing after the CNAMEs resolve |
| Google Workspace | One DKIM TXT record (default selector google), SPF include |
Generate the key in the Admin console |
| HubSpot | Two DKIM CNAMEs from the domain settings; HubSpot also shows an SPF value | Connect the email sending domain in settings |
| Mailchimp | Two DKIM CNAMEs and a DMARC record if you lack one | Authenticate the domain in the account's domain settings |
| Salesforce | Primary and alternate DKIM CNAMEs from Setup, DKIM Keys | Activate the key once Salesforce detects the records; Marketing Cloud is set up separately |
| Ticketing, form and billing tools | Varies: DKIM CNAMEs, a custom return path, or an SPF include | Check each vendor's domain authentication page |
Always copy record names and values from the tool's own settings screen. The exact hostnames differ by account, and a typo in a CNAME is the most common reason DKIM never activates. For mailbox providers specifically, we walk through the clicks in How to Set Up DKIM on Microsoft 365 and Google Workspace.
A practical rollout order
- Inventory every sender. Ask marketing, sales, support, finance and whoever runs the website. Check invoices for SaaS tools. Anything that emails customers "from" your domain counts.
- Publish DMARC at
p=nonewith a reporting address, if you have not already. The reports will show you senders nobody remembered. - Set up DKIM for each sender, starting with the mailbox provider and the highest-volume platform.
- Clean up SPF. Remove includes for tools you no longer use, and count your lookups. If you are near 10, move senders to DKIM-only rather than reaching for SPF "flattening" services that hard-code IP addresses.
- Consider subdomains for bulk mail. Sending marketing from
news.example.comkeeps its reputation separate from the mailboxes your team uses every day. - Move to
p=quarantine, thenp=reject, once the reports show all legitimate mail passing for a few weeks.
What we do for clients
We manage domains with a mix of Microsoft 365 and Google Workspace mailboxes, plus marketing and form senders, and we set up SPF, DKIM and DMARC across all of them. The work is rarely hard, but it is detailed, and it touches several teams' tools at once. Our email and domain security service covers the inventory, the DNS changes, the vendor settings and the move to an enforced DMARC policy, without breaking the mail your business depends on.
Frequently asked questions
Do I need all three records?
Yes. SPF and DKIM prove a message was authorized, and DMARC tells receivers how to judge alignment and what to do with failures. Gmail, Yahoo and Microsoft all require the full set for higher-volume senders, and having all three is a baseline expectation for everyone else.
Can I have two SPF records if I use two providers?
No. A domain can have only one SPF record. Combine every sender into a single record with multiple include: entries, and keep the total DNS lookups at 10 or fewer.
Is DKIM enough for HubSpot or Mailchimp without an SPF include?
For DMARC purposes, usually yes. An aligned DKIM pass is enough for DMARC to pass. Add an SPF include only if the vendor requires it or supports a custom return path on your domain, and watch your lookup count when you do.
Should I go straight to p=reject?
Not unless you are certain you know every sender. Start at p=none, read the reports, fix the gaps, then step up. Jumping straight to reject is how companies discover a forgotten invoicing tool when customers stop receiving invoices.
How do I check whether a message passed?
Open the full headers of a message you sent to a Gmail or Outlook address and look for the Authentication-Results line. It shows the SPF, DKIM and DMARC result and which domain each one passed for.