# What Is DMARC? Alignment, Policies and the 2026 RFCs URL: https://notificationharbor.com/journal/what-is-dmarc Type: blog Locale: en Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC tells receivers what to do when mail fails alignment. Here is how the record, policies and reports work, and what changed in 2026. What is DMARC? It is a DNS record that tells receiving mail servers what to do when a message claims your domain in the From header but fails authentication, and where to send reports about it. DMARC does not authenticate anything by itself. It checks that SPF or DKIM passed and that the domain they validated matches the domain the reader sees. That match is called alignment, and it is the part most teams get wrong. A message can pass SPF, pass DKIM, and still fail DMARC. ## DMARC is a policy layer on top of SPF and DKIM SPF lists which IPs may send for a domain. DKIM signs the message so a receiver can verify it was not altered and that the signing domain approved it. Neither one looks at the From address a human reads. DMARC closes that gap. It asks one question: does the domain in the visible From header align with the domain that passed SPF or DKIM? If yes, the message passes. If no, the receiver applies your policy. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) The record lives at `_dmarc.yourdomain.com` as a TXT record. A minimal, valid one looks like this: `_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"`Three tags do the real work. `p` is the policy, `rua` is where aggregate reports go, and `adkim` / `aspf` set how strict alignment is. Everything else is optional. ## Alignment is where good setups fail SPF authenticates the envelope sender, the Return-Path domain. DKIM authenticates the domain in the `d=` tag of the signature. DMARC needs at least one of those to match the From domain, either exactly (strict) or at the organizational-domain level (relaxed, the default). Here is the failure we see most often in traces. A team sends through a third-party provider, the provider signs with its own domain (`d=provider-mail.net`) and uses its own bounce domain. SPF passes, DKIM passes, and DMARC fails because neither domain matches `example.com`. The fix is a custom sending domain: a DKIM key published under your domain, and ideally a custom return-path on a subdomain. Every serious provider supports it. Few enable it by default. ## The three policies: none, quarantine, reject The `p` tag has three values, and they are not a ladder you climb on a schedule. - **`p=none`**: the receiver delivers normally and sends you reports. Use it for the first 2 to 4 weeks, while you inventory senders. - **`p=quarantine`**: the receiver routes failures to spam or junk. Use it once reports show all legitimate sources aligned. - **`p=reject`**: the receiver refuses failures at the SMTP stage. Use it once quarantine has run clean for a full sending cycle. `p=none` is monitoring, not protection. A domain sitting at `none` for two years has a compliance checkbox and no spoofing defence. Skip the temptation to leave it there because "nothing broke". `p=reject` is the destination for any domain that only sends mail you control. Domains with heavy mailing-list traffic or legacy forwarders need more care, because forwarding often breaks SPF and can break DKIM if the intermediary edits the body. ## Why the Gmail and Yahoo rules made this urgent Since February 2024, [Google's sender guidelines](https://support.google.com/mail/answer/81126?hl=en) require anyone sending more than 5,000 messages per day to Gmail accounts to publish a DMARC record, with SPF and DKIM in place. The policy can be `none`. Google also asks bulk senders to keep the user-reported spam rate in Postmaster Tools below 0.30%, and recommends staying under 0.10%. [Yahoo's Sender Hub](https://senders.yahooinc.com/best-practices/) states the same core requirement: a valid DMARC policy of at least `p=none`, with the From domain aligned to either the SPF or DKIM domain. Relaxed alignment is acceptable. Note what is and is not in those rules. The requirement is a published record and passing alignment, not enforcement. That is a floor. It is not a finish line. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Aggregate reports are the product, the policy is the switch The `rua` address receives daily XML reports from every receiver that honours DMARC. Each report lists source IPs, message counts, the SPF and DKIM results, and whether alignment held. This is how you find the forgotten sender: the old CRM export, the billing tool a contractor wired up in 2022, the marketing form on a subdomain nobody owns. Raw XML is unreadable at volume. Route `rua` to a mailbox a parser can ingest, or to a hosted DMARC reporting service, and look at the data grouped by source. What you want to see is every legitimate source showing 100% aligned, and everything else clearly unknown. A practical rollout runs in this order: - Publish `p=none` with a `rua` address. - Collect two to four weeks of reports. Build the sender inventory. - Fix each legitimate unaligned source with a custom DKIM domain or return-path. - Move to `p=quarantine`. Watch for support tickets about missing mail. - Move to `p=reject` when quarantine shows no legitimate failures. Ship each step separately. Changing the policy and adding a new sending provider in the same week makes any regression impossible to attribute. ## DMARCbis changes the tags, not your record In 2026 the IETF published RFC 9989, RFC 9990, and RFC 9991, which obsolete RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) is the core DMARC spec. Aggregate reporting and failure reporting moved into their own documents. The practical changes for a record owner are small: - `pct`, `rf`, and `ri` are removed. - `t` (testing mode) replaces `pct` as an all-or-nothing switch: `t=y` reports without enforcing. - `np` sets a policy for non-existent subdomains, which blocks spoofing of addresses like `abc123.example.com`. - `psd` marks public suffix domains, and a DNS tree walk replaces the old Public Suffix List lookup. Existing `v=DMARC1` records stay valid. Nothing breaks if you change nothing today. Provider support for the new tags will roll out unevenly, so a new tag that seems to do nothing usually means the receiver has not implemented it yet. The `np` tag is the one worth adopting early. Setting `np=reject` while `p` is still `none` shuts the fake-subdomain abuse path without committing the rest of your mail to enforcement. ## Subdomains, and why the default inherits A DMARC record on the organizational domain applies to subdomains too, unless you override it with `sp`. That inheritance is useful and also a trap. If marketing sends from `news.example.com` through a separate provider, it inherits the parent policy. Move the parent to `p=reject` before that provider has aligned DKIM and the newsletter goes to the floor. Publish a separate `_dmarc.news.example.com` record when a subdomain has its own sender fleet and its own rollout pace. A cleaner architecture separates streams by subdomain from the start. Transactional mail on one, lifecycle on another, human mail on the root. Each gets its own DKIM keys, its own reputation, and its own DMARC record. ## Read the Authentication-Results header before you guess When a message fails, the receiving server records why. In Gmail, "Show original" exposes the `Authentication-Results` header, and it tells you more than any dashboard. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.provider-mail.net; dkim=pass header.d=provider-mail.net; dmarc=fail (p=NONE) header.from=example.com`Read it left to right. SPF passed for `bounce.provider-mail.net`. DKIM passed for `provider-mail.net`. DMARC failed because the From header says `example.com` and neither passing domain matches it. The `(p=NONE)` note shows the policy the receiver saw. At `none` this message was delivered anyway. At `reject` it would have bounced with a 5.7.x error, and the sender would have found out from a customer. Two checks catch most of these cases. Confirm the `header.d` value in the DKIM result is your domain. Then confirm the `smtp.mailfrom` domain is your domain or a subdomain of it. ## SPF has a lookup limit that DMARC exposes SPF allows ten DNS lookups per evaluation. Every `include:` for a provider spends some of them, and nested includes spend more. Cross ten and SPF returns a permanent error, which counts as a fail. Teams with five or six sending tools hit this without noticing, because SPF failures were invisible before DMARC reporting. Once `rua` reports arrive, the pattern is obvious: one source suddenly failing SPF across all receivers on the day someone added another `include:`. This is one more reason to rely on DKIM alignment as the primary path. DKIM survives most forwarding, has no lookup budget, and is tied to the message rather than the connecting IP. Keep SPF valid, but do not build your DMARC pass on it alone. ## What DMARC will not do DMARC prevents exact-domain spoofing. It does not stop lookalike domains (`examp1e.com`), it does not judge content, and it does not fix a bad sender reputation. A perfectly aligned domain that sends to purchased lists still lands in spam. It also does not replace monitoring. Alignment can break silently: a DNS change removes a DKIM selector, a provider rotates keys, a new tool starts sending without your knowledge. Reports are how you find out before your users do. Treat the DMARC record like any other piece of production config. It belongs in version control, changes go through review, and the `rua` mailbox needs an owner. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Before you publish the record Run through this once. It takes under an hour for a single domain. - List every system that sends mail as your domain: product, billing, support desk, CRM, marketing, calendar invites. - Confirm each one signs DKIM with your domain, not the vendor's. - Set a custom return-path where the provider allows it. - Choose a `rua` destination someone will read. - Start at `p=none`, and put the date you plan to review it on the calendar. - Check spam rate in Google Postmaster Tools weekly during the rollout. ## Where to go from here If you have never looked at your reports, publish `p=none` with a `rua` address today and read what comes back in two weeks. The first report almost always names at least one sender nobody remembered. The next concrete step is deciding which of those you keep. ## FAQ ### Is DMARC required? For bulk senders, effectively yes. Google requires a DMARC record for senders of more than 5,000 messages per day to Gmail, and Yahoo requires a valid policy of at least p=none. Enforcement is not required, but the record and alignment are. ### What does p=none mean in DMARC? It means monitor only. Receivers deliver failing mail normally and send you reports. It satisfies the Gmail and Yahoo minimum but gives no protection against spoofing. ### Can an email pass SPF and DKIM and still fail DMARC? Yes. DMARC requires the domain validated by SPF or DKIM to align with the From header domain. Mail sent through a provider that signs with its own domain passes both checks and still fails alignment. ### How long should I stay on p=none? Typically two to four weeks of aggregate reports, long enough to see every legitimate sender including low-volume ones. Move on once each legitimate source shows as aligned. ### Does DMARC affect deliverability? Indirectly. A published, aligned record is a baseline requirement at Gmail and Yahoo, and failing alignment can push mail to spam or trigger rejection under an enforcing policy. It does not fix poor sender reputation or high complaint rates. ### What changed with DMARCbis and RFC 9989? RFC 9989 obsoletes RFC 7489. It removes pct, rf and ri, adds t, np and psd, and replaces Public Suffix List lookups with a DNS tree walk. Existing v=DMARC1 records remain valid.