DMARC Analyzer

TL;DR

• A DMARC record is a DNS TXT record at _dmarc.<domain> that tells receiving mail servers what to do with messages failing SPF and DKIM alignment, and where to send reports. Defined in RFC 7489, updated by RFC 9091 (the np tag) and the in-progress draft-ietf-dmarc-dmarcbis.
• The record is a semicolon-separated list of tag=value pairs. Twelve tags are defined: v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, and ri.
• Only v=DMARC1 and a p= value are required. Every other tag has an RFC-defined default. v= MUST be the first tag — anywhere else the record is malformed and ignored.
• p governs the organizational domain; sp overrides it for existing subdomains without their own DMARC record; np covers non-existent subdomains (RFC 9091) — a spoofing vector neither p nor sp address.
• adkim and aspf control identifier alignment: r (relaxed, default — match organizational domain) or s (strict — exact match).
• rua is the aggregate-report destination (a mailto: URI); without it the feedback loop is silent. ruf is the forensic-report destination but is deprecated in dmarcbis.
• Recommended production record: v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s; fo=1 — closes every spoofing vector and delivers actionable reports.

1. What is a DMARC record?

A DMARC record is a DNS TXT record published at the _dmarc subdomain of an email-sending domain. It carries the domain owner's authentication policy and reporting preferences in a compact, machine-readable format. DMARC itself is defined in RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) (March 2015), with the np tag added in RFC 9091 (July 2021) and ongoing revisions in draft-ietf-dmarc-dmarcbis (the work-in-progress successor that obsoletes RFC 7489 when published).

Every DMARC record begins with the version tag v=DMARC1 and continues with one or more tag=value pairs separated by semicolons. A minimal monitoring-only record looks like this:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A full enforcement record with subdomain and non-existent-subdomain coverage looks like this:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject;
                              rua=mailto:dmarc@example.com;
                              adkim=s; aspf=s; fo=1"

The record's job is purely to publish policy and reporting intent. The actual authentication decisions (does this message's SPF pass? does its DKIM signature verify? does the authenticated domain align with the From: header?) happen at the receiving mail server during message ingestion — DMARC merely tells the receiver what to do once those decisions are made.

For the broader DMARC primer (rollout strategy, aggregate-report XML format, mailing-list interactions), see help.php. This page is the deep dive on the record's tag-by-tag syntax — every published-but-rarely-explained tag with semantics, defaults, and worked examples.

2. How a receiver evaluates the record

1. When mail arrives, the receiver extracts the From: header domain and computes its organizational domain (the registered name plus its public suffix — example.co.uk, not news.example.co.uk).
2. The receiver queries DNS for _dmarc.<header-from> first; if no TXT record is found, it queries _dmarc.<organizational-domain>. This two-step lookup is why a subdomain without its own DMARC record inherits the organizational-domain policy.
3. The TXT record is parsed left-to-right. v=DMARC1 MUST be the first tag — anywhere else and the record is treated as malformed and ignored. Per RFC 7489 §6.4, tag names are case-insensitive but values are case-sensitive in some positions.
4. Each tag is validated against its allowed values. Unknown tags are ignored (forward compatibility); for a malformed value in a known tag the receiver falls back to the default or ignores that tag, and a record left without a valid policy tag is treated as monitoring-only if it names a valid report address, or else ignored (RFC 7489 §6.3 and §6.6.3).
5. The receiver computes SPF and DKIM results independently, then applies identifier alignment using adkim and aspf to decide whether each authenticated identifier matches the From: header domain.
6. If at least one of SPF-aligned or DKIM-aligned passes, the message passes DMARC and no policy is applied. If both fail, the receiver applies the policy chosen by the record (p, sp, or np depending on the subdomain situation).
7. The receiver records the outcome and (once per configured reporting interval, default 24h) compiles an XML aggregate report to send to the rua= address.

3. DMARC DNS syntax

A DMARC record is a DNS TXT record at the _dmarc subdomain. Its RDATA is a quoted string of tag=value pairs separated by semicolons.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; sp=reject; adkim=s; aspf=s"
^                    ^   ^    ^                                                                              ^
|                    |   |    |                                                                              |
|                    |   |    +-- Quoted RDATA: semicolon-separated tag=value pairs                          |
|                    |   +------- Record type (TXT)                                                          |
|                    +----------- Class (IN)                                                                 |
+-------------------------------- Owner name — MUST be _dmarc.<domain>                                       |
                                                                                                             |
                                  v=DMARC1 MUST be first; remaining tags are order-independent.              |

Field-by-field anatomy:

Owner name

The record MUST be published at _dmarc.<domain> — the underscore prefix signals an "underscore label" per RFC 8552. Publishing at dmarc.example.com (no underscore) is a common mistake — the record is invisible to DMARC-aware receivers.

Record type

Always TXT. RFC 7489 §6.1 defines the DMARC record as a TXT record only; an SPF-type or any other record type is never read. A single quoted string is preferred; longer records that exceed the 255-byte single-string limit may be split into multiple quoted strings, which the receiver MUST concatenate (RFC 7489 §6.1); most DNS providers handle this automatically.

RDATA

A semicolon-separated list of tag=value pairs. v=DMARC1 MUST appear first; all other tags are order-independent but conventionally written in the order v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri.

Whitespace

Whitespace around = and between tags is permitted but not required. Most operators write v=DMARC1; p=reject; sp=reject (no spaces around =, single space after the semicolon). Trailing semicolons are permitted but unnecessary.

Only one DMARC record may be published per name. Two TXT records at _dmarc.example.com both starting with v=DMARC1 cause receivers to discard BOTH and treat the domain as having no DMARC policy at all — exactly the failure mode that duplicate publication is trying to avoid. Always consolidate to a single record.

4. Every DMARC tag, explained

RFC 7489 §6.3 defines eleven tags; RFC 9091 added the twelfth (np). Each tag has a well-defined default, so a minimal record omits most of them and relies on the defaults.

Most production records contain six to eight tags. The minimum viable record is v=DMARC1; p=none; rua=mailto:…; the recommended hardened record adds sp, np, adkim=s, aspf=s, and fo=1.

5. How the tags interact

Several tags compose with each other in non-obvious ways. The interactions matter operationally because they determine which policy is actually applied to a given message.

p -> sp -> np precedence chain

The receiver picks ONE policy based on the From: header domain. (a) If the From: domain is the organizational domain itself, p applies. (b) If From: is an EXISTING subdomain (DNS resolves) without its own DMARC record, sp applies if published, else falls back to p. (c) If From: is a NON-EXISTENT subdomain (NXDOMAIN), np applies if published, else falls back to sp, else p. The np -> sp -> p waterfall is the explicit rule from RFC 9091 §2.

adkim + aspf independence

The two alignment modes are evaluated independently. A record with adkim=s; aspf=r applies strict alignment to DKIM and relaxed to SPF — useful when DKIM is signed by a tightly-controlled infrastructure but SPF includes a third-party sender on a sibling subdomain.

pct interaction with policy

pct=10; p=reject means "apply the policy of p=reject to 10% of failing messages; treat the remaining 90% as if the policy were one step less severe — quarantine". This downshift-not-skip behaviour is specified in RFC 7489 §6.6.4 and is still a frequent surprise. The deprecation in dmarcbis is in part because of this confusion.

fo requires ruf

fo only does anything when ruf= is also published — without a forensic-report destination there is nowhere for the receiver to send the generated reports. Publishing fo=1 alone is a no-op.

rua with size limits

Each mailto: URI in rua= can carry a size cap suffix: !10m means "reports up to 10 megabytes are welcome"; !100k caps at 100 kilobytes. Reports larger than the cap are NOT sent. Useful for protecting a small mailbox from a very large reporter.

Cross-domain report destinations

If the rua= or ruf= domain differs from the DMARC-record domain, the destination domain MUST publish an authorisation record at <source>._report._dmarc.<dest> containing v=DMARC1. See RFC 7489 §7.1. Without it the receiver refuses to send reports to the cross-domain address.

6. DMARC record examples

6.1 Minimal monitoring (Day 1)

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The starting point for every deployment. p=none tells receivers to take no action but still send aggregate reports. The record is safe to publish on day one — no legitimate mail will be impacted.

6.2 Soft enforcement (Phase 2)

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25;
                              rua=mailto:dmarc@example.com"

Once monitoring has shown 95%+ alignment, move to quarantine with pct=25 to apply the policy to a quarter of failing messages. Raise pct gradually as alignment improves. Note: dmarcbis deprecates pct; use sub-week policy ramps instead.

6.3 Full enforcement with subdomain coverage

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject;
                              rua=mailto:dmarc@example.com;
                              adkim=s; aspf=s; fo=1"

The recommended hardened record. p=reject stops spoofing of example.com itself; sp=reject covers existing subdomains without their own DMARC; np=reject covers non-existent-subdomain spoofing (fake.example.com when no such subdomain is in DNS); strict alignment on both DKIM and SPF; fo=1 requests forensic reports for either-fails cases.

6.4 Non-sending domain (parked)

_dmarc.example-parked.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject;
                                     rua=mailto:dmarc@example.com; aspf=s; adkim=s"

Domains that never send legitimate mail can go straight to p=reject on day one — there is no legitimate traffic to misclassify. Best practice for every brand-protection domain in a portfolio.

6.5 Forensic reports to a dedicated mailbox

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject;
                              rua=mailto:dmarc-rua@example.com!25m;
                              ruf=mailto:dmarc-ruf@example.com!10m;
                              fo=1:d:s"

Routes aggregate reports up to 25 MB to one mailbox and per-message forensic reports up to 10 MB to another. fo=1:d:s requests forensic reports for every failure type. Note most major receivers no longer send forensic reports for privacy reasons regardless of ruf=.

6.6 Cross-domain reporting

_dmarc.example.com.       IN  TXT  "v=DMARC1; p=reject;
                                  rua=mailto:reports@dmarc-vendor.com"

example.com._report._dmarc.dmarc-vendor.com.  IN  TXT  "v=DMARC1"

When the report destination is on a different domain than the DMARC record, the destination domain MUST publish an authorisation record per RFC 7489 §7.1. Most managed-DMARC vendors handle this for you when you onboard.

6.7 Multiple report destinations

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject;
                              rua=mailto:dmarc@example.com,
                                  mailto:reports@dmarc-vendor.com"

Reports get sent to BOTH addresses. Useful for running an internal dashboard while a managed vendor provides additional analytics. Each URI can carry its own size cap.

6.8 Faster reporting interval

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject;
                              rua=mailto:dmarc@example.com;
                              ri=3600"

Requests hourly aggregate reports (3600 seconds). Most major receivers ignore ri below the default 86400 seconds and still send daily reports — Google and Microsoft are explicit about this — but smaller receivers may honour the request. Use only when actively debugging.

7. DMARC record best practices

• Always start with p=none and run for at least 4-8 weeks before any enforcement. Monitoring is what surfaces forgotten senders (marketing platforms, transactional services, helpdesk systems) before they get blocked.
• Publish rua= on every DMARC record, even p=none ones. Without rua= there is no feedback loop and the record provides zero operational value.
• Publish sp AND np explicitly — never rely on inheritance. Explicit beats implicit when a reader is auditing a record six months from now. np in particular is often forgotten because it only joined RFC 9091 in 2021.
• Use adkim=s; aspf=s on non-sending domains. Strict alignment closes the relaxed-mode loophole that lets siblings of a subdomain pass DMARC when they should not.
• Skip pct in new deployments. Dmarcbis deprecates it; receivers implement inconsistently; gradual policy ramping is better achieved with sub-week policy steps (none -> quarantine -> reject) than with partial application.
• Set fo=1 when ruf= is published. fo=0 only reports when BOTH SPF and DKIM fail — exactly the cases that are easiest to diagnose anyway. fo=1 surfaces the partial-failure cases where the operational signal is highest.
• Use a dedicated mailbox for rua reports. Daily XML attachments from every major receiver will flood a shared inbox. A dedicated dmarc@ mailbox (or, better, ingestion via IMAP / Microsoft Graph into a tool like DMARC Analyzer) keeps the feedback loop manageable.
• Consolidate to a single TXT record at _dmarc.<domain>. Two records both starting with v=DMARC1 cause receivers to discard BOTH per RFC 7489 §6.6.3 — the domain effectively has no DMARC at all.
• Audit the record after every DNS change. A typo in a tag value (v=DMARCv1, p=rejct) silently invalidates the record or reduces it to monitoring only. DMARC Analyzer's Domain Security Checker performs syntactic validation on every tag.
• Watch for the v= first-position rule. p=reject; v=DMARC1; rua=... is ignored even though every individual tag is valid — v MUST be first.

8. Common DMARC record mistakes

• Typo in v=DMARC1. Common variants — v=DMARCv1, v=DMARC.1, v=dmarc1 — invalidate the record. The literal value is exactly DMARC1 (uppercase), always.
• Published at dmarc.example.com without the underscore. The owner name MUST be _dmarc.example.com (RFC 7489 §6.1). Underscore-less records are invisible to every receiver.
• Two TXT records at _dmarc.<domain>. Receivers discard BOTH per RFC 7489 §6.6.3. A frequent failure when one team publishes a vendor's record and another adds an in-house record — always consolidate.
• Forgetting the v=DMARC1 first-position rule. Some DNS UIs reorder tags alphabetically on save. Always verify with dig TXT _dmarc.<domain> after a DNS change.
• Publishing p=reject without monitoring first. Almost guaranteed to bounce legitimate marketing or transactional mail until you discover and align every sender. Run p=none for at least one full reporting cycle (typically 4-8 weeks).
• Missing or unreachable rua= mailbox. A DMARC record without a working report destination is publish-and-pray. Use a dedicated mailbox with at least 100 MB of free space; bounce-back from a full mailbox causes receivers to silently stop sending.
• Cross-domain rua without authorisation record. If the report destination's domain differs from the DMARC-record domain, the destination MUST publish <source>._report._dmarc.<dest> IN TXT "v=DMARC1". Without it, no reports are sent.
• Setting fo=1 without publishing ruf=. fo controls forensic-report generation but does nothing without a destination. Either publish both or publish neither.
• Forgetting np entirely. np=reject is the strongest protection against subdomain-spoofing attacks that use non-existent subdomains (banking.example.com when no banking subdomain is in DNS). It only shipped in RFC 9091 (2021), so older records often lack it.
• Using p=quarantine long-term as the "safe choice". Quarantine delivers spoofed mail to spam folders, where attackers know users actively rescue messages. Move to p=reject once stable.

9. DMARC record troubleshooting

The record exists but receivers act as if there is no DMARC policy

Three likely causes: (1) the record is at dmarc. instead of _dmarc. (no underscore); (2) v=DMARC1 is not in the first position; (3) two TXT records exist at _dmarc.<domain> both starting with v=DMARC1 — receivers discard duplicates per RFC 7489 §6.6.3. Verify with dig TXT _dmarc.<domain> +short.

Aggregate reports stopped arriving

Check (1) the rua= mailbox is not full; (2) the destination MX is reachable from the public internet; (3) any size-cap suffix (!10m) is large enough for the receiver's reports — Microsoft 365 reports routinely exceed 5 MB for high-volume domains; (4) the cross-domain authorisation record is still in place if applicable.

I see permerror as the DMARC result in the Authentication-Results header

The receiver could not parse your DMARC record. Common causes: extra unescaped quotes, smart-quote characters (curly instead of straight), or a tag value with invalid syntax (e.g. p=rejct with a typo). Re-publish a clean record and wait for the DNS TTL to expire.

Subdomain inheritance is not working

If news.example.com publishes its OWN DMARC record at _dmarc.news.example.com, it completely overrides the organizational-domain record — the sp tag is ONLY consulted when the subdomain has NO DMARC record. Decide whether each subdomain should have its own record or rely on sp; do not mix the two strategies.

Legitimate mail bounces after moving to p=reject

Revert to p=quarantine or p=none immediately to restore delivery; investigate which sender is unaligned via the next aggregate-report cycle. The pattern usually points at a forgotten SaaS sender that needs custom-domain DKIM enabled — see the DKIM deep dive for the per-platform procedure.

How do I see my published DMARC record?

Use dig TXT _dmarc.example.com +short from any modern dig install, or DMARC Analyzer's Domain Security Checker which parses every tag and flags missing required fields, weak policies, and unreachable report destinations.

The DMARC record looks right but DMARC results show none in reports

"none" in policy_evaluated.disposition means either (a) the message passed DMARC (one of SPF-aligned or DKIM-aligned passed) OR (b) your published policy is p=none. Check the policy_published.p field in the same report to disambiguate.

10. Frequently Asked Questions

What is a DMARC record?

A DMARC record is a DNS TXT record published at the _dmarc subdomain that tells receiving mail servers how to handle messages that fail SPF and DKIM alignment, where to send aggregate authentication reports, and which alignment mode (strict or relaxed) to apply. Defined in RFC 7489 and updated by RFC 9091 (np tag), the record is a semicolon-separated list of tag=value pairs starting with v=DMARC1. A typical record is: _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; sp=reject; adkim=s; aspf=s".

What are the required tags in a DMARC record?

Only two tags are strictly required: v (must be the literal v=DMARC1 and MUST be the first tag) and p (the policy — none, quarantine, or reject). Every other tag is optional and falls back to its RFC-defined default if omitted. Without rua= no aggregate reports are sent; without sp= the subdomain policy inherits p; without adkim/aspf the alignment mode defaults to relaxed.

What is the difference between the p, sp, and np tags?

p sets the policy for the organizational domain. sp (subdomain policy) overrides p for any existing subdomain that lacks its own DMARC record — without sp the subdomain inherits p. np (non-existent-subdomain policy, added by RFC 9091 in 2021) covers messages claiming to originate from a subdomain that does not exist in DNS at all — a common spoofing vector that p and sp do not address. Best practice: publish all three with reject for full coverage.

What does adkim=r vs adkim=s mean?

adkim and aspf control identifier alignment between the From: header domain and the DKIM signing domain (adkim) or SPF authenticated domain (aspf). r (relaxed, the default) requires the organizational domain to match — a DKIM signature on mail.example.com aligns with a From: of news@example.com. s (strict) requires an exact match — the same signature would NOT align with a different subdomain in From. Strict alignment is more secure; relaxed is more forgiving of cross-subdomain mail flows.

What is the pct tag and is it still recommended?

pct (percentage) tells receivers to apply the policy to only a percentage of failing messages — useful for staged rollout (pct=10, pct=50, pct=100). RFC 7489 defines it; however the in-progress dmarcbis draft (draft-ietf-dmarc-dmarcbis) deprecates pct because receivers implement it inconsistently and the testing benefit is small. Modern guidance: skip pct, ramp policy directly (none -> quarantine -> reject) and use sp/np for fine-grained control.

What does the fo tag do and which value should I use?

fo controls forensic-report generation conditions. fo=0 (default) reports only when BOTH SPF and DKIM fail. fo=1 reports when EITHER fails. fo=d reports when DKIM fails to verify regardless of alignment. fo=s reports when SPF fails. Multiple values can be combined with colons: fo=1:d:s. fo=1 is the standard production choice because it surfaces partial-failure cases that fo=0 hides; combine with ruf= to actually receive the reports.

How does DMARC Analyzer help me audit my DMARC record?

DMARC Analyzer's Domain Security Checker (domain_checker.php) performs a live DNS lookup for _dmarc.<your-domain> and parses every tag in the record, flagging missing required tags (v, p), weak policies (p=none after deployment), missing sp/np coverage, and report destinations that do not accept your domain. The DNS Record Generator (dns_generator.php) builds well-formed DMARC records with every tag validated against RFC 7489 / RFC 9091 syntax — copy the output directly into your DNS provider.

11. Related guides

