DMARC Setup: SPF, DKIM and Policy Step by Step

DMARC tells receiving mail servers how to handle messages that claim to come from your domain but fail authentication, and it sends you reports showing who is sending mail in your name. It depends on SPF and DKIM being set up correctly first. Many organisations publish a DMARC record once and never move beyond monitoring, or jump straight to a strict policy and block their own invoices. A careful DMARC setup avoids both: inventory every sender, fix SPF and DKIM, publish a monitoring policy, read the reports and tighten the policy step by step. This guide walks through each stage with example DNS records.

How SPF, DKIM and DMARC fit together

The three standards each play a part:

• SPF, defined in RFC 7208, lets a domain list the servers authorised to send mail for it (RFC 7208)
• DKIM, defined in RFC 6376, adds a cryptographic signature to messages; receivers retrieve the public key from DNS using a selector (RFC 6376)
• DMARC, described in RFC 7489, builds on both by checking that a passing SPF or DKIM result aligns with the domain in the visible From address, and by publishing a policy and reporting addresses (RFC 7489)

Note that RFC 7489 is an Informational document rather than a Standards Track one, although DMARC is widely deployed and now expected by major mailbox providers.

Step 1: inventory every sender

Before changing DNS, list every system that sends email using your domain:

• Your main email platform for staff mail
• Marketing and newsletter tools
• CRM and sales engagement tools
• Billing, invoicing and support systems
• Website forms and application notifications
• Any third parties sending on your behalf

Missing a sender is the most common cause of legitimate mail failing after DMARC is enforced.

Step 2: fix SPF

Publish a single SPF record listing your authorised senders. Two rules from RFC 7208 cause frequent problems:

• A domain must not have multiple SPF records; combine them into one
• Mechanisms that cause DNS lookups, such as include, a, mx, ptr and exists, plus the redirect modifier, are limited to 10 during evaluation, and exceeding the limit produces a permanent error

If you are close to the lookup limit, remove unused includes, move some senders to a subdomain or ask providers whether they support sending with their own domain aligned through DKIM instead.

Step 3: set up DKIM for every sender

Enable DKIM signing in each sending platform, using your domain rather than the provider's default. Each platform will give you a selector and a public key to publish in DNS. Use separate selectors per platform, so keys can be rotated or revoked independently.

Step 4: publish a monitoring DMARC policy

Start with a policy of none and an aggregate reporting address. RFC 7489 defines the policies none, quarantine and reject, and the rua tag for aggregate reports. The DMARC record is published as a TXT record at _dmarc under your domain.

Worked example: DMARC setup records

The records below show a simplified, untested example for the domain example.com, with one email platform and one marketing tool. Replace every value with those from your own providers.

; Simplified, untested example records for example.com

; SPF: one record listing all authorised senders
example.com.              TXT  "v=spf1 include:_spf.mailprovider.example include:send.marketingtool.example -all"

; DKIM: one selector per sending platform (public keys shortened)
mail1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"
mkt1._domainkey.example.com.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...QIDAQAB"

; DMARC: start in monitoring mode with aggregate reports
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The include values and keys here are placeholders. Your providers' documentation will give the exact values to use.

Step 5: read the aggregate reports

Aggregate reports are XML files sent by receivers, summarising messages they saw from your domain, the sending IPs and whether SPF, DKIM and alignment passed. They are hard to read raw, so most teams use a report processing tool. Look for:

• Legitimate senders failing SPF or DKIM alignment
• Unknown senders, which may be forgotten tools or spoofing
• The share of your mail passing DMARC overall

Fix legitimate senders until nearly all your genuine mail passes, and investigate unknown sources before deciding they are spoofing.

Step 6: tighten the policy gradually

Once reports show your legitimate mail passing consistently, move towards enforcement. The pct tag in RFC 7489 lets you apply the policy to a percentage of failing mail, which allows a gradual rollout.

The table below shows a hypothetical rollout plan. Timings depend on your mail volume and how quickly reports confirm results.

StagePolicy record changeMinimum periodMove on whenMonitorp=noneSeveral weeksAll known senders pass with alignmentPartial quarantinep=quarantine; pct=252 weeksNo legitimate mail affectedFull quarantinep=quarantine2 to 4 weeksReports remain cleanPartial rejectp=reject; pct=252 weeksNo legitimate mail affectedFull rejectp=rejectOngoingReview reports regularly

At any stage, if legitimate mail starts failing, step back, fix the sender and continue.

Common DMARC setup mistakes

A few mistakes cause most problems:

• Publishing a second SPF record instead of editing the existing one
• Enabling DKIM in a tool but forgetting to publish its DNS record
• Using a provider's default sending domain, so DKIM passes but does not align with your From domain
• Sending reports to a personal mailbox that nobody reads
• Moving to reject before every legitimate sender has been confirmed
• Forgetting a rarely used system, such as an annual renewal reminder, which fails months later

Keep a simple register of senders, their SPF and DKIM status and an owner for each, and update it whenever tools change.

Protect subdomains and unused domains

Attackers may spoof subdomains or domains you own but do not use for email. DMARC supports a subdomain policy tag, and domains that never send mail can publish an SPF record allowing no senders and a strict DMARC policy.

Consider BIMI after enforcement

Brand Indicators for Message Identification, or BIMI, can display your logo in supporting mail clients. According to the BIMI Group, it requires SPF or DKIM aligned with the visible From domain and DMARC at quarantine or reject, and many providers also require a valid certificate, such as a VMC or CMC, proving rights to the logo (BIMI Group FAQ). Treat it as an optional extra once enforcement is in place.

Keep authentication maintained

Authentication drifts as tools change. Review DMARC reports regularly, update SPF when adding or removing providers, rotate DKIM keys periodically and check the setup whenever a new sending tool is introduced. Our guide to bulk sender requirements explains what Gmail and Yahoo expect, and our guide to email domain warming covers building reputation on new sending domains.

Frequently Asked Questions

What is the first step in DMARC setup?

Inventory every system that sends mail using your domain, then make sure each passes SPF or DKIM with alignment before publishing a DMARC policy.

Should I start DMARC with p=reject?

No. Start with p=none and aggregate reports, fix legitimate senders, then move gradually to quarantine and reject using the pct tag.

Why does my SPF record return a permanent error?

Common causes are having more than one SPF record or exceeding the limit of 10 DNS-querying mechanisms and modifiers during evaluation.

Do I need DKIM if I have SPF?

Yes, ideally. DKIM survives many forwarding scenarios that break SPF, and bulk senders to Gmail and Yahoo are required to use both.

Protect your domain from spoofing

We inventory senders, fix SPF and DKIM, read DMARC reports and move your domain safely to enforcement. See our cold outreach and deliverability service, or talk to us about DMARC setup.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.