DMARC, SPF, and DKIM Setup: 13 Steps [2026]

Email spoofing has survived three decades of patches, filters, and awareness training because the core flaw never got fixed until recently: a mail server could claim to be anyone it wanted in the “From” field, and most receiving systems had no reliable way to check. DMARC, SPF, and DKIM close that gap by giving receiving mail servers a cryptographic and DNS-based way to verify that a message really came from the domain it claims. What changed this year is that the DMARC standard itself got rewritten. On May 20, 2026, the IETF RFC Editor published RFC 9989 and RFC 9990, putting DMARC on the formal Standards Track for the first time and officially obsoleting RFC 7489, the specification nearly every existing DMARC guide online still references.

That update matters for anyone setting up email authentication today. A domain configured against outdated guidance can still technically work, but a setup built on the current RFC 9989 baseline is the one that aligns with what IETF working groups, mailbox providers, and compliance auditors expect going forward. The sections below cover through 13 steps to publish a working SPF record, turn on DKIM signing, roll out a DMARC record from monitoring to full enforcement, and handle the Microsoft 365 and Google Workspace specifics that trip up most first-time deployments. Expect to spend around 70 minutes on the initial setup, plus a monitoring period of two to four weeks before moving to enforcement.

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

Why Email Spoofing Still Gets Through in 2026

The Simple Mail Transfer Protocol, the backbone of email delivery since the early 1980s, never required a sender to prove who they were. Anyone could type any address into the “From” field and most servers would relay the message without complaint. SPF arrived in 2014 under RFC 7208 to list which servers are authorized to send for a domain. DKIM, standardized under RFC 6376 in 2011, added a cryptographic signature so receivers could confirm a message was not altered in transit. Neither protocol on its own stops spoofing completely, because a forged message can still pass SPF (if sent through an authorized but compromised server) or skip DKIM entirely if the receiving system does not enforce it.

DMARC closes that loophole by telling receiving mail servers what to do when a message fails both checks, or passes them without matching the domain in the visible “From” header. Security researchers at Palo Alto Networks’ Unit 42, which tracks phishing and business email compromise campaigns on an ongoing basis, have long pointed to domain impersonation as one of the most persistent techniques in credential theft and wire fraud schemes, partly because so many domains still ship no DMARC policy, or ship one that only monitors without rejecting anything. Unit 42’s published research is a useful reference point for why authentication alone will not stop every attack, but it removes one of the cheapest and most common tricks available to an attacker: typing your exact domain into the From field.

Daily threat roundups aggregated by services such as CyberNetSec.io’s threat intelligence publications continue to log phishing and spoofing campaigns against organizations of every size, which is part of why mailbox providers like Google and Microsoft have steadily tightened bulk sender requirements around SPF, DKIM, and DMARC rather than loosening them.

What DMARC, SPF, and DKIM Each Check

It helps to be precise about what each protocol actually verifies, because the three get conflated constantly and that confusion is where most setup mistakes start.

SPF (Sender Policy Framework) is a DNS TXT record listing every IP address and mail server authorized to send mail on behalf of a domain. The receiving server checks the “envelope sender,” the technical return path address, not the visible From header.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, generated with a private key. The receiving server looks up the matching public key in DNS and confirms the message, or at least the parts that were signed, were not altered in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of both. It requires that SPF or DKIM pass, and that the authenticating domain aligns with the domain shown in the visible From header. It also tells receiving servers what to do with mail that fails that check, and it asks them to send back aggregate reports describing what they saw.

Google’s own documentation states it plainly: “SPF, Sender Policy Framework (SPF) helps to prevent senders from impersonating you, blocking spammers and other attackers from sending email that appears to be from your organization”, and Google recommends going further than SPF alone, advising administrators to “set up both DKIM and SPF,” and then layer DMARC on top so a domain owner can “choose what happens to messages that don’t pass SPF or DKIM.”