• MTA-STS policy file byte-syntax — the DMARC-RECORD-PARALLEL-DNS-PUBLICATION- COMPANION to this DMARC tag-by-tag reference. Where THIS page documents the DMARC TXT record at _dmarc.<domain> and the tag-by-tag grammar (v=DMARC1, p=, sp=, np=, pct=, rua=, ruf=, adkim=, aspf=, fo=, rf=, ri=), the MTA-STS-policy- syntax spoke documents the PARALLEL DNS PUBLICATION at _mta-sts.<domain> TXT (the policy-version-indicator record) and https://mta-sts.<domain>/.well-known/mta-sts.txt HTTPS (the policy file itself, with version: STSv1 / mode: enforce / mx: <pattern> / max_age: <seconds> tag grammar) — the SAME-DNS-FAMILY publication analog of THIS page's DMARC TXT record at the application-layer-vs-transport-layer protocol boundary. The four-axis DMARC- RECORD-VS-MTA-STS-RECORD-PARALLEL comparison exposes the structurally- distinct PUBLICATION-PARALLEL-FAMILY roles: (i) both DMARC and MTA-STS records use the SAME underscore-prefixed DNS label convention (_dmarc.<domain> for DMARC, _mta-sts.<domain> for MTA-STS) per RFC 8552 (DNS Scoped Data via Underscore-Prefixed Labels) — operators publishing one MUST follow the same DNS- provider publication discipline for the other; the MTA-STS-policy-syntax spoke documents the byte-syntax operators familiar with DMARC TXT publication can transfer directly to MTA-STS TXT publication; (ii) the DMARC TXT record this page documents and the _mta-sts TXT record the spoke documents are both rate-limited by the same per-zone TXT-record byte- budget (typically 4096 bytes per RFC 6891 EDNS0) — the MTA-STS-policy- syntax spoke documents the byte-syntax operators must keep concise to coexist with DMARC + SPF + DKIM-selector + BIMI + CAA records in the same zone; (iii) the MTA-STS policy file itself is published via HTTPS at mta-sts.<domain> — NOT via DNS; this divergence from DMARC's pure-DNS publication pattern is the single most important operational distinction between the two records, and the spoke documents the HTTPS-hosting prerequisites operators must satisfy (TLS certificate matching mta-sts.<domain>, Content-Type: text/plain response, the unique id: value coordinated between the TXT and HTTPS endpoints); (iv) the DMARC rua= tag the receiver-side parses to emit aggregate reports has its transport- layer counterpart in the TLS-RPT rua= tag operators publish at _smtp._tls.<domain> — the spoke documents the byte-syntax relationship between MTA-STS policy publication and TLS-RPT failure- reporting subscription (the MTA-STS policy file declares enforcement; the TLS-RPT record subscribes to the sender-side observation of enforcement failures). Read the MTA-STS- policy-syntax spoke when an operator completes their DMARC TXT-record publication on this page and needs the PARALLEL TRANSPORT-LAYER POLICY PUBLICATION — the two records form the application- layer / transport-layer pair that together close the spoofing-AND-downgrade attack surface.
• Phishing protection — the threat model behind the p= and sp= tags — the threat-model companion to this tag-by-tag reference. Where this page documents what the p=, sp=, and np= tags mean syntactically (the three enforcement values none / quarantine / reject and the apex-vs-subdomain distinction), the phishing-protection page documents which phishing attack patterns each tag-value closes: p=reject denies exact-domain spoofing (attackers forging the apex From: address), sp=reject denies subdomain abuse on unprotected child labels (attackers forging billing.example.com when only example.com has DMARC), np=reject (RFC 9091) denies never-existed-subdomain abuse (attackers registering brand-adjacent labels that the publishing domain has never used and the apex DMARC record does not implicitly cover). Read this page when stakeholders ask "why is sp=reject worth publishing when our subdomains do not currently send" — the answer is in the seven canonical phishing patterns the page catalogues and the tag-value-to-pattern mapping table.
• Email spoofing — the protocol-level technique the p= and adkim= / aspf= tags deny — the technique-catalogue companion to this tag-by-tag reference. Where this page documents what each DMARC tag means syntactically (the p= enforcement verb, the adkim= / aspf= identifier-alignment mode pair, the fo= forensic-trigger bitmap, the pct= rollout sampling rate), the spoofing page documents the seven canonical protocol-level spoofing techniques each tag-value denies at the receiver: exact-domain From-header spoofing (closed by p=reject + strict alignment), Punycode/IDN homograph From-domain spoofing (closed by display-name normalisation plus p=reject at the homoglyph's apex), Display-Name-only spoofing (closed by receiver-side BIMI adoption on top of p=reject), Reply-To substitution (closed by header validation engines that run alongside DMARC), envelope-MAIL-FROM-vs-From mismatch (closed by aspf=s strict-alignment for tenants that can publish aligned envelopes), subdomain abuse on unprotected child labels (closed by sp=reject), and never-existed-subdomain abuse (closed by np=reject per RFC 9091). Read this page for the syntactic meaning of each tag; read the spoofing page for the attacker-technique catalogue each tag-value structurally denies.
• Business Email Compromise (BEC) — the financial-fraud threat catalogue mapping each tag-value to the BEC variant it closes — the operational deep dive on the financial-fraud threat scenarios each DMARC tag-value documented on THIS page structurally closes. Where this page documents WHAT each tag MEANS (the v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri tags with syntax defaults and interaction rules), the BEC spoke documents WHICH BEC VARIANT each tag-value structurally closes — concretely mapping the six canonical BEC variants (CEO fraud, vendor / supplier-invoice fraud, payroll- redirect, attorney impersonation, W-2 / data theft, account-compromise BEC) to the specific tag-value combination that denies the attack: apex p=reject closes the exact-domain spoofing variant where the attacker sends from ceo@your-domain.com with no valid SPF / DKIM authentication; sp=reject closes the subdomain-abuse variant where the attacker exploits an unprotected child label (finance@subsidiary.your- domain.com) the apex DMARC record does NOT cover by default; np=reject per RFC 9091 closes the never-existed-subdomain variant where the attacker registers billing.your-domain.com on otherwise-unused subdomain space; adkim=s / aspf=s strict-alignment closes the relaxed- alignment-tolerance variant where the attacker sends from a malicious subdomain (news.your-domain.com) with valid DKIM/SPF for that subdomain but the From header claims the apex. The BEC spoke ALSO documents the DMARC GAP (variants DMARC cannot block) so operators understand which BEC patterns remain after the tag-by-tag publication on THIS page is complete — specifically look-alike-domain BEC (the attacker registers your-d0main.com and publishes their OWN valid SPF / DKIM / DMARC records, defeating any tag-value on the legitimate apex) and display-name BEC (the attacker sends from a random Gmail address with the From display name set to "CEO Name", bypassing DMARC entirely because the envelope From and the From header are both authentic to the random Gmail address). Read the BEC spoke when building the operational case for the specific tag-value selection on a NEW DMARC record — the spoke is the authoritative threat-catalogue reference for which BEC variants the tag values you publish will and will not close.
• Email security glossary — the broader threat-actor and incident-response context that justifies each tag-value selection — the security-context glossary cataloguing the threat-actor taxonomies (nation-state APTs, ransomware-as-a-service crews, initial-access brokers, BEC crews), the MITRE ATT&CK matrix, STRIDE threat-classification, the 7-stage cyber kill chain, the NIST SP 800-61 incident-response cycle, and the defence-in-depth control stack within which the DMARC tag values this page documents operate. Where this page documents WHAT each DMARC tag MEANS syntactically and WHICH default value each tag uses absent operator override, the security_glossary spoke documents WHY each tag-value matters in the broader threat model — concretely: p=reject maps to MITRE ATT&CK T1566.001 / T1566.002 (Spearphishing) as a Defence-Evasion prevention control closing the Delivery kill-chain stage; sp=reject + np=reject close the subdomain-spoof and never-existed-subdomain abuse variants the glossary catalogues under look-alike-domain attacks; fo=1 + ruf= feed the forensic stream the glossary catalogues as the SIEM ingestion precursor; adkim=s + aspf=s strict-alignment closes the relaxed-tolerance attack-surface the glossary catalogues under spoof-technique taxonomy. The security_glossary also provides the operator vocabulary cross-walk for tag-value justification in cross-functional security conversations: when the SOC asks "what is DMARC blocking and how do we map it to ATT&CK", the glossary is the canonical reference; when the threat-modelling team asks "where does DMARC sit in our STRIDE Spoofing defence", the glossary is the canonical cross-walk. Read the security_glossary spoke when building the cross-functional threat-model case for a specific tag-value selection — every tag-value this page documents has a corresponding entry in the broader threat-actor / kill-chain / incident-response vocabulary the glossary catalogues.
• DKIM selectors explained — the DKIM-SELECTOR-PUBLICATION-AS- STRUCTURAL-PREREQUISITE-FOR-DMARC- adkim-ALIGNMENT-EVALUATION companion to this tag-by-tag DMARC record reference. Where THIS page documents the adkim=r / adkim=s alignment-mode tag-grammar and its semantic evaluation against the DKIM d= tag at receiver-side DMARC validation, the DKIM-selectors- explained spoke documents FOUR selector-publication-discipline dimensions whose per-message publisher-side material directly determines whether the receiver- side adkim= alignment evaluation succeeds or fails: (i) the selector-as-key-identity token at the s= tag layer — every DKIM-Signature header carries an s=<selector> tag identifying the specific key the sender used to sign, with the receiver resolving the public key at <selector>._domainkey.<d-tag-domain> — the selector publication directly determines whether receiver-side DKIM verification succeeds, which is the upstream prerequisite for the adkim= alignment check even firing; (ii) the per-key TXT-record publication at the selector owner-name — each selector requires a TXT-record publication at <selector>._domainkey.<domain> carrying the v=DKIM1; k=rsa; p=<base64> canonical payload — selector-publication defects (missing record, wrong owner- name, byte-corrupted base64, chunk-concatenation breakage on keys >255 octets) directly produce DKIM=fail rows in RUA evidence, which then can't satisfy the adkim= alignment check even with otherwise-correct d= alignment to the From: header organisational domain; (iii) the dual-selector overlap discipline for key rotation — operators rotating keys must publish the new selector's TXT record AND continue signing under the old selector for at least the DNS TTL window plus the maximum receiver-side cache age — a premature old-selector revocation during the rotation window produces uniformly- observable DKIM=fail rows at receivers whose cache still holds the new selector, breaking adkim= alignment until the propagation window closes, and (iv) the per-mail-stream dedicated selector pattern — operators using multiple sending infrastructures (in-house MTA, Workspace, M365, SendGrid, Mailchimp) typically publish a dedicated selector per mail-stream (mta1._domainkey, sendgrid._domainkey, etc.) so per-stream key rotation and key compromise isolation are independent — but the adkim= alignment evaluation operates uniformly across all of them and an under- published per-stream selector produces stream-specific DKIM=fail rows in aggregate evidence that only manifest at specific sender- infrastructure rows in the per-source_ip / per-d-domain partition of the RUA stream. Pair this DMARC-record reference (the receiver-side adkim= alignment-mode tag-grammar) with the DKIM-selectors-explained spoke (the publisher-side selector-publication- discipline reference) for the cross-layer publisher↔receiver contract every DMARC-record adkim= tag-value evaluation depends on.
• How attackers bypass DMARC — the RECORD-AUTHORING-ATTACKER-RESIDUAL companion to this tag-by-tag DMARC record reference. Where THIS page documents WHAT each tag in the _dmarc.<domain> TXT record MEANS syntactically and WHICH tag-value choice closes WHICH attack vector (p=reject closes exact-domain From-header forgery, sp=reject closes subdomain-spoof, np=reject closes never-existed-subdomain abuse, adkim=s/aspf=s close relaxed-tolerance subdomain bypass, fo=1+ruf= feed the forensic-stream SIEM ingestion path), the attacker-bypass spoke documents the ATTACK-VECTOR RESIDUAL SURFACE that remains AFTER the operator has authored every tag correctly to its maximal-protection value. The residual surface is STRUCTURALLY-PARTITIONED into ten attack-class categories the spoke catalogues: (i) display-name spoofing — the visible-To-line header attack alignment cannot see (the attacker sends from an unrelated domain but names the From-header friendly-name as "Acme Bank Billing" — passes DMARC because alignment is evaluated against the address domain, not the friendly-name), (ii) lookalike-domain registration — the typosquat / homograph / TLD-swap attack vector that registers acme‐bank.com (Unicode hyphen homoglyph), acmebank.co (TLD swap), or acme-bank.com (legitimate- looking hyphenation) and authors its OWN valid DMARC record on the lookalike (passes the lookalike's DMARC and exploits the visual-similarity at the recipient), (iii) third-party-vendor compromise — when the attacker takes over an ESP-tenant the operator's rua= feedback stream legitimised as a sender (the compromised ESP signs with the operator's d= and passes alignment), (iv) ARC trust-chain abuse — when a forwarder injects ARC-Authentication-Results that the operator's receiving MTA trusts and converts a fail into a pass via ARC override, (v) DKIM-replay attacks — when the attacker re-broadcasts a legitimately- signed message to a victim distribution list (the original DKIM signature still verifies), (vi) DKIM-key compromise via weak-key / expired-key / leaked-key — when the operator publishes an RSA-1024 or older key that can be factored or has leaked, (vii) Reply-To substitution + conversation-hijacking — when the attacker passes DMARC on the initial message but redirects the reply via Reply-To to an attacker-controlled inbox, (viii) punycode / IDN homograph attacks against the From-header domain (асme.com with Cyrillic 'а'), (ix) internal-relay legitimate- sender abuse — when the attacker gets a foothold on the operator's own SMTP- AUTH infrastructure and sends with valid d= signing, (x) partner-tenant / compromised-vendor-supply-chain attacks where the legitimate partner (legitimately-aligned via vendor d= signature) is itself compromised and sends attacker-payloads. The attacker-bypass spoke is the load-bearing residual-risk reference for any operator finalising every tag on THIS record-authoring page — every tag-value documented here has ATTACK CLASSES IT DOES NOT CLOSE that the attacker-bypass spoke catalogues for the operator's complementary-defence planning (BIMI for friendly-name trust, header- validation engines, anti-homograph normalisation in receiver pipelines, DMARC-Authentication-Results header consumption, periodic key rotation discipline).
• Why SPF alone is insufficient — the DMARC-RECORD-RAISON-D-ETRE-INPUT companion documenting why every tag on this DMARC record exists at all — the DMARC-RECORD-RAISON-D-ETRE-INPUT companion documenting WHY the DMARC tag grammar catalogued on this page exists at all. Where THIS page documents WHAT each DMARC TXT-record tag MEANS syntactically (the v=DMARC1 version tag, the p=/sp=/np= policy tags, the adkim=/aspf= alignment-mode tags, the rua=/ruf= reporting URI tags, the pct=/fo=/ri=/rf= ancillary tags), the why-SPF-alone-is- insufficient spoke documents the WHY — the five SPF-only-deployment gaps that produced the need for the DMARC tag grammar on this page in the first place: (i) the From:-header spoofing gap (SPF authenticates envelope MAIL FROM not the visible From: — the GROUND of why the adkim=/aspf= alignment tags exist as a SEPARATE check on top of the underlying SPF/DKIM verdicts), (ii) the forwarding gap (SPF breaks on the second SMTP hop — the GROUND of why DMARC requires DKIM-aligned OR SPF-aligned as a logical OR, not AND), (iii) the mailing-list gap (lists rewrite both envelope AND From: — the GROUND of why pct= gradual rollout exists and why the p=quarantine intermediate policy is operationally necessary), (iv) the third-party-sender gap (CRM platforms send From: customer-domain via vendor infrastructure — the GROUND of why sp= exists as a subdomain- only policy knob distinct from p=, and why np= closes the never-existed-subdomain abuse vector), (v) the DKIM-replay gap (cooperating-spammer replay attacks — the GROUND of why fo=1 forensic feedback exists as a per-message failure-stream channel distinct from the daily-aggregate rua= feedback). Read the why-SPF-alone-is-insufficient spoke when an operator authoring the DMARC record asks "WHY does DMARC have all these tags — why not just use SPF" — the spoke is the authoritative motivation reference for every tag-grammar decision documented on this page.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery — the operational deep dive on the rua= and ruf= tag pair this tag-by-tag page introduces. Where this page tells you what rua= and ruf= mean syntactically (the mailto-or-https URI list that names the report destination), the pipeline page documents the full receiver-to- operator transport-and-ingestion path each URI activates: the receiver- side report-generator that produces the aggregate XML or forensic ARF document, DNS resolution of the rua= / ruf= URI's destination domain (including the cross-domain !example.com._report. _dmarc.<owner> opt-in record required when the report mailbox is not on the publishing domain), the MIME- attached SMTP send (or HTTPS POST for the rare https:// URI), operator-side inbound mailbox or webhook capture, MIME-part extraction, gzip-or- zip decompression, XML schema-validation (or ARF MIME-part parsing for forensic documents), and row-by-row ingestion into the analyzer's dmarc_records / dmarc_forensic_reports tables. Read this page when configuring the rua= / ruf= tags so the report mailbox is provisioned correctly, and when reports stop arriving despite a published DMARC record (typical causes: the report mailbox is bouncing, the cross-domain opt-in record is missing, operator-side IMAP-fetcher credentials rotated, or schema-validation rejected a non-conformant report).
• DMARC monitoring & reporting analysis — the DMARC-RECORD-TAG-CATALOGUE-AS- MONITORING-KPI-INPUT-PRODUCER companion to this DMARC-tag-by-tag byte-syntax reference. Where THIS page documents the per-tag byte-level grammar of every DMARC record tag (v= / p= / sp= / np= / adkim= / aspf= / pct= / rua= / ruf= / fo= / rf= / ri=), the DMARC-monitoring spoke is the OPERATIONAL DISCIPLINE applied post-publication: it documents what KPIs operators track, what alert thresholds to set, what review cadence to follow, and how to map aggregate-report data points to operational actions. The DMARC-RECORD- TAG-CATALOGUE-AS-MONITORING-KPI-INPUT- PRODUCER cross-reference establishes FOUR structurally-distinct tag-value-to- monitoring-feedback-loop dimensions: (i) p=-tag-value-determines-disposition- KPI-shape dimension — the p=none / p=quarantine / p=reject tag value THIS page documents directly determines the receiver-side disposition KPI shape the monitoring page tracks: under p=none the disposition is always "none" (monitoring-only era — only the pass/fail-rate KPIs are actionable); under p=quarantine the disposition rate becomes a primary KPI with quarantine-rate alert thresholds; under p=reject the disposition KPI gains reject-rate alerting AND volume-loss alerting (since rejected messages don't reach the recipient inbox); the monitoring page's per-policy-mode KPI dashboard structure is directly determined by which p=-tag-value THIS page's catalogue documents the publisher chose; (ii) rua=-tag-determines-monitoring- feedback-loop-existence dimension — the rua=mailto: URI list THIS page documents is the SOLE INPUT STREAM the monitoring page's 8 KPIs consume; if rua= is unset, no aggregate-report stream reaches the operator and the monitoring discipline cannot be performed at all; if the rua= mailbox bounces, the monitoring page's "reporter coverage" KPI silently degrades to zero across all receivers; the monitoring discipline the spoke documents is STRUCTURALLY PREDICATED on the rua= publishing decision THIS page documents the byte-syntax of; (iii) pct=-tag- value-determines-monitoring-statistical- sample-base dimension — the pct= tag value (1–100) THIS page documents determines the statistical sample-base the monitoring page's per-source-IP enforcement-rate KPI is computed from: at pct=10 only 10% of non-aligned messages receive the published disposition (the other 90% downgrade one step), which means the monitoring page's "policy-mode enforcement disposition rate" KPI reports per-message-disposition-rates STATISTICALLY DAMPENED by the pct=-tag-value SAMPLE-BASE the publisher chose; the monitoring page's ramp-cadence interpretation guidance accounts for the pct=-tag-value statistical damping THIS page documents; (iv) fo=-and-rf=-tag-values-determine- forensic-stream-availability-for- per-message-monitoring-investigation dimension — the fo=0/1/d/s failure-mode flags AND rf=afrf/iodef forensic-report-format selectors THIS page documents determine whether the per-failure-message forensic-report- stream (RUF / AFRF / IODEF) is generated at all by the receiver; the monitoring page's "anomaly detection patterns" section documents how to consume per-failure-message forensic evidence to diagnose the root cause of per-source-IP failure-rate spikes; if fo= and rf= are unset or set to incompatible values the per-message-investigation surface the monitoring page documents the per-failure-class diagnostic procedure for collapses entirely. Read this monitoring spoke when you finish authoring the per-tag DMARC record THIS page documents AND want to instrument the receiver-side enforcement-outcome feedback loop the published record produces.
• DMARC explained — the central DMARC primer covering rollout strategy, aggregate-report XML schema, and mailing-list / forwarding interactions. Complements this tag-by-tag deep dive.
• DMARC policy modes: p=none vs p=quarantine vs p=reject — the head-to-head COMPARATIVE reference for the p= tag's three policy values. Per-mode semantics, 11-row side-by-side comparison table, receiver behaviour at Gmail / Microsoft 365 / Yahoo / Apple iCloud, pct= sampling interaction, sp=/np= subdomain policy modes, and a scenario-based decision matrix. Read this when you need to choose the right p= value or explain what each mode actually does at the receiver.
• DMARC policy rollout — the JOURNEY companion: the Week 0 to Week 26 rollout timeline, the p=none → p=quarantine → p=reject progression, when to advance, and the pct= sampling ramp. Read this once you know what the modes mean (above) and need to know the operational sequencing of advancing through them.
• DMARC myths and misconceptions — the DMARC-RECORD-TAG-CATALOGUE-AS-PER- MISCONCEPTION-CANONICAL-REFERENCE companion to this tag-by-tag byte-syntax reference. Where THIS page documents the per-tag byte-level grammar (v= / p= / sp= / np= / pct= / adkim= / aspf= / rua= / ruf= / fo= / ri= / rf=) the publisher encodes into the _dmarc.<domain> TXT record, the myths-and-misconceptions spoke is the STAKEHOLDER-EDUCATION-AGAINST- PER-TAG-FALSE-MENTAL-MODELS reference that debunks the operator-side misconceptions that drive incorrect tag-value-selection decisions at publication time. The DMARC-RECORD-TAG-MISCONCEPTION-DEBUNKING cross-reference establishes FOUR structurally-distinct dimensions where the myths-and-misconceptions spoke debunks operator-side misconceptions about the per-tag-value-selection decisions THIS page's byte-syntax catalogue is the canonical reference for: (i) "p=none provides protection against spoofing" misconception → debunked by the monitoring-only- diagnostic-posture-with-zero-enforcement class — operators new to DMARC publication frequently interpret p=none as a "soft enforcement" posture that protects against some impersonation while allowing legitimate traffic through; the myths spoke documents the RFC 7489 §6.3 receiver-side enforcement semantics that make p=none a PURE-MONITORING diagnostic posture with ZERO receiver- side enforcement consequence — receivers deliver DMARC-failing messages with p=none identically to messages with no DMARC record at all — debunking the operator's "publishing p=none means I'm protected" mental model that masks the protect-against-active-spoofing- requires-p=quarantine-or-reject operational truth the per-tag byte-syntax catalogue this page documents underpins; (ii) "publishing the DMARC TXT record is the entire deployment" misconception → debunked by the rua-aggregate-monitoring- then-ramp-to-enforcement-lifecycle class — operators who finish authoring the tag-by- tag byte-syntax from THIS page and publish the record frequently treat the deployment as complete; the myths spoke documents the RFC 7489 §10 publication-as-pre-flight- diagnostic-step lifecycle where the record-publication is the START of a multi-week rua-monitoring → sender- inventory → mis-alignment-remediation → pct=N-ramp → p=reject-commitment journey — debunking the operator's "DMARC TXT published = deployment complete" mental model that delivers zero protection because the publisher never ramps off p=none; (iii) "I have valid SPF and DKIM records so DMARC publication is redundant" misconception → debunked by the From-header-alignment-as-load- bearing-anti-spoofing-binding class — operators with mature SPF and DKIM deployments frequently interpret DMARC as a duplicate authentication standard; the myths spoke documents the RFC 7489 §3.1 identifier-alignment binding rule (SPF authenticates the RFC 5321 envelope MAIL FROM, DKIM authenticates the DKIM-Signature header's d= tag, NEITHER inherently binds to the visible From: header) — debunking the operator's "SPF + DKIM = sufficient" mental model with the From-header- alignment-closure-only-DMARC-provides load-bearing argument that this page's aspf= + adkim= tag-byte-syntax catalogue is the publisher-side instrument for; (iv) "DMARC at p=reject blocks all phishing and spam against my domain" misconception → debunked by the lookalike- cousin-domain-and-transport-MitM-residual- gaps class — operators reaching p=reject via the rollout sequence frequently interpret the posture as a complete anti-phishing solution; the myths spoke documents the multiple residual-attack-surface dimensions DMARC-at-reject does NOT close — lookalike-cousin-domain spoofing (attacker buys vvise.example against wise.example and publishes their own valid DMARC record), transport-layer MitM stripping STARTTLS without MTA-STS, compromised-internal- account phishing from the operator's own infrastructure, BEC-attempt Display-Name spoofing within the local- part — debunking the operator's "DMARC at reject = total protection" mental model that masks the requires-full- email-authentication-stack-MTA-STS- TLS-RPT-ARC-BIMI-CAA architectural truth THIS page's per-tag catalogue is ONE pillar within. Read the myths-and- misconceptions spoke alongside this DMARC-record tag-by-tag byte-syntax reference when onboarding new publishers, when escalating publication decisions to non-technical stakeholders, or when correcting operator-side false-mental-models that drive incorrect tag-value-selection decisions — the spoke is the canonical stakeholder-education reference whose four myth-debunking dimensions directly map to the per-tag decisions THIS page's byte-syntax catalogue is the publisher-authoring instrument for.
• DMARC deployment checklist — the OPERATIONAL CHECKLIST companion. Where THIS page is the tag-by-tag REFERENCE documenting what each token in the _dmarc.<domain> TXT record MEANS, the deployment-checklist spoke is the step-by-step PROCEDURE for publishing the record: pre-flight inventory of every sending source (transactional MTA, marketing ESP, helpdesk, payroll, every SaaS that sends from @your-domain), SPF + DKIM prerequisite verification across every source, baseline RUA-stream instrumentation before the policy is published, initial p=none record construction with a syntactically complete tag set per the byte-level reference on THIS page, the receiver-side propagation verification step (querying the published TXT at multiple resolvers), and the post-publication monitoring cadence over the first 30-60 days. Read the deployment- checklist spoke when authoring a NEW DMARC record from scratch — the spoke is the procedural reference that wraps the tag-by-tag information on THIS page into an actionable deployment sequence.
• Multi-domain DMARC strategy — the operational deep dive on the sp= (subdomain policy) and np= (non-existent subdomain policy) tags this tag-by-tag page introduces. Where this page tells you what each tag means, the multi-domain page tells you how to deploy the subdomain-policy tag family across a multi-domain organization: the four-pattern decision framework (single-org-many-brands, many-orgs-one- tenant, acquired-domain wind-down, parked- domain enforcement), the Public Suffix List (PSL) organizational-domain boundary that governs which subdomains sp= actually covers, the RFC 9091 np= tag for closing the never-existed-subdomain attack surface (attackers register billing.example.com on otherwise-unused subdomain space and bypass the apex-only DMARC record), the per-domain _dmarc.<domain> publication discipline (each registrable sending domain needs its own DMARC record — sp= covers only subdomains of the publishing domain, NOT sibling brand domains), brand-aware rua= aggregator routing per brand domain (so reports flow to the brand-team inbox, not the corporate IT inbox), and the canonical parked-domain enforcement record v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.com every never-sending domain in the organization should carry to prevent attacker abuse.
• DMARC for shared hosting (cPanel / Plesk / DirectAdmin) — the per-provider procedural deep dive on the SHARED-HOSTING OPERATOR-EMPOWERMENT CEILING that constrains which DMARC tag values shared-hosting operators can realistically publish. Where THIS page is the tag-by-tag REFERENCE documenting what each token in the _dmarc.<domain> TXT record MEANS (the v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri tags with syntax defaults and interaction rules), the shared-hosting spoke is the CONTEXTUALIZED PROCEDURE for choosing tag VALUES under the shared-hosting operator-empowerment ceiling. Specifically: shared-hosting operators typically do NOT have the per-tenant ability to configure custom-domain DKIM on the shared MTA (the shared-hosting provider's outbound MTA signs every tenant's outbound mail with the PROVIDER's d= domain, not the tenant's @your-domain) — which means the adkim= tag's relaxed-vs-strict semantics documented on THIS page have a materially different operational meaning at shared-hosting deployments (relaxed alignment will NOT save you because the d= domain is the provider's, not a parent of your domain). Similarly the aspf= tag's relaxed-vs-strict semantics depends on whether the shared-hosting SPF record includes your tenant's @your-domain in the envelope-sender HELO domain — which again is provider-controlled, not tenant-controlled. The pct= ramp documented on THIS page is also operationally more conservative on shared hosting because the operator has less per-tenant observability into which tenants on the same SHARED IP block are dragging the IP reputation down. Read the shared-hosting spoke when authoring a DMARC record for a domain hosted on cPanel / Plesk / DirectAdmin / any shared-hosting platform — the spoke is the authoritative reference for the provider-specific tag-value selection that respects the operator-empowerment ceiling.
• DMARC for SaaS senders — the CNAME-delegated DMARC-record-publication pattern for multi-tenant platforms — the per-deployment procedural deep dive on the SaaS-multi-tenant DMARC-RECORD-DELEGATION pattern where the tag-by-tag DMARC record this page documents is NOT published as a TXT record by the customer themselves, but as a CNAME-delegation that points at the SaaS provider's runtime-managed TXT record. Where THIS page documents the byte-level grammar of each _dmarc.<domain> TXT-record tag (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) the operator publishes directly at their own DNS authoritative server, the SaaS-senders spoke documents the STRUCTURALLY-DIFFERENT record-publication layout the SaaS multi-tenant operator persona uses: the customer publishes _dmarc.<tenant>.<customer>.com CNAME _dmarc.<tenant-id>.<saas>.com at their own DNS provider (a CNAME record pointing to the SaaS provider's DMARC-record-management-as-a-service endpoint), while the SaaS provider publishes the actual _dmarc.<tenant-id>.<saas>.com TXT record at the SaaS provider's DNS authoritative server — with the SaaS provider OWNING the runtime tag-value decisions (which p= mode this tenant is in, which rua= mailbox receives the aggregate reports, which adkim= / aspf= strictness this tenant's authentication-plane requires) while the customer RETAINS the DNS-publishing control via the CNAME pointer they can revoke unilaterally. This creates a materially-different tag-edit workflow than the direct-TXT pattern THIS page documents: the customer cannot change any of the tag values documented on this page without the SaaS provider's agreement (the CNAME's resolution target controls the values); the SaaS provider can change every tag value for the customer without DNS-edit coordination (the CNAME continues pointing at the same runtime endpoint whose TXT record is now updated); and the customer can withdraw from the delegation by deleting the CNAME and publishing a direct TXT record on their own. Read the SaaS-senders spoke when authoring a DMARC record for a domain whose outbound mail is wholly or partly delegated to a SaaS sender (transactional-email-platform, customer- engagement-platform, marketing-automation- platform, billing-platform, customer- notification-platform) — the spoke is the authoritative reference for the CNAME-delegation tag-publication pattern the SaaS multi-tenant operator persona uses in lieu of the direct-TXT pattern this page documents at the byte-grammar level.
• DMARC for transactional email — the per-ESP DMARC-record tag-value selection for SendGrid / Mailgun / SES / Postmark / SparkPost — the per-ESP procedural deep dive on the TRANSACTIONAL-EMAIL DMARC-RECORD-AUTHORING pattern where the byte-level tag grammar this page documents is consumed by an operator who has delegated outbound transactional mail to a third-party ESP (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost, etc.) and must author the _dmarc.<domain> TXT record's tag values around that delegation constraint. Where THIS page documents the byte-level grammar of each tag the operator publishes (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) at the DNS authoritative server, the transactional-email spoke documents the per-ESP TAG-VALUE-SELECTION CONSTRAINTS the operator faces: aspf= verdict-at-verification-time depends on which Return-Path the ESP uses (SendGrid em.domain.com, Mailgun bounces.domain.com, SES feedback.domain.com, Postmark pm-bounces.domain.com); the adkim= verdict-at-verification-time depends on which s= selector the ESP signs with and whether the operator has published the CNAME-delegated DKIM keys at the matching subdomain; the p= ramp speed depends on whether the ESP's onboarding has converged on stable spf=pass + dkim=pass + DMARC-alignment across the full sending IP pool; the rua= mailbox aggregates BOTH the operator's own outbound mail AND the ESP's outbound mail under the same organizational-domain authentication-plane; the subdomain-policy choice (sp=quarantine vs sp=reject) determines whether the operator can isolate the ESP onto a dedicated mail.<domain> subdomain at a different policy tier than the parent organizational domain's non-transactional mail. This creates a materially-different tag-edit workflow than a non-ESP-delegated DMARC record: the operator's tag-edit cadence on this page is coupled to the ESP's onboarding rhythm (CNAME activation, IP pool warmup, Return-Path domain verification, custom return-path branding), and any premature p=reject ramp before the ESP's authentication-plane has stabilised breaks transactional-mail delivery for password-resets, order-confirmations, shipping-notifications, billing-receipts, and security-alerts — the EXACT mail classes whose delivery the operator cannot afford to drop. Read the transactional-email spoke when authoring a DMARC record for a domain whose outbound transactional mail is wholly or partly delegated to one or more ESPs — the spoke is the authoritative reference for the per-ESP TAG-VALUE-SELECTION CONSTRAINTS the tag-by-tag grammar this page documents must respect.
• DNS propagation explained (TTL discipline for every tag change) — the operational reference for the invisible-but-critical timing layer that every tag-edit on this page silently depends on. When you edit any tag in your DMARC record — bump p=none to p=quarantine, add sp=reject, change the rua= mailbox, drop pct=10 down to pct=0, raise the ri= interval — every recursive resolver that already has the previous TXT record cached will continue to serve the OLD record until its cache entry's TTL counter reaches zero. With the typical DNS-provider default of 14 400 seconds (4 hours) — or worse, 86 400 seconds (24 hours) — that means receivers around the world will evaluate mail against your previous tag values for hours after you save the change in your DNS provider's web UI, and your aggregate-report stream will contain conflicting policy-applied rows for several days as different receivers' caches age out at different rates. The DNS propagation reference documents: the per-record TTL mechanics (RFC 1035 §3.2.1 + RFC 2181 §8) and the authoritative-vs-recursive-vs-stub-client chain of caches, the recommended 300-second (5-minute) TTL for active tag-edit cycles vs the 3600-second (1-hour) TTL for steady-state production records, the canonical lower the TTL one full TTL period BEFORE you change the record rule that makes every tag edit feel instantaneous, the operator verification workflow using dig / kdig against the authoritative nameservers + multiple geographically diverse recursive resolvers to confirm the new tag values have actually replaced the old ones end-to-end, and the emergency-rollback case for short TTLs when an inadvertent tag change breaks legitimate mail. Read this before any tag change on a production record — TTL discipline is the single highest-leverage prerequisite decision in the whole tag-edit workflow.
• MX records explained — the RUA-RUF-EXTERNAL-DESTINATION-RECIPIENT- DOMAIN-MX-PUBLICATION-AS-PREREQUISITE-FOR- RECEIVING-AGGREGATE-AND-FORENSIC-REPORTS companion documenting the authoritative MX record (RFC 5321 §5.1 + RFC 7505 null-MX) the rua=mailto: and ruf=mailto: mailbox's domain MUST publish for any receiver-generated aggregate report or forensic-failure sample to be deliverable to the configured destination at all. Where THIS page documents the per-tag byte-layer grammar of the DMARC TXT record (the v=DMARC1 + p= + sp= + pct= + adkim= / aspf= + rua= / ruf= + fo= + rf= + ri= tag-value selection grammar), the MX-records spoke is the REPORT-DELIVERY-TRANSPORT-LAYER companion documenting the authoritative-DNS object the destination mailbox on the right-hand side of every rua= and ruf= tag implicitly depends on. The four-axis DMARC-RECORD-VS-MX-RECORD comparison exposes the structurally-distinct RUA-RUF-EXTERNAL-DESTINATION-MX-PUBLICATION roles: (i) every rua=mailto: mailbox's domain MUST publish an MX record accepting mail for the rua mailbox's local-part — if the rua-mailbox's domain has no MX (or has the RFC 7505 null-MX 0 .), the receiver's aggregate report submission attempts will produce delivery failures and the operator will receive ZERO aggregate-report rows; the tag-value will appear correctly published yet no reports will arrive; (ii) third-party aggregate- report ingestion services like DMARC-analyzer- as-a-service vendors REQUIRE the operator to complete the External Destination Verification check per RFC 7489 §7.1 — the _report._dmarc.<recipient-domain> TXT record proves the external destination consents to receiving the publisher's reports, but the underlying delivery still depends on the recipient-domain's MX publication; (iii) publishing rua=mailto: to a mailbox whose domain has a non-publishable MX produces SILENTLY DROPPED reports because the receiver-side report-generator treats SMTP-receive failures at the rua-mailbox's MX as a delivery problem the publisher must diagnose, not a publisher-side configuration error worth re-attempting; (iv) multi-recipient rua/ruf lists (rua=mailto:a@x.com,mailto:b@y.com) with one recipient's domain MX-unpublishable produce partial-delivery outcomes where some recipients receive reports and others receive nothing — invisible to the publisher unless cross-recipient-stream reconciliation is performed against the receiver-side aggregate-report-submitter logs. Read the MX-records spoke when scoping a new rua= or ruf= destination mailbox to confirm the destination domain's MX publication is suitable to receive the report stream at all, and when investigating why a syntactically-correct rua= tag value produces zero received aggregate reports.
• SPF explained — Sender Policy Framework (RFC 7208). The aspf tag controls how SPF results align with the From: header domain; this page documents the SPF record itself.
• DMARC for cPanel — the DMARC-RECORD-TAG-CATALOGUE-AS- CANONICAL-REFERENCE-FOR-CPANEL-WHM-EMAIL- DELIVERABILITY-WIZARD-AUTHORED-RECORDS companion to this DMARC record byte- syntax reference. Where THIS page documents the canonical tag-by-tag byte-syntax catalogue (the v=DMARC1 / p= / sp= / rua= / ruf= / pct= / adkim= / aspf= / fo= / rf= / ri= tags with their per-tag value-grammar and per-tag default-on-omission semantics), the DMARC-for-cPanel spoke is the SHARED-HOSTING-CONTROL-PANEL-UI- WIZARD-AUTHORED-RECORD companion documenting the STRUCTURALLY- CONSTRAINED tag-authoring surface the cPanel WHM "Email Deliverability" wizard exposes: (i) the cPanel WHM wizard typically authors a narrow subset of the full tag catalogue (often v=DMARC1; p=none; rua=mailto:<admin> as the auto-generated default, omitting sp=, adkim=, aspf=, pct=, fo=, rf=, ri=) — customers wanting the broader tag- catalogue THIS page documents must hand-edit the published TXT record via the cPanel DNS Zone Editor, an operator-side step the customer-portal-only customer rarely takes without external guidance; (ii) the cPanel wizard's rua= default typically points to the customer's primary mailbox at the customer's domain (i.e. rua=mailto:postmaster@ <customer-domain>), which delivers aggregate reports to a mailbox the customer manually inspects — scaling to a managed-DMARC- analytics workflow requires the customer to manually replace the default with a managed-receiver address (e.g. rua=mailto:<tenant- slug>@rua.<managed- receiver>.com); (iii) the cPanel wizard's p=none default is the safe-monitoring posture but does NOT enforce quarantine or reject on the From-header alignment failure — customers wanting the ENFORCEMENT-MODE p=quarantine or p=reject posture documented in THIS page's per-tag catalogue must manually edit the TXT record AND coordinate the p= ramp with the cPanel provider's shared-IP- pool reputation discipline (a premature p=reject on a cPanel-hosted customer domain with poorly-authored SPF include: chains produces immediate inbox- deliverability collateral damage); (iv) the cPanel wizard's aspf= / adkim= alignment-mode tags are NOT exposed in the UI and default to the relaxed RFC 7489 defaults — customers wanting the strict alignment posture must hand-author the tags, and the cPanel provider's outbound-Exim d-domain attribution may not respect adkim=strict (cPanel's Exim-DKIM-Milter typically signs with the customer-domain as d= but the provider may also sign with the provider's own d= if the customer's DKIM publication is incomplete). Read the DMARC-for-cPanel spoke alongside this DMARC record byte-syntax catalogue when the operator is auditing a cPanel-hosted customer's published DMARC record, when planning a multi-customer DMARC-ramp playbook across a cPanel-hosted brand portfolio, or when designing a cPanel-aware managed-DMARC- analytics onboarding workflow.
• SPF mechanisms explained — the DMARC-POLICY-RECORD-TAG-CATALOGUE- AS-CONSUMER-OF-SPF-MECHANISM-EVALUATION- OUTCOMES companion to this DMARC tag-by-tag byte-layer reference. Where THIS page documents the DMARC record's per-tag syntax (the p= policy-mode tag, the aspf=r-vs-aspf=s relaxed-vs-strict SPF-alignment-mode tag, the sp= subdomain-policy tag, the pct= sampling tag, the rua= + ruf= reporting tags, the fo= forensic-options tag), the SPF-mechanisms spoke documents the SEVEN STRUCTURALLY- DIFFERENT SPF mechanism tokens (RFC 7208 §5 — all, include:, a: / a:<domain>, mx: / mx:<domain>, ptr: / ptr:<domain>, exists:, and the IP-literal ip4: / ip6:) whose per-message evaluation outcomes the DMARC engine's p=-enforcement + aspf=-alignment evaluator DEPENDS ON to produce the final DMARC verdict. The two protocol layers chain: at the receiver, the SPF-mechanism- evaluation FIRST produces the spf= verdict by checking the connecting client IP against the SPF record's mechanism sequence — then the DMARC engine's p=-policy-mode + aspf=-alignment-mode evaluators consults BOTH the SPF-authenticated MAIL-FROM domain AND the From:-header domain to compute the DMARC SPF-alignment verdict that gates the p=-policy enforcement action. Critically: each of the seven SPF mechanism types has a STRUCTURALLY-DISTINCT per-message-evaluation FAILURE MODE that propagates into a DIFFERENT DMARC verdict outcome (a ptr:-mechanism evaluation failure produces a spf=permerror the DMARC engine treats per RFC 7489 §6.6.3 differently from a include:-recursive-lookup budget-exhaustion permerror, and an exists:-macro-evaluation temperror produces a transient spf=temperror DMARC engines treat per §6.6.2 differently from a fatal spf=fail) — and the p= + aspf= + sp= tag-byte-syntax this page documents is the publisher-side specification of how the receiver's DMARC engine should ACT on each of those structurally-distinct SPF-mechanism-evaluation outcomes. Read the SPF-mechanisms spoke alongside this DMARC tag-by-tag reference when authoring or auditing the p= / aspf= / sp= tags — the SPF mechanism vocabulary documented in the spoke is the upstream EVALUATION-LAYER whose seven verdict classes this page's DMARC-policy-record tag-bytes consume at VERIFICATION-time to compute the final receiver-side enforcement decision.
• include: vs ip4: vs a: vs mx: — the DMARC-ASPF-VERDICT-INPUT mechanism-decision reference informing every aspf= alignment evaluation this page documents — the DMARC-ASPF-VERDICT-INPUT mechanism-decision companion to this DMARC tag-by-tag syntax reference. Where THIS page documents the aspf=r-vs-aspf=s relaxed-vs-strict alignment-mode tag at the DMARC-record byte layer (the tag controlling whether the SPF-authenticated MAIL-FROM domain must ORGANISATIONALLY match the From:-header domain or must BYTE-IDENTICALLY match), the include-vs-ip4-vs-a-vs-mx spoke documents the FOUR STRUCTURALLY-DIFFERENT SPF mechanism tokens (RFC 7208 §5 — include:, ip4:, a:, mx:) the SPF-record AUTHOR chooses between when building the SPF record whose evaluation produces the spf=pass-or-spf=fail VERDICT the DMARC engine then consults for SPF ALIGNMENT under the aspf= tag. The two layers chain: at the receiver, the SPF-mechanism-evaluation FIRST produces the spf= verdict by checking the connecting client IP against the SPF-record's mechanisms — then the DMARC engine's aspf=-mode evaluator consults BOTH the SPF-authenticated MAIL-FROM domain AND the From:-header domain to compute the DMARC SPF-alignment verdict. Critically: the SPF-mechanism CHOICE made at authoring-time directly determines which MAIL-FROM domains the SPF verdict authenticates and therefore which downstream SPF-aligned-with-From outcomes the aspf= tag can produce — an include: token delegates the SPF-mechanism evaluation to the third-party sender's record (whose SPF-authenticated MAIL-FROM domain is typically the SENDER's bounce domain, NOT the publisher's vanity domain — producing a SPF-aligned-with-From FAIL under aspf=s and a likely FAIL under aspf=r too if the bounce domain is organisationally unrelated), an ip4: / a: / mx: token keeps the MAIL-FROM under the publisher's own DNS-namespace control (producing reliable SPF alignment). Read the include-vs-ip4-vs-a-vs-mx spoke alongside this tag-by-tag reference when authoring or auditing the aspf= tag — the SPF mechanism-choice at AUTHORING-time is the load-bearing INPUT to the aspf= verdict at VERIFICATION-time.
• SPF qualifiers explained — the per-character prefix grammar parallel to the DMARC p= policy-strictness grammar — the per-qualifier deep dive on the single-character SPF prefix grammar (+ Pass / - Fail / ~ SoftFail / ? Neutral) and the tail-token -all / ~all / ?all / +all grammar the operator publishes ALONGSIDE the p= / sp= / np= tag-grammar this DMARC records-explained reference catalogues. The two grammars represent the operator's chosen STRICTNESS for the two authentication layers DMARC enforces — SPF declares "what SPF verdict should the receiver return on a non-authorised IP" via the qualifier prefix characters at the SPF-record byte layer; the DMARC p= tag declares "what action should the receiver take when DMARC fails" via the none / quarantine / reject token grammar at the DMARC-record byte layer. Both grammars are co-published per domain and co-tuned during the same operator deployment rollout — the ~all SPF tail typically co-occurs with the p=none DMARC policy during the monitoring phase, and the -all SPF tail typically co-occurs with the p=reject DMARC policy during enforcement. Read the qualifiers spoke when authoring or auditing the aspf= tag value documented on this page — the SPF-pass-or-not verdict the aspf check consumes is fundamentally determined by the qualifier choice on the matched SPF mechanism, and an operator publishing aspf=s strict-alignment with a +all permissive SPF tail has produced a deliberately-disabled-SPF-defense configuration the receiver cannot enforce against.
• SPF forwarding issues — the DMARC-RECORD-PUBLISHING-CONSUMER- OF-SPF-FORWARDING-BREAK-CATALOGUE companion reference. Where THIS page documents the DMARC record-tag byte- grammar (v=DMARC1 / p= / sp= / aspf= / adkim= / pct= / rua= / ruf=) operators publish at _dmarc.<domain>, the spf_forwarding_issues spoke is the SPF- FORWARDING-BREAK CATALOGUE reference documenting the RFC 7208 §10.4 mailing- list / auto-forwarder / SRS-vs-non-SRS intermediary classes whose per-forwarder per-recipient SPF-fail outcomes the DMARC record-tag configuration on THIS page directly governs at the receiver-side disposition boundary. FOUR structurally- distinct DMARC-RECORD-TAG-CONSEQUENCES- OF-SPF-FORWARDING-BREAK dimensions the forwarding-issues spoke defines that this DMARC-record-tag-grammar page structurally consumes: (i) per- forwarder per-recipient SPF-fail-rate AS THE LOAD-BEARING INPUT to the p=quarantine / p=reject policy-mode publication decision THIS page documents — the spf_forwarding_issues spoke documents the per-forwarder SPF-fail-rate distribution (vacation auto-forwarders at Gmail/Outlook/Apple; recipient-side mailbox-rule forwarders; mailing-list intermediaries Mailman/Sympa/Discourse; per-customer enterprise forwarding appliances Mimecast/Proofpoint); the DMARC-record-publishing operator consults the per-forwarder SPF-fail- rate baseline BEFORE publishing p=quarantine or p=reject per the deployment-checklist Phase-3 ramp- exit-criteria — without DKIM-aligned- pass on the forwarded path (which survives forwarding when forwarders don't break the body-hash), forwarded legitimate mail risks the p=quarantine/p=reject disposition the DMARC record published per THIS page mandates; (ii) per- forwarder per-recipient SPF-fail-rate AS THE LOAD-BEARING INPUT to the pct= ramped-enforcement publication decision THIS page documents — the spf_forwarding_issues spoke documents the per-receiver per-forwarder SPF-fail rate as the canonical observability signal that gates the pct= ramp progression (10 → 25 → 50 → 100); the DMARC-record-publishing operator increments pct= only after per-forwarder per-recipient SPF-fail- rate has stabilised below an operator- defined threshold AND DKIM-aligned-pass- on-forwarded-path baseline has been established (the SPF half of the DMARC disjunction breaks on forwarding by design — the DKIM half MUST carry the per-receiver alignment-pass load); (iii) per-forwarder per-recipient SPF-fail-rate AS THE LOAD-BEARING INPUT to the rua= aggregate-mailbox subscription capacity-planning decision THIS page documents — the spf_forwarding_issues spoke documents the per-receiver per-forwarder SPF- fail RUA-aggregate-row population the DMARC rua= mailbox operator receives; per-day RUA ingestion cardinality the operator depends on for the per-forwarder SPF- fail-rate baseline includes ~100s of per-receiver per-forwarder source_ip / auth_results/spf/result=fail / auth_results/dkim/result=pass rows per day at most operator organisational-domain scales; the DMARC-record-publishing operator scopes rua=-mailbox ingestion capacity using the per- forwarder SPF-fail-rate baseline the spf_forwarding_issues spoke quantifies; (iv) per-forwarder per- recipient SPF-fail-rate AS THE LOAD- BEARING INPUT to the sp= per-subdomain policy publication decision THIS page documents — the spf_forwarding_issues spoke documents the per-organisational- subdomain per-forwarder SPF-fail-rate distribution that can differ from the parent organisational domain (a subdomain like news.<domain> used exclusively for marketing-broadcast mail has different forwarder-population SPF-fail dynamics than the parent <domain> used for per-recipient correspondence); the DMARC-record-publishing operator consults per-subdomain per-forwarder SPF-fail-rate baseline to publish sp=quarantine on a subdomain WHILE leaving the parent p=none at a different ramp stage. Read the spf_forwarding_issues spoke alongside this DMARC-record-grammar page when authoring the DMARC-record publication rollout — the forwarding-break catalogue is the load-bearing per- forwarder per-receiver SPF-fail-rate baseline reference every DMARC-record- tag publication decision on THIS page structurally consumes for receiver- side disposition framing.
• SPF DNS record syntax explained — the DMARC-RECORD-CROSS-PROTOCOL-SYNTAX-REFERENCE peer to this DMARC tag-by-tag byte-layer reference — the DMARC-RECORD-CROSS-PROTOCOL-SYNTAX-REFERENCE peer companion documenting the RFC 7208 §3 byte-level SPF-record DNS publication grammar that the DMARC aspf= tag documented on this page CONSUMES as its verification input. Where THIS DMARC records-explained reference catalogues the DMARC TXT-record byte-layer grammar (the v=DMARC1 version tag, the p= / sp= / np= policy tags, the aspf= / adkim= alignment-mode tags, the rua= / ruf= reporting URI tags, the pct= / fo= / ri= / rf= / adkim= ancillary tags, and the _dmarc.<domain> publication location), the SPF DNS record syntax spoke documents the PARALLEL byte-level publication grammar of the SPF TXT-record whose verification verdict the aspf= tag consumes: the mandatory v=spf1 version tag, the TXT record type (with the November 2014 deprecation of DNS RR type 99 — publication via SPF type 99 is ignored by every modern receiver), the 255-octet DNS character-string limit and the multi-string concatenation rule (when an SPF record exceeds 255 octets it must be split into multiple quoted strings within the SAME TXT RDATA — NOT into multiple TXT records, which trigger PermError per §4.5 and lose ALL SPF authentication on that domain), the "exactly one SPF record per domain" rule, the apex vs subdomain publication semantics (wildcard TXT records do NOT cover the apex — every sending subdomain needs its own explicit SPF record), and the case-sensitivity matrix (v=spf1 case-sensitive version tag, mechanism tokens case-insensitive, domain-spec case-insensitive per DNS). The two byte-layer publication grammars are co-authored per domain — DMARC at _dmarc.<domain> and SPF at the apex (or per sending subdomain) — and violations of either grammar produce receiver-side PermError or no-record-found verdicts the aspf= tag cannot enforce against. Read the SPF DNS record syntax spoke when AUTHORING or AUDITING the aspf= tag documented on this page — the SPF-pass-or-not verdict the aspf check consumes is impossible to produce if the SPF record's byte-level encoding violates the §3 publication grammar (PermError on a 255-octet-overflowing record, PermError on a double-published record, no-record-found on a missing-subdomain record), and the syntax spoke is the authoritative reference for every byte-level encoding rule the SPF record must obey to produce the verdict the aspf= tag enforces against.
• SPF for Microsoft 365 — the M365-TENANT-ASPF-VERDICT-INPUT instance companion to this DMARC tag-by-tag syntax reference. Where THIS page documents the aspf=r-vs-aspf=s relaxed-vs-strict SPF-alignment tag at the DMARC-record byte layer (the tag controlling whether the SPF-authenticated MAIL-FROM domain must ORGANISATIONALLY match the From:-header domain or must BYTE-IDENTICALLY match), the SPF-for-M365 spoke documents the M365-tenant-specific SPF-record AUTHORING decisions that determine which MAIL-FROM domains the SPF verdict authenticates — and therefore which downstream aspf= alignment outcomes the DMARC engine produces — for the largest single SPF-authoring population in the operator field (~400M+ M365 commercial seats globally). The two layers chain: at the receiver, the M365-tenant's SPF record (containing include:spf.protection.outlook.com as the load-bearing token, optionally extended with secondary include: tokens for third-party SaaS senders and explicit ip4: tokens for hybrid Exchange-on-prem co-existence) FIRST produces an spf=pass or spf=fail verdict against the MAIL-FROM bounce-domain envelope, then the DMARC engine SECOND consumes that verdict under the aspf= tag this page documents to determine whether the SPF-pass authenticates the From: header domain. The M365-tenant-specific authoring decisions (the M365-managed include, the ~all-vs--all qualifier choice, the hybrid Exchange-on-prem explicit IP enumeration, the secondary SaaS-sender include strategy, the Direct-Send coverage envelope) directly determine the verdict distribution that flows into this page's aspf= alignment evaluation. Read the SPF-for-M365 spoke alongside this tag-by-tag reference when authoring or auditing the aspf= tag for an M365-tenant — the M365-tenant's SPF-record choices at AUTHORING-time are the load-bearing INPUT to the aspf= verdict at VERIFICATION-time, and the alignment-strict / alignment-relaxed selection on aspf= can pass or fail depending entirely on the M365 SPF authoring decisions documented in the spoke.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). The adkim tag controls how DKIM signing-domain alignment is evaluated.
• DKIM best practices — the DKIM-OPERATOR-DISCIPLINE-RULESET- AS-PREREQUISITE-FOR-MEANINGFUL-adkim- AND-FO-AND-RUF-TAG-EVALUATION-AT-RECEIVER- SIDE companion reference. Where THIS page documents the DMARC TXT-record TAG-BY-TAG byte-syntax in protocol-precise terms (the v= / p= / sp= / np= / pct= / rua= / ruf= / adkim= / aspf= / fo= / rf= / ri= tag-by-tag grammar, defaults, and interaction rules), the DKIM-best-practices spoke documents the UPSTREAM-PUBLISHER OPERATOR-DISCIPLINE RULESET whose collective satisfaction is the structural prerequisite for THREE of this page's tags to produce meaningful receiver-side enforcement: (i) the adkim= tag's DKIM-signing- domain alignment evaluation is STRUCTURALLY DEFEATED when the upstream- publisher DKIM-signing-domain is signed by a key that fails verification (RSA-1024 key length defeated by major receivers' RFC 8301 §3 enforcement, weak c=simple/simple canonicalization defeated by legitimate-forwarder body-modification, single-selector-no-rotation defeated by replay-attack window expansion); (ii) the fo= failure- reporting-options tag's per-message failure-attribution semantics materialise per-DKIM-key-state at the receiver — fo=1 (report on either SPF or DKIM failure) produces meaningful forensic streams ONLY when the upstream DKIM-signing discipline ALSO produces meaningful DKIM-pass events on the legitimate mail stream baseline, otherwise the forensic-stream signal/noise ratio collapses; (iii) the ruf= forensic-report mailbox tag's per- message RFC 6591 AFRF envelope is load-bearing for incident-response operators ONLY when the upstream DKIM-signing discipline is mature enough that the resulting forensic stream consists of genuinely-anomalous events not steady-state DKIM- misconfiguration noise. Read the DKIM-best-practices spoke alongside THIS page when planning the adkim=s strict-alignment transition (which structurally REQUIRES the operator-discipline ruleset to be in place before the receiver-side strict-evaluation produces non-noise verdicts) or scoping the fo= / ruf= forensic-stream instrumentation (which is operationally useful ONLY downstream of a stable DKIM-publication baseline). The DKIM-best-practices ruleset is the UPSTREAM PUBLISHER CONTRACT whose satisfaction makes THIS page's tag- by-tag receiver-side enforcement framework meaningful at the per-message verdict layer.
• DKIM cryptography basics — the DMARC-RECORD-TAG-BYTE-SYNTAX- CONSUMER-OF-PUBLISHER-SIDE-DKIM-RSA-VS- ED25519-KEYPAIR-AND-SHA-256-HASH-AND- CANONICALIZATION-CRYPTOGRAPHIC-FOUNDATION companion reference. Where THIS page documents the DMARC TXT-record TAG-BY-TAG byte-syntax in protocol-precise terms (the adkim= / aspf= alignment-strictness tag-byte syntax, the fo= failure-reporting-options tag-byte syntax, the ruf= forensic- report mailbox tag-byte syntax — each producing receiver-side enforcement ONLY when the upstream-publisher DKIM signing produces meaningful DKIM-pass events on the legitimate mail stream baseline), the cryptography-basics spoke is the PUBLISHER-SIDE CRYPTOGRAPHIC-FOUNDATION canonical reference documenting the FOUR cryptographic-foundation primitives the DMARC-tag-byte-syntax THIS page documents structurally consumes as upstream prerequisites: (i) RSA-2048 (or Ed25519 per RFC 8463) keypair- generation algorithm whose per-message DKIM-Signature b=-tag signature-math produces the dkim=pass verdict the adkim=r / adkim=s tag-byte-syntax THIS page documents evaluates against the RFC 5322 From-domain — without a cryptographically-valid signature the adkim= tag-byte-syntax has nothing to evaluate against, (ii) SHA-256 hash-algorithm discipline (RFC 8301 §3 deprecates SHA-1 and RFC 8463 introduces Ed25519 + SHA-256 as the Ed25519-modernisation pair) whose per-message a=-tag publication choice determines whether the per-receiver DKIM-verifier produces a dkim=pass that the fo= forensic-reporting-options tag-byte- syntax THIS page documents can mint meaningful per-message failure-attribution events for, (iii) RFC 6376 §3.4 simple- vs-relaxed canonicalization algorithm- pair publication-choice whose per- publisher c=-tag publication determines per-message signature survival across per-forwarder header-and-body modification — the ruf= forensic-report mailbox tag-byte-syntax THIS page documents only mints meaningful AFRF-envelope-encapsulated forensic evidence when the per-publisher canonicalization-discipline is mature enough that the resulting forensic stream consists of genuinely-anomalous events not steady-state canonicalization- choice noise, (iv) per-publisher private- key custody-and-rotation discipline whose per-rotation overlap-vs-cutover discipline determines whether the adkim=s strict-alignment transition this page's tag-byte-syntax documents produces non- noise verdicts at the receiver-side strict-evaluation. Read the cryptography- basics spoke alongside THIS page when scoping the upstream cryptographic- foundation prerequisites that the DMARC TXT-record tag-byte-syntax this page documents structurally depends on at every per-message receiver-side enforcement evaluation.
• DKIM for Google Workspace — the WORKSPACE-TENANT-google._domainkey- TXT-RECORD-PUBLICATION-AS-PREREQUISITE-FOR- MEANINGFUL-adkim-EVALUATION-AGAINST- WORKSPACE-HOSTED-OUTBOUND-MAIL-STREAMS companion to this DMARC tag-by-tag syntax reference. Where THIS page documents the DMARC-record byte-level encoding (the v=DMARC1; p=…; rua=…; ruf=…; fo=…; adkim=…; aspf=…; sp=…; np=…; pct=…; ri=…; rf=… tag-value catalogue published at _dmarc.<domain>) — i.e. the AUTHORING-side of the DMARC protocol — the DKIM-for-Google-Workspace spoke is the WORKSPACE-TENANT-DKIM-IDENTITY-ANCHOR companion documenting the Workspace-tenant- specific DKIM publication topology whose per-tenant signing-identity anchor is the load-bearing prerequisite for the adkim=r and adkim=s tag evaluation this page documents. Google Workspace's DKIM publication model is structurally distinct from most ESP-managed DKIM deployments: the domain-owner generates a 2048-bit key pair via the Workspace Admin Console's Apps > Google Workspace > Gmail > Authenticate email surface, publishes the public key as a TXT record at google._domainkey.<your- workspace-domain> (using the literal selector google by Workspace convention), and toggles the Start authentication button to enable Gmail's outbound DKIM signer for that tenant's mail-streams. This per-tenant signing-identity anchor structurally determines THREE distinct DMARC-tag evaluation outcomes documented here: (i) the adkim=r (relaxed organisational-domain match) tag evaluation against a Workspace-tenant- signed mail-stream requires that the Workspace signer's d=<workspace- domain> tag value share an organisational-domain root with the From:-header domain — when the Workspace tenant's google._domainkey.<domain> TXT record is published correctly and the signer is enabled, the Workspace outbound signer emits d=<workspace- domain> matching the From: domain, and adkim=r evaluation passes via Public Suffix List organisational-domain boundary lookup; when the Workspace deployment is incomplete (TXT record absent or signer toggle OFF), the receiver sees no DKIM-Signature at all from the Workspace side and the adkim evaluation has no signing-domain to align against; (ii) the adkim=s (strict byte-identical match) tag evaluation against a Workspace-tenant-signed mail-stream requires byte-identical match between the Workspace signer's d= tag value and the From:-header domain — Workspace's per-tenant signer emits d=<workspace- domain> directly (NOT d=<tenant>.gappssmtp.com which is the gappssmtp-fallback variant that breaks adkim=s) when the operator has published the google._domainkey.<workspace- domain> TXT record correctly; the gappssmtp-fallback variant ( d=<tenant>.gappssmtp.com) fires when the operator has NOT yet published the per-tenant google._domainkey TXT record, and is the canonical alignment-failure pattern under adkim=s the alignment-with-DMARC spoke documents elsewhere; (iii) the rua=mailto: and ruf=mailto: reporting tags capture the per-message DKIM-alignment verification outcomes for the Workspace- tenant-signed mail-streams in the receiver- side aggregate-report and forensic-report evidence streams — the per-message auth_results/dkim XML rows in each RUA payload cite the Workspace signer's <domain><workspace- domain></domain> + <selector>google</selector> + <result>pass|fail|permerror| temperror</result> verdict triplets, providing the operator with per-tenant per-mail-stream DKIM-alignment verification evidence the adkim= / aspf= tag-choice operationally depends on. Read the DKIM-for-Google-Workspace spoke alongside this DMARC tag-by-tag syntax reference when authoring the _dmarc.<workspace-domain> publication for a Workspace-hosted domain — the Workspace-tenant-specific google._domainkey TXT-record publication mechanics the spoke documents are the load-bearing DKIM-signing-identity prerequisite that determines whether the adkim=r or adkim=s tag this page documents has any DKIM signature at all to evaluate against the Workspace-hosted outbound mail-stream's From: header.
• Email deliverability fundamentals — the DELIVERABILITY-AUTHENTICATION-POLICY-PILLAR consumer of every tag this page documents — the DELIVERABILITY-AUTHENTICATION-POLICY-PILLAR downstream-consumer companion to this DMARC tag-by-tag syntax reference. Where THIS page documents the DMARC-record byte-level encoding (v=DMARC1; p=…; rua=…; ruf=…; fo=…; adkim=…; aspf=…; sp=…; np=…; pct=…; ri=…; rf=… tag-value list separated by semicolons, published at _dmarc.<domain>) — i.e. the AUTHORING-side of the DMARC protocol — the email-deliverability page documents the BUSINESS-OUTCOME SIDE: how each tag-value choice propagates through the receiver's accept-vs-reject-vs-spam-folder placement decision and ultimately shifts the sender's inbox-placement rate at every major mailbox provider (Gmail, Microsoft Consumer / M365, Yahoo / AOL, ProtonMail, Apple iCloud Mail). The deliverability page documents the FOUR-STAGE DELIVERY FUNNEL (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) and per-tag-value deliverability impact: the p=none-vs-p=quarantine-vs-p=reject transition's effect on inbox-placement signaling, the adkim=r-vs-adkim=s choice's effect on alignment-pass-rate and downstream placement, the pct= ramp's per-percentile impact on enforcement-driven deliverability cliff, and the Gmail / Yahoo February 2024 bulk-sender deliverability cliff (5,000-msgs/day senders REQUIRED to publish DMARC) the p=none-or-higher publication is a hard prerequisite for. Read the deliverability page when modeling the business impact of a tag-value change documented here — every p= / adkim= / pct= tag-edit ripples through the deliverability funnel described in the deliverability page's four-stage receiver-side acceptance → placement → engagement outcomes chain.
• DKIM alignment with DMARC (the adkim= tag deep dive) — the operational deep dive on the adkim=r/s tag this tag-by-tag reference introduces but does not exhaustively cover. Where this page documents what adkim=r (relaxed: organisational-domain match) and adkim=s (strict: byte- identical match) mean syntactically at the DMARC-record layer, the alignment-with-DMARC page documents the full evaluation algorithm receivers run when computing the DKIM alignment result: the DKIM-Signature d= tag extraction, the From:-header domain extraction, the Public Suffix List (PSL) organisational-domain boundary lookup that adkim=r depends on, the byte-comparison rule adkim=s enforces, and the canonical alignment-failure patterns each mode produces: the onmicrosoft.com gotcha (M365 signing with d=<tenant>.onmicrosoft.com when the From: domain is the customer's vanity domain), the gappssmtp.com gotcha (Workspace signing with d=<domain>.gappssmtp.com), and ESP shared-domain signing patterns (SendGrid, Mailchimp, Postmark, Mandrill signing with d=<esp-domain> unless CNAME-delegated authenticated- domain DKIM is configured). Read this page when choosing between adkim=r and adkim=s for a publication, and when an aggregate-report payload shows dkim=pass + dmarc=fail on rows from a known authenticated sender — alignment is almost certainly the missing link.
• DKIM troubleshooting — the DMARC-ADKIM-ALIGNMENT-MODE-TAG- INTERACTION-WITH-PER-MAIL-STREAM-DKIM- VERIFICATION-FAILURE-DIAGNOSTIC companion to this DMARC tag-by-tag reference. Where this page documents what adkim=r/s means at the DMARC-record byte-syntax layer and the adjacent dkim-alignment-with-DMARC spoke documents the full alignment-evaluation algorithm receivers run, the dkim- troubleshooting spoke is the FINER- GRAINED DIAGNOSTIC-ACTION-LAYER companion for the orthogonal DKIM-verification- failure class that produces dkim=fail (NOT dkim=pass + aligned=false) rows in the RUA stream. The adkim= tag controls ONLY the alignment-mode evaluation that runs AFTER a successful DKIM verification — but when the verification ITSELF fails (broken body hash, missing signed header, rotated selector, expired signature, modified canonicalization), the adkim= tag is moot because no verification result exists to align in the first place. The dkim-troubleshooting spoke documents the seven-step diagnostic decision tree operators execute on these dkim=fail rows: selector resolution-still-extant audit, published- vs-signing key match audit, in-transit body-modification audit, signed-headers h= tag consistency audit, canonicalization c= tag implementation audit, t=/x= timestamp validity audit, per-receiver verifier implementation audit. Pair this page (the adkim= tag byte-syntax reference) with the dkim-troubleshooting spoke (the per-mail-stream verification- failure diagnostic playbook) when an adkim= publication decision needs to account for the operator's actual DKIM-verification-failure rate before committing to adkim=s strict mode that would compound on top of any existing verification-failure-derived DKIM-failures. The dkim-troubleshooting spoke is the prerequisite operational- readiness audit BEFORE the adkim= tag choice this page documents becomes a load-bearing policy decision.
• DKIM canonicalization — the DKIM-CANONICALIZATION-ALGORITHM- CHOICE-AS-LOAD-BEARING-UPSTREAM- DETERMINANT-OF-THE-adkim-TAG- EVALUATION-OUTCOME companion to this DMARC-record tag-by-tag byte-syntax reference. Where THIS page documents the DMARC-record tag-catalogue (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) and the per-tag receiver-side evaluation contract, the DKIM-canonicalization spoke documents the RFC 6376 §3.4 four-combination algorithm catalogue whose per-publisher per-selector authoring choice is the LOAD-BEARING UPSTREAM PRIMITIVE every DMARC-record adkim= tag-evaluation outcome structurally depends on. Three concrete DMARC-tag-vs-canonicalization coupling points: (i) the adkim= alignment-mode tag evaluates the DKIM header.d domain against the RFC 5322 From: domain ONLY when the per-message DKIM signature verifies — which in turn depends on the per-publisher canonicalization-algorithm survival through intermediate MTAs; an adkim=s strict-alignment commitment is meaningless if the per-publisher c=simple/simple choice causes the DKIM signature to invalidate before reaching the receiver; (ii) the fo= forensic-trigger- option tag's per-mechanism failure- capture commitment depends on the per-publisher canonicalization- algorithm choice surviving the forwarder fleet — sustained per-message canonicalization-induced DKIM-fail cascades into the fo=1 / fo=d-emitted forensic evidence stream that compounds the operator's forensic-volume burden; the DKIM-canonicalization spoke documents the per-algorithm-pair failure-signature catalogue the operator consumes when interpreting the per-receiver forensic-emission evidence; (iii) the rua= aggregate-report- emission destination's per-row DKIM verdict decomposition exposes the per-publisher canonicalization- algorithm choice as the upstream attribution axis — the per- receiver per-day per-source-IP aggregate-XML evidence stream materially decomposes the per-message DKIM-pass-vs-fail distribution by per-publisher c=-tag choice; the DKIM-canonicalization spoke documents the per-algorithm- pair expected-pass-rate baseline the per-tag DMARC-record-evaluation- outcome interpretation depends on. Read the DKIM-canonicalization spoke as the LOAD-BEARING UPSTREAM CRYPTOGRAPHIC PRIMITIVE reference for the per-tag DMARC-record evaluation contract this page catalogues.
• DKIM DNS record syntax (RFC 6376 §3.6.2 byte-level TXT-record encoding rules) — the cross-protocol BYTE-SYNTAX SIBLING of this DMARC tag-by-tag reference. Where this page documents the DMARC-record byte-level encoding (v=DMARC1; p=…; rua=…; ruf=…; fo=…; adkim=…; aspf=…; sp=…; np=…; pct=…; ri=…; rf=… tag-value list separated by semicolons, published at _dmarc.<domain>), the DKIM-DNS-syntax spoke documents the STRUCTURALLY-PARALLEL byte-level encoding of the DKIM KEY TXT record across the DMARC trinity: the v=DKIM1; k=rsa; p=<base64-public-key>; h=sha256; t=y; s=email tag-value list separated by semicolons, published at <selector>._domainkey.<domain>. The two record formats share three structural conventions — (i) the case-sensitive v= version-tag preamble (uppercase DMARC1 / uppercase DKIM1), (ii) the semicolon-separated tag-value list grammar (case-sensitive lowercase tag names, both tolerate optional whitespace around the = and ;), (iii) the RFC 1035 §3.3.14 255-octet character- string concatenation rule (a long DKIM-key p= base64 blob must be split into multiple quoted strings in the zone file, exactly as rua= / ruf= URI lists in long DMARC records must be split). The two record formats diverge on three byte- syntax conventions — (i) DMARC's ; tag terminator is idempotent at end-of-record (trailing ; tolerated), DKIM's is STRICTLY tag-list-internal (trailing ; with empty tag-name AFTER it is a permerror), (ii) DMARC URIs in rua=/ruf= require RFC 3986 percent-encoding of comma/semicolon/exclamation-mark, DKIM's p= base64 blob does NOT require percent-encoding (base64 alphabet excludes those characters by construction), (iii) DMARC's p=none/p=quarantine/ p=reject values are ENUM strings, DKIM's p=<base64> is OPAQUE binary data. Read both pages together when standing up the full SPF + DKIM + DMARC trinity DNS publication — the DMARC record above defines policy semantics, the DKIM-DNS-syntax page defines the cryptographic-prerequisite-key publication the DMARC alignment evaluation depends on for the DKIM-pass half of the alignment rule, and the byte-syntax discipline operators apply to one record transfers verbatim to the other.
• DKIM-Signature header anatomy — the DMARC-RECORD-PUBLICATION-CONSUMER- OF-PER-MESSAGE-DKIM-SIGNATURE-HEADER- BYTE-CORRECTNESS companion to this DMARC-tag-by-tag reference. Where this page documents the per-tag DMARC-record byte-grammar (v=DMARC1; p=…; rua=…; ruf=…; fo=…; adkim=…; aspf=…; sp=…; np=…; pct=…; ri=…; rf=…) published once-per-domain at _dmarc.<domain>, the DKIM-Signature header-anatomy spoke is the per-message signature-header byte- grammar reference whose RFC 6376 §3.5 tag-list compliance is the upstream precondition for FOUR distinct DMARC- record tags THIS page documents to evaluate meaningfully on receiver side: (i) adkim= tag evaluates against signature d= — the DMARC adkim=r relaxed / adkim=s strict alignment mode this page documents performs its evaluation against the per-message DKIM-Signature header's d= tag value (organizational-domain match under adkim=r / exact-domain match under adkim=s); the spoke documents the per-message d= tag byte-correctness whose absence or misformat breaks the adkim= evaluation regardless of which mode the DMARC publisher chooses; (ii) p= and sp= tag enforcement operates on DKIM-verifier verdict derived from signature b= — the DMARC p=none/quarantine/reject and sp=… subdomain-policy enforcement modes THIS page documents operate on the per-message DKIM-verifier verdict (pass/fail/permerror/temperror) that the receiver-side DKIM-verifier computes by cryptographically validating the per-message b=<base64- signature> bytes against the canonicalized-header-set covered by the h= tag and the canonicalized-body-hash matching the bh= tag — the spoke documents each per-message tag's byte-correctness whose failure produces the dkim=fail verdict that cascades into the p=quarantine/reject enforcement THIS page documents; (iii) ruf= and fo= tag forensic-stream composes per-message signature-tag bytes — the DMARC ruf=mailto:… failure-report URI and fo=0/1/d/s failure- reporting-options tags THIS page documents produce per-message RFC 6591 AFRF reports whose evidence stream includes the per-message DKIM-Signature header tag- list bytes the spoke documents — a forensic-receiver-side analyst inspects per-incident d= s= h= bh= b= bytes against the canonical v=DKIM1 DNS-published-key record to root-cause the per-message verification failure; (iv) pct= ramped enforcement observes per-message signature-byte correctness uniformly across sampled subset — the DMARC pct=<0..100> percentage- sampled-enforcement tag THIS page documents applies p= enforcement to a sampled subset of per-message DKIM-Signature verifications; the spoke documents which per-message DKIM-Signature header tag-list-byte violations the sampled subset's receiver-side evaluation catches uniformly, distinguishing per- message DKIM-Signature-byte-correctness issues (caught uniformly across all samples) from per-source-IP per-day-volume baseline issues (which exhibit per-sample statistical variance). Pair this page (the DMARC-record tag-by-tag publication reference) with the DKIM-Signature header-anatomy spoke (the per-message signature-header byte-grammar reference) when diagnosing why a published DMARC record's adkim=, p=, ruf=, or pct= tag is producing unexpected receiver-side enforcement verdicts — the spoke documents the canonical compliant per-message DKIM-Signature header byte-layout whose violation on the signing side breaks the upstream DKIM-verifier verdict chain THIS page documents the DMARC-tag layer evaluates against.
• BIMI explained — Brand Indicators for Message Identification. BIMI requires DMARC at p=quarantine or p=reject — a strong commercial incentive to fully deploy DMARC.
• BIMI Verified Mark Certificates (VMC and CMC) — the cert-acquisition deep dive operators reach for after this DMARC tag-by-tag reference confirms their record is at p=quarantine or p=reject. Once the p= tag clears the BIMI eligibility floor, the next gating step is the Verified Mark Certificate the BIMI record's a= tag points to: Gmail / Apple Mail / Yahoo / Fastmail require a VMC (or, on Gmail only, a CMC) before they display the brand logo in the inbox. The certificates page documents the VMC vs CMC distinction (registered trademark vs unregistered mark), the two issuing CAs (DigiCert and Entrust), the trademark-evidence + chain-of-title documentation pack each CA validates, the public-PKI chain mailbox providers verify, the PEM-bundle file format served at the a= URL, the 12-month renewal cadence, and the pricing landscape. Read once the DMARC record on this page is at enforce and you need the operational sequence for the visible-brand-logo layer DMARC unlocks.
• BIMI SVG file requirements (SVG Tiny PS profile) — the other-half BIMI deployment-artefact reference operators reach for once this DMARC tag-by-tag reference confirms the record is at p=quarantine or p=reject. The BIMI record carries two file URLs: a= for the Verified Mark Certificate (documented in the certificates page above) AND l= for the brand logo as a profile-conformant SVG file. Even with a valid VMC, the logo will not render in any major BIMI-displaying inbox if the SVG file violates the Tiny PS profile — the mailbox provider validates BOTH files server-side before rendering. The SVG-requirements page documents the baseProfile="tiny-ps" root attribute that gates conformance (its omission is the #1 silent-rejection cause), the permitted/forbidden element whitelist (no <script>, no <animate>, no external raster <image> references — even though all three parse), the 1:1 square aspect ratio with safe central crop circle that survives Gmail's and Apple Mail's downstream circular cropping, the HTTPS-only fetch contract with public-PKI trust chain, the < 32 KB recommended file-size ceiling for inbox render latency, and the SVG-validator tooling published by the BIMI Group. Read alongside the certificates spoke once your DMARC record is at enforce and you need the complete two-file BIMI deployment-artefact reference.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Companion transport-security standard. DMARC governs message authentication; MTA-STS governs the transport encryption it travels over.
• DANE for SMTP — the DANE-AS-DNSSEC-TRUST-MODEL-TRANSPORT- LAYER-PUBLICATION-PARALLEL-TO-DMARC-MESSAGE- AUTHENTICATION-PUBLICATION companion documenting the DNSSEC-anchored TLSA- record publication at _25._tcp.<mx-host> owner-name that operates as the DNSSEC- trust-model alternative to the X.509-PKI- trust-model MTA-STS publication a publisher already pairs alongside the DMARC TXT-record publication THIS page documents. Documents FOUR complementary- publication dimensions (the DANE TLSA record at _25._tcp.mx1.example.com provides per-MX cryptographic-identity- binding evidence the sending MTA validates BEFORE STARTTLS handshake — sitting ALONGSIDE the DMARC TXT record at _dmarc.example.com at the SAME author-domain's DNS-zone publication scope, providing the transport-layer identity-binding companion to the application-layer message-authentication identity-binding the DMARC record publishes; the DANE TLSA publication prerequisite is DNSSEC-signing of the author-domain DNS zone — the publisher MUST first publish DS records at the registrar and configure DNSSEC-signing infrastructure BEFORE TLSA records carry any cryptographic weight, structurally parallel to the DMARC publication prerequisite of operationally-correct SPF and DKIM records that produce reliable per-message DMARC alignment outcomes; the DANE TLSA-record per-MX-host publication granularity differs from the MTA-STS policy-file per-author-domain publication granularity — DANE publishes a separate TLSA record at each per-MX owner-name allowing per-MX cert-pinning granularity, while MTA-STS publishes a single policy file per author-domain listing all valid MX-pattern entries with shared X.509-PKI-CA-trust validation — the publisher choosing between DANE and MTA-STS as the transport-layer complement to DMARC must reconcile per-MX cert-pinning granularity needs against per-author-domain policy-file simplicity; the DANE TLSA-record published at the author-domain's DNS zone is observable via per-day TLS-RPT JSON aggregate reports the receiver-side validating- MTAs publish back to the _smtp._tls.example.com owner-name's rua=mailto:tls-rua@example.com endpoint — the per-day TLSA-validation- failure stream is structurally parallel to the per-day DMARC aggregate-report RUA stream THIS page's rua= tag publishes for application-layer DMARC-evaluation observability). Read the DANE explainer spoke when authoring a publisher-side DMARC-publication playbook that intends to publish a transport-layer-security record alongside the DMARC record — the DANE spoke documents the DNSSEC-trust-model choice that operates alongside the DMARC TXT-record publication THIS page documents.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). The DMARC aggregate-report equivalent for transport-encryption failures.
• TLS-RPT record syntax — the BYTE-LEVEL DNS-RECORD SYNTAX PARALLEL the TLS-RPT publisher-side record sits in alongside the DMARC publisher-side record this page documents. Where THIS page documents the byte-level DMARC tag-by-tag grammar (v=DMARC1; p= / sp= / np= policy tags, adkim= / aspf= alignment-mode tags, pct= sampling tag, fo= failure- reporting-option tag, rua= aggregate- report-URI tag, ruf= failure- report-URI tag, ri= reporting-interval tag, rf= reporting-format tag), the TLS-RPT record-syntax spoke documents the byte-level TLS-RPT tag-grammar published at the cross-protocol-parallel _smtp._tls.<domain>. IN TXT "v=TLSRPTv1; rua=mailto:..." owner-name location. The two records share DEEP structural parallels in DNS- record-grammar conventions: both use the v=<PROTOCOL>v1; <TAG>=<VALUE>[; ...] tag-grammar shape (DMARC: v=DMARC1; TLS-RPT: v=TLSRPTv1), both require the v= version tag in first position (RFC 7489 §6.4 for DMARC, RFC 8460 §3.2 for TLS-RPT), both share the rua= report-aggregation tag name with comma-separated URI-list semantics, both share the mailto: URI scheme for SMTP report delivery, and both require external-domain authorisation when the report-receiving domain differs from the publishing domain (DMARC's _report._dmarc. delegation record; TLS-RPT's equivalent v=TLSRPTv1; rua=mailto:... reciprocal- publication). Read this spoke when deploying the DMARC publisher-side record per THIS page and you need the parallel TLS-RPT publisher- side record for the transport-layer reporting stream — the byte-level grammar conventions are structurally similar enough that operators routinely co-publish the two records as part of a single DNS-record deployment workflow.
• Reverse DNS / PTR records for mail servers — the IN-ADDR.ARPA / IP6.ARPA reverse-zone DNS-record class operator must publish alongside this DMARC TXT-record — the REVERSE-ZONE DNS-INFRASTRUCTURE sibling completing the DNS-record-class coverage for the operator's mail-sending domain. Where THIS page documents the byte-level DMARC tag-by-tag grammar at the forward-zone _dmarc.<domain> IN TXT "v=DMARC1; p=…" owner-name (policy publication for the alignment-enforcement layer), the reverse-dns-ptr spoke documents the RFC 1033 / RFC 1035 PTR-record syntax for the reverse-zone 1.2.3.4.in-addr.arpa IN PTR mail.example.com. publication (IP-to-hostname resolution for the connecting mail-sending IPs). The two records sit at DIFFERENT DNS classes (DMARC at forward-zone TXT under the special _dmarc. sub-owner-name, PTR at reverse-zone PTR under the in-addr.arpa / ip6.arpa delegation) but form the OPERATOR-COMPLETE DNS-DEPLOYMENT PAIR for a domain's mail-authentication posture: the DMARC record documented on this page DECLARES the alignment-enforcement policy receivers apply to SPF + DKIM verdicts; the PTR record documented on the sibling spoke announces the IP-to-hostname binding the receiver-side FCrDNS check validates BEFORE the DMARC evaluation even runs. The aggregate-report stream the rua= tag on this page configures contains source_ip rows that operators OPERATIONALLY MUST cross-reference against PTR lookups to understand "which sender is this IP" — the aggregate-report XML schema does NOT include the PTR hostname; the operator's analysis workflow performs the PTR lookup per the reverse-dns-ptr spoke's procedure to enrich the source_ip into a human- readable sender identifier. Read the reverse-dns-ptr spoke when scoping the DMARC deployment documented on this page — every IP that will be enumerated in the operator's SPF record and that will sign with the operator's DKIM keys MUST also have a matching PTR record so the receiver-side FCrDNS, IP-reputation, and aggregate-report-analysis layers see the infrastructure as a coherent unit rather than an anonymous IP.
• CAA records explained — Certification Authority Authorization (RFC 8659). DNS-level certificate-issuance control; complements DMARC's message-authentication control.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the DMARC-RECORD-aspf-TAG-EVALUATION- DEPENDS-ON-SUCCESSFUL-SPF-EVALUATION companion to this DMARC tag-by-tag reference. Where THIS page documents the DMARC TXT record at _dmarc.< domain> and the per-tag grammar (v=DMARC1, p=, sp=, pct=, rua=, ruf=, adkim=, aspf=, fo=, rf=, ri=) and the receiver-side evaluation contract, the SPF-lookup-limit spoke is the PER-RECEIVER-SPF-EVALUATION- BUDGET REFERENCE documenting the RFC 7208 §4.6.4 enforcement contract that MUST complete WITHOUT `permerror` for the aspf= tag this page documents to produce a meaningful receiver-side verdict. The DMARC-aspf-TAG-VS-SPF-LOOKUP- LIMIT cross-reference establishes FOUR structurally-distinct DMARC-tag-evaluation dependencies on the SPF-budget enforcement contract: (i) the aspf=r relaxed-mode default tag this page documents only meaningfully evaluates when the receiver-side SPF evaluation terminates in spf=pass — RFC 7489 §4 explicitly requires the receiver to evaluate SPF FIRST, and if the operator's SPF record breaches the §4.6.4 10-budget the entire aspf= alignment-mode evaluation is short-circuited because the receiver has nothing to align AGAINST; the SPF-lookup-limit spoke documents the per-receiver §11.1.1 `permerror` enforcement timeline and the per-mechanism cost accounting operators apply at SPF-record publication to ensure the aspf= tag this page documents can produce a meaningful verdict; (ii) the aspf=s strict-mode opt-in tag has the SAME prerequisite — a passing SPF evaluation that the receiver can align against the header.From organisational-domain; an SPF- record budget breach cascades into spf=permerror which produces DMARC-fail under BOTH aspf=r and aspf=s modes (the strict mode does not somehow REPAIR the broken SPF evaluation; it merely tightens the alignment criterion AFTER SPF passes); (iii) the pct= percentage-applicability sampling tag this page documents only meaningfully samples when the underlying SPF / DKIM evaluation produces a meaningful pass-or-fail verdict; a sustained spf=permerror rate from a breached SPF budget short-circuits the per-receiver-interval sampling AND cascades into the fo= failure- reporting trigger this page documents (fo=0 default reports DMARC-fail only when both SPF AND DKIM fail; an SPF-permerror counted as SPF- fail combined with a single misconfigured-DKIM signature drives the forensic-stream into a flood that masks legitimate-flow regression detection); (iv) the rua= aggregate-report endpoint this page documents is the canonical operator-side observability channel through which the operator detects an SPF-record budget breach — sustained spf=permerror rows surface in the daily aggregate-report XML stream receivers emit per rua= endpoint subscription; the SPF- lookup-limit spoke documents the per- receiver-interval observability pattern operators apply (cross-reference spf=permerror rows against per-ESP-vendor source-IP attribution to localise which include-cascade sub-record breached the 10-budget) — and the rua= tag this page documents is the operator-side primary detection instrument. Pair this page (the DMARC tag-by-tag publication reference) with the SPF-lookup-limit spoke (the per- receiver SPF-evaluation enforcement- contract reference) when authoring the complete deployment posture — the spoke documents the per-receiver §11.1.1 `permerror` enforcement timeline and the per-mechanism budget-accounting matrix operators MUST satisfy at SPF-record publication to ensure the aspf= / pct= / fo= / rua= tag evaluation this page documents produces meaningful receiver-side enforcement verdicts AND meaningful operator-side observability against the deployed posture.
• SPF PermError vs TempError diagnostic deep dive — the AUTH-RESULT-ENUM- DEFEATS-DMARC-ALIGNMENT companion reference. Where THIS page documents the DMARC _dmarc.<domain> TXT-record byte-syntax with the aspf= alignment-mode tag (relaxed default vs strict opt-in) that determines which domain-relation between the SPF- validating MAIL FROM RFC5321 envelope and the header.From RFC5322 author domain DMARC accepts as aligned, the SPF-PermError-vs-TempError spoke is the authoritative reference for the SEVEN-VALUE auth-result enum that DMARC's per-message alignment evaluation consumes — RFC 7489 §6.6.3 prescribes the receiver evaluating a DMARC record looks up the SPF auth_result and the DKIM auth_result (each one of none, neutral, pass, fail, softfail, temperror, permerror per RFC 7208 §2.6), then applies the disjunction-rule (SPF-aligned-pass OR DKIM-aligned-pass) and the publisher-prescribed p= policy. BOTH TempError AND PermError DEFEAT DMARC alignment by structural construction — alignment requires an authoritative pass result, and neither error mode produces one. The two error modes diverge sharply in operator response posture: TempError is transient (intermittent resolver failure / SERVFAIL / DNS-timeout — retry-with-backoff is the receiver-side response per RFC 7208 §5, no operator action required if the rate stays low), while PermError is permanent (publisher's SPF record has structurally-broken syntax / exceeded 10-DNS-lookup- cap / multiple SPF records on same domain — receiver-side response is immediate-permanent-fail-non-retry, operator action required immediately). The seven canonical PermError causes (record-not-found, syntax-error, multiple-records, too-many-lookups, void-lookup-cap, recursive-include, deprecated-mechanism) and the three canonical TempError causes (DNS resolver timeout, SERVFAIL upstream, transient network unreachable) are each catalogued in the spoke with per-symptom decision matrix and cause-specific resolution playbook. Operators reading their DMARC record contract on THIS page need to read the PermError-vs-TempError spoke alongside to understand WHEN the publisher's SPF will surface as the error-mode column of aggregate- report auth_results (and therefore DEFEAT the DMARC alignment-check this page's aspf= tag configures) vs WHEN it will produce an authoritative pass/fail the alignment-check can act on. Read the PermError-vs-TempError spoke alongside this page when authoring the DMARC publication runbook for any publisher with include:-heavy SPF chains (M365 + SendGrid + Mailgun + Marketo + Salesforce frequently exceeds the 10-lookup cap), publishers undergoing MX-record migrations (the mx mechanism expands into the lookup chain), or publishers diagnosing unexplained DMARC-alignment-fail bursts in the aggregate-report feed — the PermError-vs-TempError spoke is the canonical resource for converting an auth_result-column symptom into a specific cause-class and resolution.
• DMARC forensic / failure reports — the per-publisher ruf-tag-publication as per-message AFRF forensic-evidence- capture primitive complement to the rua- tag aggregate-evidence publication this DMARC-record byte-syntax reference documents. Where THIS page documents the byte-grammar of the per-publisher _dmarc.<domain> TXT- record's complete per-tag inventory (the canonical v=DMARC1 version anchor + p= policy + pct= percentage-ramp + sp= subdomain-policy + np= non-existent-subdomain- policy + adkim= + aspf= alignment-modes + rua= aggregate-mailbox + ruf= forensic-mailbox + fo= failure-options + rf= report-format + ri= report-interval), the forensic-reports spoke documents the structurally-distinct PER-MESSAGE AFRF (Abuse Feedback Report Format, RFC 6591) forensic-evidence-capture publication-discipline downstream consumer of the ruf= + fo= + rf= per-tag subset this page documents. Four PER-TAG-TO-AFRF-CAPTURE coupling dimensions the forensic-reports spoke documents that THIS page's per-tag byte-syntax catalogue is the upstream publisher-side input for: (i) ruf=mailto:<mailbox> per-publisher publication discipline as the per-message AFRF delivery endpoint — every per-receiver AFRF forensic-evidence emission traverses the per-publisher ruf= mailbox the per-tag byte-syntax this page documents publishes; (ii) fo=0|1|d|s per-publisher failure-options publication discipline as the per-receiver AFRF trigger criterion — the per- publisher per-failure-options token choice (fo=0 AFRF on complete-alignment-fail only, fo=1 AFRF on any underlying-mechanism fail, fo=d AFRF on DKIM-fail only, fo=s AFRF on SPF-fail only) directly determines the per-receiver AFRF emission criterion; (iii) rf=afrf|iodef per- publisher report-format publication discipline as the per-receiver AFRF byte-format selector — the canonical rf=afrf default produces RFC 6591-format MIME-multipart AFRF reports; (iv) per- publisher receiver-implementation- coverage matrix as the load-bearing constraint on per-publisher ruf-stream completeness — Google / Microsoft / Yahoo each emit AFRF forensic-evidence with DIFFERENT per- receiver implementation choices, producing per-publisher ruf-stream gaps the forensic-reports spoke catalogues as the canonical per-publisher per- receiver coverage-completeness reference. Read the forensic-reports spoke alongside this DMARC-record byte-syntax reference whenever authoring the per-publisher ruf= + fo= + rf= per-tag subset — the per-publisher per-tag byte-syntax choice this page documents is the load-bearing per-publisher publication- decision the forensic-reports spoke's per-message AFRF-evidence-capture pipeline downstream-consumes for every per-receiver AFRF emission that materialises into the per-publisher ruf-mailbox.
• DNS Record Generator — interactive wizard for building DMARC, SPF, DKIM, BIMI, MTA-STS, CAA, and TLS-RPT records with per-tag syntax validation.
• MTA-STS for Microsoft 365 — the DMARC-PILLAR-LAYERED-WITH- TRANSPORT-ENCRYPTION-AT-M365- EXCHANGE-ONLINE-EOP-RECEIVE- BOUNDARY-FOR-DEFENSE-IN-DEPTH companion reference. Where THIS page documents the DMARC _dmarc.<domain> TXT-record byte-syntax and per-tag semantics (v=DMARC1, p=, sp=, np=, pct=, rua=, ruf=, aspf=, adkim=, fo=, rf=, ri=), the MTA-STS-for-Microsoft-365 spoke documents the M365-tenant-specific MTA-STS publication step (policy file hosted at https://mta-sts.<domain>/.well-known/mta-sts.txt with version: STSv1 + mode: enforce|testing|none + mx: allow-list + max_age:, plus the _mta-sts.<domain> TXT-record with v=STSv1 + id=) that COMPLEMENTS the DMARC record this page documents. DMARC and MTA-STS operate on ORTHOGONAL layers of the email stack — DMARC enforces message-layer identity-alignment (header.from must align with SPF or DKIM-authenticated d=), MTA-STS enforces SMTP transport- layer TLS-policy compliance (sending MTA refuses to deliver over non-TLS or non-policy-compliant TLS) — and a complete defense-in-depth posture on the M365 topology publishes BOTH records alongside each other to protect against orthogonal attacker surfaces. Read the M365 MTA-STS spoke alongside this page when authoring the email-security DNS-record inventory for a domain whose primary mail egress and ingress is M365 Exchange Online — the DMARC record described here is one of the records the deployment publishes; the M365 MTA-STS publication is the transport-layer companion.
• DMARC for Microsoft 365 hybrid Exchange — the HYBRID-EXCHANGE-PER-TOPOLOGY-DMARC-TAG-AUTHORING-COMPANION spoke to this DMARC-records-explained canonical tag-syntax reference. Where THIS page documents the byte-level syntax and per-tag semantics of the _dmarc.<domain> TXT-record (v=DMARC1, p=, sp=, np=, pct=, rua=, ruf=, aspf=, adkim=, fo=, rf=, ri=), the hybrid-Exchange deployment spoke documents how each of those tags interacts with the canonical Microsoft enterprise topology spectrum the page enumerates: how p= ramps through the four-phase rollout sequence (p=none → p=quarantine 10% → p=quarantine 100% → p=reject) gated on the per-topology dual-source-alignment-pass- rate plateau; how sp= + np= govern subdomain policy when the hybrid topology sends from a mix of <tenant>.onmicrosoft.com cloud-only signatures and on-prem-Exchange signatures with custom subdomains; how aspf= + adkim= relaxed-vs-strict choices determine whether a Classic Hybrid on-prem-outbound message with d=<onprem-subdomain> aligns to a header-From at the org-domain level via the PSL boundary, and whether Centralized-Mail-Transport messages signed by selector1.<tenant>._domainkey / selector2.<tenant>._domainkey align under strict-mode; how fo= controls per-failure-mode forensic reporting capture rates required to diagnose hybrid-topology-specific Default-Frontend-Connector DKIM-strip failures; how rua= + ruf= destinations must aggregate evidence from BOTH the on-prem-Exchange-side (40.92.0.0/15 / Edge Transport IPs) and the cloud-side (40.107.0.0/16, 52.100.0.0/14) sender cohorts. The hybrid-Exchange spoke is the canonical operational reference for the per-tag-value decisions an operator must make when authoring a DMARC record for a domain whose outbound mail traverses any of the five hybrid-Exchange topologies, plus the SEND-CONNECTOR / DEFAULT-FRONTEND-CONNECTOR / ANONYMOUS-SMTP-RELAY-THROUGH-ON-PREM / ARC-SEALING-THE-ON-PREM-TO-CLOUD-RELAY configuration patterns that determine which per-message DMARC verdict the RUA stream will report at each topology boundary. Read the hybrid-Exchange spoke alongside this page when authoring a new _dmarc.<domain> record for a domain that uses Microsoft 365 with on-prem Exchange coexistence, or when revising an existing DMARC record to advance from p=none baseline toward p=reject enforcement across a hybrid topology — the per-tag syntax documented here is the same in provider-agnostic and hybrid-Exchange contexts, but the OPERATIONAL consequences of each tag-value choice are topology-determined in hybrid Exchange, and the hybrid spoke is the canonical reference for which tag-values are compatible with which mail-flow path.
• DMARC aggregate (RUA) reports — the DMARC-RECORD-RUA-TAG-PUBLICATION- AS-RECEIVER-FACING-EVIDENCE-EMISSION- DESTINATION-AT-FOUR-PER-RUA-TAG- EVIDENCE-CONSUMPTION-DIMENSIONS companion to this tag-by-tag DMARC TXT record publisher reference. Where THIS page documents the tag-by-tag DMARC TXT record byte-syntax (the v=DMARC1 version-tag, the p= / sp= policy-mode tags, the rua=mailto: / ruf=mailto: reporting- endpoint tags, the pct= ramp-percentage tag, the adkim= / aspf= alignment-mode tags, the fo= failure-reporting- options tag, the ri= reporting-interval tag, the rf= failure- report-format tag) operators publish at the _dmarc.<domain> owner name, the aggregate-reports spoke is the RECEIVER-EMITTED-EVIDENCE- DATA-MODEL companion documenting the per-receiver per-day XML aggregate- report byte-shape the rua=mailto: tag publisher consumes. Concretely, the spoke documents FOUR per-RUA-tag evidence- consumption dimensions: (i) rua=mailto: external-destination DNS-authorisation- record contract — when the publisher publishes rua=mailto:<recipient>@<recipient-domain> where <recipient-domain> differs from the protected <domain>, the aggregate-reports spoke documents the RFC 7489 §7.1 external-destination authorisation-record requirement at <domain>._report._dmarc.<recipient-domain> as the precondition for the receiver to honour the cross-domain delivery target — without which the per-receiver per-day RUA emission silently drops and the per-tag publication discipline THIS page documents produces ZERO evidence at the publisher; (ii) RUA XML root <feedback> element + <report_metadata> per-receiver per-report attribution envelope — the aggregate- reports spoke documents the per-RUA envelope structure (<feedback> ><report_metadata> + <org_name> + <email> + <report_id> + <date_range> ><begin>/<end> POSIX-epoch UTC timestamps) the publisher uses to attribute each received RUA to a specific receiver + time-window pair — providing the per-reporter coverage map THIS page's per-tag publication discipline aims to maximise; (iii) per-row <policy_evaluated> + <auth_results> per-source-IP per-disposition evidence — the aggregate- reports spoke documents the per-row XML structure (<row> ><source_ip> + <count> + <policy_evaluated> ><disposition>/<dkim>/<spf> + <identifiers> ><header_from> + <auth_results> ><dkim> ><domain>/<result>/<selector> and <auth_results> ><spf> ><domain>/<result>) whose per-row verdict stream is the load-bearing evidence the p= / sp= / pct= / adkim= / aspf= tag-value-selection decisions THIS page documents must consume to ramp safely from p=none through p=quarantine to p=reject; (iv) per-RUA <policy_published> echo-back of the per-tag byte-publication evidence the receiver re-emits — the aggregate-reports spoke documents how every receiver echoes back its observed <policy_published> ><p>/<sp>/<pct>/<adkim>/<aspf>/<fo> tag-value snapshot at report- generation time within the RUA envelope itself — providing the publisher with per-receiver byte-level confirmation that the per-tag publication discipline THIS page documents propagated to the receiver's authoritative resolver cache (the per-receiver per-resolver- TTL-window publication-verification primitive every per-tag-change operator-discipline cycle this page prescribes depends on). Read the aggregate-reports spoke AFTER consulting THIS tag-by-tag DMARC TXT record reference to close the feedback loop between the publisher-side per-tag byte-publication discipline and the receiver-side per-row per-day evidence stream the rua=mailto: tag publication produces.
• SPF for Google Workspace — the WORKSPACE-TENANT-SPF-PUBLICATION- AS-LOAD-BEARING-EXECUTION-LAYER- INSTANTIATION-OF-EVERY-DMARC-TXT- RECORD-TAG-CATALOGUED-HERE companion to this tag-by-tag DMARC TXT record reference. Where THIS page documents the RFC 7489 §6.3 + §6.4 + RFC 9091 DMARC TXT record tag catalogue (the v=DMARC1 version-tag, the p= policy-tag-tree, the sp= subdomain-policy-tag, the aspf= / adkim= alignment-mode- tags, the pct= sampling- tag, the rua= / ruf= mailbox-list-tags, the fo= forensic-options- tag, the np= non-existent- domain-policy-tag), the SPF-for-Google- Workspace spoke is the EXECUTION-LAYER DEPLOYMENT-REFERENCE documenting how the per-tenant SPF publication produces the message-layer SPF input every per- tag evaluation depends on at FOUR per- Workspace-tenant-SPF-publication-to- DMARC-tag-evaluation-coupling dimensions: (i) per-tenant include:_spf.google.com cascade publication is the per-source- IP SPF evaluation primitive whose Pass / Fail verdict feeds the aspf=<mode> SPF- alignment match-mode evaluator THIS page's aspf= tag section catalogues — the SPF-for-Workspace spoke documents the per-tenant include-cascade publication discipline whose per-source-IP SPF result is the load-bearing message-layer authentication-input the aspf=r relaxed-match vs aspf=s strict-match SPF-alignment evaluator THIS page documents authenticates the Header-From against; (ii) per-tenant SPF coverage completeness determines whether p=reject publication is safe to roll out for a Workspace-tenant — the SPF-for-Workspace spoke documents the per-tenant SPF-publication sufficiency-audit (third-party-sender cascade completeness, per-tenant outbound- gateway IP-list coverage, per- tenant per-subdomain SPF publication) whose insufficiency is the load-bearing root cause of p=quarantine / p=reject publication regression THIS page's p= tag-section warns against — the p=-tag-value choice is only safe when the per-tenant SPF publication-coverage the SPF-for-Workspace spoke prescribes is verified; (iii) per-tenant per-subdomain SPF publication interacts with the sp= subdomain- policy-tag THIS page catalogues — the SPF-for-Workspace spoke documents the per-tenant per- subdomain SPF publication discipline (per-Workspace-tenant subdomain _spf.<subdomain> publication, per-subdomain outbound-gateway delegation, per-subdomain third-party-sender cascade extension) whose per- subdomain SPF coverage is the load-bearing input the sp=-tag per-subdomain DMARC enforcement evaluator THIS page documents consumes when determining the per-subdomain DMARC verdict; (iv) per-tenant rua=mailto: / ruf=mailto: ingestion endpoint observes per-source-IP SPF- Pass-rate divergence the SPF-for-Workspace publication-discipline produces — the SPF- for-Workspace spoke documents how the per-tenant Workspace outbound mail-flow (per-tenant smarthost, per-tenant third- party-sender cascade) drives the per-source-IP SPF-Pass- rate distribution the rua=-tag aggregate-XML stream THIS page catalogues surfaces to the operator — closing the feedback loop between the SPF-for-Workspace spoke's per-tenant publication discipline and the rua=- tag receiver-side evidence the publisher reads. Read the SPF-for- Workspace spoke ALONGSIDE this tag-by-tag DMARC TXT record reference when authoring or auditing a Workspace-tenant DMARC publication — the spoke documents the per-tenant SPF publication discipline whose per-source-IP SPF verdict is the load-bearing message-layer authentication- input every DMARC tag-evaluation outcome THIS page catalogues consumes on the Google Workspace cloud-only deployment architecture.
• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM, MTA-STS, TLS-RPT, CAA, BIMI, and DNSSEC against any domain.
• DMARC troubleshooting — the SYMPTOM-DRIVEN TAG-MISCONFIGURATION- DIAGNOSIS companion to THIS tag-by-tag DMARC TXT record reference. Where THIS page documents the RFC 7489 §6.3 + §6.4 + RFC 9091 DMARC TXT record tag catalogue (the v=DMARC1 version-tag, p= policy-tag-tree, sp= subdomain-policy-tag, pct= sampling-tag, rua= aggregate-mailbox-list, ruf= forensic-mailbox-list, fo= failure-options-tag, adkim= + aspf= alignment-mode tags, ri= report-interval-tag, rf= report-format-tag, np= non- existent-domain-policy-tag) as the SYNTAX REFERENCE, the troubleshooting spoke documents the SYMPTOM-DRIVEN debugging playbook whose per-symptom root-cause attribution traces back to the per-tag mis-publication root cause this page's catalogue defines. Four TAG-CATALOGUE-VS- TROUBLESHOOTING-PLAYBOOK axes the troubleshooting spoke documents that THIS page is the syntax reference for: (1) p= mis-publication diagnosis — the troubleshooting spoke's "unexpected receiver-side quarantine / reject of legitimate messages" symptom- catalogue traces the per-message receiver- side disposition back to the p=quarantine / p=reject published-tag state this page documents the canonical syntax of (per RFC 7489 §6.3); (2) rua= mailbox-publication diagnosis — the troubleshooting spoke's "no aggregate reports arriving" symptom traces the rua=mailto: published-tag state through the rua- destination domain's MX RR + external-domain- verification TXT prerequisites back to the per-receiver rua-delivery decision (this page's rua= tag documentation IS the canonical syntax reference for the published-tag the symptom diagnostic depends on); (3) sp=-tag subdomain-coverage diagnosis — the troubleshooting spoke's "subdomain unexpectedly enforced" symptom traces the per-message header.From=<sub.tenant.com> AGAINST the organisational-domain p= + sp= inheritance rule this page documents at the tag level; (4) adkim= + aspf= alignment-mode diagnosis — the troubleshooting spoke's "DMARC = fail despite SPF / DKIM = pass" symptom traces the per-message alignment evaluation AGAINST the adkim=r/adkim=s + aspf=r/aspf=s published-tag-mode this page's alignment- mode tag catalogue defines the syntax of. Read THIS page when AUTHORING or AUDITING a DMARC TXT record; read the troubleshooting spoke when DIAGNOSING the rua-stream evidence that the published tags produce at the receiver-side.
• DMARC for Google Workspace — the WORKSPACE-TENANT-DMARC-RECORD- PUBLICATION-INSTANTIATION companion to this DMARC-record-tag byte-grammar reference. Where THIS page documents the per-tag DMARC TXT-record byte- grammar (per RFC 7489 §6.3 the v=DMARC1 identifier, p= / sp= / pct= enforcement-stage commitment, adkim= / aspf= alignment-mode commitment, rua= / ruf= report-destination commitment, fo= / rf= / ri= report-tuning commitment), the Workspace-deployment spoke is the WORKSPACE-TENANT DMARC-RECORD- PUBLICATION-COORDINATION REFERENCE documenting how each per-tag byte- grammar primitive THIS page documents instantiates concretely on a Google Workspace tenant. Concretely the spoke documents FOUR per-Workspace- tenant-configuration-vs-DMARC-record- tag-coordination dimensions: (i) per-Workspace-tenant _dmarc.<org-domain> TXT-RR v=DMARC1; p=<mode>; adkim=<mode>; aspf=<mode>; sp=<mode> publication runs against the per-tenant Admin Console DNS publication workflow — the Workspace-deployment spoke documents the per-Workspace-tenant DMARC TXT-RR publication-discipline contract every Workspace operator must apply at the per-tenant organisational-domain authoritative DNS zone (Workspace publishes against the operator-controlled DNS rather than a Workspace-managed sub-delegation); (ii) per- Workspace-tenant adkim=s-strict-mode publication discipline coordinates against the per-tenant google._domainkey.<org-domain> DKIM TXT-RR direct-publication — the Workspace-deployment spoke documents the per-tenant alignment- mode coordination contract every Workspace operator must apply: the adkim=s-strict-mode publication this page documents at the DMARC-record byte-grammar tier only works when the per-Workspace- tenant google._domainkey.<org-domain> DKIM TXT-RR is published DIRECTLY (no CNAME-delegation chase) so the per-message d=<org-domain> tag binding matches FQDN-literal- equality with the Friendly-From- header organisational domain; (iii) per-Workspace-tenant aspf=s-strict-mode publication discipline coordinates against the per-tenant _spf.google.com include- cascade publication — the Workspace-deployment spoke documents the per-tenant SPF-leg-alignment coordination contract every Workspace operator must apply because the per-tenant SPF chain publishes include:_spf.google.com producing spf=pass against an envelope-MAIL-FROM that rewrites to Workspace-internal envelope domains under forwarding — the aspf=s-strict- mode publication this page documents only succeeds when the Workspace- tenant envelope-MAIL-FROM remains organisationally-aligned with the Friendly-From-header organisational domain; and (iv) per- Workspace-tenant rua=mailto:<aggregate- report-destination> publication coordinates against third-party aggregate-report- ingestion endpoint authoring — the Workspace-deployment spoke documents the per-tenant rua=-tag publication discipline every Workspace operator must apply because per-tenant cross-domain authorisation TXT-RR at <org-domain>._report._dmarc.<recipient-domain> per RFC 7489 §7.1 must be published on the third-party aggregate-report- ingestion domain BEFORE receivers emit per-day RUA streams. Read the Workspace-deployment spoke ALONGSIDE this DMARC-record-tag byte-grammar reference when authoring or auditing a Workspace-tenant DMARC TXT-RR publication — the spoke documents how each per-tag byte-grammar primitive THIS page establishes instantiates concretely on the Google Workspace cloud-only deployment architecture.
• MTA-STS vs DANE comparison — the MTA-STS-VS-DANE-CHOICE-OF- TRANSPORT-LAYER-TLS-ENFORCEMENT- DISCIPLINE-AS-LOAD-BEARING-TRANSPORT- LAYER-PUBLICATION-CHOICE-PARALLEL-TO- DMARC-RECORD-TAG-PUBLICATION-CHOICE companion to THIS tag-by-tag DMARC TXT-record reference. Where THIS page documents the RFC 7489 §6.3 + §6.4 + RFC 9091 DMARC TXT-record per-tag publication discipline (the v=DMARC1, p=, sp=, pct=, aspf= / adkim=, rua= / ruf=, fo=, np= per-tag choices the publisher makes per organisational-domain), the MTA-STS-vs-DANE spoke is the TRANSPORT-LAYER-TLS-ENFORCEMENT- PUBLICATION-CHOICE REFERENCE documenting the parallel per-domain per-publisher choice-of-discipline between RFC 8461 MTA-STS (HTTPS-policy-host mta-sts.<domain> publication + _mta-sts TXT-record discovery) and RFC 7672 DANE-for-SMTP (DNSSEC-anchored _25._tcp.<mx> TLSA-RR publication) at FOUR cross-layer per-publisher-publication- choice-coupling dimensions: (i) per-publisher per-domain publication-discipline-CHOICE: DMARC publishes only ONE per-domain v=DMARC1 TXT-record per organisational-domain, but the MTA-STS-vs-DANE choice forces the publisher to pick HTTPS-policy-host publication vs DNSSEC-anchored TLSA-RR publication (or both) per organisational-domain — both the DMARC per-tag-value publication choice and the MTA-STS- vs-DANE per-domain transport-layer- TLS-publication choice are publisher- side per-domain operational decisions the publisher commits to via published DNS-records the receiver- side verifier consumes deterministically, and the MTA-STS-vs-DANE spoke documents the per-domain choice-of- publication-discipline whose cross- layer publication-decision parallels the DMARC per-tag-value publication decision THIS page documents; (ii) per-publisher per-domain DNSSEC-dependency CHOICE: DMARC publishes a non-DNSSEC-required TXT-record (DMARC has no DNSSEC tag), whereas DANE-for-SMTP REQUIRES DNSSEC-signed zones to bootstrap trust while MTA-STS uses HTTPS-CA trust without requiring DNSSEC — the MTA-STS-vs-DANE spoke documents the per-publisher DNSSEC-deployment- prerequisite differential (MTA-STS: HTTPS-CA trust, no DNSSEC required; DANE-for-SMTP: DNSSEC required for zone-level TLSA-RR cryptographic- anchoring) whose per-publisher deployment-prerequisite choice is the load-bearing transport-layer prerequisite parallel to the DMARC per-tag publication discipline (which itself has no DNSSEC prerequisite) THIS page documents; (iii) per-receiver per- publication evaluation-algorithm CHOICE: DMARC publishes per-tag- value enforcement (p=quarantine, p=reject) the receiver- side enforcement-evaluator applies per-message; MTA-STS-vs-DANE publishes per-domain transport-layer TLS-enforcement (MTA-STS mode:enforce via HTTPS-policy-host vs DANE TLSA-RR DANE-validates) the receiver-side SMTP-MTA applies per-SMTP- connection — the MTA-STS- vs-DANE spoke documents the per- receiver per-publication evaluation algorithm choice whose transport- layer per-SMTP-connection-evaluation is the cross-layer sibling to the DMARC per-message per-tag-value evaluation THIS page documents; (iv) per-publisher per-domain TLS-enforcement-COMPLEMENTS-DMARC: DMARC's p=reject message-layer enforcement is complemented by MTA-STS-or-DANE's transport-layer TLS-enforcement — together they close the per-domain message-layer + transport-layer publication-discipline stack — the MTA-STS-vs-DANE spoke documents the per-publisher per- domain transport-layer TLS- enforcement-publication choice whose deployment-discipline complements the DMARC per-tag publication-discipline THIS page documents — DMARC closes the message-layer Header-From spoofing-defense surface, MTA-STS- or-DANE closes the transport- layer in-flight TLS-stripping / DNS-MX-redirection defense surface. Read the MTA-STS-vs-DANE spoke ALONGSIDE this DMARC TXT- record reference when authoring the per-domain cross-layer publication-discipline stack — the spoke documents the transport- layer TLS-enforcement-publication choice whose cross-layer publication-decision parallels the DMARC per-tag publication- decision THIS page documents.
• Email authentication glossary — the DMARC-RECORD-TAG-CATALOGUE- AS-LOAD-BEARING-CONSUMER-AND- PRODUCER-OF-CANONICAL-DEFINED-TERM- DEFINITIONS companion to this DMARC per-tag byte-syntax catalogue. Where THIS page documents the RFC 7489 §6.3 DMARC TXT-record per-tag byte-syntax catalogue (the v=DMARC1 first-position version tag, the per- tag grammar for p= / sp= / np= / adkim= / aspf= / pct= / fo= / rua= / ruf= / ri= / rf=, the per-tag value-list semantics, the per-tag publication-discipline rules), the email-authentication-glossary spoke documents the canonical DefinedTerm JSON-LD reference whose per-term entity-first definition-lede is the upstream-vocabulary substrate every per-tag byte-syntax slot on THIS page consumes at FOUR per-DMARC- record-tag-to-glossary-defined-term coupling dimensions: (i) per- DMARC-tag-value-grammar-as-load- bearing-consumer-of-canonical- defined-term-definition — every per-tag value-grammar slot THIS page documents (e.g., p=quarantine / p=reject policy-mode values, adkim=s / adkim=r alignment-mode values, pct=<0-100> sampling-rate values, fo=0 / fo=1 / fo=d / fo=s failure-reporting- option values) CONSUMES the canonical DefinedTerm definition the glossary spoke documents for the underlying protocol-concept the value-grammar slot enumerates — operator-side per-tag value-selection requires prior canonical-definition fluency in the underlying protocol-concept the value-grammar slot enumerates; (ii) per-DMARC-tag-organisational- domain-PSL-RFC-5321-vs-5322-alignment- vocabulary-as-load-bearing-consumer- of-canonical-defined-term-definition — the aspf= / adkim= per-tag alignment-evaluation grammar THIS page documents CONSUMES the canonical glossary-spoke definition of organisational domain (the Public Suffix List eTLD+1 derivation), RFC 5321 envelope-MAIL- FROM-domain identifier, RFC 5322 header-From-domain identifier, and identifier-alignment-mode-strict-vs- relaxed semantics — operator-side aspf= / adkim= per-tag value-selection requires prior canonical-definition fluency in the four-term identifier- alignment vocabulary the glossary spoke documents; (iii) per- DMARC-rua=-and-ruf=-aggregate-and- forensic-report-receiver-vocabulary- as-load-bearing-consumer-of- canonical-defined-term-definition — the rua=mailto: / ruf=mailto: / ri=<seconds> / rf=afrf per-tag reporting-stream grammar THIS page documents CONSUMES the canonical glossary-spoke definition of aggregate report, forensic report, Authentication-Failure Reporting Format, and reporting-interval semantics — operator-side reporting-stream per-tag value- selection requires prior canonical- definition fluency in the four-term reporting-vocabulary the glossary spoke documents; (iv) per- DMARC-record-publication-discipline- AI-retrieval-engine-citation- vocabulary-as-load-bearing-producer- of-canonical-defined-term-definition — every per-tag byte-syntax slot THIS page documents PRODUCES the per-term entity-first definition the glossary-spoke DefinedTermSet JSON-LD root cites as the canonical reference for AI- retrieval-engine citation (Perplexity / ChatGPT / Claude / Gemini / Google AI Overviews / Bing Copilot) — the bi-directional citation loop between THIS per-tag byte-syntax reference and the glossary-spoke DefinedTerm JSON-LD entries is the AI-retrieval-engine canonical- reference foundation the cluster relies on for per-term deep-link citability. Read the email-authentication-glossary spoke alongside THIS page when the operator asks "what is the canonical definition of the protocol-concept this per-tag byte-syntax slot enumerates" — the answer is FOUR-LAYERED: THIS page documents the per-tag byte-syntax catalogue, the email-authentication- glossary spoke documents the canonical DefinedTerm definition for every protocol-concept the per-tag byte-syntax catalogue enumerates.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the PER-PUBLISHER-DMARC-TXT- RECORD-BYTE-GRAMMAR-AS- STRUCTURAL-PARALLEL-TO-RFC-8460- §4-TLS-RPT-JSON-AGGREGATE- REPORT-BYTE-GRAMMAR companion to this DMARC-record-byte-syntax reference. Where THIS page documents the per-publisher _dmarc.<d-domain> TXT-record byte-grammar (the v=DMARC1 version- prefix, the p= policy-mode field, the rua= / ruf= reporting- mailbox URI fields, the pct= partial- coverage field, the adkim= / aspf= alignment- mode fields), the tls_rpt_ report_format spoke documents the structurally-parallel RFC 8460 §4 TLS-RPT JSON-aggregate report byte-schema (the organization-name report-emitter field, the date-range per-report time-bucket field, the contact-info operator-contact field, the report-id per-report identifier, the policies[] per-policy-document array, the summary per-policy success/failure- count fields, the failure-details[] per-failure-class catalogue) whose per-emitted-report byte- anatomy IS the structural twin of the per-published DMARC TXT- record byte-anatomy THIS page documents at the per-publisher- emitted-vs-per-receiver-emitted byte-format-locus boundary. FOUR structurally-distinct PER- PUBLISHED-RECORD-VS-PER-EMITTED- REPORT-BYTE-ANATOMY-COUPLING- DIMENSIONS the tls_rpt_report_ format spoke operationally documents: (i) per- publisher rua=mailto:<rua-mailbox> DMARC-aggregate-report emission-target field AS LOAD- BEARING-STRUCTURAL-TWIN-OF-PER- PUBLISHER rua=mailto:<tls-rpt-mailbox> TLS-RPT-aggregate-report- emission-target field at the per-publisher _smtp._tls.<d-domain> TLS-RPT discovery TXT-record publication — the DMARC TXT-record rua= field and the TLS-RPT TXT-record rua= field share the canonical RFC 7489 §6.2 + RFC 8460 §3 mailto-URI emission- target byte-grammar; both publisher-emitted fields signal a per-publisher receiver-side report-emission destination the receiver-side JSON-or-XML aggregate-report-emitter consumes; (ii) per- receiver-emitted DMARC aggregate-report <report_metadata> XML envelope AS LOAD-BEARING- STRUCTURAL-TWIN-OF-PER- RECEIVER-EMITTED TLS-RPT JSON organization-name + date-range + contact-info + report-id envelope-fields — the per-receiver per-publisher per- day report-envelope-metadata byte-anatomy is structurally the same across DMARC-XML and TLS-RPT-JSON aggregate-report formats; the tls_rpt_report_ format spoke documents the JSON envelope-field byte-anatomy whose structural-twin relationship to the DMARC-XML envelope-field byte-anatomy IS the canonical per-publisher- consumer report-ingestion parallelism THIS page's per- publisher reporting-mailbox- publication discipline depends on; (iii) per-receiver- emitted DMARC aggregate-report <record> per- source-IP-per-disposition row AS LOAD-BEARING-STRUCTURAL- TWIN-OF-PER-RECEIVER-EMITTED TLS-RPT JSON policies[].failure- details[] per-failure- class row — the per- row evidence-emission byte- anatomy parallels: DMARC per- row <source_ip> + <count> + <policy_evaluated> elements vs TLS-RPT per-row sending-mta-ip + total-failure-session- count + result-type fields are the per-source-IP- per-receiver-side-outcome evidence catalogue both formats emit at row-level granularity; (iv) per-publisher- emitted DMARC TXT-record p=none → p=quarantine → p=reject policy-mode- progression AS LOAD-BEARING- STRUCTURAL-PARALLEL-TO-PER- PUBLISHER-EMITTED MTA-STS mode: none → mode: testing → mode: enforce policy-mode-progression REPORTED-VIA-TLS-RPT-JSON- AGGREGATE-PER-POLICY-MODE summary-counts — the DMARC three-state policy progression THIS page documents is structurally paralleled by the MTA-STS three-state policy progression whose per-publisher per-mode receiver-side enforcement outcomes are catalogued in the TLS-RPT JSON- aggregate per-policy summary.total-successful- session-count + summary.total-failure- session-count field- pair the tls_rpt_report_format spoke documents at byte level. Read the tls_rpt_report_format spoke ALONGSIDE this DMARC- record byte-syntax reference whenever the publisher scopes a per-publisher per-aggregate- report-format byte-anatomy comparison plan — the RFC- 8460-§4-JSON-aggregate-report- format byte-schema THIS comparison spoke documents IS the canonical load-bearing per-receiver-emitted-aggregate- report byte-anatomy structurally paralleling the per-publisher-emitted-DMARC- TXT-record byte-anatomy THIS page documents at the per- publisher-vs-per-receiver byte-format-locus boundary.
• DKIM failures explained — the DKIM-VERDICT-FAILURE TAXONOMY companion to this DMARC-record per-tag byte-grammar reference. Where THIS page documents the per-tag publication discipline (v=DMARC1, p=, sp=, adkim=, aspf=, rua=, fo=, ri=) every publisher owes their _dmarc subdomain, the DKIM-failures-explained spoke documents the four-class DKIM verdict-failure taxonomy (bodyhash-mismatch, signature-mismatch, permerror, temperror) the receiver-side DMARC alignment evaluator consumes when applying THIS page's per-tag publisher commitment against the per-message DKIM verdict. Read THIS page when AUTHORING the per-tag DMARC TXT record publication discipline; read the DKIM-failures spoke when DIAGNOSING the per-message DKIM verdict that drives THIS page's p= enforcement-stage commitment.
• DMARC alignment evaluation — the per-publisher per-domain DMARC-record adkim= and aspf= tag publication-as- load-bearing receiver-side identifier- alignment-evaluation contract companion to this DMARC TXT-record per-tag byte-grammar reference. Where THIS page documents the publisher-side per-tag DMARC TXT-RR publication discipline at _dmarc.<d> (including the adkim=r relaxed-organisational-domain-mode default vs adkim=s strict-exact-match-mode opt-in for DKIM alignment and the parallel aspf=r vs aspf=s for SPF alignment per RFC 7489 §6.3), the DMARC-alignment spoke documents the receiver-side per- message identifier-alignment evaluator that consumes those publisher commitments and emits the per-receiver per-day per-message policy_ evaluated/dkim={pass,fail} + policy_evaluated/spf={pass,fail} attribution-row the RUA aggregate-report stream this page's rua= tag publication subscribes to. Read THIS page when AUTHORING the per-tag DMARC TXT-RR publication discipline including the alignment-mode tag-pair; read the DMARC-alignment spoke when DIAGNOSING per-receiver per-day per-message alignment-evaluation outcomes attributed against the per-publisher per-domain alignment-mode publication commitment THIS page's adkim= + aspf= tag-pair catalogue establishes. Four per-tag- publication-vs-receiver-alignment- evaluation coupling axes the alignment spoke documents: (i) per-publisher per-domain adkim= / aspf= tag-pair publication-discipline STRUCTURALLY GATES per-receiver per- message alignment-mode evaluation — the publisher's tag-pair choice IS the per-receiver evaluator's organisational-domain-vs-exact-match decision input; (ii) per- publisher per-domain alignment-mode mis-publication silently surfaces as a DKIM-failures-taxonomy classification rather than an alignment-tag root cause — the DKIM- failures-explained sibling spoke above documents the four-class verdict-failure taxonomy that consumes the alignment-mode commitment as input; alignment-mode mis-publication appears in the per- receiver per-day RUA stream as a bodyhash-mismatch / signature- mismatch symptom-class even though the root cause is the per-publisher per-domain alignment-tag publication; (iii) per-publisher per- domain alignment-mode authoring IS the prerequisite the per-publisher per-domain DMARC p= enforcement-mode ramp progression structurally depends on — per-publisher per-domain operators MUST baseline-monitor per- receiver per-day per-message alignment-evaluation outcomes BEFORE per-publisher per-domain Phase 3+ ramp authoring crosses the per- receiver dispositional-enforcement boundary; (iv) per-publisher per-domain alignment-mode publication choice (r vs s) IS load-bearing for per-publisher per-domain hosted-service sending- portfolio compatibility — per-publisher per-domain operators sending via per-tenant Workspace / M365 / ESP-platform tenants where the per-message DKIM- Signature d= identifier is a sub-domain of the organisational From: domain MUST publish adkim=r for DKIM-aligned-pass-rate to remain above the per-phase ramp-advancement floor across the per-tenant signing- infrastructure.
• DMARC for Microsoft 365 — the M365-TENANT-PER-ACCEPTED-DOMAIN- DMARC-TXT-PUBLICATION-EXECUTION- DISCIPLINE companion to this per- publisher per-domain DMARC TXT publication-discipline reference. Where THIS page documents the per-tag DMARC TXT-record authoring discipline (per-publisher v=DMARC1 version pinning, per-publisher p= enforcement-stage commitment, per-publisher sp= subdomain-policy publication, per-publisher pct= ramp discipline, per-publisher rua=mailto: + ruf=mailto: feedback- loop publication, per-publisher adkim= + aspf= alignment-mode authoring), the M365- deployment spoke is the PER-M365- TENANT EXECUTION-DISCIPLINE COMPANION documenting how each per-tag publication discipline instantiates concretely on Microsoft 365 at FOUR per-M365-tenant-per-accepted-domain- DMARC-TXT-publication-vs-per-publisher- per-domain-DMARC-protocol-record- publication-instantiation dimensions: (i) per-M365-tenant per- accepted-domain _dmarc.<domain> TXT publication is the per-publisher per-domain DMARC-publication-discipline instantiation — the M365- deployment spoke documents how the per-tenant per-accepted-domain authoritative DNS-zone _dmarc.<domain> TXT publication discipline is the per- tenant authoring surface for the per- publisher per-domain DMARC publication THIS page documents the per-tag authoring contract for; (ii) per-M365-tenant per- organisational-domain p= + sp= publication is the per-publisher per- domain enforcement-stage-and-subdomain- policy publication instantiation — the M365-deployment spoke documents how the per-tenant per-organisational- domain p=none → p=quarantine → p=reject ramp and the per-organisational-domain sp= subdomain-policy publication discipline THIS page documents instantiate concretely on Microsoft 365 at the per-tenant per- accepted-domain DMARC authoring tier; (iii) per-M365-tenant per- domain rua=mailto: publication for Exchange-Online- emitted aggregate reports is the per- publisher per-domain feedback-loop publication instantiation — the M365-deployment spoke documents how the per-tenant per-domain rua=mailto: publication discipline THIS page documents instantiates concretely as the per- tenant operator's RUA mailbox Exchange Online (as a receiver) emits aggregate reports to AND the per- tenant operator's RUA mailbox per- publisher Exchange Online (as a sender) consumes external-receiver aggregate reports from; and (iv) per-M365-tenant per-domain alignment-mode authoring (adkim= + aspf=) is the per- publisher per-domain alignment- evaluation publication instantiation — the M365-deployment spoke documents how the per-tenant per-domain strict- vs-relaxed alignment-mode authoring discipline THIS page documents instantiates concretely at the per- accepted-domain DMARC publication tier whose per-publisher commitment drives the per-message DMARC alignment- evaluation outcome receivers consume. Read the M365-deployment spoke ALONGSIDE this DMARC-records reference whenever the per-tenant M365 operator scopes the per-publisher per-domain DMARC TXT publication discipline — the per-tag DMARC TXT publication discipline THIS page documents is the per-publisher per-domain AUTHORING primitive; the per-M365-tenant per- accepted-domain DMARC publication is the per-tenant per-domain EXECUTION- SURFACE primitive that closes the per- publisher per-domain authoring-to- execution loop.
• DKIM replay attacks — the per-message AUTHENTICATED-REPLAY-AS- DMARC-PASS-ENFORCEMENT-BYPASS companion to this DMARC TXT record byte-grammar reference. Where THIS page documents the per-publisher per- domain DMARC TXT publication discipline (the p=reject / p=quarantine / p=none per-publisher enforcement- stage commitment + adkim= / aspf= per-publisher alignment-mode authoring + pct= per-publisher ramp-percentage selection) that drives the per- receiver per-message DMARC verdict, the DKIM- replay-attacks spoke documents the specific per-message attack class in which a sophisticated attacker captures a legitimately DKIM-signed message from a high-reputation per-publisher per-domain sender and re-broadcasts the byte- for-byte signed message to an attacker-chosen recipient set: because the DKIM signature still verifies and the original From: still aligns with the original d=, the per- message DMARC verdict is pass — DMARC applies NO protective enforcement even when this page's p=reject publication discipline is operationally committed. Three CROSS-LAYER-PUBLICATION- DISCIPLINE coupling dimensions the replay- attacks spoke documents the DMARC TXT publication reference does NOT cover at the per-publisher per-domain authoring tier: (i) RFC 7489 DMARC threat-model coverage boundary at the authenticated- replay vs unauthenticated-forgery attack- class boundary — RFC 7489 §2.4 and §11 explicitly scope DMARC to the per-message unauthenticated-forgery threat model (the attacker spoofs the From: but cannot DKIM- sign); the per-message authenticated-replay threat model (the attacker controls the envelope-recipient list but inherits the DKIM signature from a legitimate per-publisher signer) is OUTSIDE the DMARC threat model, and the per-tag DMARC TXT publication discipline THIS page documents provides NO per-publisher per-domain authoring lever to narrow the per-message authenticated-replay attack surface; (ii) per-publisher per-domain replay-window-bounding via DKIM key rotation as the per-publisher per-selector out-of-band defence at the DKIM-DNS-key- publication tier the DMARC TXT publication does NOT participate in — the per- publisher per-selector selector._domainkey.<d> TXT-RR rotation discipline (documented in help_dkim_key_rotation.php) bounds the per-publisher per-selector replay window to the per-selector active- key lifetime; the per-publisher per-domain DMARC TXT publication discipline THIS page documents at _dmarc.<d> provides NO equivalent per-publisher per- domain replay-window-bounding lever and the per-publisher per-domain DKIM-key-rotation cadence operates at a separate per-selector DNS coordinate the DMARC TXT publication discipline cannot reach; (iii) per- publisher per-domain RFC 6376bis body-length- restricted-replay future-protocol-extension coverage at the IETF in-progress per-message recipient-count-tag publication boundary the DMARC TXT publication does NOT participate in — the per-publisher per-message recipient-count tag the IETF DKIM-bis drafts propose would commit the per-message replay-defence to the per-message DKIM- Signature header byte-grammar (a per-message per-signer authoring-tier mitigation); the per-publisher per-domain DMARC TXT publication discipline THIS page documents provides NO per-publisher per-domain authoring lever for the per-message recipient-count-restricted-replay defence class. Read the DKIM-replay-attacks spoke ALONGSIDE this DMARC TXT publication reference whenever the per-publisher per- domain operator AUDITS the per-publisher per-domain DMARC threat-model coverage — the per-publisher per-domain DMARC TXT publication discipline THIS page documents is the per-publisher per-domain DMARC AUTHORING primitive against the unauthenticated-forgery attack class; the per-publisher per-domain DKIM-replay- attacks spoke is the per-publisher per- message THREAT-MODEL-COVERAGE-BOUNDARY documentation primitive that closes the per-publisher per-domain DMARC-coverage- vs-replay-coverage gap at the per-publisher per-domain authoring tier.
• DKIM for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-DKIM- PUBLICATION-AS-DKIM-PILLAR-DOWNSTREAM- INSTANTIATION-OF-DMARC-PUBLICATION- DISCIPLINE companion documenting the per-M365-tenant per-custom-domain DKIM publication tutorial (Exchange Online / Microsoft 365 Defender admin-center DKIM enablement, the 2048-bit selector1._domainkey / selector2._domainkey per-tenant CNAME publication, the per- tenant selector-rotation cadence, the Microsoft Graph PowerShell DKIM management cmdlets, the per-tenant DKIM signing-domain verification — the per- M365-tenant per-custom-domain DKIM publication operations whose per-tenant successful execution PRODUCES the downstream DKIM-pillar aligned-pass evidence the per-publisher per-domain DMARC record this page documents depends on to deliver per-publisher per-domain DMARC enforcement). Where THIS page documents the per-publisher per-domain RFC 7489 DMARC record byte- grammar tag-list reference (the v=DMARC1 version tag, the p= policy tag, the sp= subdomain-policy tag, the pct= percentage-tag, the rua= aggregate- reporting-URI tag, the ruf= forensic-reporting-URI tag, the adkim= / aspf= alignment-mode tags, the fo= failure-options tag, the ri= reporting- interval tag, the rf= report-format tag), the DKIM-for-M365 spoke documents the PER-M365-TENANT per-custom-domain DKIM-PILLAR downstream instantiation of the DMARC publication discipline this page documents — the per-M365-tenant per- custom-domain DKIM publication operations that PRODUCE the downstream DKIM-pillar aligned-pass evidence the DMARC record this page documents evaluates to deliver per-publisher per-domain enforcement. Read THIS page when AUTHORING the per-publisher per- domain DMARC record byte-grammar tag- list; read the DKIM-for-M365 spoke when AUTHORING the per-M365-tenant per- custom-domain DKIM publication that PRODUCES the downstream DKIM-pillar aligned-pass evidence the DMARC record this page documents enforcement-ramp progression depends on.
• ARC (Authenticated Received Chain, RFC 8617) explained — the DMARC-RECORD-TAG-GRAMMAR-AT-RECEIVE- SIDE-INDIRECT-MAIL-AUTH-PRESERVATION companion to this DMARC record tag-by-tag reference. Where THIS page documents the per-publisher per-domain DMARC TXT-record byte-grammar (v= / p= / sp= / np= / pct= / rua= / ruf= / fo= / aspf= / adkim= tags), the ARC-explained spoke is the RECEIVE-SIDE-INDIRECT-MAIL- AUTH-PRESERVATION REFERENCE every DMARC publisher consults when investigating per- domain DMARC-pass-rate gaps correlating with mailing-list-expansion / auto- forwarder / hybrid-relay second-hop SPF-break failure modes. Three structurally- distinct DMARC-record-tag-and-ARC-verdict coordination dimensions: (i) the aspf= / adkim= alignment-mode tags this page documents operate on the ORIGINAL-DOMAIN identifiers receivers preserve via ARC chain across second-hops — strict-alignment publishers with high mailing-list-exposed traffic observe per-receiver ARC-adoption-rate differences that drive cross-receiver DMARC-pass-rate asymmetry; (ii) the rua=mailto: aggregate-report stream this page documents as the publisher observability surface includes per-message ARC-result rows in modern receiver emitters' XML payloads, surfacing per- member-domain ARC-Sealer trust-anchor coverage gaps the publisher needs to coordinate with ARC-sealing forwarder operators; (iii) the fo=1 / fo=d / fo=s failure-report emission filter-tag grammar this page documents amplifies forensic evidence collection on per-message ARC- chain validation outcomes, producing the per-message AFRF MIME-envelope rows whose ARC-result fields the publisher's per- message forensic analysis depends on.
• MTA-STS for Google Workspace
• DKIM key rotation
• Email authentication ecosystem — the PER-PUBLISHER-PER-DOMAIN-DMARC- TXT-RR-PUBLICATION-DISCIPLINE-AS-LOAD- BEARING-COMPOSITE-VERDICT-POLICY-AND- REPORTING-LEG-OF-THE-CROSS-PROTOCOL-EMAIL- AUTHENTICATION-ECOSYSTEM companion to this DMARC TXT-RR byte-grammar publication- discipline reference. Where THIS page documents the per-publisher per-domain DMARC TXT-RR tag-vocabulary (v=DMARC1 + p= + sp= + pct= + rua= + ruf= + adkim= + aspf= + fo= + ri= + np= per RFC 7489 §6.3 + RFC 9091) published at _dmarc.<domain>, the email-authentication-ecosystem spoke is the CROSS-PROTOCOL OVERVIEW reference whose per-publisher per-domain SPF + DKIM + DMARC + ARC + BIMI publication-portfolio THIS DMARC TXT-RR byte-grammar page is the canonical composite-verdict-policy-and- reporting-leg of at FOUR per-publisher per- domain DMARC-TXT-RR-publication-discipline- vs-cross-protocol-ecosystem coupling dimensions: (i) per-publisher per- domain DMARC composite-verdict-policy-leg AS load-bearing downstream consumer of per-publisher per-domain SPF envelope- MAIL-FROM-layer-authorization-leg + per-publisher per-selector DKIM application-layer-cryptographic- authentication-leg — per- publisher per-domain DMARC composite- verdict per RFC 7489 §6.6 IS the load-bearing per-publisher per-domain application-layer downstream consumer of upstream SPF and DKIM per-message authentication-leg verdicts — the per-publisher per-domain policy_evaluated/spf + policy_evaluated/dkim attribution per RFC 7489 §6.6.1 cascades into the per-publisher per- domain DMARC composite-verdict disposition- decision (p=none / p=quarantine / p=reject) the email- authentication-ecosystem reference documents the cross-protocol publication- portfolio of; (ii) per-publisher per-domain DMARC rua=mailto: aggregate-report-URI publication-discipline AS load-bearing per-publisher per-domain observability-leg of the cross-protocol ecosystem — per-publisher per-domain DMARC rua= publication per RFC 7489 §7.2 drives per-receiver per-day per-source-IP per- row aggregate-XML report-emission pipeline the email-authentication-ecosystem reference documents the cross-protocol observability-pipeline of — the per- publisher per-domain operator-actionable per-day evidence-stream for SPF + DKIM per-message authentication-leg verdict attribution; (iii) per-publisher per-domain DMARC enforcement-mode p= publication-decision AS load-bearing precondition for per- publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility per RFC 9716 §4.1 enforcement-mode-prerequisite cascade — per-publisher per-domain DMARC p=quarantine or p=reject enforcement-tag publication-decision IS the load-bearing upstream application-layer authentication- policy precondition gating per-publisher per-domain BIMI Indicator-record brand- indicator-rendering eligibility — the email-authentication-ecosystem reference documents this cross-protocol enforcement-mode-prerequisite-cascade publication-portfolio coordination; (iv) per-publisher per-domain DMARC TXT-RR publication-discipline AS load- bearing publication-cadence-coordination primitive of the per-publisher per-domain cross-protocol publication-discipline portfolio — per-publisher per-domain DMARC _dmarc.<d> TXT-RR publication-discipline cadence coordination with per-publisher per-domain SPF apex-TXT-RR publication-cadence + per- publisher per-selector DKIM TXT-RR publication-cadence + per-publisher per- domain BIMI default._bimi.<d> TXT-RR publication-cadence underpins the per-publisher per-domain composite cross- protocol publication-discipline-portfolio coordination the email-authentication- ecosystem reference documents. Read the email-authentication-ecosystem spoke WITH this DMARC TXT-RR byte-grammar publication-discipline reference when AUTHORING per-publisher per-domain composite cross-protocol authentication- and-policy publication-discipline portfolio at the per-publisher per-domain composite cross-protocol-email-authentication- ecosystem-and-DMARC-TXT-RR-byte-grammar coordination boundary.
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance — the foundational DMARC specification.
• RFC 9091 — Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension To Support Non-existent Domains — the np tag specification.
• draft-ietf-dmarc-dmarcbis — the in-progress DMARC revision; deprecates pct and ruf.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

12. Audit your DMARC record now

DMARC Analyzer's Domain Security Checker performs a live DNS lookup for _dmarc.<your-domain> via includes/DnsChecker.php, parses every tag against the RFC 7489 + RFC 9091 grammar, and flags missing required tags (v, p), weak monitoring-only policies after enforcement deadlines, missing sp/np coverage, unreachable report destinations, and typographic errors that silently invalidate the whole record. The DNS Record Generator's DMARC wizard builds well-formed records with per-tag validation — copy the output directly into your DNS provider.

Check my DMARC record Sign up — Free plan