SPF, DKIM and DMARC: set up email authentication in the right order

SPF, DKIM and DMARC are three DNS records that together prove an email really comes from your domain: SPF lists the servers allowed to send for you, DKIM signs each message, and DMARC checks that the visible From address passed one of them and tells receivers what to do when it did not. Set them up in that order. Without them your invoices and newsletters land in spam, and anyone can send mail that looks like yours.

This guide is the map of email authentication for whoever manages the domain's DNS. By the end you will know what each record does, have one SPF record, DKIM signing for every service that sends as you, and a DMARC policy that moves safely from monitoring to rejecting forged mail. Allow an hour for the records and a few weeks of reports before the last step.

Quick answer

• Order: SPF, then DKIM, then DMARC. DMARC relies on the other two, so it goes last.
• SPF: one TXT record at the domain root listing every service that sends for you, for example v=spf1 include:_spf.google.com ~all. Never two SPF records, never more than 10 DNS lookups.
• DKIM: turn on signing in each sending service (Google Workspace, Microsoft 365, your newsletter tool, your shop) and publish the key record it gives you.
• DMARC: start with v=DMARC1; p=none; rua=mailto:[email protected] at _dmarc.example.com, read the reports for 2–4 weeks, then move to p=quarantine and later p=reject.
• Gmail and Yahoo require SPF, DKIM and a DMARC record from anyone sending about 5,000 or more messages a day to their users; Microsoft applies the same rule to Outlook.com since May 2025.
• Check all of it at once with the free email and DNS health check.

SPF vs DKIM vs DMARC: what each one does

Email authentication is three checks a receiving mail server runs on every message, each answering a different question:

DKIM vs SPF. SPF checks the server; DKIM checks the message. SPF breaks when mail is forwarded, because the forwarding server is not on your list. A DKIM signature travels with the message and usually survives forwarding.

DMARC vs DKIM. DKIM proves that some domain signed the message, not necessarily the one your recipient sees. DMARC adds that link to the visible From address, plus a policy and reports. That is why you need all three: SPF and DKIM supply the proof, DMARC decides what the proof is worth.

Where MX records fit

An MX record is a different job: it says which servers receive mail for your domain, each with a priority number (lower is tried first). SPF, DKIM and DMARC are about mail you send. They share the same DNS zone, so a DNS move that drops the MX records stops incoming mail, and one that drops the TXT records breaks authentication. The MX records fix page covers lookups and priorities.

What is an SPF record?

SPF (Sender Policy Framework, RFC 7208) is a TXT record at the domain root listing the servers allowed to send mail for it. The receiver checks the connecting server against that list, using the domain in the envelope sender (the Return-Path), not the From line people see.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:203.0.113.25 ~all"

