DNS security checker
If nobody has configured otherwise, anyone on the internet can send email that appears to come from your domain. Point the scanner at a domain you control and get the mail authentication records, the DNSSEC state and the configuration behind them - graded, kept, and watched for the day any of it changes.
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.
Five reasons to check your own DNS
DNS is the only layer on this list where the damage usually lands on somebody else. A domain that can be impersonated is used against your customers, your suppliers and your own staff.
01
Find out whether anyone can send mail as you
The mail records decide this - SPF, DKIM and DMARC, with MTA-STS and TLS-RPT protecting the connection that carries the mail - and each has a page of its own: SPF, DKIM, DMARC, MTA-STS and DNSSEC.
A domain with no DMARC record is a domain anyone can write convincing phishing from.
02
Find the records that outlived what they pointed at
DNS records are created for a service and survive it. The record pointing at a cloud platform the company stopped paying for is the classic route to a subdomain takeover - anyone who claims that service name now serves content from your subdomain, under your name.
03
See whether DNSSEC is on, and whether it is correct
DNSSEC signs DNS answers so a client can tell they were not tampered with in transit. It is off by default at most providers. It is also the one item on this list where a half-finished configuration is worse than none, because a broken signature makes the domain fail to resolve rather than merely resolve insecurely.
04
Catch the change nobody announced
DNS is edited by more people than any other layer - marketing adding a tool, IT moving a mail provider, a contractor pointing a subdomain somewhere. Each edit is small and none of them are reviewed. An SPF record that grows one entry at a time eventually exceeds its lookup limit and silently stops working.
05
Produce evidence that the domain is protected
Insurers and enterprise customers increasingly ask about DMARC by name. A dated report showing the policy 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 DNS changes
DNS changes take effect quietly and immediately, and the person who made the change is often not in the security team.
Scheduled scans turn that into a difference you are told about: this record was not here last week, this policy went from quarantine back to none, this grade dropped. 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
DNS answers are public, so this scan reads rather than probes. It queries the domain the way a mail server or a resolver would.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. A missing DMARC policy and an untidy TXT record are not sitting in the same undifferentiated list.
What the scan checks
01
Mail authentication
SPF, DKIM, DMARC, MTA-STS and TLS-RPT - whether each exists and what it tells a receiving server to do, with SPF, DKIM, DMARC and MTA-STS available on their own pages.
02
DNSSEC
Whether the domain is signed, and whether the chain of trust is intact.
03
Records and nameservers
The configuration itself: which nameservers are authoritative, and whether the record set contains anything that should not be there.
Questions before you scan
What may I scan?
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.
DNS records are public. Why does this need verification?
The records are public and the check is read-only, so the scan itself is harmless. Verification is about what happens next: a domain in your AYAsec account is monitored, graded and kept in your history, and none of that should be possible for a domain that is not yours.
We do not send email from this domain. Do we still need SPF and DMARC?
Yes, and arguably more. A domain that sends no mail should say so explicitly - an SPF record authorising nothing 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.
Will turning on DMARC stop our own email?
It can, if it is enabled at reject before the legitimate senders are known. That is the reason the policy exists in three stages: start at none and read the reports, move to quarantine, then to reject. The scan tells you which stage you are at, not that you should jump to the end.
Is DNSSEC worth enabling?
It depends on your provider. Where it is a switch, yes. Where it means manual key management, the honest answer is that a broken DNSSEC configuration takes your domain offline, and a domain that resolves insecurely is a smaller risk than a domain that does not resolve.
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 someone changed the record. Retention depends on your plan.
Keep the history, not just the result
Run the full check against your own domains, on a schedule, with every change flagged to whoever needs to see it.
More free security scanners for HTTP, TLS and ports
DNS is one of five scored layers. The others each answer a different question:
Online port scanner
what is this estate willing to talk to a stranger about?
SSL/TLS checker
is the encryption sound, and when does the certificate expire?
HTTP security checker
is the web application configured defensively?
All five together are what attack surface management means in practice.