dmarc checker

RFC 7489 §6.1 places the dmarc record at the `_dmarc` label under the policy domain, not at the apex. the apex TXT is where spf lives; putting dmarc there would collide with spf parsers.

relaxed (`r`) accepts any subdomain under the same organisational domain — e.g. `mail.example.com` aligned with From: `example.com`. strict (`s`) requires an exact fqdn match. `aspf` works the same way for spf alignment.

receivers are advised to reject, but dmarc is a policy signal, not a mandate. large mailbox providers (gmail, outlook) honor it; some smaller operators ignore it entirely. `pct` can gate rollout — `p=reject; pct=10` means only 10% of failing mail is rejected; the rest falls back to the `sp` or `quarantine` treatment.

yes. a subdomain may publish its own `_dmarc.sub.example.com` TXT, which overrides the parent. if it doesn't, receivers inherit the parent's policy but apply the `sp` tag instead of `p` when scoring the subdomain.

`fo` controls when forensic reports fire: `0` (default) = report only on total dmarc failure; `1` = report when any auth check fails; `d` = dkim failure; `s` = spf failure. it only matters if you publish a `ruf` address.

dmarc (domain-based message authentication, reporting & conformance) is an email-authentication policy published as a txt record at `_dmarc.<domain>`. it tells receivers what to do with mail that fails spf or dkim alignment — monitor, quarantine, or reject — and where to send reports, closing the gap that lets spammers spoof your domain.

dmarc stands for domain-based message authentication, reporting, and conformance. it builds on the two older email-authentication standards, spf and dkim, adding alignment between the visible From: address and those checks, plus a reporting channel so domain owners can see who is sending mail in their name.

a receiver checks whether an incoming message passes spf or dkim and whether the authenticated domain aligns with the visible From: header. it then applies your published policy — `p=none`, `quarantine`, or `reject` — to anything that fails, and emails aggregate reports to the `rua` address you specified.

first get spf and dkim passing for every legitimate sender. then publish a txt record at `_dmarc.<domain>` starting with `v=DMARC1; p=none; rua=mailto:[email protected]` to collect reports without blocking. once reports confirm all real mail aligns, tighten the policy to `quarantine` and finally `reject`.

a dmarc record is a single txt record at `_dmarc.<domain>` holding semicolon-separated tags: `v=DMARC1` (version), `p=` (policy — none/quarantine/reject), `rua`/`ruf` (report addresses), `adkim`/`aspf` (alignment mode), `pct` (rollout percentage), and `sp` (subdomain policy). this tool parses each tag for you.

yes if your domain sends email — gmail and yahoo now require dmarc for bulk senders, and without it anyone can spoof your domain in phishing. even a monitor-only `p=none` record is worth publishing for visibility, though only `quarantine` or `reject` actually blocks spoofed mail.

not usually. a DMARC record at _dmarc.yourdomain.com covers the organizational domain and, by default, its subdomains. you can override subdomains with the sp tag (subdomain policy); if sp is absent, subdomains inherit the main p value. publish a separate _dmarc record on a subdomain only when it needs its own policy or its own reporting address.

DMARC passes if either SPF or DKIM passes with alignment, so one is technically enough. in practice you want both: SPF alignment breaks on forwarding and on ESPs that use their own return-path, while DKIM survives forwarding. relying on SPF alone makes a lot of legitimate mail fail DMARC, so sign every sender with aligned DKIM too.

common causes: the rua value is missing the mailto: prefix, a syntax error elsewhere makes receivers ignore the whole record, the report address is on another domain that has not published the _report._dmarc authorization, DNS has not propagated, or the domain sends too little mail to generate reports. confirm the record parses and that external-domain reporting is authorized.

yes for bulk senders. since february 2024 Google and Yahoo require senders of more than about 5,000 messages a day to publish SPF, DKIM and a DMARC record (at least p=none), plus one-click unsubscribe and a low spam-complaint rate. smaller senders are not strictly required to, but authenticated mail still lands far better.