Can a stranger send email
as your company today?
Email authentication is the control every questionnaire asks about and almost nobody finishes. GuardianGaze evaluates SPF, DKIM, DMARC, MTA-STS and TLS-RPT across every domain you own, and turns them into one deterministic answer with the evidence attached.
Email Security, step by step
Anyone can send as you
SPF that never reaches enforcement, DMARC parked at p=none, no MTA-STS. The records exist, so audits pass, and mail from your domain still cannot be trusted.
Spoofability, stated plainly
SPF, DKIM, DMARC, MTA-STS and TLS-RPT are evaluated together into one deterministic answer: can a stranger send mail as this domain, yes or no.
A one-line DNS fix, verified
Most email findings are a single record change. Make it, and the next scan clears the finding automatically, with the compliance control it satisfied recorded against it.
Email authentication scored per domain, with the record that produced the finding
Can a stranger send email that appears to come from you?
For a large share of organisations the answer is yes, and nobody inside has ever checked. Email was designed without authentication (the sender address in a message is a claim, not a verified fact) and the three records that fix this all have to be configured deliberately.
The consequence is business email compromise, which by loss volume is consistently among the most expensive categories of cybercrime. It is not technically sophisticated. It relies on an invoice, a payment change request or an urgent instruction appearing to come from a real address at a real company, and it works because the receiving mail server has no basis to reject it.
The controls that prevent it are free, well documented and take a competent administrator an afternoon. They remain unimplemented at an enormous number of organisations because nobody owns them and nobody measures them.
SPF, DKIM, DMARC, MTA-STS and TLS-RPT, and what each one does
SPF lists which servers may send on behalf of your domain. Its common failure is being too permissive: a record that ends in a catch-all, or that has accumulated so many third parties over the years that it exceeds the lookup limit and silently stops being evaluated at all.
DKIM signs messages cryptographically so a receiver can verify the content was not altered and the sender was authorised. Its common failure is a key that was rotated at one provider and never updated for another, so a portion of legitimate mail fails silently.
DMARC ties the two together and tells receivers what to do when a message fails: nothing, quarantine, or reject. The overwhelming majority of published DMARC records are set to none, which means the domain is being monitored and nothing is being blocked. A DMARC record at none provides reporting, not protection, and it is routinely mistaken for the latter.
MTA-STS and TLS-RPT govern transport encryption between mail servers and report on failures, less commonly implemented, and the pair that stops a downgrade attack on mail in transit.
Why most organisations stall at p=none
Moving DMARC from none to quarantine or reject is where the work is, and where nearly everyone stops. The reason is a legitimate fear: somewhere in the organisation, a system sends mail as your domain that nobody has documented: a CRM, a ticketing tool, an invoicing platform, a marketing service set up by a team that never told IT. Enforce before finding it and that mail starts bouncing.
So the sequence that works is to publish a record at none with reporting, read the reports until every legitimate sender is identified and authorised, then move to quarantine, then to reject. It is not difficult. It requires someone to own it for a few weeks, which is the actual scarce resource.
Continuous monitoring matters afterwards, because mail configuration decays. A new SaaS tool gets added, a provider changes their sending infrastructure, a key rotates. A domain that reached enforcement two years ago and has not been checked since is not necessarily still protected.
Checking suppliers, and the lookalikes
The same check runs against any domain, which makes it one of the most useful single signals in vendor assessment. A supplier who invoices you and has no DMARC enforcement is a supplier whose invoices can be impersonated, and payment redirection fraud usually arrives through a real supplier's spoofed domain rather than an obviously fake one.
Mail records also expose the provider chain unusually clearly. An SPF record enumerates every third party permitted to send on a company's behalf, which is often the single most revealing public record any organisation publishes about who it works with.
Then there are lookalike domains (a substituted character, a different TLD) registered specifically to sidestep authentication entirely. Perfect DMARC on your own domain does nothing about mail from a domain that merely resembles yours, which is why mail authentication and impersonation monitoring are two halves of the same control rather than alternatives.
The five records, what they do, and how they fail
| Record | Purpose | Common failure |
|---|---|---|
| SPF | Lists authorised sending servers | Too permissive, or exceeds the lookup limit and stops being evaluated |
| DKIM | Cryptographically signs messages | Key rotated at one provider, never updated at another |
| DMARC | Tells receivers what to do on failure | Published at p=none, reporting, not protection |
| MTA-STS | Enforces TLS between mail servers | Not published at all |
| TLS-RPT | Reports transport encryption failures | Not published, so failures go unseen |
“We had DMARC records on every domain and were still spoofable on four of them.”
Email Security | common questions
What does DMARC actually protect against?
Someone sending mail that appears to come from your domain, the mechanism behind most business email compromise and invoice fraud. Without it, a receiving server has no basis to reject a forged sender.
We have a DMARC record. Are we protected?
Only if the policy is quarantine or reject. Most published records are set to none, which means you are receiving reports and nothing is being blocked. It is the most common misunderstanding in this area.
Why does everyone stall at p=none?
Because enforcement breaks any undocumented system that sends as your domain: a CRM, an invoicing tool, a marketing platform someone set up years ago. The fix is to read the reports until every legitimate sender is identified, then move to quarantine, then reject.
How long does it take to get to enforcement?
Usually a few weeks, and the constraint is ownership rather than difficulty. Somebody has to read the reports and chase down each unrecognised sender.
Should we check our suppliers' mail authentication?
Yes. A supplier who invoices you and has no DMARC enforcement is a supplier whose invoices can be impersonated, and payment redirection fraud usually arrives through a real supplier's spoofed domain rather than an obviously fake one.
Does DMARC stop lookalike domains?
No. A domain with a substituted character is a different domain and can publish its own perfect authentication records. Mail authentication and impersonation monitoring cover different halves of the same problem.
Does mail configuration need ongoing monitoring?
Yes, because it decays. New SaaS tools get added, providers change sending infrastructure, keys rotate. A domain that reached enforcement two years ago is not necessarily still enforcing.
Where this connects
Domain takedown →
Lookalike domains that sidestep authentication entirely.
Third-party risk →
Checking whether suppliers who invoice you can be impersonated.
Domain security module →
How mail and domain findings are scored.
Check whether your domains can be spoofed
Domain security is one of six modules assessed in the free rating. The email findings usually arrive first, because they are the fastest to prove.