The record starts with v=spf1, lists the allowed senders (include: for a provider's list, ip4:/ip6: for your own addresses) and ends with one all term. ~all (softfail) marks mail from anywhere else as suspect and -all (fail) says it is not yours; start with ~all while you confirm every sender. ?all and +all offer no protection.

Our SPF record guide goes through the syntax term by term, with copy-ready examples for common setups and the full ~all versus -all decision. The SPF record fix page has more examples.

Multiple SPF records and the 10-lookup limit

A domain must have exactly one SPF record. Two TXT records starting with v=spf1 make SPF fail with a permanent error (permerror) for all your mail. To add a sender, add its include: to the existing record:

; Wrong: two SPF records, both invalid
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:mail.zendesk.com ~all"

; Right: one record, both senders
example.com.  TXT  "v=spf1 include:_spf.google.com include:mail.zendesk.com ~all"

RFC 7208 also caps SPF at 10 terms that need a DNS lookup (include, a, mx, ptr, exists, redirect), counted across every nested include; ip4:, ip6: and all are free. Past 10, receivers stop with permerror too. Providers change their records, so a record that was fine last year can be over the limit today; count with a tool rather than by hand.

The guide to multiple SPF records and the 10-lookup limit shows how to merge two records, counts a real record term by term, and lists the ways back under 10, from removing unused services to moving senders to a subdomain, with an honest look at flattening. Many newsletter and transactional services need no include in your root record at all, because they authenticate your domain through DKIM.

What is DKIM, and what is a selector?

DKIM (DomainKeys Identified Mail, RFC 6376) signs each outgoing message with a private key that stays with the sending service. The signature travels in a DKIM-Signature header that names the signing domain (d=example.com) and a selector (s=google), and the receiver checks it against the public key at selector._domainkey.example.com. If anyone changed the message on the way, the check fails; if nobody did, the signature usually survives forwarding, which SPF does not.

Selectors give each service its own key, which is why DKIM is switched on in every sending service rather than in your DNS alone. For DMARC, the signature must use your domain in d=, not the service's. Our guide to DKIM, selectors and the DKIM record explains the signature, how to find your selector and what goes in the record. Where to switch it on in common services:

Google Workspace and Microsoft 365 have their own sections below. Menu paths and record targets change; follow the service's own page when it differs. The DKIM fix page covers key rotation.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain with two jobs: it tells receivers what to do with mail that claims to be from your domain but fails authentication, and it asks them to send you daily reports of every server that sent mail as you. The IETF updated the standard in May 2026: RFC 9989 replaces RFC 7489, and RFC 9990 and 9991 cover the reports. Records still start with v=DMARC1, and existing records keep working.

A message passes DMARC when SPF or DKIM passes and the domain it checked matches the From domain (alignment). That link to the visible address is what SPF and DKIM lack on their own. Your first record changes nothing about delivery, so it cannot break mail:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Our guide to what DMARC is and how to publish your first record explains the receiver's checks step by step, every tag after the 2026 update, record examples for common cases and the mistakes that make receivers ignore a record. The DMARC fix page has a short version.

DMARC policy: none, quarantine and reject

The policy (p=) is none (report only), quarantine (spam folder) or reject (refuse). Only the last two stop forged mail, which is why scanners flag p=none as "DMARC quarantine/reject policy not enabled". It is not an error; it is a reminder that monitoring protects nobody.

Move up once 2–4 weeks of reports show every legitimate service passing with alignment: p=none, then p=quarantine, then p=reject. RFC 9989 dropped the old pct tag and added t=y, a testing flag that asks receivers to apply one level softer, and np=, a policy for subdomains that do not exist. Alignment problems, a service passing SPF or DKIM for its own domain rather than yours, are the usual reason a policy change catches real mail.

The DMARC policy guide has the full rollout: a checklist before each step, the record for each stage, how alignment fails and how to fix it, quarantine versus reject, and subdomain policies.

How do DMARC reports work?

Each receiver that gets mail from your domain (Google, Microsoft, Yahoo and others) sends one aggregate report a day as a zipped or gzipped XML file to your rua address. Inside, one <record> per sending IP address gives a message count and whether DKIM and SPF passed for your domain, followed by the raw checks behind that verdict. Reports contain no message content, only IP addresses, domains, counts and results.

Sort the rows into three groups: your services passing (nothing to do), your services failing (turn on DKIM or add them to SPF), and servers you do not recognise (spoofing or a forgotten tool; look up the IP owner before deciding). When only the first and the last group are left, you are ready to tighten the policy.

Our guide to reading DMARC aggregate reports walks through a full report part by part, the four patterns that need action, how to identify an unknown sending IP, and what RFC 9990 changed in the format in May 2026.

SPF, DKIM and DMARC on Google Workspace

On Google Workspace the SPF record is v=spf1 include:_spf.google.com ~all, plus includes for any other senders. DKIM is generated in the Admin console under Apps → Google Workspace → Gmail → Authenticate email, published as a TXT record at google._domainkey, and only takes effect once you click Start authentication. Until then Google signs with a shared gappssmtp.com domain that does not align with yours. DMARC is a plain DNS record at _dmarc; Google's Admin Help recommends starting at p=none.

The Google Workspace SPF, DKIM and DMARC guide has every step with the exact values, the MX records, what to do about secondary domains and domain aliases, and how to confirm each record in Gmail's Show original.

SPF, DKIM and DMARC on Microsoft 365

On Microsoft 365 the SPF record is v=spf1 include:spf.protection.outlook.com -all (GCC High, DoD and 21Vianet tenants use their own include). DKIM uses two CNAME records, selector1._domainkey and selector2._domainkey, whose targets you copy from the Microsoft Defender portal before switching signing on; until then Microsoft signs with your onmicrosoft.com domain. DMARC is the same _dmarc TXT record as everywhere else.

The Microsoft 365 SPF, DKIM and DMARC guide walks through the portal and the PowerShell alternative, the newer CNAME format for domains added since May 2025, and how Microsoft 365 applies other domains' DMARC policies to your incoming mail.

What Gmail, Yahoo and Outlook require from bulk senders

Since February 2024, everyone sending to Gmail or Yahoo addresses must authenticate with SPF or DKIM, send from IPs with valid forward and reverse DNS, use TLS, and keep the spam complaint rate below 0.3%. Bulk senders, which Google defines as close to 5,000 or more messages a day to personal Gmail accounts, must also have both SPF and DKIM, a DMARC record (p=none is enough) with an aligned From domain, and one-click unsubscribe in marketing mail, honoured within 2 days.

Google began rejecting more non-compliant bulk mail from November 2025. Microsoft applied the same authentication rule to Outlook.com, Hotmail and Live addresses on 5 May 2025 for domains sending more than 5,000 messages a day, rejecting the rest with 550 5.7.515.

The guide to Google's DMARC requirement and the bulk-sender rules explains who counts as a bulk sender, the one-click unsubscribe headers from RFC 8058, and how to check each requirement.

Why are my emails going to spam?

Mail lands in spam for five reasons, best checked in this order: your domain fails SPF, DKIM or DMARC; a tool sends as you (a newsletter tool, your shop, website forms) without being set up for your domain; your reputation suffers from spam complaints or old lists; your own mail server lacks reverse DNS or TLS; or the message itself looks like spam. The first two account for most cases and are fixed in DNS and in the tools' settings.

WordPress is a common cause of the second: it sends form and order mail through the web server by default, with no DKIM and from an IP address that is not in your SPF record. An SMTP plugin fixes it.

The guide why are my emails going to spam takes you through the diagnosis step by step: where the problem happens, how to read the authentication results in a message, how to find the tools that send as you, and what Google's 0.1% and 0.3% spam-rate thresholds mean for your list.

DMARC fail and "554 5.7.5" errors

A bounce such as "554 5.7.5 permanent error evaluating DMARC policy" means the receiver could not get a usable DMARC result for your domain. Usually your DMARC record is broken or duplicated, your SPF record fails with permerror (two records or more than 10 lookups), or a service sends without aligned SPF or DKIM while your policy says reject. Gmail's 550 5.7.26 and Microsoft's 550 5.7.509 say the same in other words.

In message headers, dmarc=fail next to dkim=pass means DKIM passed for the service's domain, not yours; dkim=fail means the key in DNS does not match the signature or the message was changed on the way. The guide to the 554 5.7.5 DMARC error and DMARC and DKIM fail results shows how to tell the causes apart, how to read an Authentication-Results header, and how to stop the damage while you fix the sender.

BIMI: your logo in the inbox

BIMI (Brand Indicators for Message Identification) is a TXT record at default._bimi.yourdomain that points to your logo, so supporting inboxes such as Gmail, Yahoo and Apple Mail show it next to your mail. It is the reward for finishing DMARC: it works only when your policy is quarantine or reject.

The logo must be a square SVG in the SVG Tiny PS profile. Gmail also needs a mark certificate, a VMC (which requires a registered trademark and adds a checkmark) or a CMC; Apple Mail accepts only a VMC, and Yahoo can show logos without one. Our guide to BIMI, its logo rules and VMC certificates covers the requirements, the record and why a logo may not show. Set it up last; the BIMI fix page lists the requirements in short.

How do I check my SPF, DKIM and DMARC records?

The check reads your MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI records, follows every SPF include to the end and tries 27 common DKIM selectors. Every problem comes with the record to paste, written for your provider when the MX records reveal it. It only reads public DNS and sends no mail.

DKIM keys sit under a selector name only your provider knows. If yours uses a custom one, this check reports "not found" even though DKIM works; the s= value in a sent message's DKIM-Signature header tells you the real selector.

It also checks two optional extras for later: MTA-STS and TLS-RPT (encrypted delivery to you, and reports when it fails).

Cloudflare DNS

Add TXT and CNAME records under DNS → Records. Mail-related CNAMEs (DKIM for Microsoft 365, Mailchimp, SendGrid) must be DNS only (grey cloud), not proxied, or receivers get Cloudflare's address instead of the key.

Verify

• Run the email and DNS health check again. SPF should read "valid (n of 10 DNS lookups)", DMARC should name your policy and report address, and DKIM should show a key.
• From a terminal:

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

• Send a message to a Gmail address, open it, choose Show original, and look for SPF: PASS, DKIM: PASS and DMARC: PASS. In Outlook, the Authentication-Results header shows the same.
• After a week, the DMARC reports should show every real service with dkim or spf pass in policy_evaluated.
• Never jump straight to p=reject: the first sign of a forgotten sender is then customers not receiving invoices.

Questions people ask

What is an MX record?

An MX (mail exchanger) record is a DNS record that names the servers receiving email for your domain, each with a priority number; senders try the lowest number first. Google Workspace uses smtp.google.com, Microsoft 365 a host ending in mail.protection.outlook.com. MX records handle incoming mail only; SPF, DKIM and DMARC authenticate the mail you send.

What is the difference between SPF, DKIM and DMARC?

SPF lists the servers allowed to send for your domain, DKIM signs each message so receivers can prove it is unchanged, and DMARC checks that the visible From domain passed one of them and says what to do if not. SPF and DKIM each prove something; DMARC connects that proof to the address your recipient sees and adds reports. You need all three.

Which should I set up first: SPF, DKIM or DMARC?

Set up SPF first, then DKIM, then DMARC. DMARC only evaluates the results of the other two, so publishing it before they work just produces reports full of failures. SPF is one record; DKIM has to be switched on in every service that sends as you. Start DMARC at p=none and tighten it once reports show all your mail passing.

Is email authentication required by law?

Generally no. SPF, DKIM and DMARC are technical standards, not legal duties for ordinary businesses. What makes them mandatory in practice are the mailbox providers: Gmail, Yahoo and Outlook.com require all three from anyone sending around 5,000 or more messages a day to their users, and reject or filter mail that falls short. Some governments require DMARC for their own agencies' domains.

How do I protect a domain that never sends email?

Yes, a short version. A domain that never sends mail can still be forged, so publish records that say nobody sends for it: v=spf1 -all at the root and v=DMARC1; p=reject at _dmarc. No DKIM key is needed. This matters most for parked domains, old brand names and spelling-mistake domains that only redirect to your main site.

Do SPF, DKIM and DMARC cover my subdomains?

Partly. A DMARC record on your main domain also covers its subdomains, unless you set a separate sp= policy or the subdomain publishes its own _dmarc record. SPF does not inherit: a subdomain that sends mail, such as news.example.com, needs its own SPF record. DKIM keys are tied to whatever domain the service signs with, so set them up per sending domain.