DMARC checker
Most domains with a DMARC record have it set to do nothing. The record exists, the questionnaire gets a tick, and anyone can still send convincing email as the domain. Check a domain you control and get the record in full and the policy it actually sets.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
What DMARC does that SPF and DKIM do not
SPF says which servers may send for your domain. DKIM signs a message so the recipient can tell it was not altered. Neither of them says what to do when the check fails - and left to themselves, most receivers deliver the message anyway.
DMARC is the instruction. It is a TXT record at _dmarc.yourdomain.com that tells a receiving server three things: what to do with mail that fails, where to send reports about it, and how strictly to match the domain the reader sees against the domain that was checked.
Six reasons to check your own DMARC
01
The policy that means "notice this and do nothing"
A DMARC record has one setting that matters more than all the others:
| Policy | What the receiver does with failing mail |
|---|---|
p=none | Delivers it. Sends you a report and nothing else |
p=quarantine | Puts it in spam |
p=reject | Refuses it outright |
p=none is the correct place to start and the wrong place to stay. It exists so you can watch for a few weeks and find the legitimate senders you forgot about, before you switch on enforcement.
A great many domains have been sitting at p=none for years, because nothing ever forced the next step and the record looks present on any checklist that only asks whether DMARC exists.
02
Why you cannot simply skip to reject
Because it will stop your own mail.
Every organisation sends from more places than it remembers: a ticketing system, an invoicing tool, a newsletter platform, a server that mails alerts, a form on a site built three years ago. At p=reject, every one of those that is not authorised stops being delivered - and the people who notice first are your customers.
The three stages exist to be walked, not chosen. Start at none, read what the reports show, authorise what is legitimate, then move to quarantine, then to reject.
03
The reports nobody reads
A DMARC record can name two report addresses:
rua- aggregate reports. Daily XML summaries from receiving providers: how much mail claimed to be from you, how much passed, and from whereruf- failure reports. Per-message detail, sent by far fewer providers, and they can contain parts of real messages
The aggregate reports are the whole point of p=none and they are unreadable by a person - they arrive as compressed XML from dozens of providers. Without something to collect and present them, the stage you are supposed to learn from teaches you nothing, and the domain stays at none forever.
A record with no rua address is a record that cannot do its job.
04
Alignment, and why mail can pass SPF and still fail DMARC
This is the part that surprises people who thought they were done.
SPF checks the envelope sender - the address used in the delivery conversation. The reader never sees it. What the reader sees is the From: header, and DMARC exists to protect that one.
So DMARC requires not just that SPF or DKIM passed, but that the domain it passed for matches the domain in the From: header. A mail platform that sends on your behalf using its own envelope domain will pass SPF for itself and fail DMARC for you, unless it has been configured to align.
The record's aspf and adkim settings control how strictly that match is made - r for relaxed, which allows subdomains, s for strict, which does not.
05
The subdomain nobody set a policy for
A DMARC record can carry a separate policy for subdomains, sp. If it is absent, subdomains inherit the main policy - which is usually what you want.
Where it goes wrong is a record that sets p=reject and sp=none, often during a cautious rollout and then left that way. The main domain is protected and every subdomain is wide open, which is where an attacker will go.
06
Evidence for the people who now ask by name
Insurers and enterprise customers increasingly ask about DMARC specifically, and some ask for the policy value rather than a yes. A dated report showing the record and when it changed is a better answer than a screenshot of a DNS panel, and it is evidence you can keep.
Know the day your policy changes
A DMARC policy can be weakened in one edit, by one person, for one good reason - a batch of legitimate mail was being rejected and the quickest fix was to drop back to none. It is meant to be temporary. It rarely is.
Scheduled scans turn that into a difference you are told about: this policy went from quarantine to none, this record changed. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the domain
A domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the check run
DMARC records are public, so this reads rather than probes. It looks up _dmarc on your domain the way a receiving mail server would.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. A missing record and a policy that only watches are not sitting in the same undifferentiated list.
What this is part of
DMARC is one of several mail-related records AYAsec checks as part of its DNS scan, alongside SPF, DKIM, MTA-STS, TLS-RPT and DNSSEC. It is one scan, and this page is about one part of what it looks at.
DNS carries 20% of the composite grade. The others are HTTP at 30%, TLS and ports at 20% each, and domain credibility at 10%. All of them together are what attack surface management means in practice.
Questions before you check
What may I check?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the domain to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
We do not send email from this domain. Do we need DMARC?
Yes, and arguably more. A domain that sends nothing should say so explicitly - an SPF record authorising nobody and a DMARC policy of reject. A parked domain with no records is the easiest of all to impersonate, because nobody is watching the replies.
How long should we stay at p=none?
Long enough to see a full cycle of your own sending, which for most organisations means a few weeks - monthly invoicing and quarterly campaigns both need to appear in the reports before you enforce. Staying longer than a quarter usually means nobody is reading the reports.
Will moving to reject break anything?
It will break anything that is sending as you without being authorised, which is the point - but that set includes your own forgotten tools until you find them. That is what the earlier stages are for.
Does DMARC need both SPF and DKIM to pass?
No. One of the two passing and aligning is enough. In practice DKIM is the more durable of the two, because it survives forwarding and SPF often does not.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the domain to an AYAsec account instead, and every scan is kept - a series that tells you when the policy was weakened and by how much. Retention depends on your plan.
Keep the history, not just the result
Run the full DNS check against your own domains, on a schedule, with a message when a policy moves backwards.