How to Set Up SPF, DKIM & DMARC

T
Tilak Pujari, CEOUpdated: Aug 3, 2026
How to Set Up SPF, DKIM & DMARC

Key Takeaways

  • Set up SPF first, then DKIM, then DMARC, because DMARC depends on one of the other two passing with alignment.
  • SPF should list every legitimate sending service, but it can only use 10 DNS lookups before many receivers treat it as a permerror.
  • DKIM is usually the most stable control because the signature survives forwarding better than SPF.
  • Start DMARC with p=none, review reports, then move to quarantine or reject when alignment is clean.
  • Gmail and Yahoo require bulk senders, 5,000 or more messages a day, to authenticate mail and publish DMARC.
  • Publishing records is only half the job, you also need ongoing testing after platform changes, new vendors, and domain updates.

Google and Yahoo began enforcing stronger sender requirements for bulk senders in 2024, including authentication and a published DMARC record for domains sending 5,000 or more messages a day to their users. That made SPF, DKIM, and DMARC operational requirements, not optional cleanup work.

If you own deliverability, lifecycle, or RevOps, the hard part is rarely understanding what these acronyms mean. The hard part is getting the records live in the right order, keeping them aligned across platforms, and knowing which mistakes will actually hurt Gmail, Outlook, Yahoo, or Apple Mail visibility.

Here is the practical setup sequence, what each record should look like, and the checks to run before you call authentication done.

What SPF, DKIM, and DMARC each do

ProtocolWhat it checksWhy it mattersCommon failure point
SPFWhether the sending IP is allowed to send for your domainStops obvious spoofing and supports DMARCMissing vendor includes, too many DNS lookups, wrong return-path domain
DKIMWhether the message was signed with your domain's private keyProves message integrity and usually survives forwarding better than SPFSelector mismatch, broken signing, expired or missing key
DMARCWhether SPF or DKIM passed and aligned with the visible From domainTells receivers how to handle unauthenticated mail and gives reportingNo alignment, over-aggressive policy, reports sent to an unmonitored inbox

The decision logic is simple. SPF and DKIM prove pieces of identity. DMARC decides whether those identities match the domain your recipient actually sees in the From line.

Before you publish anything, inventory your sending sources

Most authentication problems start before DNS. Make a list of every platform that sends mail using your domain or subdomains. That usually includes your ESP, CRM, sales engagement platform, support system, product notifications, finance tools, recruiting tools, and any custom application mail.

For each sender, capture four things: the From domain it uses, the return-path or envelope-from domain, whether it supports custom DKIM signing, and the exact DNS records the vendor requires. If even one source is missing from your inventory, your DMARC rollout can turn into a false positive machine.

A common example is marketing mail signed on news.example.com, lifecycle mail from app.example.com, and support mail from example.com. Those can all be healthy, but only if your DNS and alignment model match the way each platform actually sends.

Step 1, publish SPF

What your SPF record should include

SPF is a TXT record published on the sending domain. It lists the servers allowed to send mail for that domain. A basic record often looks like this:

Example: v=spf1 include:esp.example.net include:_spf.google.com ~all

The end value matters. ~all is a soft fail and is often safer during setup. -all is a hard fail and is better once you are sure your sender inventory is complete.

Rules that matter in production

  • You should publish only one SPF record per domain. Multiple SPF records can cause a permerror.
  • SPF allows only 10 DNS lookups. If you stack too many includes, receivers can stop evaluating the record correctly.
  • SPF checks the envelope-from domain, not the visible From header. That is why SPF can pass but still fail DMARC alignment.

Common SPF mistakes

The most common mistakes are leaving out a sending vendor, publishing duplicate SPF records, and nesting too many includes. Another frequent issue is authenticating only the root domain when the platform is actually sending from a subdomain.

For deliverability teams, the main decision is whether SPF is your primary authentication control or just supporting infrastructure. In practice, it is safer to treat SPF as necessary but not sufficient. Forwarding can break it, and DMARC only needs one aligned identifier to pass.

Step 2, enable DKIM

Why DKIM usually does more heavy lifting

DKIM signs each message with a private key. The matching public key lives in DNS. When the signature verifies, the receiver knows the message was authorized by your domain and was not modified in transit.

Because the DKIM identity can align directly with the visible From domain, it often becomes the most reliable path to DMARC pass, especially when messages are forwarded or routed through intermediaries.

How to publish DKIM

Your sending platform will usually give you a selector and a public key. The DNS record is typically published on a host name like selector1._domainkey.example.com.

Example: selector1._domainkey.example.com with a TXT value beginning v=DKIM1; k=rsa; p=...

Whenever possible, use a 2048-bit key. Many modern providers support it, and it gives you a healthier long-term security posture than older 1024-bit keys.

