SPF, DKIM and DMARC Explained: A Complete Setup and Rollout Guide

Email was designed without sender authentication, so anyone can write any From: address. SPF, DKIM and DMARC are the three DNS-based mechanisms that let receiving servers judge whether a message really comes from your domain. After reading this guide you will be able to publish working records, understand why a message passes one check but still fails DMARC, and roll out a strict policy without blocking your own invoices.

The three mechanisms in one view

SPF and DKIM each authenticate a domain, but not necessarily the one the reader sees. DMARC ties them to the visible From: header and adds policy and reporting. That distinction explains most confusing results.

SPF: who may send

SPF is a list of servers authorised to send mail whose envelope sender (the MAIL FROM or return-path address) uses your domain. The receiver checks the connecting IP against your record.

example.com.  IN TXT  "v=spf1 ip4:203.0.113.25 include:_spf.mailprovider.example -all"

Reading it left to right:

• v=spf1 identifies the record. There must be exactly one SPF record per domain; two records cause a permanent error.
• ip4: and ip6: authorise address ranges directly.
• include: pulls in another domain's SPF policy, which is how most hosted senders work.
• a and mx authorise the addresses of your A or MX records.
• The ending is the default result for everything else: -all (fail), ~all (softfail), ?all (neutral). Choose -all once you are confident the list is complete; ~all is a common cautious setting during rollout.

SPF has a limit of ten DNS-querying terms, and it breaks when forwarded because the forwarder's IP is not in your list. Both topics matter; the limit has its own walkthrough in fixing SPF "too many DNS lookups".

DKIM: a signature on the message

With DKIM, the sending system signs selected headers and the body with a private key, and publishes the matching public key in DNS. The receiver reads the DKIM-Signature header, finds the d= domain and s= selector, fetches the key, and verifies.

selector1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Details that matter:

• Selectors let a domain publish several keys at once, one per sending service, and rotate keys without downtime. The selector name is chosen by the sender or provider.
• Key length: 2048-bit RSA is the recommended minimum today; 1024-bit is considered weak and many providers have moved off it. Some DNS hosts struggle with the longer TXT value, which needs splitting into multiple quoted strings within one record. Providers frequently publish the key as a CNAME to their own host instead, which avoids the problem and lets them rotate for you.
• DKIM survives forwarding when the message is not modified, which is why it is the more robust of the two for forwarded mail. Mailing lists that alter subjects or add footers can break the signature.
• To rotate a key: publish a new selector, switch the sender to sign with it, wait until in-flight mail is delivered, then remove the old selector.

To find a selector, look at the headers of a message from that service and read the s= value in DKIM-Signature, then query it:

dig TXT selector1._domainkey.example.com +short

DMARC: alignment, policy and reports

DMARC lets the domain owner say what receivers should do with mail that fails authentication. A message passes DMARC if either SPF or DKIM passes and is aligned with the domain in the From: header.

Alignment

Alignment means the authenticated domain matches the From domain:

• Relaxed (default): organisational domains match, so bounce.example.com aligns with example.com.
• Strict: the domains must match exactly.

This is where third-party senders go wrong. A newsletter service might send with the return-path bounce.sender-service.example, so SPF passes for that domain but does not align with example.com. SPF passes, DMARC does not benefit. The remedy is to configure DKIM signing with your domain (a custom signing domain), or a custom return-path on your domain, as the provider allows. DKIM alignment is usually the easier of the two.

The record

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

If the reporting address is on a different domain than the one being reported, the receiving domain must publish an authorisation record (example.com._report._dmarc.reportdomain.example), or many receivers will not send reports there.

Reading aggregate reports

Aggregate reports are daily XML files from receivers, listing each sending IP, the volume, and whether SPF, DKIM and alignment passed. Raw XML is tedious, so most people use a report-processing service or a small parser. What you are looking for:

• Legitimate senders that fail alignment (fix these first).
• Sources you did not know about, such as an old CRM or a marketing tool someone signed up for.
• Unfamiliar IPs failing everywhere, which are likely spoofing attempts and exactly what enforcement will block.

A rollout plan that does not break mail

