Skip to content
Tin Letter
Tin LetterFrom the editors
Tin Letter29 Sep2026
Re: Deliverability

SPF, DKIM and DMARC for newsletters: a plain guide

Dear sender,

SPF, DKIM and DMARC are three DNS records that help mailbox providers check that an email claiming to be from your domain really is. SPF lists the servers allowed to send for you, DKIM adds a signature, and DMARC says what to do when those checks fail. If your newsletter goes to Gmail addresses, Google already requires at least SPF or DKIM from every sender, so this is no longer an optional extra. For most small senders, setting them up means copying a few values from your email provider into your domain settings.

Close-up of a red 1950 postmark and meter stamp on aged paper, reading Washington D.C.
A 1950 postmark. Email authentication does a similar job: it shows where a message really came from. Photo: Post office, CC0, via Wikimedia Commons.

What the three checks do

How a mailbox provider checks a newsletter An envelope passes three checks in turn: SPF asks if the sending server is on your list, DKIM asks if the signature is intact, and DMARC checks that the result aligns with the From domain and applies your policy. Your issue SPF Is this serveron the domain'spublished list?Checks thesending server DKIM Is the signaturevalid for thisdomain?Can surviveforwarding DMARC Does a pass lineup with the Fromdomain?Sets your policyand sends reports
A simplified view of the checks. Diagram: Tin Letter.

The National Cyber Security Centre's email security guidance gives the short version. SPF publishes the IP addresses that should be trusted for your domain. DKIM cryptographically signs what you send, with the advantage that it can support forwarded email. DMARC sets a policy for receiving servers to apply when a message passes neither check, and generates reports.

The piece people miss is alignment. As Google explains, to pass DMARC a message must be authenticated by SPF or DKIM, and the authenticating domain must match the domain in your From address. Your provider's own domain passing SPF on your behalf does not help you here. You want the provider to sign with your domain, which is usually called custom domain authentication or something close to it.

Google's rules, by volume

Google's sender guidelines are the requirements most small lists meet first, because so many readers use Gmail. Other mailbox providers have their own expectations, and these figures can change, so check the current page.

  • All senders to Gmail accounts must set up SPF or DKIM, use TLS, have valid forward and reverse DNS for the sending domains or IPs, and keep spam rates reported in Postmaster Tools below 0.3%.
  • Senders of more than 5,000 messages a day to Gmail accounts must also set up SPF, DKIM and DMARC together, align the From domain, and support one-click unsubscribe for marketing and subscribed messages, with a visible link in the body. The DMARC policy can be set to none.

A hosted email platform takes care of TLS and reverse DNS. The domain records and the spam rate remain yours. Do not send from a free webmail address through a bulk tool either: Google warns against impersonating Gmail From headers, and you cannot publish records for a domain you do not own.

Setting it up, in order

You need access to wherever your domain's DNS is managed, and your email provider's authentication help page. Before you start, write down everything that sends email as your domain. People usually forget a booking system, an accounting package or a contact form.

Step one: SPF

There should be one SPF record per domain, published as a TXT record. It looks something like the NCSC's example:

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

If you already have a record, add to it. Do not create a second one. Watch the limit too: the NCSC notes that SPF restricts domain lookups to 10, and that "include" entries can use several each, so a pile of cloud services can breach it quickly. It suggests sending from separate sub-domains, which have their own limits. A sub-domain such as news.yourdomain.org.uk for the newsletter is a tidy arrangement anyway.

Step two: DKIM

Your provider will generate the key and give you one or more records to publish, often as CNAME or TXT entries. Add them exactly as given, then press whatever verification button the tool offers. DNS changes can take a while to spread, so an immediate failure may just mean you need to wait.

Step three: DMARC at "none"

The NCSC's starting record takes this form:

v=DMARC1;p=none;rua=mailto:[email protected]

A policy of none will not affect delivery. It simply asks for reports on where email claiming to be from your domain appears to be coming from. Those reports arrive as machine-readable files, so send them to a mailbox set aside for them or a reporting tool.

Step four: tighten it gradually

Read the reports until all your legitimate senders pass. Then move to quarantine and later reject. The NCSC says that many organisations move from quarantine to reject after about three months, and suggests starting with a small percentage of mail and monitoring closely afterwards. Skipping ahead risks your own invoices being binned, so go slowly. For a very small organisation, staying at quarantine for a long time is better than a hasty reject that nobody monitors.

What authentication will not fix

These records prove identity. They cannot make anyone want your email. Sending to people who never asked, or who stopped reading long ago, generates the spam complaints that Google measures. Authentication and list hygiene work together, and a properly consented list is the base of both.

A quick test: send an issue to a Gmail account, open the message menu, choose "Show original", and look for pass results against SPF, DKIM and DMARC.

Yours faithfully,

The editors of Tin Letter

P.S. Put a reminder in your calendar to look at your DMARC reports next month. They are of no use unread.

Enclosures: sources we cite