SPF, DKIM and DMARC: how to set them up for cold email

SPF lists the servers allowed to send email for your domain, DKIM signs each message with a key published in your DNS, and DMARC checks that at least one of them passes for the domain in your From address — and tells receivers what to do, and where to report, when neither does. For cold email you need all three: Gmail and Yahoo require them of bulk senders, and Outlook.com rejects high-volume mail that fails them. For a domain that sends only through Google Workspace, the three records look like this:

Host                 Type   Value
@                    TXT    v=spf1 include:_spf.google.com ~all
google._domainkey    TXT    v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B…  (from the Admin console)
_dmarc               TXT    v=DMARC1; p=none; rua=mailto:dmarc@example.com

How SPF, DKIM and DMARC fit together

Every email carries two sender addresses. The envelope sender — also called the Return-Path or MAIL FROM — is used between servers and receives bounces. The From address in the header is the one the recipient sees. SPF checks the first, DKIM checks a domain named in its signature, and DMARC ties both to the second.

SPF (RFC 7208)

A TXT record on your domain listing the servers that may use it as an envelope sender. The receiver checks the connecting server’s IP address against the list.

DKIM (RFC 6376)

Your provider signs each message with a private key. The signature names a domain (d=) and a selector (s=); receivers fetch the public key from selector._domainkey.domain and confirm the message wasn’t altered.

DMARC (RFC 9989)

A TXT record at _dmarc.domain. A message passes when SPF or DKIM passes and the domain it passed for aligns with the From domain. The record says what you want done with mail that fails and where to send reports.

DMARC was updated in May 2026, when the IETF published it as a Standards Track specification in RFC 9989, with aggregate reporting in RFC 9990. Both replace RFC 7489. Existing records keep working — the version tag is still v=DMARC1 — but a few tags changed, as described below.

Alignment: the part most setups get wrong

SPF and DKIM can both pass while DMARC fails, because DMARC only counts a pass for a domain that matches your From address. RFC 9989 defines two modes. In relaxed alignment, the default, the domains only need the same organizational domain, so mail.example.com aligns with example.com. In strict alignment they must be identical. The RFC notes that “nearly all Domain Owners have found relaxed alignment sufficient”.

The fourth row is the classic failure: a sending service authenticates as itself rather than as you. Mail sent through Google Workspace, with DKIM set up for your own domain, aligns on both. Gmail requires bulk senders to align at least one and recommends aligning both, adding that it’s “likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement”.

Step 1: Set up SPF

1. List everything that sends as your domain. Your email provider, plus any CRM, help desk, billing system or website form that sends with your domain in the From or envelope address.
2. Build one record. Start with v=spf1, add an include: (or ip4: and ip6: ranges) for each sender, and end with ~all.
3. Publish it as a TXT record at the root of the domain (host @). If an SPF record already exists, edit it: a second record makes SPF fail for everything.
4. Wait, then check. Google says SPF can take up to 48 hours to start working.

SPF record examples

The Google examples come from Google’s Set up SPF help page and the Microsoft ones from Microsoft Learn.

The 10-lookup limit

RFC 7208 limits the DNS lookups a receiver will make to evaluate SPF to 10. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost one, and so do those inside included records; ip4, ip6 and all are free. Over 10, the result is a permanent error, which DMARC treats as a failure. The RFC also says implementations should limit “void lookups” — names that return nothing — to two.

As of October 2026, include:_spf.google.com and include:spf.protection.outlook.com each cost one lookup, because Google and Microsoft list their address ranges directly in those records. Other services’ includes can nest several more. If you’re over the limit, remove services that no longer send for you, or move one to a subdomain with its own SPF record. “Flattening” includes into IP ranges also works, but breaks quietly when a service changes its addresses.

~all or -all?

The record ends with a rule for servers that aren’t listed. ~all (softfail) says they probably aren’t authorized; -all (fail) says they definitely aren’t. Google recommends ~all. Microsoft recommends -all for Microsoft 365 domains, so that DMARC can act on messages that fail SPF and carry no DKIM signature. RFC 9989 adds a caution: some receivers check SPF before DMARC, so -all can get a message rejected at the start of the SMTP conversation even if an aligned DKIM signature would have passed it — and those rejections never appear in your DMARC reports.

For a cold-email domain that sends only through your provider, with DKIM on and DMARC published, either is defensible; we suggest ~all unless you’re certain every legitimate sender is listed. Never use +all, which authorizes every server on the internet, and Microsoft advises against ?all in production.

Step 2: Turn on DKIM

Google Workspace

1. Generate a key. In the Google Admin console, open Apps › Google Workspace › Gmail › Authenticate email, choose the domain and click Generate new record. Pick a 2048-bit key if your DNS host supports it and keep the default selector, google. Google notes that a new account may need to wait 24–72 hours after turning on Gmail before it can generate a key.
2. Publish it. At your DNS host, add a TXT record with the host name Google shows (google._domainkey) and the value that starts v=DKIM1.
3. Start authentication. Back in the Admin console, click Start authentication. Google says DKIM can take up to 48 hours to start working.
4. Check a real message. Send an email to a Gmail address you can open, choose Show original, and look for DKIM: PASS with your domain. Google notes you can’t verify it by sending a test to yourself.

google._domainkey.example.com.   TXT   v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…

The p= value is your public key, shortened here. Some DNS hosts limit how long one TXT string can be, so a 2048-bit key may have to be split; Google’s Set up DKIM page covers it.

Microsoft 365 and other providers

Microsoft 365 publishes DKIM through two CNAME records, selector1._domainkey and selector2._domainkey, whose values you copy from the Microsoft Defender portal before switching signing on (see Microsoft Learn). Other providers give you a selector and a TXT or CNAME record; the name always takes the form selector._domainkey.yourdomain. Whatever the provider, the signature’s d= domain must be your domain or a subdomain of it to align. Gmail requires keys of at least 1024 bits for mail to personal accounts and recommends 2048.

