DMARC Questions,
Answered

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that tells receiving mail servers what to do when SPF or DKIM checks fail. It prevents attackers from sending email that appears to come from your domain, protecting your brand and recipients from phishing and spoofing. DMARC is defined in RFC 7489.

Yes. If your domain sends email - or even if it does not - you need DMARC. Without it, anyone can send email impersonating your domain. Google and Yahoo now require at least p=none for domains sending 5,000+ messages per day. PCI DSS v4.0 requires DMARC for customer-facing domains. Non-sending domains should publish p=reject to prevent impersonation.

Start by ensuring SPF and DKIM are configured for your domain. Then publish a DNS TXT record at _dmarc.yourdomain.com with p=none and a rua= reporting address. Monitor aggregate reports for at least 90 days, fix authentication for all legitimate senders, then progressively move to p=quarantine and finally p=reject. Use our DMARC Checker to validate your record.

Publishing a DMARC record at p=none takes minutes. Reaching full enforcement at p=reject typically takes 9 to 18 months. Each phase (none, quarantine, reject) requires a minimum of 90 days of monitoring to identify all legitimate sending sources and fix their authentication. Organizations with fewer third-party senders may move faster.

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. A typical record looks like: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r. The v= and p= tags are required; all others are optional but recommended. See our What is DMARC page for a full breakdown of every tag.

SPF verifies that the sending server is authorized by the domain's DNS record - it checks the envelope sender (Return-Path). DKIM attaches a cryptographic signature to prove the message was not altered in transit. DMARC ties them together: it requires that either SPF or DKIM passes AND aligns with the visible From header domain, then tells receivers what to do when authentication fails. Use our SPF Checker and DKIM Lookup to test your records.

No. A domain must have exactly one DMARC TXT record at _dmarc.domain.com. Multiple DMARC records cause a PermError and receivers will ignore all of them. If you need to send reports to multiple addresses, list them comma-separated in the rua= tag: rua=mailto:dmarc@example.com,mailto:reports@example.com.

DMARC alignment means the domain in the visible From header must match the domain that passed SPF or DKIM. Relaxed alignment (default) allows subdomain matching - mail.example.com aligns with example.com. Strict alignment requires an exact domain match. Alignment prevents attackers from passing SPF with their own domain while spoofing yours in the From header.

The p=none policy instructs receiving servers to take no enforcement action on messages that fail DMARC. Messages are delivered normally regardless of authentication results. The purpose is monitoring: receivers still send aggregate reports, giving the domain owner visibility into all sending sources. Always start with p=none before moving to enforcement.

The p=quarantine policy instructs receiving servers to route failing messages to the spam or junk folder. The message still exists - recipients can find it - but it is flagged as suspicious. This is the intermediate enforcement step between p=none (monitoring) and p=reject (full block). See our DMARC Policy guide for the full progression.

The p=reject policy instructs receiving servers to reject failing messages at the SMTP level. The recipient never sees the message and the sending server receives a bounce. This is the strongest DMARC protection and the ultimate goal for every domain. Reaching p=reject requires thorough monitoring through the p=none and p=quarantine phases first.

The pct= tag controls what percentage of failing messages receive the enforcement action. At pct=25, only 25% of failing messages are quarantined or rejected - the rest are treated as p=none. This allows gradual rollout of enforcement. Start at pct=10, increase to 25, 50, then 100 over several weeks. If pct= is omitted, it defaults to 100.

An aggregate report (RUA) is an XML file sent daily by receiving mail servers summarizing authentication results for all messages claiming to be from your domain. It shows which IP addresses sent email, whether SPF and DKIM passed, and what policy was applied. Aggregate reports are the foundation of DMARC monitoring - they give you the data needed to make enforcement decisions. DMARC Report converts these XML files into visual dashboards.

A forensic report (RUF) provides per-message failure details - the specific email that failed authentication, the sender IP, the From/Return-Path mismatch, and which mechanism failed. Forensic reports are useful for investigating active spoofing attempts but are less commonly supported by receivers than aggregate reports. Some receivers do not send RUF reports at all due to privacy concerns.

