RFC 7489 • Anti-Spoofing Architecture • Real-Time DoH

DMARC Record Generator & Policy Tester

Construct production-hardened v=DMARC1 DNS records, configure rejection policies (p=reject), and audit live published domain records directly from your browser.

Loading DMARC Builder...
Sponsored Diagnostic PartnerCLS = 0 Guaranteed
Ad Space (responsive) • Slot: dmarc-generator-banner-ad

Reserved banner container configured with strict Core Web Vitals CLS = 0 layout preservation.

What is DMARC and Why Does It Anchor Email Security?

DMARC (Domain-based Message Authentication, Reporting, and Conformance), standardized in RFC 7489, is the crucial third pillar of email deliverability alongside SPF and DKIM. While SPF verifies sending IP addresses and DKIM cryptographically signs message contents, neither protocol prevents an attacker from displaying a forged domain in the visibleFrom: header seen by everyday users.

DMARC solves this vulnerability through Identifier Alignment: it requires that the domain in the visibleFrom: header matches the authenticated domain validated by either SPF (envelope return-path) or DKIM (signature domain d=). Furthermore, DMARC empowers the domain owner to tell receiving servers what to do with messages that fail alignment: monitor them, quarantine them to spam, or reject them outright.

The Three DMARC Policies: Safe Progression Roadmap

Enforcing DMARC requires a structured rollout to ensure legitimate business systems (e.g., Salesforce, Zendesk, Mailchimp) are fully authenticated before turning on strict blocking:

Phase 1: Monitoring (p=none)

Deliverability is unaffected. Recipient servers send daily aggregate XML telemetry to your rua= address. Allows you to discover all SaaS tools and marketing vendors sending on your behalf.

Phase 2: Quarantine (p=quarantine)

Unauthenticated or spoofed messages are diverted to the recipient's Spam/Junk folder. You can test this safely using the pct=25 tag to quarantine only 25% of failing traffic initially.

Phase 3: Strict Rejection (p=reject)

The gold standard of email security. Senders attempting to spoof your domain are rejected at the SMTP connection layer. Protects your brand from executive impersonation and CEO fraud phishing.

Relaxed vs. Strict Alignment (aspf & adkim)

DMARC offers two alignment modes for both SPF (aspf=) and DKIM (adkim=):

  • Relaxed Alignment (Default, aspf=r, adkim=r): The authenticated domain and the header domain must share the same Organizational Domain (e.g. mail.example.com aligns with example.com). Almost all enterprise organizations operate in relaxed mode to accommodate third-party subdomains.
  • Strict Alignment (aspf=s, adkim=s): The domain in the header must exactly match the domain verified by SPF or DKIM with identical subdomains. Any mismatch between subdomains triggers a DMARC failure.

Frequently Asked Questions (FAQ)

Where must a DMARC record be published in DNS?

DMARC records must strictly be published as a TXT record at the specific subdomain_dmarc.yourdomain.com. Placing the record at the root domain or omitting the leading underscore will cause resolvers to ignore the policy entirely.

Can DMARC reports be sent to a domain other than the sender's?

Yes, but the receiving domain must authorize it via External Destination Verification (RFC 7489 Section 7.1). The destination domain must publish a TXT record at senderdomain.com._report._dmarc.recipientdomain.com with value v=DMARC1 to prevent third parties from spamming arbitrary inboxes with XML reports.

Does DMARC require both SPF and DKIM to pass?

No! DMARC only requires that at least one mechanism passes and is aligned. If DKIM passes with alignment, the message passes DMARC even if SPF fails (for instance, when an email is forwarded through an intermediary mailing list).