DNS Checker
Look up any DNS record, including DKIM and DMARC
What is DMARC?
In short: DMARC tells other mail servers what to do with email that claims to be from your domain but can't prove it.
Anyone can put your domain in the From line of an email. DMARC is a TXT record
you publish at _dmarc.<your domain>. It tells receiving mail
servers three things:
- How to check the email really came from you. SPF or DKIM must pass, and the domain it passed for must match the From domain. This match is called "alignment".
- What to do when the check fails. This is your policy: do nothing, treat it as suspicious, or refuse it.
- Where to send reports about who is sending email as your domain.
-
An email arrives with
example.comin the From line - The receiving server checks SPF and DKIM
- Does a passing result match the From domain?
-
Yes: DMARC passes, deliver as
normal
No: apply your policy
(
p=) -
Either way, the result goes into your report (
rua=)
New in the current standard
RFC 9989 (May 2026) replaces RFC 7489. Three tags were added:
np=, psd= and t=. Three were removed:
pct=, rf= and ri=. Finding the
"organisational domain" no longer uses the Public Suffix List; it uses a DNS
lookup up the domain tree instead. Tags with a New badge in the
list were added in this version.
Good to know
DMARC is a request, not an order. Receivers are allowed to follow their own rules instead. The big mailbox providers do follow it.
Reading your results
In short: What the coloured status at the top of your results means.
| Status | What it means |
|---|---|
| Full enforcement (p=reject) | Email that fails DMARC should be refused. This is the strongest protection. |
| Partial enforcement (p=quarantine) | Email that fails DMARC should be treated as suspicious, usually sent to the spam folder. |
| Monitoring only (p=none) | Nothing happens to failing email. You only get reports. A good first step, but it does not stop spoofing. |
| Missing policy |
The record has no valid p= tag. If it has a valid
rua= address, receivers treat it as p=none. If
not, they skip DMARC for your domain completely.
|
| Invalid DMARC version |
The record does not start with v=DMARC1. Receivers ignore
the whole record, as if you had none.
|
"Not set" in the table means the tag is not in your record. The table then shows what applies instead, for example the default value or the policy the tag falls back to.
Good to know
The status only reads your record. It can't tell whether your real email
passes SPF or DKIM. Your rua= reports show that.
Version v=
In short: Marks the TXT record as a DMARC record.
What it does
It must be the very first tag, and its value must be exactly
DMARC1, in capitals.
Allowed values
| Value | Meaning |
|---|---|
DMARC1 |
The only valid value. |
If it's missing
Receivers ignore the whole record. They do the same if it isn't the first tag or has a different value.
Example
v=DMARC1; p=reject"This is a DMARC record, and failing email should be refused."
Good to know
v=dmarc1 in lower case is not valid. The value is case-sensitive.
Domain policy p=
In short: What receivers should do with email from your domain that fails DMARC.
What it does
The policy applies to your domain and also to its subdomains, unless
sp= or np= says otherwise.
Allowed values
| Value | Meaning | Status shown |
|---|---|---|
none |
Take no action. Deliver as normal. Reports are still sent. | Monitoring only |
quarantine |
Treat as suspicious, usually the spam folder. | Partial enforcement |
reject |
Refuse the email. | Full enforcement |
If it's missing
If the record has a valid rua= address, receivers act as if it said
p=none. Otherwise they skip DMARC for your domain.
Example
v=DMARC1; p=quarantine; rua=mailto:[email protected]"Treat failing email as suspicious, and send daily reports to [email protected]."
Good to know
The usual path is none, then quarantine, then
reject. Set up rua= before you leave
none, so you can see which of your own senders would fail. Use
t=y while you test a stricter policy.
Subdomain policy sp=
In short: The policy for your subdomains that really exist,
such as mail.example.com.
What it does
Same values as p=. It applies only to subdomains, not to the domain
itself.
Allowed values
| Value | Meaning |
|---|---|
none |
Take no action. |
quarantine |
Treat as suspicious. |
reject |
Refuse the email. |
If it's missing
Subdomains use p=.
Example
v=DMARC1; p=reject; sp=quarantine"Refuse failing email from example.com, but only treat failing email from its subdomains as suspicious."
Good to know
sp= only works in the record at the top of your domain (for
example _dmarc.example.com). In a record published for a
subdomain, it is ignored.
Non-existent subdomain policy np=
In short: The policy for subdomains that don't exist in DNS at all.
What it does
Spoofers often make up subdomains, such as
invoices-x7.example.com, hoping nobody protects them. A subdomain
is "non-existent" when a DNS lookup for it says the name does not exist
(NXDOMAIN). It does not mean a newly created subdomain. A
subdomain you set up has DNS records, so it falls under sp=.
Allowed values
| Value | Meaning |
|---|---|
none |
Take no action. |
quarantine |
Treat as suspicious. |
reject |
Refuse the email. |
If it's missing
sp= applies if it is set, otherwise p=.
Example
v=DMARC1; p=quarantine; np=reject"Treat failing email as suspicious, but refuse anything from a made-up subdomain."
-
example.comUsesp=-
mail.example.comExists in DNS, so it usessp= -
invoices-x7.example.comDoes not exist in DNS, so it usesnp=
-
Good to know
np=reject is a safe choice for most domains. No real email should
come from a name that doesn't exist.
DKIM alignment adkim=
In short: How closely the DKIM signing domain must match the From domain.
What it does
DKIM signs an email for a domain, shown in its d= tag. For DMARC,
that domain must match the From domain.
Allowed values
| Value | Meaning |
|---|---|
r |
Relaxed. The same organisational domain is enough, so
mail.example.com matches example.com.
|
s |
Strict. The two domains must be exactly the same. |
If it's missing
Relaxed (r).
Example
adkim=s
"The DKIM d= domain must be exactly the From domain."
From: [email protected]
DKIM d=: mail.example.com
Relaxed: match. Both are under
example.com.
Strict: no match.
mail.example.com is not example.com.
Good to know
Only choose strict if every service that sends for you signs with your exact domain. Otherwise real email starts failing.
SPF alignment aspf=
In short: How closely the SPF domain must match the From domain.
What it does
SPF checks the MAIL FROM address (also called the Return-Path or envelope sender), not the From address people see. For DMARC, that domain must match the From domain.
Allowed values
| Value | Meaning |
|---|---|
r |
Relaxed. The same organisational domain is enough. |
s |
Strict. The two domains must be exactly the same. |
If it's missing
Relaxed (r).
Example
aspf=r
"A Return-Path at bounce.example.com counts as matching
example.com."
The alignment diagram on the DKIM alignment page works the same way for SPF.
Good to know
Many email services use their own Return-Path domain. SPF then passes for them, not for you, so it can't align. DKIM signed with your domain is the fix.
Aggregate reports rua=
In short: Where to send summary reports about email sent as your domain.
What it does
Receivers send XML reports, usually once a day, listing which servers sent email
as your domain and whether it passed. The value is a comma-separated list of
mailto: addresses.
Allowed values
| Value | Meaning |
|---|---|
mailto:address |
Send reports to this address. Separate several with commas. |
If it's missing
Receivers don't send aggregate reports for your domain. A record with no valid
p= also gets ignored completely without a valid rua=.
Example
rua=mailto:[email protected]"Send daily summary reports to [email protected]."
Good to know
If the address is on a different domain, such as a reporting service, that
domain must allow it. It publishes a TXT record at
example.com._report._dmarc.<their domain> starting with
v=DMARC1. Without it, receivers ignore that address. An old size
suffix such as !10m on the address is no longer used, and
receivers ignore it.
Failure reports ruf=
In short: Where to send a report about each single email that fails.
What it does
Same format as rua=, but receivers send one report per failing
message instead of a daily summary.
Allowed values
| Value | Meaning |
|---|---|
mailto:address |
Send failure reports to this address. Separate several with commas. |
If it's missing
Receivers don't send failure reports.
Example
ruf=mailto:[email protected]"Send a report for each failing email to [email protected]."
Good to know
These reports can contain parts of the real email, including personal details. Most receivers don't send them at all because of privacy concerns. The table used to call these "forensic reports".
Failure report options fo=
In short: When a failure report should be sent.
Allowed values
| Value | Meaning |
|---|---|
0 |
Send a report if both SPF and DKIM fail to give an aligned pass. |
1 |
Send a report if either SPF or DKIM fails to give an aligned pass. |
d |
Send a DKIM report if a DKIM signature failed, aligned or not. |
s |
Send an SPF report if SPF failed, aligned or not. |
You can combine values with a colon, such as 1:d.
0 and 1 can't be used together.
If it's missing
0.
Example
ruf=mailto:[email protected]; fo=1"Send a failure report whenever SPF or DKIM fails to give an aligned pass."
Good to know
fo= does nothing without ruf=.
Test mode t=
In short: Ask receivers to apply your policy one step softer while you test it.
Allowed values
| Value | Meaning |
|---|---|
y |
Test mode. reject is applied as quarantine,
and quarantine as none.
|
n |
Normal. Apply the policy as written. |
If it's missing
n.
Example
v=DMARC1; p=reject; t=y"I plan to reject failing email, but for now please only treat it as suspicious."
Good to know
Reports keep coming as normal in test mode, and t=y has no effect
on a none policy. It replaces the old pct=0 trick.
Percentage (legacy) pct=
In short: A removed tag that asked receivers to apply the policy to only some failing email.
What it does
pct= was removed in RFC 9989 because receivers rarely applied it
accurately.
Allowed values
| Value | Meaning |
|---|---|
0 to 100 |
Under the old standard, the percentage of failing email the policy applied to. |
If it's missing
Nothing. It is no longer part of the standard.
Example
p=reject; pct=25"Under the old standard: reject a quarter of failing email."
Good to know
Receivers following the current standard ignore it. Some older receivers may
still use it. To test safely, use t=y instead.
Public suffix domain psd=
In short: Says whether this domain is a public suffix, like
co.za, where other people register their own domains.
Allowed values
| Value | Meaning |
|---|---|
y |
This is a public suffix domain, run by a registry. |
n |
This domain is the top of an organisation's own domain tree. |
u |
Not stated. Receivers work it out with a DNS lookup up the domain tree. |
If it's missing
u.
Example
v=DMARC1; p=reject; psd=n"example.com is the top of our domain tree."
Good to know
Most domain owners never need to set this.
Report format and interval rf=
ri=
In short: Two removed tags for the failure report format and how often to send aggregate reports.
What it does
RFC 9989 removed both. Receivers following the current standard ignore them.
If it's missing
Nothing. Leaving them out is correct.
Example
rf=afrf; ri=86400"Under the old standard: failure reports in AFRF format, aggregate reports every 86400 seconds (one day)."
Good to know
This tool doesn't show these tags in the results table, even if your record has them. You can safely remove them from your record.