The complete guide to SPF, DKIM and DMARC

Email was designed without any way to prove who sent a message. Even today, anyone can type your domain into the From line of an email and send it. SPF, DKIM and DMARC are the three DNS-based standards that close that gap, and together they are now the entry ticket to the inbox at every major mailbox provider.

This guide explains what each one does, why you need all three, how alignment ties them together and how to roll them out in an order that protects your domain without blocking your own legitimate mail.

The short version: SPF says which servers may send for you, DKIM proves the message was not forged or altered, and DMARC checks that those results match the address people actually see, then tells receivers what to do when they do not.

Why authentication is no longer optional

In February 2024, Google and Yahoo began enforcing new rules for bulk senders. If you send more than about 5,000 messages a day to their users, you must:

• Publish SPF and sign with DKIM.
• Publish a DMARC record (at minimum p=none).
• Pass DMARC alignment, meaning SPF or DKIM authenticates your From domain.
• Support one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers.
• Keep spam complaints below 0.3%, ideally under 0.1%.

Microsoft applied the same authentication baseline to Outlook.com, Hotmail and Live addresses for high-volume senders in May 2025. Non-compliant mail now gets filtered or rejected with errors such as 550 5.7.26 at Gmail or 5.7.515 at Outlook.

Even below that threshold, skipping authentication is a bad trade. Unauthenticated mail gets less trust, and your domain stays open for anyone to spoof in phishing attacks against your own customers.

How the three checks work together

When a receiving server gets your message, it runs the checks in roughly this order:

1. SPF. Is the connecting IP on the list published by the Return-Path domain?
2. DKIM. Does the signature in the DKIM-Signature header verify against the public key in DNS for the signing domain?
3. DMARC. Did SPF or DKIM pass for a domain that aligns with the visible From domain? If not, apply the domain owner’s policy.

The reason DMARC exists is that SPF and DKIM each leave a gap. SPF checks the envelope sender (also called Return-Path or MAIL FROM), not the From header that people see. A spammer can pass SPF with their own domain while displaying yours. DKIM proves a message was signed by some domain and not changed, but by itself it does not say that domain has to be yours or what to do on failure.

DMARC adds the missing link: at least one passing result has to belong to the same domain as the From address.

SPF: who is allowed to send

The Sender Policy Framework (RFC 7208) is a single TXT record listing every server authorized to send mail using your domain in the envelope sender. The receiver compares the connecting IP to that list.

SPF syntax

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

Reading it left to right:

• v=spf1 is the required version tag and must come first.
• include:_spf.google.com authorizes Google Workspace servers.
• include:_spf.yourprovider.com authorizes a marketing or transactional platform. Each ESP publishes its own include value.
• ip4:203.0.113.25 authorizes one of your own servers.
• -all says every other server should fail.

Mechanisms and lookup cost

The all qualifier

• -all (fail): unlisted servers are not authorized. The right end state.
• ~all (softfail): unlisted servers are suspect. Useful while you are still finding senders.
• ?all (neutral): no opinion. Offers no protection.
• +all (pass): authorizes the whole internet. Never use it.

The 10-lookup limit

RFC 7208 caps SPF evaluation at 10 DNS lookups, and nested includes count too. Google’s include alone uses several. Exceed the limit and SPF returns permerror, which most receivers treat as a fail. The SPF Checker counts your lookups, including nested ones, and the SPF Generator builds a clean record from your list of senders.

If you are over the limit, remove services you no longer use, replace a and mx with explicit ip4 ranges where they are stable, or move some senders to a subdomain with its own SPF record.

DKIM: a signature that proves the message is genuine

DomainKeys Identified Mail (RFC 6376) attaches a cryptographic signature to each message. Your sending server signs selected headers and the body with a private key. The receiver fetches the matching public key from DNS and verifies the signature. If anything signed was altered on the way, verification fails.

What a signature looks like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=s1; t=1790000000;
  h=from:to:subject:date:message-id:list-unsubscribe;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

The fields you need to recognize:

• d= is the signing domain. For DMARC, it must align with your From domain.
• s= is the selector, which tells the receiver where in DNS to find the key.
• a= is the algorithm, almost always rsa-sha256.
• h= lists the signed headers.
• bh= is the body hash and b= is the signature itself.