Raw DMARC aggregate reports are XML files that are difficult to read manually. Use a DMARC report analyzer like DMARC Report to convert XML into visual dashboards showing sender authentication status, alignment results, and policy actions. The tool automatically classifies senders by vendor (Google Workspace, Microsoft 365, SendGrid, etc.) and highlights failures that need attention.

Common reasons: your DMARC record does not include a rua= tag, the rua= email address has a typo, or not enough email volume has been sent to trigger reports (receivers typically batch reports daily). If rua= points to a different domain than the one being authenticated, you need an external verification DNS record. Allow 24-72 hours after publishing your DMARC record for reports to start arriving. Use our DMARC Checker to validate your record syntax.

Most receivers send aggregate reports once every 24 hours, typically at midnight UTC. Some large receivers like Google and Microsoft may send multiple reports per day. The volume of reports you receive depends on how many different receivers process email from your domain. Popular domains may receive hundreds of reports daily from dozens of receivers.

The journey from p=none to p=reject typically takes 9 to 18 months. Each phase requires a minimum of 90 days: p=none for monitoring and sender identification, p=quarantine for intermediate enforcement, and p=reject for full protection. Organizations with fewer third-party senders and simpler email infrastructure may move faster, but rushing enforcement causes legitimate email to be blocked.

If a legitimate sender fails DMARC at p=quarantine, their email goes to spam. At p=reject, it is blocked entirely. To fix this: check aggregate reports to identify the failing sender, configure their SPF include or DKIM signing, and verify alignment passes. Using the pct= tag to gradually roll out enforcement helps catch these issues before they affect all email.

Quarantine provides meaningful protection - spoofed messages leave the inbox. However, p=reject is the recommended goal because it prevents delivery entirely. Some compliance frameworks (PCI DSS v4.0, CISA BOD 18-01 for federal agencies) specifically require p=reject. Additionally, p=reject is required to qualify for BIMI, which displays your brand logo in supporting email clients.

Yes. Traditional email forwarding can break SPF alignment because the forwarding server's IP is not in the original domain's SPF record. DKIM typically survives forwarding because the signature is attached to the message itself. This is why DKIM alignment is especially important for domains whose recipients forward email. ARC (Authenticated Received Chain) is a newer protocol designed to address this, but adoption is still growing.

DMARC is required by an increasing number of standards and organizations. Google and Yahoo require at least p=none for bulk senders (5,000+ messages/day). PCI DSS v4.0 requires DMARC for domains used in customer communications (effective March 2025). CISA BOD 18-01 mandates p=reject for US federal agencies. Many cyber insurance policies and procurement processes now require DMARC enforcement.

Since February 2024, Google and Yahoo require all bulk senders (5,000+ messages/day to Gmail/Yahoo users) to have a DMARC policy of at least p=none with a valid rua= address. Additionally, senders must have properly configured SPF and DKIM, include one-click unsubscribe headers in marketing email, and maintain a spam complaint rate below 0.3%. Non-compliant senders experience delivery throttling and rejections.

Yes. PCI DSS v4.0 (effective March 2025) requires organizations that process cardholder data to implement DMARC on domains used in customer-facing communications. Specifically, Requirement 5.4.1 states that anti-phishing mechanisms must include domain-based authentication (DMARC, SPF, DKIM). Most PCI assessors expect p=reject or p=quarantine for compliance.

Binding Operational Directive 18-01, issued by the Cybersecurity and Infrastructure Security Agency (CISA), requires all US federal executive branch agencies to implement DMARC at p=reject. This directive has significantly increased DMARC adoption in the government sector and is often cited as a best practice benchmark by other organizations and industries.

DMARC supports HIPAA compliance by preventing email spoofing of healthcare domain names, reducing the risk of phishing attacks that could lead to Protected Health Information (PHI) exposure. While HIPAA does not explicitly name DMARC, the Security Rule requires safeguards to protect electronic PHI, and email authentication is considered a reasonable and appropriate measure. Note that forensic reports (RUF) may contain message content, so healthcare organizations should use aggregate reports (RUA) only or ensure forensic reports are handled in compliance with HIPAA.