Email Authentication - DMARC

Starting February 2024, Gmail and Yahoo require DKIM and DMARC authentication for all senders. We strongly recommend setting up both.

For full details, see our article on Google and Yahoo authentication changes in 2024.

DMARC (Domain-based Message Authentication Reporting and Conformance) verifies emails by combining SPF and DKIM. It lets domain owners define what happens to unauthorized email — monitor it, quarantine it, or reject it outright.

This article covers what DMARC is, how to read and configure a DMARC record, how the authentication flow works, and how to resolve DMARC failures when sending through a shared domain.

What is DMARC?

DMARC — Domain-based Message Authentication Reporting and Conformance — is a free technical standard that verifies emails by combining SPF and DKIM. Introduced in 2012, it helps prevent email fraud like phishing by letting domain owners specify how unauthorized use of their domain should be handled via a policy tag ( p= ).

There are three policy levels:

Monitors your email traffic. No action is taken on failing messages — useful for initial visibility.

Unauthorized emails are directed to the recipient's spam or junk folder instead of the inbox.

The strictest and recommended final policy. Unauthorized emails are not delivered at all.

What is a DMARC Record?

A DMARC record lives in a TXT-type DNS entry named _dmarc. It is composed of tags assigned with values, separated by semicolons. Here is the simplest valid record:

v=DMARC1; p=none;

The table below explains all available tags and their default values:

Tag | Name | Default | Description

v | DMARC Version | DMARC1 | Must always be "DMARC1". If missing or incorrect, the entire record is ignored.

p | Policy | none | Action for emails failing DMARC checks: none (monitor), quarantine (spam), reject (block).

adkim | DKIM Alignment | r | r (Relaxed): DKIM domains sharing a common Organizational Domain pass. s (Strict): Requires exact domain match.

aspf | SPF Alignment | r | Same as adkim but for SPF. r (Relaxed) or s (Strict) matching of the SPF domain against the From domain.

sp | Sub-domain Policy | p= value | Explicit policy for sub-domains under this DMARC record. Inherits the parent p= value if not set.

fo | Forensic Reporting Options | 0 | 0: Report if all mechanisms fail. 1: Report if any fail. d: Report on DKIM failure. s: Report on SPF failure.

ruf | Forensic Report URI | none | Where to send forensic (failure) reports. Format: mailto:address@example.org

rua | Aggregate Report URI | none | Where to send aggregate XML feedback reports. Format: mailto:address@example.org

rf | Reporting Format | afrf | Format for individual forensic reports.

pct | Percentage | 100 | Percentage of failing messages the policy applies to. Only valid with quarantine or reject.

ri | Reporting Interval | 86400 | Frequency (in seconds) for receiving aggregate XML reports. Default is 86400 (24 hours).

Not sure how to structure your DMARC record? Use a free DMARC generator tool to build one correctly.

How Does DMARC Work?

DMARC works across three phases: Authentication, Reporting, and Conformance (policy enforcement). Each configuration serves to authenticate emails and define how failures are handled.

• Receiving servers verify SPF or DKIM authentication methods.
• Validates whether the SPF domain (Return-Path) or DKIM domain (d=) aligns with the "From" domain in the email header.
• Extracts and enforces the DMARC policy from the DNS record of the "From" domain.

SPF passes and aligns with the "From" domain → DMARC passes:

v=DMARC1; p=none; aspf=r;

DKIM passes and aligns with the "From" domain → DMARC passes:

v=DMARC1; p=none; adkim=s;

Both SPF and DKIM fail → DMARC fails:

v=DMARC1; p=reject;

• Allows subdomains in SPF/DKIM checks, comparing them to the "From" domain. A subdomain sharing the same Organizational Domain passes.
• Requires an exact match of the SPF/DKIM domain with the "From" domain. No subdomain exceptions.
• Periodic XML reports with pass/fail results, sent to addresses specified with the rua tag.
• Detailed failure reports sent to the ruf address. Many providers limit these due to privacy concerns.
• Controls how frequently aggregate XML reports are sent. Default is 86400 seconds (24 hours).

Aggregate reports every 24 hours:

v=DMARC1; p=none; rua=mailto:postmaster@mydomain.com; ri=86400;

Forensic reports every 7 days:

v=DMARC1; p=none; ruf=mailto:postmaster@mydomain.com; ri=604800;

• Defines how receiving servers handle emails that fail DMARC checks — none, quarantine, or reject.
• Specifies what percentage of failing messages the policy is applied to. Useful for gradual rollout.

Start with quarantine at 50% for testing:

v=DMARC1; p=quarantine; pct=50;

Move to full reject enforcement:

v=DMARC1; p=reject;

Resolving DMARC Failures on Shared Domains

DMARC is not required to send emails from shared domains on the Adaptive AI Phone email system.

When you switch to the Adaptive AI Phone email system, or have not configured your own Adaptive AI Email or SMTP, all emails are sent through a shared domain. If your "From" address domain has a strict DMARC policy ( p=reject or p=quarantine ), you may see the following error:

"The domain in your from address has a p=reject DMARC policy. Without a dedicated sending domain configured, most inbox providers will reject your messages, resulting in elevated bounces. To avoid elevated bounces, use company emails."

Your actual DMARC record: v=DMARC1; p=reject

Log in to your DNS provider and update your _dmarc TXT record so the policy reads p=none. This ensures messages are delivered even when DMARC fails, while you work toward configuring a dedicated sending domain.

Relaxing to p=none reduces your domain's protection against spoofing. Treat this as a temporary measure and set up a dedicated sending domain as soon as possible to restore full DMARC enforcement.

Frequently Asked Questions