How to Set Up DMARC for a New Domain (Without Breaking Your Email)

DMARC is the last layer of email authentication. Done right, it stops spoofing of your domain. Done wrong, it silently drops your own legitimate email. Here is the order of operations that avoids breaking anything.

What DMARC Does (In One Sentence)

DMARC tells receiving mail servers: a message claiming to come from your domain is only legitimate if it passes SPF or DKIM, AND the passing check's domain aligns with the From header. If neither, apply the policy you have published (none, quarantine, or reject).

That is it. No new sender authentication — just a published policy that tells the world what to do when SPF and DKIM do not agree.

Prerequisites

Do not publish DMARC before these are in place. If you do, legitimate mail will start failing silently.

• SPF record listing every server that sends mail as your domain.
• DKIM signing configured on every sending platform — your MTA, your SMTP relay, Google Workspace, Mailgun, SendGrid, Postmark, whatever.

Step 1: Publish SPF

Add a single TXT record at the root of your domain. List every IP and every third-party service allowed to send as you.

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~all"

Notes:

• Only one SPF record per domain. Multiple records = undefined behavior = fails.
• ~all means softfail (marks suspicious but delivers). Use this while rolling out.
• -all means fail outright. Switch to this only after you are confident everyone legitimate is listed.
• SPF has a 10-DNS-lookup limit. Each include: and a/mx counts. Exceed it and SPF stops working.

Step 2: Enable DKIM Signing

Each sending platform generates a public key and a selector name. You publish the public key at <selector>._domainkey.example.com; the platform signs outgoing mail with the matching private key. Receiving servers verify the signature.

Every platform has a one-click setup:

• Google Workspace → Apps → Gmail → Authenticate email → Generate DKIM record
• Microsoft 365 → Security → Email auth → Enable DKIM per domain
• Mailgun / SendGrid / Postmark → Domain settings → Add DKIM records
• Self-hosted Postfix → OpenDKIM package, generate keys, publish the public key

The critical thing: the d= tag in the DKIM signature must match (or be a subdomain of) the From header domain. Most platforms get this right, but check — a DKIM signature with d=mailgun.org will not align when From is [email protected].

Step 3: Publish DMARC With p=none

Monitor mode. Tells receivers to report on authentication failures but take no action.

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

rua is where aggregate reports go. Use an address you will actually read. Or point it at a DMARC aggregator — Dmarcian, Postmark's DMARC Digests, or Cloudflare's DMARC Analytics, which is free and handles the XML parsing for you.

Step 4: Read the Reports for at Least Two Weeks

Every major mail receiver (Gmail, Yahoo, Microsoft, etc.) will start sending you daily XML reports. You will see every source IP that sent mail as your domain, whether SPF and DKIM passed, and what percentage aligned.

Expect surprises. You will find sending sources you forgot existed — a marketing automation tool, a transactional service a vendor set up years ago, your help desk. Add every legitimate source to SPF (and configure DKIM for it) before moving on.

Step 5: Move to p=quarantine With pct=10

Gradual rollout. Only 10 percent of failing messages get quarantined at first.

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

Watch reports for another week. If DMARC pass rate stays above 98 percent, ramp to pct=50, then pct=100.

Step 6: Move to p=reject

The full policy. Any unaligned message with your domain in the From header gets bounced.

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

Spoofers can no longer pretend to be you to any receiver that honors DMARC — which is now essentially every major provider.

Gotchas Nobody Mentions

Forwarding breaks SPF

When a mailing list or alias forwards your message, the envelope sender changes, which breaks SPF alignment. Most forwarders apply Sender Rewriting Scheme (SRS) and you will see envelopes like [email protected] in DMARC reports. This is normal. DKIM still aligns (if the forwarder does not modify the body), so DMARC still passes via DKIM alone.

Mailing lists break DKIM too

A mailing list server often adds a footer ("This message was sent to [email protected] — unsubscribe..."). That body modification invalidates the DKIM signature. ARC (Authenticated Received Chain) is the fix but not every receiver honors it. If your users are on mailing lists, expect some DMARC fails there.

Subdomain policy

By default, DMARC applies to the apex and all subdomains. Override per-subdomain with sp= (e.g., sp=quarantine) or publish a separate _dmarc.subdomain.example.com record.

Third-party senders need alignment

If you use Mailgun, SendGrid, or similar with their default setup, the envelope sender is usually their domain, not yours — which means SPF will not align. Most services let you "authenticate" with a CNAME that makes their sending subdomain appear under your domain. Do that. DKIM alignment alone can carry DMARC, but having both is safer.

Verify Your Setup

Run a scan against your domain at internetsecure.org and it will check SPF, DKIM selectors, DMARC policy, and flag common misconfigurations in one pass.