Operational checks for DKIM

  • Confirm the selector in DNS exactly matches the selector your platform is using.
  • Make sure the domain in the DKIM d= value aligns with the visible From domain for DMARC purposes.
  • Test after every ESP migration, dedicated IP cutover, or domain rebrand.
  • Rotate keys on a documented cadence instead of leaving the same selector in place indefinitely.

Step 3, publish DMARC

Start with monitoring, not enforcement

DMARC is also a TXT record, usually published at _dmarc.example.com. The right starting point for most teams is p=none. That tells receivers to send reports while you evaluate real traffic and alignment.

Example: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

This record says: collect aggregate reports, evaluate all mail, and use strict alignment for both DKIM and SPF.

Understand alignment before you tighten policy

DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. Alignment is where many programs stumble. A message can have a valid DKIM signature from a vendor domain or an SPF pass on a bounce domain and still fail DMARC because the identities do not match your From domain closely enough.

Strict alignment, adkim=s and aspf=s, requires an exact domain match. Relaxed alignment, r, allows a subdomain relationship. If your setup spans root and subdomains across several platforms, relaxed alignment may be the safer first move.

When to move to quarantine or reject

Once your DMARC reports show that legitimate mail is consistently aligned, move deliberately to enforcement. A common path is:

  • p=none while you inventory and fix sources
  • p=quarantine when you want receivers to treat failures suspiciously
  • p=reject when you are confident unauthorized mail should be blocked outright

If you run multiple business units or have a long tail of operational senders, enforcement is less about courage and more about visibility. Do not advance policy until the unknown traffic is understood.

How to verify your setup at Gmail, Outlook, Yahoo, and Apple Mail

Publishing DNS is not the finish line. Send test messages to seed accounts and inspect headers. You want to see SPF pass, DKIM pass, and DMARC pass with alignment on the domains you intended.

At Gmail, authentication and user engagement both matter, so a valid setup is necessary but not enough for inbox placement. At Outlook, infrastructure consistency and complaint patterns can be more volatile. Yahoo follows the same broad logic as Gmail on authentication requirements. Apple Mail, as a client, will still display whatever reaches the inbox, but your authentication posture influences whether providers accepted the mail in the first place.

Focus on these checks:

  • The visible From domain matches your DMARC design.
  • The DKIM d= domain is yours, or an aligned subdomain.
  • The SPF authenticated domain is one you intended to use for alignment.
  • No sending platform reverted to a default vendor domain after a configuration change.

Troubleshooting patterns you will actually see

SPF passes, DMARC fails

This usually means the envelope-from domain is not aligned with the visible From domain. Check your custom return-path or bounce domain settings in the sending platform.

DKIM fails only on one platform

Look for a selector mismatch, a stale DNS value, or signing disabled after a domain change. This happens often after a new business unit is added to the same ESP account.

DMARC reports show unknown sources

Do not assume they are malicious. They may be forgotten internal tools, procurement systems, or legacy CRM workflows. Classify first, then decide whether to authenticate or block.

Everything is authenticated, but inbox placement still slips

Authentication is the floor, not the ceiling. Gmail and Outlook will still factor engagement, complaints, volume shifts, and content patterns into filtering decisions. SPF, DKIM, and DMARC help providers trust the identity, they do not guarantee positive reputation on their own.

A practical rollout sequence for teams

  • Inventory every sender and subdomain.
  • Publish or consolidate SPF records, keeping total DNS lookups under 10.
  • Enable DKIM on every platform using aligned domains and modern key lengths.
  • Publish DMARC with p=none and a monitored reporting mailbox.
  • Review aggregate reports, fix unknown or misaligned sources, then move to enforcement.
  • Retest after every vendor onboarding, migration, or domain change.

The best setup is the one your team can maintain. If you cannot explain which platforms send as which domains and how each one authenticates, your DNS is probably more fragile than it looks.

Related reading: dkim vs spf and spf and dkim deliverability.

Run your first deliverability test

FAQs

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

Yes. In practice, modern senders should have all three. DMARC depends on SPF or DKIM, and Gmail and Yahoo expect authenticated mail plus a published DMARC record for bulk senders.

Should I use a root domain or a subdomain for sending?

For many teams, subdomains are cleaner. They separate marketing, product, and transactional streams, which makes alignment, reputation management, and troubleshooting easier.

What is the safest first DMARC policy?

p=none is usually the right starting point. It lets you see what is sending before you ask receivers to quarantine or reject failures.

How long does SPF, DKIM, and DMARC setup take?

If your sender inventory is clean, basic setup can happen in a day. The longer part is validating every source and moving DMARC from monitoring to enforcement safely.

Can I rely on SPF alone?

No. SPF is useful, but forwarding can break it and it does not guarantee DMARC alignment. DKIM plus DMARC gives you a much more stable foundation.

Stay in the loop

Deliverability insights, product updates, and early access to new features. No spam, unsubscribe anytime.

By subscribing, you agree to our Privacy Policy. Unsubscribe anytime.