You can see these fields in any received message with the Header Analyzer.

The DNS record and selectors

The public key is a TXT record at selector._domainkey.yourdomain:

s1._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5dF3..."
  "...IDAQAB" )

v=DKIM1 is the version, k=rsa the key type and p= the base64 public key. An empty p= means the key has been revoked.

Selectors let one domain publish many keys at once. Each ESP uses its own: Google Workspace uses google, and others use names like s1, k1 or selector1. Some providers ask you to publish a CNAME that points to a key they host, which lets them rotate keys without you touching DNS.

Key length and rotation

Use 2048-bit RSA keys (RFC 8301 sets 1024 as the floor). A 2048-bit key is longer than a single 255-character DNS string, so it is split into several quoted strings inside one record, as shown above. Rotate keys at least yearly by publishing a new selector, switching signing to it, and removing the old key after a week or two. Verify each selector with the DKIM Checker.

DMARC: alignment, policy and reports

Domain-based Message Authentication, Reporting and Conformance (RFC 7489) does three things SPF and DKIM cannot: it requires alignment with the From domain, it sets a policy for failures, and it sends you reports about everyone using your domain.

A starter record

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

DMARC tags

If your rua address is on a different domain, that domain must publish an authorization record, otherwise receivers will not send reports there. The DMARC Generator builds a valid record for each stage and the DMARC Checker validates what you published.

Alignment explained

Alignment is the rule that makes DMARC meaningful.

• Relaxed (default): the organizational domains must match. news.example.com aligns with example.com.
• Strict: the domains must match exactly. news.example.com does not align with example.com.

A message passes DMARC if either SPF passes with an aligned Return-Path domain or DKIM passes with an aligned d= domain. You only need one, but having both gives you a safety net. DKIM alignment matters most in practice because it survives forwarding, while SPF usually breaks when a message is relayed through another server.

The most common failure pattern: your ESP’s SPF passes, but for the ESP’s own bounce domain, not yours. SPF is not aligned. If DKIM also signs with the ESP’s domain instead of yours, DMARC fails even though both checks “passed.” The fix is to set up custom DKIM (and ideally a custom Return-Path) on your own domain in the ESP’s settings.

The policy ladder

• p=none: monitor only. Receivers deliver as usual and send reports. No spoofing protection.
• p=quarantine: failing mail goes to spam or junk.
• p=reject: failing mail is refused during the SMTP conversation.

Industry surveys consistently find that a large share of domains with DMARC never move past p=none. That meets the letter of the bulk sender rules but stops nobody from spoofing you.

Reading aggregate reports

Aggregate (rua) reports are daily XML files from each receiver, listing every IP that sent mail using your From domain, how many messages it sent, and whether SPF and DKIM passed and aligned. They are how you find the forgotten CRM, the helpdesk tool or the old web server still sending invoices. Raw XML is hard to read, so most teams use a free or paid DMARC report processor to turn it into a dashboard.

Forwarding, mailing lists and ARC

Authentication was designed for mail that travels directly from sender to receiver. Real mail does not always behave that way.

When a message is forwarded (for example, from a university address to a personal Gmail account), the forwarding server connects from its own IP. SPF fails, because that IP is not in your record. DKIM usually survives, because forwarding does not normally change the signed headers or body. That is why aligned DKIM is the more reliable of the two for DMARC.

Mailing lists are harder. Many add a footer or a tag to the subject line, which breaks the DKIM signature. With both SPF and DKIM broken, a strict DMARC policy would cause list mail to fail. Modern list software works around this by rewriting the From address to the list’s own domain.

ARC (Authenticated Received Chain, RFC 8617) helps here. Intermediaries such as forwarders and list servers record the authentication results they saw before modifying the message and sign that record. Receivers that trust the intermediary can use the ARC chain to accept the message even though the original SPF and DKIM no longer pass. You do not publish anything for ARC yourself; it is handled by the servers in between. It is one more reason not to worry excessively about moving to p=reject once your own senders are aligned.

Subdomains and sending strategy

Many organizations send different kinds of mail from different subdomains, such as mail.example.com for marketing and notify.example.com for transactional messages. This has real advantages:

• Each subdomain builds its own reputation, so a bad marketing campaign does not drag down password resets.
• Each can have its own SPF record, which keeps you clear of the 10-lookup limit on the root domain.
• DMARC reports become easier to read, because each stream is separated.

