Email sender domain setup: SPF, DKIM and DMARC explained

Three DNS records prove that mail claiming to come from your domain is really yours. SPF lists the servers allowed to send for the domain. DKIM adds a cryptographic signature to each message that receivers check against a public key you publish. DMARC tells receivers what to do when a message fails both checks and sends you reports. Gmail's published rules, in force from 1 February 2024, ask every sender to set up SPF or DKIM, and ask anyone who sends more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, align the From domain with the SPF or DKIM domain, and support one-click unsubscribe in marketing mail.

For an online store the practical order is: set up the platform's own domain authentication for each tool that sends in your name (marketing platform, shop, helpdesk, transactional service), publish one SPF record that covers them, enable DKIM for each, and add DMARC at the monitoring policy first. The records are DNS entries, so the work is configuration and testing; check whether your DNS host or email tools charge for any part of it. For the platform side see our guides to moving between email platforms and email marketing pricing units.

Two details cause most trouble. SPF allows at most ten DNS-lookup terms during evaluation (the standard counts include, a, mx, ptr and exists mechanisms and the redirect modifier, not ip4, ip6 or all); exceeding the limit produces a permanent error, so adding one "include" for every tool you try eventually breaks the record. And a domain must not publish more than one SPF record: the standard says multiple SPF records are not permitted for the same owner name, so a second tool's instructions must be merged into the existing record, not added as another.

A sender signs each message with a private key and publishes the matching public key in DNS at the name selector._domainkey.yourdomain, as a TXT record whose p= tag holds the key; an empty p= means the key has been revoked. The d= tag names the signing domain and the s= tag the selector, which lets a domain keep several keys at once, for example one per sending tool. The signature covers the From header, the other headers listed in h= and a hash of the body. RFC 6376 requires keys of at least 1024 bits for long-lived keys, and Gmail's help page says keys must be 1024 bits or longer and recommends 2048. In practice each sending platform gives you the selector and the record value to publish; you do not generate the signature yourself.

DMARC passes when SPF or DKIM passes and the passing domain aligns with the domain in the visible From address. Under relaxed alignment the organizational domains must match; under strict alignment only an exact domain match counts. That is why a marketing tool that sends from its own domain but shows your address in From still fails DMARC unless it signs with your domain or uses an aligned return path. Gmail's page says the DMARC policy for bulk senders can be set to none, so a monitoring policy meets that requirement; moving to quarantine or reject later is your decision once the reports show every legitimate sender passes.

The page states a threshold of more than 5,000 messages a day to Gmail accounts and does not say that smaller senders may skip authentication: the all-senders list already asks for SPF or DKIM. It gives no timeframe for honouring an unsubscribe request, so we do not state one. Other mailbox providers publish their own rules, which we did not read.