How to Set Up SPF, DKIM and DMARC

Publish the three DNS records that stop others sending mail as your domain: list your senders, write SPF, publish a DKIM key, start DMARC at p=none and tighten it.

Last reviewed:

AdSense Placeholder
Slot: header_reference_page
On this page

Steps

  1. List every service that sends mail as your domain

    Write down your mailbox provider, newsletter tool, invoicing or CRM system, website contact form and any server that sends alerts. Every one of them must be covered by SPF, DKIM or both, or its mail will fail once you enforce DMARC.

  2. Build the SPF record

    Open the SPF Record Generator, tick your mail provider from the list, add any extra IP addresses or include: entries, and keep ~all while you test. Watch the lookup counter: SPF allows at most 10 DNS lookups. Publish the result as one TXT record at your domain.

  3. Create and publish a DKIM key

    If your provider (for example Google Workspace or Microsoft 365) signs mail for you, generate the key in its admin console and publish the TXT record it gives you. If you run your own mail server, make a key pair with the DKIM Record Generator, install the private key on the server and publish the public key at selector._domainkey.yourdomain.

  4. Publish DMARC in monitoring mode

    Use the DMARC Record Generator to write v=DMARC1; p=none; rua=mailto:... and publish it as a TXT record at _dmarc.yourdomain. With p=none nothing is blocked; you only start receiving aggregate reports.

  5. Check the published records

    Run the Email Deliverability Checker on your domain to confirm that SPF, DMARC and MX are found and read back exactly as you typed them. Use DNS Record Lookup with the TXT type if a record seems to be missing; changes can take time to spread.

  6. Read the reports, then tighten the policy

    After a couple of weeks, review who is sending as your domain. Fix any legitimate sender that fails, then move to p=quarantine and later p=reject. Change the SPF ending from ~all to -all once you trust the list.

What you need

Access to your domain's DNS settings (at your registrar or DNS host), an address that can receive DMARC reports, and the list of everything that sends mail as your domain.

The three records at a glance

Record Published at What it proves
SPF TXT on the domain itself The sending server's IP address is allowed to send for this domain
DKIM TXT at selector._domainkey.domain The message carries a valid signature from a key the domain published and was not altered
DMARC TXT at _dmarc.domain What receivers should do when neither SPF nor DKIM lines up with the visible From address, and where to send reports

A finished setup for a placeholder domain looks like this:

example.com.                 TXT  "v=spf1 include:_spf.mailhost.example ~all"
s1._domainkey.example.com.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
_dmarc.example.com.          TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Rolling out DMARC safely

Stage Policy Effect
Monitor p=none Nothing is blocked; reports show every source
Soft enforcement p=quarantine Failing mail goes to spam
Full enforcement p=reject Failing mail is refused

Stay in each stage until the reports show no legitimate source failing. Spend longer on monitoring than feels necessary, because forgotten senders (a billing system, an old newsletter tool) are the usual casualties.

Common pitfalls

  • Two SPF records. A domain must have exactly one SPF TXT record. Merge them into one.
  • More than 10 lookups. Each include, a, mx, exists and redirect counts, and so does everything the included records do in turn. Going over makes SPF fail with a permanent error.
  • Using +all. It authorises the whole internet. Never publish it.
  • Forgetting third-party senders. Newsletter, ticketing and invoicing services each need to be in SPF and should sign with your domain through DKIM.
  • Ignoring alignment. DMARC needs the domain that passed SPF or DKIM to match the visible From domain. A service that signs only with its own domain does not help your DMARC result.
  • Report mailbox flooding. Aggregate reports are XML files. Use a dedicated mailbox or a report-processing service.

Going further

How the three standards fit together is explained in How Email Authentication Works: SPF, DKIM and DMARC, and the exact tag syntax is in SPF, DKIM and DMARC Syntax Cheat Sheet. To test a message you have received, follow How to Check If an Email Is Spoofed.

Try these tools

See also

  • Guide How Email Authentication Works: SPF, DKIM and DMARC
    What SPF, DKIM and DMARC each check, what their DNS records look like.
  • Cheat sheet SPF, DKIM and DMARC Syntax Cheat Sheet
    Record syntax for SPF mechanisms and qualifiers, DKIM signature and key tags (RFC 6376) and DMARC tags (RFC 7489 and RFC 9989).
  • Glossary SPF
    SPF (Sender Policy Framework) is a DNS record listing which servers may send email for a domain.
  • Glossary DKIM
    DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing email that receivers verify with a public key published in DNS.
  • Glossary DMARC
    DMARC is a DNS policy that tells receivers what to do with email that fails SPF and DKIM alignment, and where to send reports about it.

Frequently Asked Questions

Yes. SPF and DKIM each prove something different, and DMARC is what makes a receiver act on the result and send you reports. Large mailbox providers now expect all three from anyone who sends in volume, and a domain with only SPF can still be spoofed in ways SPF alone cannot catch.

A DKIM record lives at a name that includes a selector you choose (such as s1._domainkey.example.com), and there is no way to discover the selector from outside. The Email Deliverability Checker therefore reports SPF, DMARC and MX only. To verify DKIM, send yourself a message and read the Authentication-Results header in the received copy.

You can, but you will probably lose real mail. Until the reports show that every legitimate sender passes, use p=none, then quarantine, then reject.

AdSense Placeholder
Slot: footer_leaderboard