Microsoft describes DMARC the same way in its own Defender for Office 365 documentation: “Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a method of email authentication to validate mail sent from your Microsoft 365 organization”. The three protocols are not redundant. SPF and DKIM are independent authentication methods, and DMARC is the policy and reporting layer that ties them together and gives a domain owner actual control over what happens to failing mail.

Protocol	Current standard	Published	What it checks	Status in 2026
SPF	RFC 7208	April 2014	Which mail servers may send for a domain	Active, unchanged
DKIM	RFC 6376	September 2011	Cryptographic signature proving a message was not altered	Active, unchanged
DMARC	RFC 9989 (plus RFC 9990 for reporting)	May 2026	Alignment between SPF/DKIM and the visible From domain, plus policy and reporting	Active, replaces RFC 7489 and RFC 9091
DKIM2	draft-ietf-dkim-dkim2-spec-07 (Internet-Draft)	October 18, 2026	Proposed successor adding post-quantum signing and stronger replay protection	Experimental draft, not deployed in production

Prerequisites and Tools You Need Before You Start

This setup does not require installing software on a server. Everything happens at the DNS layer, through your domain registrar or DNS host, plus the admin console of whatever platform sends your mail. Before you start, gather the following:

Administrative access to your domain’s DNS zone, through your registrar, Cloudflare, Route 53, or whichever DNS host you use.
Administrative access to every platform that sends mail using your domain: your email provider (Microsoft 365, Google Workspace, or another host), plus any marketing platform, CRM, helpdesk tool, or transactional email API. Invoicing systems and password reset senders are the ones people forget.
A command line with dig or nslookup available, or a browser based DNS lookup tool, to verify records after you publish them.
An email address to receive DMARC aggregate reports, ideally a dedicated mailbox rather than someone’s personal inbox, since reports arrive daily and the volume adds up.
Patience for a monitoring period. Google’s guidance and Microsoft’s documentation both frame this as a staged rollout, not an overnight switch, and jumping straight to enforcement before you have read any reports is the single most common way to break legitimate mail.

You do not need a DMARC monitoring vendor to complete this tutorial. You can read raw aggregate reports by hand for a small domain, though a vendor becomes genuinely useful once you are receiving reports from a dozen or more sending sources and need the data visualized.

Step 1: Inventory Every System That Sends Mail From Your Domain

Before touching DNS, write down every system that sends mail using your domain in the From address. This is the step people skip, and it is the reason most DMARC rollouts stall partway through enforcement. Typical sources include your primary mailbox provider, a marketing email platform, a CRM’s outbound sequences, a helpdesk or support ticketing tool, a transactional email API used for password resets and receipts, an accounting or invoicing platform, a payroll provider, and any internal scripts or cron jobs that send alert emails.

For each one, note two things: whether it supports SPF, which most do by giving you an “include” value to add to your SPF record, and whether it supports custom domain DKIM signing, since some platforms only sign with their own domain unless you add a CNAME record they provide. You will need both pieces of information in the next few steps, and if you discover a sending source you cannot authenticate, that is useful information now, before you set a policy that quarantines or rejects its mail.

Step 2: Publish Your SPF Record

A domain should publish exactly one SPF TXT record, starting with the v=spf1 tag. Multiple SPF records on the same domain are a common misconfiguration, and receiving mail servers will either ignore all of them or fail evaluation entirely when they find more than one. If you already have an SPF record, edit it rather than adding a second one.

; Example SPF TXT record for example.com
; Published at the root of the DNS zone, type TXT

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Each include mechanism pulls in the authorized sending servers for one platform. The -all at the end tells receivers to fail any message from a server not explicitly listed. Some guides recommend a softer ~all (soft fail) while you are still testing, which lets unauthorized mail through but flags it, a reasonable transitional setting if you are not fully confident your inventory from Step 1 is complete.

After publishing, verify it resolved correctly:

dig TXT example.com +short

# Expected output (one record only):
"v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Step 3: Stay Under the SPF 10 Lookup Limit

