SPF, DKIM and DMARC in plain English

SPF, DKIM and DMARC are three records in your domain's DNS that let receiving mail servers confirm an email really came from you. SPF lists who may send for your domain, DKIM signs each message, and DMARC says what to do when a check fails. Without them, your invoices can land in spam and someone else can send mail that looks like yours.

Why do these three records matter now?

In February 2024, Google and Yahoo began requiring senders of large volumes of mail to authenticate it. Google's published guidelines say senders of more than 5,000 messages a day to Gmail addresses must set up SPF, DKIM and DMARC, support one-click unsubscribe for marketing mail, and keep spam complaints low. Microsoft announced comparable requirements for Outlook.com in 2025.

The rules are aimed at bulk senders, but the same checks decide how all your mail is treated. A small business sending a few hundred quotes a week still benefits, because the records protect your domain's name from being forged in phishing emails aimed at your customers.

What is SPF?

SPF, the Sender Policy Framework (RFC 7208), is a list of the servers and services allowed to send email for your domain. It lives in a TXT record at the root of your domain. A typical record for a business on Google Workspace that also uses a newsletter tool looks like this:

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

Read it from left to right: this is an SPF record, Google's servers may send, the newsletter provider's servers may send, and anything else should be treated with suspicion (~all is a soft fail, -all a hard fail).

Things that go wrong:

• Two SPF records: a domain may have only one. Two cause both to fail.
• Too many lookups: SPF allows a maximum of 10 DNS lookups. Every include costs one or more. Exceed it and the check fails.
• Forgotten senders: the CRM, the invoicing app, the helpdesk and the website contact form all send mail as you. Each must be listed.

What is DKIM?

DKIM, DomainKeys Identified Mail (RFC 6376), signs each outgoing message with a private key. The matching public key sits in your DNS under a name called a selector, such as selector1._domainkey.example.com. The receiver fetches the public key and checks that the signature fits the message.

DKIM proves two things: the message came from a system you authorised, and it was not changed on the way. Google Workspace and Microsoft 365 both generate DKIM keys for you. You publish the record they give you and then switch signing on. Do this for every service that sends as your domain.

What is DMARC?

DMARC ties the other two together. It is a TXT record at _dmarc.yourdomain.com that does two jobs. It tells receivers what to do when a message fails authentication, and it asks them to send you reports.

A starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The p tag is the policy:

• none: monitor only. Mail is delivered as usual, and you receive reports.
• quarantine: failing mail goes to spam.
• reject: failing mail is refused.

DMARC also checks alignment. The domain in the visible From address must match the domain that passed SPF or DKIM. This is the part that stops a scammer using your name in the From line while passing checks on their own domain.

What is the right order for setting these up?

1. List every service that sends mail as your domain. Ask finance, sales, support and your web developer. This list is the most valuable part of the job.
2. Publish SPF with all of them, in one record.
3. Enable DKIM in each service and publish the keys.
4. Publish DMARC with p=none and a mailbox for reports.
5. Read the reports for a few weeks. Free or low-cost report tools turn the raw XML into readable tables. Look for legitimate senders that fail and fix them.
6. Move to quarantine, then to reject once failures are only forged mail.
7. Re-check whenever you add a new tool that sends email.

Do not skip step 5. Going straight to reject is how a business discovers on a Monday morning that its payment receipts have been bouncing since Friday.

How do you check that it works?

Send a test message from each system to a Gmail address. Open the message, choose "Show original" and look for SPF: PASS, DKIM: PASS and DMARC: PASS. Free checkers such as Google's Admin Toolbox and MXToolbox read your public records and flag problems like duplicate SPF entries. Our free health check also looks at your domain's email setup.

What about Google Workspace and Microsoft 365?

Both give step-by-step setup in their admin consoles. The common trap is the mix of services around them. A company on Microsoft 365 may send its marketing through a third party, invoices through accounting software and order mails from its web shop. Each has its own instructions for SPF and DKIM, and each must be added.

If your domain is used by several teams or brands, consider setting separate subdomains for marketing mail, such as news.example.com. That keeps a problem with newsletter reputation from touching your day-to-day business mail.

What are the trade-offs?

Strict policies protect the domain and raise the cost of mistakes. A hard reject stops spoofing. It also stops any legitimate sender you forgot. Staged rollout is slower and much safer.

Reporting adds a stream of data to read. Use a tool, or an outside team, to summarise it. Otherwise the reports pile up unread and the policy never advances beyond none.

Authentication does not guarantee inbox placement. Sender reputation, content and list hygiene still matter.

Where does TechSum fit?

We audit your domain's email records, find every sending service, set up the three records correctly and move DMARC to enforcement in stages. Google Workspace and Microsoft 365 administration is part of the same work. See the email deliverability page and the Digital Infrastructure pillar, or start with the Digital Health Check.