Why this matters
Email was built without any way to prove who a message came from. These three DNS records are how you close that gap, and this page covers what they do and the questions people ask.
Why email can be forged at all
The name in the "From" line is simply text, and anyone can type anything into it. Nothing in the basic delivery of email checks that it matches where the message actually came from, so a scammer can send email that appears to come from your organisation and it will arrive looking entirely genuine.
The fix is a set of DNS records that let receivers check for themselves. SPF lists the servers allowed to send for your domain, and DKIM adds a signature. Neither one looks at the "From" line a reader actually sees, though, so a forged message can pass both and still show your name. DMARC is the record that closes the gap: it makes receivers compare the "From" line against the domain SPF or DKIM actually verified, and tells them what to do when the two don't match. That's also why an SPF record on its own won't stop this.
What that looks like in practice:
- An email to your donors, apparently from your director, asking them to give via a new link.
- An invoice to your finance person, apparently from a colleague, with changed bank details.
- A message to a partner organisation, apparently from your team, carrying malware.
Advocacy organisations make good targets for this. You handle donations, and your supporter and staff lists are often public.
The three records
SPF lists which servers are allowed to send email as your domain. DKIM adds a cryptographic signature, so a message can be proven to come from you and to be unaltered. DMARC ties the two together and tells receiving mail servers what to do when a message fails: nothing, send it to spam, or refuse it.
All three are public DNS records, and none of them cost anything.
The most common trap
Plenty of organisations have a DMARC record set to p=none and believe they're
protected. p=none only watches and reports, and blocks nothing at all. A record
can be present and still do nothing, so this check reports which policy a receiver would
actually apply rather than whether a record exists.
What to aim for
p=quarantine is the setting to reach — after monitoring with reports shows
your legitimate senders are covered. It tells the receiving mail server to put forged
messages in the recipient's spam folder, so the donor or colleague being targeted doesn't
find it in their inbox.
There is a stricter setting, p=reject, which has forged mail refused instead of
spam-foldered. It also refuses genuine mail that a mailing list relays from its own servers
while leaving your address in the From line, so if people at your organisation email
listservs, quarantine is the better place to stop.
Do you store my domain or my results?
No. The checks run in your own browser, querying public DNS directly, so the domain you enter never reaches us and no results are saved.
We do count page views. The domain is stripped out before anything is recorded, so we can see how many people used the check without seeing which organisations were checked.
It says DKIM couldn't be confirmed. Is that bad?
Usually not. DKIM keys are stored at an address containing a "selector" name chosen by your provider, and DNS gives no way to list what exists, only to look up an exact name. So we try the selectors the major providers use, and if yours uses an unusual one we can't see it. We report that as unconfirmed rather than missing.
When we say no DKIM key is published at all, that result is reliable.
I fixed it, but the check shows the old result
DNS changes take time to spread. A brand-new record is usually visible within an hour; a record you edited can keep showing its old value for as long as that record's previous TTL, which is sometimes a day. Wait a little and press Re-check.
Will this stop the spam I receive?
No. These records stop other people forging your domain when sending to others. They do nothing about junk or phishing arriving in your inbox — that is your provider's spam filtering, and a separate job.
Two-factor authentication is worth turning on, but it belongs to a third job again: it protects your accounts from being taken over, which is what happens after someone falls for a phishing email. It does not filter what arrives.
Why does mail from our mailing list fail?
A mailing list relays your message from its own servers while leaving your address in the From line, and most lists add a footer or tag the subject, which breaks your DKIM signature too. So the mail no longer proves it came from you. This is normal and expected, and it's the main reason to tighten DMARC in stages rather than all at once.
Can you fix it for us?
We're a small team and can't take on DNS administration for other organisations. The fix guides are written to be handed straight to whoever manages your website or email.
What we can and can't see
This check reads public DNS records, the same information any mail server in the world can look up. We never see your email and we can't see inside your systems. DNS alone has limits: we can confirm that a DKIM key is published, but not whether your outgoing mail is being signed with it.