SPF evaluation has a hard limit: no more than 10 DNS lookups per check, counting nested include, a, mx, ptr, exists, and redirect mechanisms. Exceed it and the entire SPF check returns a permanent error, which most receiving systems treat as a fail, even for legitimate mail. This is easy to hit by accident, because a single include:somevendor.com can itself contain several more nested includes that never show up directly in your own record.

Count your lookups before you publish a long SPF record. Several free SPF flattening and lookup count tools exist, but you can also check manually by resolving each include chain with dig and counting nested includes by hand for smaller setups. If you are close to the limit, consolidate services where possible, remove sending platforms you no longer use, or ask a vendor whether they offer a flattened or reduced lookup SPF include specifically for high complexity domains.

Step 4: Enable DKIM Signing on Every Sending Platform

DKIM setup happens in two places: inside the sending platform’s admin console, where you generate or request a key pair and turn on signing, and in your DNS, where you publish the public key, usually as a CNAME pointing to a key the vendor hosts, or as a TXT record containing the key directly. Google’s documentation recommends a 2,048 bit key where the domain provider supports it, and requires a minimum of 1,024 bits for mail delivered to personal Gmail accounts.

# Example DKIM CNAME records, one pair per sending platform
# Replace "selector1" with the exact selector name your provider assigns

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.sendgrid.net.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.sendgrid.net.

# Google Workspace example, TXT record format
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

Repeat this for every platform you listed in Step 1 that supports custom domain DKIM. A platform that only signs with its own domain, not yours, cannot pass DKIM alignment later, which matters once you reach enforcement, so flag those now.

Step 5: Confirm DKIM Alignment With Your Visible From Domain

DKIM can pass while still failing DMARC, and this catches more administrators than almost any other single setup mistake. DMARC does not just require a valid DKIM signature. It requires that the domain in the DKIM signature, the d= tag, match, or be a subdomain of, the domain shown in the visible From header. Microsoft’s own troubleshooting documentation calls this out directly for Exchange Online: a custom sending domain that has not had DKIM explicitly enabled may still get signed automatically, but with the tenant’s default *.onmicrosoft.com domain rather than the custom domain, which prevents alignment with a From: [email protected] address.

Send a test message from each sending platform to a mailbox you control, then check the raw headers for the Authentication-Results line. Look specifically for dkim=pass header.d=example.com, not just dkim=pass with some other domain in the header.d field. If the domain does not match, go back to the sending platform’s settings and confirm custom domain DKIM signing is actually enabled, not just the keys published.

Step 6: Publish Your First DMARC Record in Monitor Mode

With SPF and DKIM in place, publish a DMARC record at _dmarc.example.com, set to p=none. This mode changes nothing about mail delivery. It only asks receivers to send back reports describing what they see, which is exactly what you need before setting any enforcement policy under the current RFC 9989 framework.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; fo=1"

The rua tag sets the mailbox that receives aggregate reports. The pct=100 tag applies the policy to all mail, irrelevant at p=none, but worth setting explicitly so it is already correct when you move to enforcement. The fo=1 tag asks for forensic failure reports if any sending receiver supports them, covered further in Step 13.

Step 7: Collect and Read Your First Aggregate Reports

Reports start arriving within 24 to 48 hours, sent daily by each major mailbox provider that received mail from your domain. They arrive as gzip compressed XML attachments, one per sending provider per day. For a small domain, opening a handful by hand is manageable. For anything larger, a free aggregate report parser, several open source options exist, and most DMARC monitoring vendors offer a free tier that just renders reports, turns the raw XML into a readable table.

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>312</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

That example record shows messages from one IP address, all passing both SPF and DKIM. The ones worth hunting for are records with dkim or spf set to fail, especially from source IPs you recognize as your own legitimate sending platforms. Those failures are exactly what the next step addresses.

Step 8: Track Down and Fix Unauthenticated Senders

Run this monitoring period for at least two weeks, ideally four, before changing your policy. During that time, every failing source IP in your reports falls into one of three categories: a legitimate sender you forgot to add to SPF or DKIM in Steps 1 through 5, a forwarding service that legitimately breaks SPF alignment, covered in the pitfalls section below, or genuine spoofing attempting to use your domain without authorization.