1. Inventory every sender. Mail server, web app, newsletter tool, CRM, helpdesk, billing system, HR platform. Ask each department.
2. Publish SPF with the known senders and ~all.
3. Enable DKIM for each sender, signing with your own domain.
4. Publish DMARC at p=none with an rua address. This changes nothing about delivery; it only starts collecting data.
5. Review reports for several weeks, covering a full business cycle so monthly invoices and quarterly mailings appear. Fix each legitimate failing source.
6. Move to p=quarantine, starting with a low pct such as 10 or 25, and raise it as reports stay clean.
7. Move to p=reject when legitimate mail passes consistently. Keep monitoring because new tools appear over time.
8. Handle subdomains. Use sp= or separate _dmarc records for subdomains. Parked or unused domains that never send mail should publish v=spf1 -all and p=reject outright.

Common third-party senders

Most services follow the same pattern: an include: for SPF where applicable, plus one or more DKIM CNAME or TXT records they ask you to publish, and optionally a custom return-path or tracking domain. Examples of what to expect, with placeholder values:

; SPF for a hosted workspace and a transactional sender
example.com.  IN TXT  "v=spf1 include:_spf.workspace.example include:spf.transactional.example ~all"

; DKIM as a CNAME to the provider
s1._domainkey.example.com.  IN CNAME  s1.domainkey.transactional.example.

; Custom return-path so SPF aligns
bounces.example.com.  IN CNAME  return.transactional.example.

Always use the exact hostnames and values from the provider's current setup page; they differ and occasionally change.

Testing

• Look up all records with the Email DNS Checker, and build starting-point records with the SPF & DMARC Generator.
• Send a real message to the Email Deliverability Test and inspect the SPF, DKIM and DMARC verdicts.
• Open a message in Gmail or Outlook and view the original headers. Look for Authentication-Results: lines showing spf=pass, dkim=pass, dmarc=pass.
• Query records manually:

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

Common mistakes

• Two SPF records at one name. Merge them into a single record.
• Exceeding ten lookups from stacked include: entries.
• Using +all or a missing ending, which authorises the whole internet.
• DKIM published but not enabled on the sending service, so no signature is added.
• Wrong or truncated DKIM key after copy and paste, often from a DNS host that splits long strings badly.
• DMARC rua pointing to a mailbox no one reads or one that bounces.
• Assuming SPF pass equals DMARC pass. It must align.
• Forgetting subdomains, where attackers can spoof billing.example.com if there is no sp policy.
• Treating authentication as a spam guarantee. Passing all three does not ensure inbox placement; reputation and content still matter. If delivery drops, check whether your IP is listed with the Blacklist Checker and read the blacklist removal guide.

Next steps

• Verify your current records with the Email DNS Checker and MX Lookup.
• Generate a first policy with the SPF & DMARC Generator.
• If SPF reports a permanent error, read fixing SPF too many DNS lookups.
• Refresh DNS basics in DNS explained for website owners.

FAQ

Do I need all three of SPF, DKIM and DMARC?

For reliable delivery and protection against spoofing, yes. Major mailbox providers expect authentication from senders, especially for bulk mail. SPF and DKIM provide the checks, and DMARC makes them meaningful by requiring alignment and telling receivers what to do on failure.

Why does DMARC fail when SPF says pass?

Because the SPF-authenticated domain (the return-path) did not match the visible From domain. Configure the sending service to use your domain for DKIM signing or the return-path so at least one method aligns.

What DMARC policy should I start with?

Start with p=none and an rua address so you can see who is sending as your domain. Move to quarantine and then reject only after reports show your legitimate mail passing consistently.

Are ruf forensic reports worth enabling?

Often not. Many large receivers do not send them, and where they are sent they can contain message content or personal data. Aggregate rua reports provide most of the useful information.

How long should a DKIM key be?

Use 2048-bit RSA where your DNS host and sender support it. Shorter 1024-bit keys are widely considered weak. If your DNS provider limits TXT length, publish the key split into multiple strings or use the provider's CNAME-based setup.

Does DKIM survive email forwarding?

Usually yes, if the forwarder does not alter the signed parts of the message. SPF commonly breaks on forwarding since the forwarding server is not in your SPF record, which is why DMARC accepts either method passing.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.