How to setup DMARC?

DMARC is the policy layer that makes SPF and DKIM enforceable. Without DMARC, a domain can have perfect SPF and DKIM and still be spoofed, because receivers have no way to know what the domain owner wants done with mail that fails authentication. In 2026 DMARC is no longer optional — Gmail, Yahoo and Microsoft treat a missing DMARC record as a negative signal, and publishing one at minimum p=none is required for any domain sending commercial mail.

What DMARC does

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a DNS TXT record that does three things:

1. Tells receiving mail servers what policy to apply when a message fails both SPF and DKIM alignment (none, quarantine, or reject).
2. Requests aggregate reports showing every IP that sent mail claiming to be your domain.
3. Optionally requests forensic (per-failure) reports with redacted message samples.

A typical DMARC record for a production domain:

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

Tag reference

• v=DMARC1 — version, always required.
• p= — policy: none, quarantine, or reject.
• sp= — policy for subdomains. Defaults to same as p= if omitted.
• rua=mailto: — aggregate report destination. Multiple allowed, comma-separated.
• ruf=mailto: — forensic report destination. Most receivers do not send these anymore due to privacy concerns.
• pct= — percentage of failing mail to apply policy to. Useful for gradual rollout.
• adkim= — DKIM alignment: s (strict, exact match) or r (relaxed, organisational domain match). Default relaxed.
• aspf= — SPF alignment: same values as adkim. Default relaxed.
• fo= — forensic report generation: 0 (all fail), 1 (any fail), d (DKIM fail), s (SPF fail). Default 0.
• ri= — reporting interval in seconds. Default 86400 (daily).

The recommended rollout path

Do not publish p=reject on day one. The rollout is staged over 60-90 days:

Phase 1 (day 1, monitoring only). Publish:

v=DMARC1; p=none; rua=mailto:[email protected]

This enforces nothing but starts aggregate reporting. Leave it for 14 days minimum. You will receive daily XML reports from Google, Microsoft, Yahoo and others.

Phase 2 (week 3, parse and fix). Parse the aggregate reports. Look for:

• Your own services failing alignment (misconfigured SaaS, forgotten ESPs, forwarding).
• Unknown IPs sending as your domain (shadow IT or spoofing).

Fix each legitimate service by configuring SPF or DKIM to align with the organisational domain. This is where most of the work lives.

Phase 3 (week 5-6, gradual quarantine). Move to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

25% of failing mail now goes to spam folders. Monitor complaints. If clean for 7 days, raise to 50%. Then 100%. Then move to p=reject; pct=10.

Phase 4 (week 10-12, enforcement). Full enforcement:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

At this point any mail failing DMARC alignment is rejected by receivers. Your domain is now actively protected against spoofing.

Alignment, explained

Alignment is the concept that trips up most DMARC implementations. DMARC requires that either SPF or DKIM not only pass, but also align with the organisational domain visible in the From: header.

Relaxed alignment — the organisational domain must match. mg.example.com aligns with example.com.

Strict alignment — the full domain must match exactly. mg.example.com does not align with example.com.

Common alignment failure: your ESP uses [email protected] as the envelope sender. SPF passes for sendgrid.net, but the From: header shows [email protected]. No alignment, DMARC fails. Fix by configuring the ESP to use a subdomain of your domain (mg.example.com) as the envelope sender and enabling DKIM signing with d=example.com.

Parsing aggregate reports

DMARC aggregate reports are XML files emailed daily to your rua= address. They look like this (simplified):

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Each <record> is one source IP + result combination. The key fields:

• source_ip — who is sending.
• count — how many messages.
• disposition — what the receiver did (none, quarantine, reject).
• dkim / spf — alignment results.

Tools that parse these cheaply: OpenDMARC, several open-source Python libraries, or commercial dashboards. For low volume (under 1000 messages/day) a simple mailbox and manual review works fine.

Subdomain policy

By default, DMARC's sp= tag equals p=. But you often want different policies. Common pattern:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

For a domain that sends mail only from subdomains but the apex never legitimately sends:

v=DMARC1; p=reject; sp=none; rua=mailto:[email protected]

For every subdomain you know sends mail, publish a per-subdomain DMARC record. This overrides sp=.