Step 3: Publish DMARC

A DMARC record is a TXT record at _dmarc.yourdomain.com. Here is a DMARC record example for monitoring mode, the right place to start:

_dmarc.example.com.   TXT   v=DMARC1; p=none; rua=mailto:dmarc@example.com

One trap: some DNS hosts add your domain to whatever host name you type, so entering _dmarc.example.com creates _dmarc.example.com.example.com. Google’s Set up DMARC page warns about this — enter just _dmarc if your host works that way.

A safe rollout: none, then quarantine, then reject

1. Get SPF and DKIM passing first. Google advises that both should be authenticating for at least 48 hours before you publish DMARC.
2. Publish p=none with rua. Mail is delivered exactly as before, and reports start arriving. RFC 9989 calls this monitoring mode.
3. Read the reports and fix what fails. Look for legitimate sources that fail or don’t align — a billing system, a help desk, a website form — and fix their SPF or DKIM. Google suggests at least a week of reports; RFC 9989 notes it can take “many months” for organizations with many mail streams.
4. Move to p=quarantine. Failing mail goes to spam. Google’s recommended rollout starts with a small percentage using pct; under RFC 9989 that tag is retired and t=y is the new way to test, though receivers will take time to adopt it. On a small domain with one sending source, moving the whole domain once reports are clean is simpler.
5. Move to p=reject. Failing mail is refused. This is the strongest protection against people spoofing your domain, and the point at which a forgotten sender’s mail stops arriving, so get there only after reports have been clean for a while.

v=DMARC1; p=none; rua=mailto:dmarc@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

For a separate cold-email domain that only ever sends through Google Workspace, the whole path can take a few weeks. For your main domain, with years of tools sending in your name, go slowly.

Reading DMARC reports

Aggregate reports, defined in RFC 9990, are XML files that receivers email to your rua address, typically daily. Each lists the IP addresses that sent mail using your domain, how many messages, whether SPF and DKIM passed and aligned, and what the receiver did with them. A busy domain can receive many reports a day, so Google suggests a dedicated mailbox or group, or a service that parses them, rather than your own inbox.

If reports go to an address on a different domain, that domain must agree to receive them by publishing a record such as example.com._report._dmarc.reports.example.net. Report-processing services set this up for you.

BIMI, briefly

BIMI (Brand Indicators for Message Identification) lets supporting mailbox providers show your logo beside your messages. For Gmail it needs DMARC at enforcement — p=quarantine or p=reject, applied to all mail — and a Verified Mark Certificate, which requires a registered trademark, or a Common Mark Certificate. Gmail shows a checkmark next to senders with a VMC. The record lives at default._bimi.yourdomain.com, for example v=BIMI1;l=;a=https://images.example.com/brand/certificate.pem, per Google’s Set up BIMI page.

BIMI is a display feature; it doesn’t replace the reputation that decides whether mail reaches the inbox. Google notes the trademark process alone can take 6 to 12 months, so for a dedicated cold-email domain it’s rarely worth it.

How to check your records

dig +short TXT example.com
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

• Google’s Admin Toolbox Check MX and Dig look up the same records in a browser.
• Send a message to a Gmail account you can open, then choose Show original on the copy that arrived: you want PASS for SPF, DKIM and DMARC.
• In Outlook, the Authentication-Results line in a received message’s headers shows the same checks.
• Google Postmaster Tools shows the share of your mail to personal Gmail accounts that passes each check, once your volume is high enough.

What Gmail, Yahoo and Microsoft require

Sources: Google’s Email sender guidelines and FAQ, Yahoo’s Sender Requirements and FAQ, and Microsoft’s 550 5.7.515 support article, as of October 2026.

These rules cover mail sent to each provider’s personal accounts. Google says its sender guidelines don’t apply to mail sent to Google Workspace accounts, and company mail systems set their own policies — but they check the same three records.

Common mistakes

• Two SPF records on one domain, which fails SPF for everything.
• An SPF record that misses a sender — often the help desk or billing tool added last year — or needs more than 10 lookups.
• A DKIM key published in DNS, but Start authentication never clicked in Google Workspace.
• A DMARC record at the wrong name because the DNS host appended the domain.
• Reports sent to a personal inbox, where they’re either ignored or bury everything else.
• Jumping straight to p=reject without reading a week of reports.
• Forgetting subdomains: without sp or a record of their own, they inherit the parent’s policy.

How SalesScope handles this

SalesScope checks the SPF, DKIM and DMARC records of every domain you send from, explains what it finds in plain words, and tells you the exact change to make:

• SPF: whether there is exactly one record, whether it names your provider (include:_spf.google.com for Google Workspace, include:spf.protection.outlook.com for Microsoft 365), how many of the 10 DNS lookups it uses, and whether any include is broken. A record ending in -all is read correctly as valid.
• DKIM: whether a key is published at the selector your provider signs with — google._domainkey for Google Workspace, selector1._domainkey and selector2._domainkey for Microsoft 365 — and whether it has been revoked.
• DMARC: the policy that applies to your domain, found by walking up the domain tree as RFC 9989 describes, with p=none flagged as a warning rather than a pass.
• Before sending: a sequence warns you before it sends from a domain whose SPF or DKIM is missing.

Where something can’t be seen from outside — a DKIM selector your admin chose, or an outbound gateway — SalesScope says “Can’t confirm” and explains how to check it in Gmail. Every campaign email also carries one-click unsubscribe headers, which RFC 8058 requires to be covered by a valid DKIM signature. See deliverability guardrails.