With relaxed alignment (the default), a From address at news.example.com aligns with DKIM signed by example.com and vice versa, so you have flexibility in how you sign. Use the sp= tag in your root DMARC record to set a policy for subdomains that do not publish their own, and publish a separate _dmarc record on any subdomain that needs a different policy during rollout.

Where your ESP fits in

You rarely write SPF includes or generate DKIM keys by hand. Your ESP gives you the values to publish. In the domain or sender settings of platforms such as SendPulse, Mailchimp or Brevo, you will find:

• An SPF include to add to your existing record (for SendPulse, include:mxsmtp.sendpulse.com).
• A DKIM record or CNAME for a specific selector (SendPulse uses sign, so the record lives at sign._domainkey.yourdomain).
• Sometimes a CNAME for a custom Return-Path or bounce domain, which gives you SPF alignment.
• Sometimes a tracking domain CNAME, so link domains match your brand.

Publish exactly what the provider gives you, add it to your single SPF record rather than creating a new one, then verify inside the ESP and with our checkers. If you are moving between providers, the ESP migration playbook covers how to run both sets of records during the switch.

Step-by-step rollout in the right order

Rushing to p=reject is the fastest way to block your own invoices. Follow this order instead.

1. Inventory every sender

List everything that sends as your domain: your mailbox provider, marketing platform, transactional or SMTP service, CRM, helpdesk, billing system, website forms and any servers you run. Ask finance, support and sales what tools they use; shadow senders are the most common reason DMARC rollouts stall.

2. Publish one SPF record

Combine every sender into one v=spf1 record ending in ~all. Check lookups with the SPF Checker and stay at or under 10.

3. Turn on DKIM everywhere

Enable custom DKIM in each platform so it signs with your domain. Publish each selector, use 2048-bit keys where the provider allows it, and verify each one.

4. Publish DMARC at p=none

Add a _dmarc record with p=none and an rua address. Reports start arriving within a day or two.

5. Read reports for two to six weeks

Match every sending IP to a known service. Fix any legitimate source that fails aligned SPF and DKIM. Investigate anything you do not recognize; it may be spoofing.

6. Tighten step by step

Switch SPF to -all. Move DMARC to p=quarantine, optionally with pct=25 then pct=100. After another clean period, move to p=reject. Add sp=reject if you do not send from subdomains, and consider parking unused domains with v=spf1 -all and a reject DMARC record so they cannot be abused.

7. Test end to end

Checking each record in DNS proves it is published. It does not prove that your mail actually passes. For that, send a real message from each sending service to a Gmail or Outlook mailbox you control and look at the Authentication-Results header:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=s1;
  spf=pass (google.com: domain of bounce@mail.example.com designates 198.51.100.20 as permitted sender) smtp.mailfrom=mail.example.com;
  dmarc=pass (p=REJECT sp=QUARANTINE dis=NONE) header.from=example.com

You want pass for all three, and you want the DKIM header.i and SPF smtp.mailfrom domains to share your organizational domain. Paste the full headers into the Header Analyzer to see the results laid out and spot alignment gaps quickly.

Common mistakes that break authentication

• Two SPF records. Always a permerror. Merge them.
• Too many lookups. Nested includes add up quickly. Audit and trim.
• Forgotten senders. A tool nobody told IT about will start failing the day you enforce DMARC.
• ESP DKIM left on the shared domain. The message is signed, but not by you, so DKIM does not align.
• Using +all or ptr. The first authorizes everyone; the second is slow and deprecated.
• DKIM key pasted with line breaks or quotes in the wrong place. The record fails to parse. Check with the DKIM Checker.
• Staying on p=none forever. Monitoring is a phase, not a finish line.
• Forgetting subdomains. Without sp=, subdomains inherit p, which may be stricter or looser than you expect.

How authentication relates to reputation and DNS

Authentication is necessary but not sufficient. It tells receivers who you are; your sender reputation tells them whether to trust that identity. You also need the supporting records, such as MX and reverse DNS, covered in the DNS records for email guide.

When everything is published, run your domain through the Sender Reputation Checker to see SPF, DKIM, DMARC, blocklist status and DNS graded together, then work through the deliverability playbook for the non-technical side.