For the first category, go back and add the missing SPF include or DKIM key. For the second, decide whether DKIM alone, which survives most forwarding scenarios SPF does not, is sufficient, or whether you need ARC headers, covered in the advanced tips section. For the third category, do nothing yet, other than confirm the volume and source. That is precisely the traffic a stricter policy is designed to stop.

Step 9: Move to p=quarantine

Once your reports show that every legitimate sending source passes consistently, move your DMARC policy from p=none to p=quarantine, and start with a low percentage rather than applying it to all mail at once.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1"

At pct=25, only a quarter of failing mail is quarantined, typically routed to spam, while the rest is still only monitored. Watch your reports for another one to two weeks, raise the percentage in increments of 25, then 50, then 100, and only proceed if no legitimate sender starts failing. This staged approach is the single best protection against accidentally sending your own invoices or password resets to recipients’ spam folders.

Step 10: Enforce With p=reject

Once quarantine has run at 100 percent without issues for a few weeks, move to full enforcement:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; sp=reject"

At p=reject, receiving servers refuse any mail that fails DMARC outright rather than quarantining it. The sp=reject tag extends the same policy to subdomains, worth including explicitly, since an attacker who cannot spoof your root domain will often try a subdomain instead if it is left unprotected. Keep monitoring reports even after reaching this stage. New sending platforms get added to organizations constantly, and each one needs to go through Steps 1 through 5 before it will survive enforcement.

DMARC policy stage	Tag	Effect on failing mail	Typical duration before advancing
Monitor	p=none	No effect, reports only	2 to 4 weeks
Partial quarantine	p=quarantine; pct=25 to 50	A percentage routed to spam	1 to 2 weeks per increment
Full quarantine	p=quarantine; pct=100	All failing mail routed to spam	2 to 4 weeks
Full enforcement	p=reject; pct=100	All failing mail refused outright	Ongoing, monitored indefinitely

Step 11: Configure SPF, DKIM, and DMARC for Microsoft 365 and Exchange Online

Exchange Online has its own specific wiring. Microsoft’s documented SPF value for Microsoft 365 is include:spf.protection.outlook.com, and its recommended deployment order is SPF first, DKIM second, DMARC last, for a custom domain.

# Microsoft 365 SPF record for a domain that ONLY sends through Microsoft 365
v=spf1 include:spf.protection.outlook.com -all

# Microsoft-provided DKIM CNAME pair (values come from your tenant's Microsoft 365 admin center)
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

Exchange Online signs outbound mail from the tenant’s initial *.onmicrosoft.com domain by default, even before you touch anything. That default signature does not establish DKIM alignment for a custom domain’s From address. You have to explicitly publish both CNAME records in Microsoft’s admin center under mail flow or Defender settings, and turn on DKIM signing for that specific custom domain, or the alignment check from Step 5 will keep failing. Microsoft’s guidance also flags that mail forwarding can break SPF by changing the sending path, and recommends relying on DKIM, plus ARC headers or Enhanced Filtering for Connectors, where internal forwarding is unavoidable.

Step 12: Configure SPF, DKIM, and DMARC for Google Workspace and Gmail

Google Workspace follows the same three part sequence, configured from the Admin console under Apps, then Google Workspace, then Gmail, then Authenticate email. Google’s own sender guidelines state that authenticated messages “help protect recipients from malicious messages, such as spoofing and phishing messages,” and Google requires senders delivering more than 5,000 messages per day to personal Gmail accounts to have SPF, DKIM, and DMARC fully configured, not optional.

# Google Workspace SPF include
v=spf1 include:_spf.google.com -all

# Generate and turn on DKIM inside Admin console > Apps > Google Workspace > Gmail > Authenticate email
# Then publish the TXT record Google generates for you:
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

Generate the DKIM key inside the Admin console first. Google will not display the public key for you to publish until signing is set up on their end, and the key will not actually start signing mail until you flip the “turn on” toggle a second time after the DNS record has propagated. That two step sequence catches a lot of first-time Workspace administrators who publish the record and then wonder why DKIM is still showing as not authenticating.