Troubleshooting

No aggregate reports arriving. Check the rua= mailbox works and DNS-wise the domain is resolvable. If rua= is at a different domain, that domain needs to publish an authorisation record: example.com._report._dmarc.reportinghost.com TXT "v=DMARC1".

Aggregate reports show high volume of unknown sources. Either shadow IT (someone signed up for a SaaS with your domain) or spoofing (bad actors using your domain). Both require investigation.

DMARC passes in testing but fails in production. Check that production mail uses the same envelope sender and DKIM selector as your test setup. ESPs often differ per-environment.

DMARC record syntax error. Common mistakes: using , between tags instead of ;, spaces inside tag values, multiple p= tags. Run through IntoDNS.ai's DMARC parser.

When to use IntoDNS.ai

IntoDNS.ai parses your DMARC record, checks syntax, validates rua= addresses, confirms the record is at _dmarc.yourdomain (not the apex), and flags common misconfigurations like missing rua= or p=quarantine without pct=. After every DMARC change, scan to confirm the record is live and well-formed before waiting 24 hours for the first aggregate report.

External reporting destinations

If your rua= address is at a third-party domain (common when using a managed DMARC service), the reporting domain must publish an authorisation record. Without it, receivers refuse to send reports to prevent abuse as a reporting spam vector.

The authorisation record lives at the third-party's domain:

yourdomain._report._dmarc.thirdparty.com TXT "v=DMARC1"

If you send reports to two different external domains, each must publish an authorisation record.

DMARC in practice: small, medium, large

Small domain (under 1000/day). Single ESP, few moving parts. Go straight from p=none to p=quarantine in 2-3 weeks, then to p=reject after 30 days of clean reports. Manual report review works.

Medium domain (1000-100000/day). Multiple ESPs, SaaS integrations, marketing and transactional separately. Rollout takes 60-90 days. Need automated DMARC report parsing (OpenDMARC or equivalent). Watch for shadow IT every quarter.

Large domain (over 100000/day). Dozens of senders, subdomains, regional variations. Rollout takes 6-12 months. Typically requires a dedicated DMARC platform for report aggregation. Work through subdomains first, apex last, because apex policy affects everything by default.

DMARC beyond the basics

Once p=reject is stable, three further investments pay off:

• ARC (Authenticated Received Chain) — helps forwarded mail pass DMARC.
• MTA-STS — enforces TLS on inbound mail, protects the transport layer.
• BIMI — requires p=quarantine or p=reject and displays your logo in supporting clients.

These are the natural next steps after DMARC enforcement. Together they make up the 2026 baseline for a well-configured email domain.

DMARC and third-party senders

A surprisingly common cause of DMARC failure is a SaaS platform that sends mail "from" your domain but cannot or will not sign with d=yourdomain. Typical examples: appointment reminders, feedback surveys, NPS tools, low-code automation platforms. Each of these may send a handful of messages per day from no-reply@yourdomain but sign with their own d= tag, which does not align.

Under p=none you see these in aggregate reports as aligned failures. Under p=reject they bounce.

The fix path depends on the vendor:

1. Check if the vendor supports custom DKIM signing with your domain. Most serious ESPs do; many smaller tools do not.
2. If custom signing is supported, configure it and publish the vendor-provided DKIM public key.
3. If not, move that traffic to a subdomain (e.g. alerts.yourdomain) with its own DMARC at p=none or p=quarantine but not p=reject. Accept that this subdomain has weaker protection.
4. If moving is not possible and the vendor must send from the apex, consider whether that vendor is worth keeping.

DMARC failure investigation workflow

When aggregate reports show a failure, a reasonable investigation follows this sequence:

1. Identify the source IP from the report.
2. Reverse DNS the IP to identify the sending organisation.
3. Check if that sender is in your inventory. If yes, debug their configuration. If no, either new shadow IT or active spoofing.
4. For known senders, check their documentation for DKIM setup. Publish the missing key.
5. For unknown senders, investigate internally (someone signed up for a new tool) or externally (report spoofing to the sending organisation's abuse contact).

Following this workflow for every new failure pattern keeps your DMARC reports clean and your authenticated-mail visibility accurate.