Find out who is sending email as you - then stop them.
Your domain can be used to send phishing today, and unless someone is collecting
DMARC reports you will never hear about it. MailGuardHQ collects those reports,
tells you in plain language what they mean, and walks you to the point where forged
mail is rejected outright.
See every service sending mail as your domain - including the ones you forgot about.
Move from monitoring to enforcement without breaking your real mail.
Findings written for the person who has to fix them, not for a protocol expert.
Hosting providers commonly act on the signals below. We cannot see them for your account, and nobody outside your provider can. A clean result elsewhere in this report is not a guarantee of delivery. Your provider acts on information it does not publish and does not share.
How much mail your hosting account sendsProviders count every message your whole account sends, across all its domains.
Spam complaints about mail from your accountProviders receive complaints about mail from any domain on your account.
Which scripts or mailboxes send your mailOnly your provider's mail logs show whether a message came from a website script or a mailbox login.
Your provider's own blocklistsProviders keep internal lists they do not publish. An address can be clean on every public list and still be on one.
Spam trapsTrap addresses are never revealed by their owners, so no one outside can test for them.
Microsoft's complaint reportsMicrosoft shares complaint data only with whoever is responsible for the sending server.
Total mail sent from your server's addressOn shared hosting your server's address also sends mail for other customers.
The name your mail server introduces itself withReceivers see the name a server gives when it connects. On shared hosting this is your provider's name, and that is normal.
Your provider's security and firewall eventsProviders record security events against their customers' accounts and addresses.
Automated mail sent from a person's mailboxWebsite forms, apps and billing systems sometimes send from a staff address, which ties that person's mailbox to automated mail.
Test systems sending as your real domainA development or test system with real mail settings sends real mail as your domain.
Your provider's reason for a blockOnly your provider knows why it blocked sending, and its first answer may describe what it sees now, not what started it.
The three records
SPF, DKIM and DMARC, without the jargon
Three DNS records decide whether a receiving mail server believes a message really
came from you. Most domains have one or two of them, half configured, and no way of
telling whether they work.
SPF
The guest list
SPF lists which servers are allowed to send mail using your domain. If a message
arrives from somewhere not on the list, SPF says so. Its catch: it is capped at ten
DNS lookups, and once you exceed that cap receivers stop evaluating it entirely -
silently.
DKIM
The wax seal
DKIM adds a cryptographic signature to each message you send. A receiver checks the
signature against a key published in your DNS. If the message was altered or forged,
the seal does not match. Unlike SPF, it survives message forwarding.
DMARC
The instruction
DMARC ties the two together and tells receivers what to do when they fail: nothing
(p=none), send it to spam (p=quarantine), or reject it
(p=reject). It also asks receivers to report back - and that reporting
address is what almost everyone leaves out.
How it works
Three steps, and you can stop after any of them
1. Check
Run the free check above. It reads what your domain publishes right now and tells
you which of the thirteen items pass, which need attention, and which genuinely do
not apply to you.
2. Collect
Point your DMARC reporting address at us. Mail providers worldwide start sending
daily reports on every message that claimed to be from your domain. We parse them
and show you the senders, not the XML.
3. Enforce
Once the reports show your legitimate mail passing, move the policy to quarantine
and then reject. We tell you when the evidence says it is safe - and enforcement is
never applied automatically without you approving it.
Why this keeps happening
A DMARC record with no reporting address does nothing
It is the most common finding we see: a domain publishes
v=DMARC1; p=none; and stops there. It looks configured. It reports to
nobody, enforces nothing, and blocks no forgery. The domain owner believes they are
covered.
Adding a reporting address changes nothing about how your mail is delivered - it
cannot break anything - and it is the only way to find out what is being sent in
your name.
What a real report tells you
Every IP address that sent mail claiming to be your domain.
Whether each one passed SPF, DKIM, both, or neither.
Which country and network it came from.
How much of your mail a new sending service is quietly responsible for.
Whether a sender you have never heard of has been at it for weeks.
Start with the check. It costs nothing and takes seconds.
No signup, no credit card, no agent to install. If the result is clean, you have lost a minute. If it is not, you have found something worth knowing.