Step 13: Add Forensic Reporting, BIMI, and Ongoing Monitoring

Aggregate reports, the rua tag, tell you what happened in bulk. Forensic reports, the ruf tag, deliver details on individual failing messages, including headers, though far fewer mailbox providers support sending them due to privacy concerns, so treat ruf as a bonus rather than a dependable data source. Once you are at p=reject, your domain also becomes eligible for BIMI, Brand Indicators for Message Identification, which displays your verified logo next to authenticated mail in supporting inboxes. EasyDMARC and GMO GlobalSign announced a partnership on October 20, 2026 pairing EasyDMARC’s SPF, DKIM, and DMARC management tools with GlobalSign’s Verified Mark and Common Mark Certificates specifically to support BIMI logo display, a sign that logo verification is becoming a more standard add-on to a finished DMARC rollout rather than a niche feature.

From here, monitoring is not a one-time task. New SaaS tools, marketing platforms, and automated systems get connected to company domains constantly, and each one needs to pass through the same inventory, SPF, and DKIM steps before enforcement will let its mail through. Treat your DMARC aggregate reports the way you would treat any other security log: something to check on a schedule, not just during initial setup.

A Complete Working Example: One Company’s Full DNS Record Set

To tie the whole rollout together, here is what a finished, fully enforced setup looks like for a mid-sized company, “Example Corp,” sending mail through Microsoft 365 for general staff mail, SendGrid for transactional email, and a marketing platform for newsletters.

# === SPF (one record, three sending sources) ===
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.marketingplatform.com -all"

# === DKIM (one selector pair per sending source) ===
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.
s1._domainkey.example.com.          CNAME  s1.domainkey.sendgrid.net.
s2._domainkey.example.com.          CNAME  s2.domainkey.sendgrid.net.
mkt._domainkey.example.com.         TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

# === DMARC (fully enforced, after staged rollout) ===
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=reject; fo=1; adkim=r; aspf=r"

Notice the record count: one SPF record covering three vendors through include mechanisms, well under the 10 lookup limit, five DKIM selector records, one or two per sending source since some platforms rotate between two active selectors, and a single DMARC record carrying the full enforcement policy plus reporting addresses. The adkim=r and aspf=r tags set relaxed alignment mode, allowing subdomains to align with the organizational domain, which is the default and the right choice for most organizations unless you have a specific reason to require strict alignment.

Verify the whole set with three lookups once it is live:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CNAME selector1._domainkey.example.com +short

If all three return the values you published, with no duplicate SPF records and a resolving DKIM CNAME chain, the setup is complete and the domain is fully protected under the current RFC 9989 framework.

Common Pitfalls When Setting Up DMARC, SPF, and DKIM

Most failed rollouts trace back to one of the following mistakes, in roughly descending order of how often they show up in support forums and aggregate reports.

Publishing more than one SPF record. A domain gets exactly one. If a previous IT provider or a marketing tool’s setup wizard already added one, edit it instead of adding a second, since multiple SPF TXT records on one domain can cause the entire check to fail or be ignored.
Exceeding the 10 DNS-lookup limit. Nested includes from nested vendors add up fast. A record that looks short can still exceed the limit if two or three of its includes themselves contain several more includes, and the result is a silent permanent error rather than a clear warning.
Jumping straight to p=reject. Skipping the monitoring stage is the fastest way to send your own password resets and invoices straight to the void. The staged rollout in Steps 6 through 10 exists specifically to prevent this.
Assuming Microsoft 365’s default signing covers custom domains. Exchange Online signs with the tenant’s *.onmicrosoft.com domain by default. Without explicitly publishing the custom domain DKIM CNAME records and turning on signing for that domain, DKIM alignment keeps failing, even though DKIM technically “passes” on the wrong domain.
Not accounting for mail forwarding. Internal forwarding rules, mailing list software, and some helpdesk ticketing tools rewrite or relay mail in ways that break SPF alignment even for completely legitimate messages. DKIM tends to survive forwarding better than SPF, one reason DMARC only requires one of the two to pass and align, not both.
Forgetting the subdomain policy tag. Without an explicit sp= tag, some receivers inherit the organizational domain’s policy for subdomains, but leaving it unset or weaker than your root policy gives an attacker an easy workaround: spoof a subdomain instead of the root.
Ignoring aggregate reports once enforcement is live. A policy that worked perfectly at launch can break months later when a new SaaS tool gets connected without going through the SPF and DKIM steps first. Reports catch this early, if anyone is reading them.

