How to set up SPF, DKIM and DMARC.

This is the step people skip and the reason most DMARC rollouts break something. Your mail provider is rarely the only sender. Anything that emails a customer on your behalf has to be accounted for before you tell the world to reject unauthorised mail.

• Your mail provider — Microsoft 365, Google Workspace, or a mailbox at your host
• Accounting and invoicing software that emails invoices directly
• CRM and marketing platforms
• Your website’s contact and enquiry forms
• Booking, ticketing or support systems
• Anything a supplier sends “from” your domain

If you inherited the domain, assume the list is incomplete. The DMARC reports in step five will tell you what you missed — which is exactly why the first policy is p=none.

SPF names the servers allowed to send mail for your domain. It is a single TXT record at the root of the domain, and there must only ever be one — two SPF records is a configuration error that causes both to be ignored.

Take the include: value from each provider’s documentation and combine them into one record. A Microsoft 365 domain that also sends through an invoicing tool looks roughly like this:

• Type: TXT — Name: @ (the domain root)
• Value: v=spf1 include:spf.protection.outlook.com include:your-invoicing-tool.com -all
• End with -all once you are confident the list is complete; use ~all while you are still finding senders

SPF allows a maximum of ten DNS lookups. Each include: usually costs one, and exceeding ten makes the whole record fail. If you are close to the limit, flattening or a subdomain strategy is the fix.

DKIM adds a cryptographic signature to every message, so a receiving server can prove the mail was not altered and genuinely came from you. Unlike SPF, it survives forwarding — which is why it does most of the real work.

Your provider generates the key pair and gives you the records. In Microsoft 365 and Google Workspace this is two CNAME records or one TXT, published at a selector under _domainkey.

• Generate the keys in your mail provider’s admin console
• Publish the records exactly as given — a trailing dot or missing character breaks the signature
• Return to the console and switch signing on, which is a separate action from publishing
• Repeat for every sender that supports DKIM, not just your mailbox provider

DMARC ties the other two together and tells receiving servers what to do when a message fails. Crucially, it also asks them to send you reports.

Start at p=none. It changes nothing about delivery and simply turns on reporting, which is what makes the rest of this safe.

• Type: TXT — Name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.uk; fo=1
• Use a mailbox or group that someone actually reads

Do not start at p=reject because an article told you it is the goal. It is the destination, not the starting point, and going straight there will bounce legitimate mail you have not discovered yet.

Reports arrive daily as XML, which is unpleasant to read directly. Any DMARC report viewer will turn them into a list of sources with pass and fail counts.

You are looking for one thing: sources sending as you that are failing. Each is either a legitimate system you missed in step one, or someone spoofing you. Legitimate senders get added to SPF and DKIM. Everything else is the reason you are doing this.