DMARC Lookup & Generator

Look up existing DMARC records for any domain or build a new v=DMARC1 TXT record with the interactive generator

Try:

Configure DMARC Record

Policy (p=) Required

none Start here — Monitor only, no action taken

quarantine — Send failing emails to spam folder

reject Strictest — Reject failing emails outright

Subdomain Policy (sp=) Optional — inherits p= if omitted

Aggregate Report URI (rua=) Optional but recommended

Email address(es) to receive daily aggregate XML reports from receiving mail servers.

mailto:

Forensic Report URI (ruf=) Optional

Email address(es) to receive per-message forensic failure reports (may be blocked by some providers).

mailto:

Percentage of messages filtered (pct=)

100%

Start at a lower percentage (e.g. 10%) when rolling out a stricter policy, then increase gradually.

DKIM Alignment (adkim=)

r Relaxed Recommended

s Strict

SPF Alignment (aspf=)

r Relaxed Recommended

s Strict

Failure Reporting Options (fo=)

Report Interval (ri=) seconds — default 86400 (24h)

Generated DMARC Record

Publish this as a TXT record on your domain's DNS. The host/name must be exactly _dmarc:

Frequently Asked Questions

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication policy that builds on SPF and DKIM. It allows domain owners to specify what receiving mail servers should do when emails fail authentication checks — none (monitor), quarantine (spam), or reject — and receive reports on authentication activity. It is published as a DNS TXT record at _dmarc.yourdomain.com.

Start with p=none to monitor without enforcing. Analyze the aggregate reports (rua) for 2-4 weeks to identify all legitimate email sources. Fix any SPF/DKIM misconfigurations. Then move to p=quarantine; pct=10 (quarantine 10% of failing mail) and gradually increase pct. Finally, move to p=reject once you're confident all legitimate mail passes. This phased approach prevents accidentally blocking legitimate email.

Relaxed alignment (r) allows the authenticated domain to be a parent of the From domain. For example, SPF passes if mail.example.com aligns with example.com. This is the default and works for most setups including email forwarding. Strict alignment (s) requires an exact domain match — mail.example.com would NOT align with example.com. Only use strict if you have a specific security requirement.

Aggregate reports are daily XML files sent by receiving mail servers (Gmail, Yahoo, Microsoft, etc.) that summarize authentication results for your domain. Each report shows: the sending IP, volumes of email, SPF and DKIM pass/fail results, and the disposition applied. Analyzing these reports is essential for understanding your email ecosystem and identifying unauthorized senders. Free tools like DMARC Analyzer and Google Postmaster Tools can parse these XML reports into readable dashboards.

DMARC Tag Reference

Tag	Name	Default	Description
`v`	Version	—	Must be `DMARC1`. Required.
`p`	Policy	—	`none`, `quarantine`, or `reject`. Required.
`sp`	Subdomain Policy	Inherits `p`	Policy for subdomains. Overrides `p` for subdomain mail.
`rua`	Aggregate Report URI	None	Where to send daily aggregate XML reports (`mailto:`).
`ruf`	Forensic Report URI	None	Where to send per-message forensic failure reports.
`pct`	Percentage	100	Percentage of failing messages the policy is applied to.
`adkim`	DKIM Alignment	`r`	`r` = relaxed, `s` = strict.
`aspf`	SPF Alignment	`r`	`r` = relaxed, `s` = strict.
`fo`	Failure Options	`0`	When to generate forensic reports: `0`=both fail, `1`=either fails, `d`=DKIM fail, `s`=SPF fail.
`ri`	Report Interval	86400	Seconds between aggregate reports. Most providers ignore this and send daily.

How DMARC Works

When a receiving mail server gets an email claiming to be from your domain, it follows this process:

Check SPF

Verify the sending server's IP address is listed in the domain's SPF record. This confirms the mail was sent from an authorized server.

Check DKIM

Verify the email's cryptographic DKIM signature against the public key in DNS. This confirms the message body wasn't altered in transit.

Apply DMARC Policy

If either SPF or DKIM passes and the authenticated domain aligns with the From header, DMARC passes. Otherwise the domain's p= policy is applied.

Key point: DMARC requires alignment — the domain that passes SPF or DKIM must match the domain in the visible From: header. This is what prevents display-name spoofing.

DMARC Rollout Checklist

Follow this phased approach to reach p=reject safely without disrupting legitimate email.

1

Audit your email senders

List every service that sends email from your domain — ESP, CRM, ticketing, transactional email, billing tools, etc. Each one needs a valid SPF include and/or DKIM signature.
2

Publish SPF and DKIM for all senders

Use SPF Lookup & Generator to verify your SPF record includes all sending IPs. Use DKIM Checker to confirm all selectors resolve correctly.
3

Start with p=none; rua=mailto:you@domain.com

This is monitor-only mode. No email is rejected. Collect aggregate reports for 2–4 weeks to build a complete picture of who is sending email as your domain.
4

Move to p=quarantine; pct=10

Apply quarantine policy to 10% of failing messages. Watch reports for legitimate email caught by the policy. Fix any remaining authentication gaps. Increase pct= weekly (25 → 50 → 75 → 100).
5

Reach p=reject

Once you're confident all legitimate email passes, set p=reject. Receiving servers will outright block unauthenticated mail claiming to be from your domain — the strongest protection against spoofing and phishing.

Common DMARC Mistakes to Avoid

Jumping straight to `p=reject`

Skipping the monitoring phase (p=none) risks blocking legitimate email from services you forgot were sending on your behalf — such as a CRM, HR system, or mailing list.

No `rua=` address

Without an aggregate report address you're flying blind. You won't know which servers are sending email as your domain, making it impossible to safely tighten the policy.

Strict alignment with third-party senders

Using adkim=s or aspf=s breaks many ESPs that send from subdomain envelopes. Keep alignment relaxed (r) unless you have a specific reason to tighten it.

Forgetting subdomains

DMARC applies to the organizational domain and all subdomains unless you set a separate sp= policy. If a subdomain sends mail, ensure it also has proper SPF and DKIM.

Publishing multiple DMARC records

A domain must have exactly one _dmarc TXT record. Publishing two records causes a DMARC permerror and most receivers will treat it as no DMARC record at all.

Ignoring email forwarding

Email forwarding often breaks SPF (the forwarding server's IP is not in your SPF record) and may re-sign DKIM. With p=reject, forwarded email may be lost. Consider this before enforcing.

The Email Authentication Stack

DMARC is the policy layer that ties together SPF and DKIM. All three work together to protect your domain from spoofing and improve deliverability.

Protocol	What it authenticates	DNS Record	Our Tool
SPF	The sending server's IP address is authorized to send for the domain	`TXT` at root domain	SPF Lookup & Generator
DKIM	The message was cryptographically signed by an authorized sender and not altered	`TXT` at `{selector}._domainkey.{domain}`	DKIM Checker
DMARC	SPF/DKIM alignment with the visible `From:` header — sets enforcement policy and reporting	`TXT` at `_dmarc.{domain}`	This tool
BIMI	Displays the domain's brand logo in supporting email clients once SPF, DKIM, and DMARC all pass	`TXT` at `default._bimi.{domain}`	BIMI Lookup & Generator
MX	Where inbound email for the domain should be delivered	`MX` at root domain	MX Lookup