Troubleshooting Guide: Fixing the Most Common Failures

Here is how to diagnose and fix the specific failures that show up most often once a domain is past initial setup and into live monitoring.

SPF returns “permerror.” You have exceeded the 10 lookup limit. Count nested includes manually or with a flattening tool, then remove unused vendors or consolidate sending sources.
SPF passes but DMARC still fails. Check alignment, not just the pass or fail result. The domain SPF authenticated, the envelope sender, may not match the visible From domain. This commonly happens with third party senders that use their own return path domain.
DKIM shows “pass” but on the wrong domain. This is the Microsoft 365 default signing issue from Step 11. Check the header.d= value in the Authentication-Results header. If it shows onmicrosoft.com instead of your custom domain, go back and explicitly enable custom domain DKIM.
No aggregate reports are arriving at all. Confirm the rua mailbox actually exists and can receive external mail, since some ticketing systems or shared mailboxes silently reject unrecognized senders. Also confirm your DMARC record resolves correctly with no syntax errors, since a malformed record is sometimes treated as if no DMARC record exists at all.
Legitimate mail started failing after a vendor change. A sending platform may have changed its SPF include values or DKIM selectors without much notice. Check the vendor’s current setup documentation rather than assuming your old configuration still matches their current infrastructure.
Internally forwarded mail fails DMARC for recipients. This is expected behavior, not a misconfiguration, when forwarding breaks SPF alignment and the forwarder does not sign with DKIM or add ARC headers. Ask whether your forwarding or mailing list tool supports ARC, covered in the advanced tips below.
A subdomain is sending unauthenticated mail you did not expect. Check whether a marketing or testing tool provisioned a subdomain, such as mail.example.com or send.example.com, without you publishing SPF, DKIM, or inheriting your DMARC policy. The sp= tag controls this, but only once you have identified every subdomain actually in use.
BIMI logo is not displaying despite enforcement. BIMI requires p=reject, or in some implementations p=quarantine at a high percentage, plus a correctly formatted SVG logo file and, for several major inbox providers, a Verified Mark Certificate. Confirm all three conditions before assuming the DMARC record itself is the problem.
DMARC record published but still showing as “not detected” by a checker tool. DNS propagation can take anywhere from a few minutes to 48 hours depending on your DNS host’s TTL settings and the checker’s own cache. Wait and re-check before assuming the record syntax is wrong.

Advanced Tips: BIMI, ARC, and What DKIM2 Changes Next

Once your core DMARC, SPF, and DKIM setup is stable at enforcement, a few additional pieces are worth knowing about, even though none of them are required for a working deployment.

ARC (Authenticated Received Chain) helps preserve authentication results through legitimate forwarding, such as mailing lists or internal relay systems that modify a message before passing it along. A trusted intermediary adds ARC headers that let the final receiving server see the original SPF and DKIM results, even though the message’s own SPF check would otherwise fail after forwarding. Microsoft’s guidance specifically points to ARC, or its own Enhanced Filtering for Connectors feature, as mitigations for internal forwarding scenarios.

BIMI, discussed in Step 13, is worth planning for early if brand visibility in the inbox matters to your organization, since it depends on your domain already sitting at a strong DMARC enforcement policy before a logo will display anywhere.

