Guide · Deliverability

SPF, DKIM and DMARC explained for B2B senders

What each record does, how they work together, and what Google and Microsoft now require from senders.

Published 18 October 2026By HighNode Digital

Cover image for the HighNode Digital guide: SPF, DKIM and DMARC explained for B2B senders

The short answer

SPF, DKIM and DMARC are DNS records that let mailbox providers check an email really came from your domain. SPF lists the servers allowed to send for the domain. DKIM adds a cryptographic signature that proves the message was not altered. DMARC tells receivers what to do when those checks fail, and sends you reports about it.

None of the three guarantees inbox placement. But without them, major providers increasingly treat your mail as untrustworthy, and some reject it outright.

Flow diagram: an arriving email is checked with SPF, then DKIM, then DMARC; the DMARC policy decides whether a failing message is delivered, sent to spam or rejected.
How SPF, DKIM and DMARC work together when your email arrives.

SPF: who may send

SPF (Sender Policy Framework) is a single TXT record on your domain that lists the services allowed to send email using it. A receiving server compares the sending server with that list.

v=spf1 include:_spf.google.com ~all

This example allows Google Workspace to send for the domain. The ending says how strictly to treat everything else: ~all (soft fail) or -all (fail).

  • One SPF record per domain. Two separate SPF records make the check fail. Combine them into one.
  • Stay within 10 DNS lookups. Each include can trigger further lookups. The SPF standard sets a limit of 10; going over it causes an error.
  • SPF checks the envelope sender, not the visible From address. That is why DMARC alignment matters (see below).

DKIM: proof the message is intact

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held by your email provider. The matching public key is published in DNS under a selector, for example google._domainkey.yourdomain.com. The receiver uses it to confirm the signature.

If the message was changed in transit, or the key in DNS does not match, the check fails. Use a 2048-bit key where your provider supports it, and make sure each service that sends for you signs with your domain rather than its own.

DMARC: the policy that ties them together

DMARC adds two things. First, alignment: the domain in the visible From address must match the domain that passed SPF or DKIM. Second, a policy telling receivers what to do with mail that fails.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
PolicyWhat receivers are asked to doWhen to use it
p=noneDeliver as normal, but send reportsStarting out, while you confirm every legitimate sender passes
p=quarantineTreat failing mail as suspicious, usually spamOnce reports show your own mail passes consistently
p=rejectRefuse failing mailThe strongest protection against spoofing of your domain

The rua address receives daily aggregate reports. They are XML files, so most teams use a DMARC reporting tool to read them.

What Google and Microsoft require

Google requires all senders to Gmail accounts to set up SPF or DKIM and keep the spam rate reported in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to personal Gmail accounts must use SPF and DKIM, publish DMARC (a p=none policy is accepted), align the From domain with SPF or DKIM, and support one-click unsubscribe on marketing and subscribed messages. Google recommends keeping the spam rate below 0.1%.

Microsoft applies similar rules to senders of more than 5,000 messages a day to Outlook.com, Hotmail.com and Live.com addresses: SPF must pass, DKIM must pass, and DMARC must be published with at least p=none and aligned with SPF or DKIM. Since 5 May 2025, mail that does not comply is rejected rather than sent to Junk.

Even below 5,000 a day, set up all three. The thresholds decide when the rules are enforced strictly, not whether authentication helps. A properly authenticated domain is simply more trustworthy to every provider.

Common mistakes

  • Two SPF records on the same domain after adding a new tool.
  • SPF that exceeds the 10-lookup limit because old services were never removed.
  • A sending platform signing DKIM with its own domain, so DMARC alignment fails.
  • DMARC published with no reporting address, so nobody sees failures.
  • Jumping straight to p=reject before checking every legitimate sender, which blocks your own invoices or support mail.
  • Setting up records on the main domain but forgetting the separate sending domains used for outreach.

How to check your records

  1. Look up the TXT records for your domain with a DNS lookup tool and confirm there is exactly one record starting v=spf1.
  2. Look up _dmarc.yourdomain.com and confirm a single record starting v=DMARC1.
  3. Send a test message to a Gmail account, open it, choose Show original, and confirm SPF, DKIM and DMARC all show PASS.
  4. Repeat for every domain and every service that sends on your behalf.
Need a hand with this? Our Email infrastructure service covers this work end to end.

Introductory call

Let’s talk about your outreach and follow-up.

A 30-minute call to understand your requirements, current challenges and goals — and whether we’re a good fit.

  • Pick a time that suits your time zone
  • Talk through your setup and goals
  • Discuss possible approaches — no obligation