Flexy Blogs

SPF, DKIM and DMARC Explained: Email Authentication for Marketers

SPF, DKIM and DMARC Explained: Email Authentication for Marketers
Photo: Jay Wennington, CC0, via Stocksnap

If your emails are landing in spam, missing authentication is a common cause. Here is what SPF, DKIM and DMARC each do, how they work together, and how to set them up safely.

Email was designed without a reliable way to prove who sent a message, which is why spoofing and phishing are so common. SPF, DKIM and DMARC are three standards that add that proof. Mailbox providers increasingly expect them, and Google's email sender guidelines require all three for organisations sending large volumes to Gmail users.

If you send newsletters, invoices or any email from your own domain, these settings directly affect whether messages reach the inbox.

SPF: which servers may send for you

Sender Policy Framework is a DNS record listing the servers and services allowed to send email for your domain, such as your email provider, your newsletter platform and your invoicing software. Receiving servers check whether the message came from one of them.

  • A domain should have only one SPF record. Add new services to the existing record instead of creating a second.
  • SPF allows a maximum of 10 DNS lookups. Each "include" counts, so long lists of services can break it.

DKIM: a tamper-proof signature

DomainKeys Identified Mail adds a cryptographic signature to each message. The sending service holds a private key; you publish the matching public key in your DNS. Receiving servers use it to confirm the message really came from an authorised sender and was not altered in transit.

Each sending service, whether your mailbox provider or your newsletter tool, usually gives you its own DKIM record to add. Set it up for every service that sends on your behalf.

DMARC: the policy that ties it together

DMARC tells receiving servers what to do when a message claiming to be from your domain fails authentication, and sends you reports about it. Crucially, it checks alignment: the domain in the visible "From" address must match the domain verified by SPF or DKIM. That is what stops someone spoofing your brand.

A DMARC record has a policy:

  • p=none: monitor only, take no action. The safe place to start.
  • p=quarantine: send failing messages to spam.
  • p=reject: refuse failing messages entirely.

Google's guide to setting up DMARC walks through the record syntax and a gradual rollout.

A safe rollout, step by step

  1. List every service that sends email as your domain: mailbox provider, newsletter platform, CRM, helpdesk, invoicing, website contact forms.
  2. Set up SPF with all of them in a single record.
  3. Enable DKIM in each service and publish their DNS records.
  4. Publish DMARC with p=none and a reporting address, then read the reports for a few weeks. They reveal services you forgot.
  5. Fix anything that fails, then move to p=quarantine, and later to p=reject once reports are clean.

Moving straight to reject before you know every sender can block your own legitimate invoices or password resets, so take the gradual path.

Authentication is necessary, not sufficient

Passing SPF, DKIM and DMARC proves who you are; it does not make people want your email. Deliverability also depends on:

  • Sending only to people who opted in, and removing addresses that bounce
  • A clear, working unsubscribe link (one-click unsubscribe for marketing email to large providers)
  • Low spam complaint rates
  • Consistent sending volume rather than sudden spikes
  • Content people actually open and read; see our guide to subject lines in the submissions library

How to check your setup

Send a message to a Gmail account, open it, and choose "Show original". The header summary shows whether SPF, DKIM and DMARC passed. Large senders can also register their domain with Google Postmaster Tools to monitor reputation and spam rates.

Planning a campaign? Our UTM guide explains how to measure which emails drive results once they arrive.

FlexyBlogs Editorial Team

Practical guides from the FlexyBlogs editors
Articles under this byline are researched and written by the FlexyBlogs editorial team. We link to primary sources such as government agencies, standards bodies and official documentation, and we update articles when guidance changes. Some drafts are prepared with the help of AI writing tools and are edited and fact-checked by a member of the team before publication. Spotted an error? Tell us through the contact page.
View all posts

0 Comments

No comments yet — be the first to share what you think.

Leave a reply

Your email address is never published.