DKIM2 is the one piece of this picture genuinely in motion. It remains an IETF Internet-Draft, currently at revision draft-ietf-dkim-dkim2-spec-07, published October 18, 2026, with an intended status of Standards Track, meaning it has not been finalized or deployed by any major mail provider. The draft’s most notable addition is a composite post-quantum signing algorithm, MLDSA44-Ed25519-SHA512, alongside stronger replay protection and a requirement that the From header itself be authenticated, something neither DKIM nor SPF currently guarantees on its own. A related Internet-Draft, reportedly published separately in September 2026 and updated in October 2026, proposes extending DMARC itself to recognize DKIM2 as a valid authentication mechanism for forwarding scenarios. Continue deploying ordinary DKIM alongside SPF and DMARC for now, and treat DKIM2 as something to watch rather than something to deploy.

If you want a second set of eyes on your rollout data rather than reading raw XML by hand, several hosted DMARC monitoring services price their entry tiers for small domains in a comparable range, summarized below based on their published 2026 pricing pages.

Vendor	Entry pricing (as published, 2026)	Notable feature
PowerDMARC	From around $8/month, free tier available	SSO/SAML across plans, ISO 27001:2022 certified
DMARCTrust	From £13.90/month	Choice of EU or US data region at signup
dmarcian	From $24/month	Founded by one of the original DMARC spec authors
EasyDMARC	From €35.99/month (billed annually)	EU-headquartered, partnered with GlobalSign for BIMI certificates
Valimail	Free Monitor tier; paid enforcement from $5,000/year	FedRAMP deployment option for federal environments

None of these are required. Reading reports by hand, or with a free open source parser, is entirely sufficient for the scale of most small and mid-sized domains.

Frequently Asked Questions

Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM only authenticate mail. Without DMARC, there is no policy telling receiving servers what to do about mail that fails, and no reporting mechanism to show you what is happening with your domain. A domain with SPF and DKIM but no DMARC record is still fully spoofable.

What changed with RFC 9989?
Published on May 19, 2026, RFC 9989 replaced RFC 7489 as the formal DMARC specification and put the protocol on the IETF Standards Track for the first time, rather than leaving it as an informational document. RFC 9990, published the same day, separately formalizes DMARC’s aggregate reporting format. The practical setup steps have not changed, but any documentation still citing only RFC 7489 is referencing a specification the current standard has obsoleted.

How long should I stay in monitor mode before enforcing a policy?
Two to four weeks at minimum, long enough to capture reports from every regular sending pattern, including weekly or monthly automated mail, such as payroll or billing cycles, that might not send during a shorter window.

Can I set up DMARC without a dedicated monitoring tool?
Yes. Aggregate reports arrive as plain XML attachments you can open and read directly, or parse with free open source tools. A paid vendor becomes more useful once you are managing many domains or receiving reports from a large number of sending sources, but it is not required to complete a working setup.

Why does my Microsoft 365 domain fail DKIM alignment even though DKIM shows as passing?
Exchange Online signs mail with the tenant’s default *.onmicrosoft.com domain unless you explicitly publish the two Microsoft-provided DKIM CNAME records for your custom domain and turn on signing for it. Until you do, DKIM technically passes, just on the wrong domain, which fails DMARC’s alignment check.

Does forwarding mail break DMARC?
It can break SPF alignment specifically, because forwarding changes the effective sending path. DKIM tends to survive forwarding, since it signs message content rather than the sending path, one reason DMARC only requires either SPF or DKIM to pass and align, not both at once.

Is DKIM2 something I should deploy now?
No. As of October 2026, DKIM2 remains an Internet-Draft with Experimental and Standards Track intended status, not a finalized or deployed standard. No major mail provider has announced production support. Continue using standard DKIM alongside SPF and DMARC, and revisit DKIM2 once it reaches a finalized RFC and provider adoption.

What is the fastest way to break my own email by mistake?
Setting p=reject immediately, before confirming every legitimate sending source passes SPF or DKIM with correct alignment. The staged rollout through monitor, partial quarantine, full quarantine, and only then full enforcement exists specifically to catch misconfigurations before they start silently rejecting real mail.

Set Up DMARC, SPF, and DKIM: 13 Steps, 70 Min [2026]