Can anyone send email as your domain?
Read the records that decide whether your domain can be forged — SPF, DMARC, DKIM, MTA-STS, TLS-RPT and DNSSEC — resolved in your own browser, with what each one is actually doing and what a spoofing incident obliges an Indian entity to report.
Check your domain
The lookup runs in your browser against a public DNS resolver. Nothing passes through us, and no domain anyone types here is recorded anywhere — which is also why we cannot show you a history of what you checked.
This is a worked example, not your domain. It shows the configuration this tool most often has to explain — SPF and DKIM correctly published, DMARC parked at p=none, transport records absent. Enter a domain above to replace it.
- DMARC — Exposed
The policy is published but enforces nothing
p=none tells receiving servers to take no action on mail that fails. It is the correct place to start — it turns on the reports you need before enforcing — but it is a monitoring configuration, and a domain left here is as forgeable as one with no record at all. This is where most domains stop.
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.in - MTA-STS — Gap
Nothing requires mail to you to be encrypted
Without a policy, a sending server that cannot negotiate TLS falls back to delivering in cleartext rather than refusing. MTA-STS is what turns that fallback off. This protects mail arriving at you, which is the opposite direction from everything above.
No record at _mta-sts - TLS-RPT — Gap
Delivery failures are not reported to anyone
No address is published for TLS reporting, so a sending server that fails to establish an encrypted connection to you has nowhere to say so. A downgrade or an interception attempt produces no report anybody receives.
No record at _smtp._tls - DNSSEC — Gap
The answers above are not authenticated
The resolver did not report validation, which usually means the zone is unsigned. Anyone positioned to tamper with DNS could substitute any record on this page, including the DMARC policy. Absence of the flag is weaker evidence than its presence, so confirm with your registrar before treating the zone as unsigned.
No AD flag in the response - SPF — Published
A sender policy is published, ending in a soft fail
~all marks unlisted senders as suspicious rather than refusing them, which is the correct choice when DMARC is doing the enforcing. If your DMARC policy is not at enforcement, nothing downstream acts on this.
v=spf1 include:_spf.google.com ~all - DKIM — Published
A signing key is published
Probed against 12 common selectors. Others may exist and cannot be discovered this way, so this confirms signing is set up without confirming that every sending service signs.
google._domainkey - MX — Context
5 mail hosts
Where mail to this domain is delivered. Shown because it decides whose console the fixes above are made in.
aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com
A clean result here is the absence of one class of finding, never a verdict on your security. These are seven records read from public DNS; a security rating is calculated from several hundred signals across an entire external surface, and email security is one risk vector inside it.
Take this away as a print-ready remediation pack
Everything above is yours already. This is the version you can put in front of your team — the same result with your details on it, the owner columns your incident file needs, and the checklist attached. It opens here and lands in your inbox, so it is to hand when you actually need it rather than in a tab you closed.
What each record decides
Three of these are about mail leaving your domain and three are about mail arriving at it, which is the distinction most summaries skip.
- SPF lists the servers allowed to send as you. It is checked against the envelope sender, and on its own it produces a result that nothing is obliged to act on.
- DKIM signs outgoing mail with a key published in your DNS, so a receiving server can confirm the message was not altered and did come from a system holding your key.
- DMARC is the instruction. It says what a receiving server should do when SPF and DKIM both fail, and it is the only one of the three that changes what happens to a forged message.
- MTA-STS tells servers sending mail to you that they must use TLS and must not fall back to cleartext, and TLS-RPT gives them somewhere to report it when they cannot.
- DNSSEC authenticates all of the above. Without it, everything on this page is a set of unsigned assertions that anyone able to tamper with DNS could replace.
Why p=none is the usual finding
Publishing DMARC is easy and enforcing it is not, so a great many domains stop at the first step. p=none is genuinely the right place to begin: it turns on the aggregate reports that tell you which legitimate services send as you, and moving to enforcement without reading those reports for a few weeks reliably breaks the invoicing system, the CRM, the ticketing tool and the marketing platform at once.
The failure is not starting there. It is staying. A record parked at p=none looks like compliance on an audit checklist and provides exactly as much protection against impersonation as publishing nothing at all — which is to say none.
What a spoofing incident obliges in India
Identity theft, spoofing and phishing attacks is its own category in CERT-In's Annexure I list of reportable incidents, and so is attacks on servers such as database, mail and DNS. Both carry the six-hour obligation, and the CERT-In Directions are made under section 70B(6) of the Information Technology Act rather than under any sectoral statute — so they bind every entity in India regardless of who licenses it.
The trap is where that clock starts. It runs from noticing the incident or being brought to notice of it, which in a spoofing case is almost always the second: a customer forwards you an invoice they nearly paid, or a supplier asks why your finance team changed bank details. The clock started when they told you, not when you finished working out what happened.
For every filing a single incident starts and who each goes to, use the incident reporting clock, and to rehearse one before it happens, the tabletop generator.
The readings above are of records published in public DNS and are not a determination that any message has been forged. Two limits are worth restating: DKIM selectors cannot be enumerated over DNS, so a negative DKIM result is not evidence of absence; and an MTA-STS policy file is served over HTTPS without the headers a browser needs to read it, so only the DNS half of that check is visible here. Every instrument cited here was verified against the issuing regulator's own notification on .
Questions this page answers
- How do I stop someone sending email pretending to be my domain?
- Publish a DMARC record and move it to enforcement. SPF states which servers may send for your domain and DKIM signs the mail, but neither instructs a receiving server what to do when a message fails — that instruction is the DMARC policy. At p=none nothing happens; at p=quarantine failing mail goes to spam; at p=reject it is refused. Until the policy is at quarantine or reject, the other two records are advisory.
- Is DMARC p=none good enough?
- No, and it is the most common configuration there is. p=none tells receiving servers to take no action on mail that fails your checks, so a domain sitting there is as forgeable as one with no record at all. It is the right place to start, because it turns on the aggregate reports you need in order to enforce safely without breaking legitimate mail — but it is a starting point, not a destination.
- Can you tell whether a domain has DKIM set up?
- Only partially, and any tool claiming otherwise is overstating it. DKIM selectors cannot be enumerated over DNS — there is no record that lists them — so the only option is to probe names that are commonly used. A domain signing with a custom selector looks exactly like one with no DKIM at all. A positive result is meaningful; a negative one is not evidence of absence.
- What is MTA-STS, and does it matter?
- MTA-STS tells servers sending mail to you that they must negotiate TLS and must not fall back to delivering in cleartext if it fails. It protects mail arriving at you, which is the opposite direction from SPF, DKIM and DMARC. It has two halves — a DNS record announcing the policy, and the policy file served over HTTPS — and only the DNS half is visible to a browser, because the policy file is not served with the headers a browser needs to read it.
- Do you have to report email spoofing to CERT-In?
- Identity theft, spoofing and phishing attacks is a category in CERT-In’s Annexure I, and so is attacks on servers such as database, mail and DNS. Both carry the six-hour reporting obligation. The clock runs from noticing the incident or being brought to notice of it, so a customer forwarding you a forged invoice starts it — not the point at which you finish confirming what happened.
- Does a clean email security result mean we are secure?
- It means one class of finding is absent. These are records read from public DNS about one part of one risk vector. A security rating is calculated from several hundred signals across an entire external estate — patching, TLS configuration, exposed services, endpoint hygiene, credentials circulating on underground markets — and email security is one component inside it.