8 min read Diesen Artikel auf Deutsch lesen
DKIM DMARC and SPF for Cold Email Senders
The short answer
SPF (RFC 7208) lists the servers allowed to send for your domain. DKIM (RFC 6376) signs each message with a key published in DNS. DMARC (RFC 7489) passes only when SPF or DKIM passes and that domain matches your From address. If you send from Google Workspace and Brevo, each needs its own DKIM key, and both have to fit into one SPF record. Then publish DMARC at p=none.
In this article
- DKIM vs SPF vs DMARC: what does each one actually check?
- How do DKIM, DMARC and SPF work together in a single check?
- SPF, DKIM and DMARC in Google Workspace: why doesn't Brevo mail reuse Google's records?
- How do you set up SPF, DKIM and DMARC, step by step?
- Why do SPF, DKIM or DMARC fail even after setup?
- Which DMARC policy should a cold outreach domain start with?
- How does EmailFlow OS use your SPF, DKIM and DMARC records?
- Questions people ask
DKIM vs SPF vs DMARC: what does each one actually check?
People often treat DKIM, DMARC and SPF as one checkbox. They're actually three separate tests, and each one looks at a different part of the message. SPF looks at the envelope sender, the MAIL FROM address the receiving server sees during the SMTP conversation. It doesn't look at the From line your recipient reads. DKIM checks a cryptographic signature in the message header against a public key published under a selector. DMARC is the only one of the three that ties the result to the visible From domain, and it tells the receiver what to do when that link is missing.
- SPF, RFC 7208: one TXT record at the root of the domain, starting with v=spf1. It passes when the connecting IP is listed. It's limited to 10 DNS lookups.
- DKIM, RFC 6376: a TXT record at selector._domainkey.yourdomain. It passes when the signature verifies, which means the signed headers and body weren't changed in transit.
- DMARC, RFC 7489: a TXT record at _dmarc.yourdomain. It passes when SPF or DKIM passes and that domain aligns with the From domain.
- Reporting: DMARC's rua tag sends aggregate XML reports to an address you choose. SPF and DKIM have no reporting of their own.
What doesn't work: relying on SPF alone. Forwarding changes the connecting IP, so SPF breaks, while a DKIM signature usually survives the forward.
How do DKIM, DMARC and SPF work together in a single check?
The receiving server runs SPF and DKIM first, then hands both results to DMARC. Under relaxed alignment, which is the default (aspf=r and adkim=r), the authenticated domain only has to share the organisational domain with the From address. With From set to anna@example.com, a DKIM signature from d=mail.example.com aligns. A signature from d=brevo-owned-domain.com passes DKIM but fails alignment, so it doesn't help DMARC at all. That's the most common surprise for senders who use a third-party platform: every check in the headers reads "pass" and DMARC still fails. Strict alignment (adkim=s) requires an exact domain match, which is rarely worth the trouble for a cold outreach domain. The practical rule is that at least one of the two mechanisms has to pass under your own domain. DKIM is the better candidate, because it survives forwarding and doesn't depend on the bounce address the platform uses. You can see all three results in the Authentication-Results header of a test message, written as spf=, dkim= and dmarc=.
SPF, DKIM and DMARC in Google Workspace: why doesn't Brevo mail reuse Google's records?
Google Workspace only authenticates mail that leaves Google's servers. Its SPF include is include:_spf.google.com. Its DKIM key is generated in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, with google as the default selector and 2048 bits as the recommended key length. After you publish the record, Google says DNS can take up to 48 hours to update before you click Start authentication. None of that covers mail Brevo sends for your domain. Brevo signs with its own key under its own selector, so you end up with two DKIM records side by side, and that's fine because selectors don't collide. SPF works differently. A domain may publish only one v=spf1 record, so Google's include and the one Brevo shows in its domain authentication screen have to go into the same line. If you publish two separate SPF records, the result is a permerror, which isn't treated as a pass. The Google-side record and the 255-character split for long keys are covered in G Suite DKIM: Google Record and Brevo Setup.
How do you set up SPF, DKIM and DMARC, step by step?
Order matters. DMARC evaluates the other two, so you publish it last. Start with a record that only reports, and only tighten it once the reports are clean.
- List every service that sends as your domain: Google Workspace, Brevo, your CRM, your billing tool. Each one needs either an SPF entry or its own DKIM key.
- Publish a single SPF TXT record at the root, for example v=spf1 include:_spf.google.com plus the Brevo include, ending in ~all. Count the lookups and stay at 10 or fewer.
- Generate DKIM keys in each service and publish them as TXT (or CNAME, if the provider asks for that) at selector._domainkey. Then click verify in each service.
- Publish DMARC at _dmarc with v=DMARC1; p=none; rua=mailto:your-report-address. The p=none policy asks receivers to take no action on failures. It only gathers data.
- Send a test to a Gmail address, open Show original and confirm that SPF, DKIM and DMARC each read PASS.
- Read the aggregate reports for at least a few weeks before you move to p=quarantine.
On GoDaddy DNS, the Host field appends your domain automatically. Typing the full name gives you selector._domainkey.example.com.example.com, as described in GoDaddy DKIM Setup for Brevo Senders.
Why do SPF, DKIM or DMARC fail even after setup?
Most failures come from DNS mistakes or unaligned domains, not from the protocols themselves. These are the ones we see most often, along with their causes:
- SPF permerror: two v=spf1 records on the same domain, or more than 10 DNS-querying mechanisms (include, a, mx, redirect, exists), counted recursively.
- DKIM body hash mismatch: something rewrote the message after signing, such as a footer added by a gateway or a mailing list.
- DKIM key not found: the selector name is wrong, the hostname got doubled by the DNS panel, or the record hasn't propagated yet.
- Truncated 2048-bit key: a TXT string is capped at 255 characters, and some panels cut the key off instead of splitting it into several quoted strings.
- DMARC fail despite two passes: SPF and DKIM passed under the platform's domain, not yours, so neither one aligns with From.
- Missing DMARC entirely: Gmail and Yahoo have required it since February 2024 for anyone sending 5,000 or more messages a day to their users.
You can confirm each record with dig TXT plus the hostname (_dmarc.example.com or selector._domainkey.example.com) before you start blaming the content.
Which DMARC policy should a cold outreach domain start with?
Start with p=none. It's the minimum Google's bulk sender guidelines accept, and it asks receivers to take no action on failing mail, so a forgotten tool sending as your domain shows up in the reports rather than being quarantined. Once the aggregate reports list only sources you recognise, all aligned, move to p=quarantine. If you want to tighten gradually, use the pct tag, for example pct=25, which applies the policy to a quarter of failing mail. p=reject is the end state. What doesn't work is jumping straight to reject on a domain whose senders you haven't inventoried. Calendar invites, invoices or a forgotten form handler can quietly stop arriving. Also keep in mind that DMARC doesn't do warm-up for you. A new domain with correct records still has no sending history, and receivers judge volume and complaint rate separately. Gmail's published spam-rate threshold is 0.3%. Plan the volume ramp alongside the DNS work, as set out in Email Warm Up: Daily Volumes and DNS Setup.
How does EmailFlow OS use your SPF, DKIM and DMARC records?
EmailFlow OS doesn't send from a shared platform address. You record one video and upload it to EmailFlow OS, connect your own Brevo account and sending domain, and import your prospect list into EmailFlow OS. EmailFlow OS then creates a personalised version of that recording for each recipient, not each company, and sends each one from your inbox through your Brevo account under your domain. That's why the records above are yours to get right. The DKIM key Brevo verifies for your domain and the DMARC policy at _dmarc.yourdomain are what receiving servers evaluate for every personalised message. A shared sender domain would put your mail under someone else's reputation. With this setup, the reputation, the reports and the DNS stay under your control. What a receiving server does with each message remains its own decision, weighed on authentication, sending history and complaints. How the per-recipient video fits into a full sequence is described in Cold Outreach with One Personalised Video.
Questions people ask
- Do I need all three: SPF, DKIM and DMARC?
- For bulk mail to Gmail and Yahoo, yes. Since February 2024, senders of 5,000 or more messages a day must publish SPF, DKIM and DMARC (at least p=none), with alignment. Below that volume, SPF or DKIM is the minimum, but DKIM plus DMARC is the only combination that ties authentication to your visible From domain.
- Can a domain have two SPF records?
- No. RFC 7208 allows exactly one v=spf1 record per domain. Two records produce a permerror, which receivers treat as a failure. To combine Google Workspace and Brevo, put both include mechanisms in one record and keep the total at 10 DNS lookups or fewer.
- What is DKIM alignment?
- Alignment means the d= domain in the DKIM signature matches the From domain. Under relaxed mode (adkim=r), a subdomain like mail.example.com aligns with example.com. Under strict mode (adkim=s), it must match exactly. A signature that's valid but unaligned doesn't count toward DMARC.
- How long does DNS take for DKIM to verify?
- Usually minutes to a few hours, depending on the record's TTL. Google states that changes can take up to 48 hours before Workspace DKIM authentication can be switched on. If verification fails after that, check for a doubled hostname or a truncated 2048-bit key.