Cold email deliverability basics: SPF, DKIM and DMARC in plain English

Before I send an outreach email, I want to know whether the receiving system can check who sent it. A sensible message still needs a sensible technical setup.

SPF, DKIM and DMARC help with that checking. They are related, but they do different jobs. I find them easier to understand when I separate permission to send, a message signature and alignment with the address a reader sees.

None of these settings guarantees inbox placement. They are foundations, not a way around consent, relevance or a recipient's decision to reject a message.

Start with the addresses behind an email

An email has more than one sender identity. The visible From address is the one a reader usually sees. The envelope sender is used during delivery and commonly appears in the Return-Path header after delivery.

Those addresses can use different domains. That is normal in some sending arrangements, but it matters when I check authentication.

If I use a mailbox provider plus a separate sending service, I ask which domain each service uses for the envelope sender, the visible From address and DKIM signing. I do not assume that connecting an account makes all those identities match.

I keep an inventory of legitimate senders before changing DNS. That includes everyday mail, invoices, forms and any other system sending on the domain's behalf.

SPF checks permission for the envelope sender

SPF is a DNS record that describes which servers are authorised to send for a domain. In the usual email delivery case, the receiver checks it against the envelope sender domain, not simply the visible From address.

That distinction is important. An SPF pass for a sending service's domain does not, by itself, establish that the visible From domain is authenticated through DMARC.

I use the instructions from my actual providers rather than copying a record from an unrelated example. I also check for an existing SPF record before adding anything. Publishing multiple separate SPF records for the same domain is not the right way to add another sender.

When several services need authorisation, I ask the person managing DNS to combine the requirements correctly and check SPF's lookup limits. Guessing here can break mail that was already working.

DKIM adds a checkable signature

DKIM attaches a digital signature to an email. The receiving system uses a public key published in DNS to check that signature.

A valid signature helps show that the signed parts of the message have not changed since signing and associates the message with a signing domain. It does not prove that the offer is honest or that the recipient wanted the email.

I enable DKIM in the sending provider and publish the exact DNS record it supplies. Then I verify that outgoing messages are actually being signed. Adding a record without enabling signing in the service can leave the job unfinished.

The signing domain is shown in the signature's d= value. I note that domain because DMARC uses it when checking alignment with the visible From domain.

DMARC connects authentication to the visible From domain

DMARC asks whether the domain in the visible From address aligns with an authenticated domain. It can pass through aligned SPF or aligned DKIM. Both mechanisms do not have to pass for DMARC to pass.

Alignment is not just another word for authentication. SPF might pass for a provider's unrelated envelope domain while failing to give the visible From domain the alignment it needs. DKIM can have the same issue if the signing domain is unrelated.

Alignment may be relaxed or strict. Under relaxed alignment, related subdomains can align through the same organisational domain. Strict alignment requires an exact domain match for the relevant check.

DMARC also publishes a requested policy for messages that fail and can request reports. I would not move straight to a rejecting policy without checking every legitimate sender. A reporting stage can reveal services that still need configuration.

Check the requirements for the mail you send

I use Google's email sender guidelines as the reference for mail sent to personal Gmail accounts. They distinguish requirements for all senders from additional requirements for bulk senders.

Google lists SPF or DKIM for all senders and SPF, DKIM and DMARC for bulk senders, alongside other requirements. For bulk senders, the visible From domain must align with SPF or DKIM for DMARC. I still prefer to configure and verify all three rather than do the minimum.

Authentication is only part of the guidance. I also review unsubscribe requirements for relevant marketing and subscription messages, message formatting, transport security and complaint handling. Technical compliance does not establish permission to contact someone.

Test before increasing activity

I send test messages through every legitimate sending path and inspect the received authentication results. I want to see the actual SPF, DKIM and DMARC outcomes, not just a green status in a setup screen.

If results are unclear, I ask my provider or a qualified administrator to review them before sending more. I avoid changing several records at once without a recovery plan.

Then I watch delivery failures, complaints and stop requests. I do not treat opens as reliable proof of inbox placement. Better targeting, as described in defining your ideal customer, matters alongside the technical checks.

What to do this week

• List every service sending mail for your domain.
• Identify the envelope, From and DKIM signing domains.
• Check SPF and enable DKIM with your providers.
• Review DMARC alignment and reporting before tightening policy.
• Send tests and inspect received authentication results.
• Check applicable consent and unsubscribe requirements.
• Stop and investigate unexplained failures before expanding sending.

My goal is accountable, correctly configured mail to appropriate recipients. Authentication supports that goal. It cannot make an unwanted message welcome or promise where any particular email will land.