The sender says it is your bank. The name in your inbox says it is your bank. The advice you were given was to check the sender address, so you check it, and it says it is your bank.
None of that is evidence. The display name is free text the sender chooses, and the address beside it can be forged as easily as a return address on an envelope. Neither is checked by anything on its way to you.
The real check happens elsewhere. It is why some forgeries vanish and others land in your inbox looking perfect.
The check happens in DNS, before you see anything
A domain owner publishes records saying who is allowed to send mail as them. SPF lists the permitted servers. DMARC says what a receiving server should do when a message fails those checks — and that second one is where the teeth are.
A DMARC policy of reject asks receiving servers to throw forged mail away. A quarantine policy asks them to treat it as spam. No policy at all gives no instruction, leaving receiving servers to guess.
We looked up eight domains
5 of the 8 publish reject: DBS, PayPal, gov.sg, Google and NASA. Two — SingPost and GitHub — publish quarantine. DBS goes furthest of any of them, publishing v=spf1 -all, which says no server on earth is authorised to send mail for that name.
The eighth publishes none, which asks receivers for reports and instructs them to do nothing. That one is ours, and until this guide went looking it published nothing at all.
That last one was our own defect, and this guide is what found it
When we gathered these examples, recatools.com had an SPF record and no DMARC policy at all. A receiving server handed a message forged in our name had no instruction, and fell back on its own judgement — which for a small domain often means delivering it.
We left our own result in the table instead of fixing it first, because a guide on checking domains should not hide its own homework. We added the record on 11 August 2026 and updated this page to match.
It now reads p=none, which is the honest starting point and not a finish line. That policy collects reports and asks receivers to do nothing, so a forgery is still delivered. Moving to quarantine and then reject means first confirming from those reports that every legitimate sender passes — which is exactly the homework the five reject domains above have already done.
This underlines the point: every organisation in that table is competent, yet two of the eight still sit at quarantine rather than reject. Publishing a strict policy risks discarding legitimate mail from a service you forgot was sending on your behalf, which is why plenty of domains stop short.
So what can you actually check, as the person receiving it?
Very little of this is visible to you, and pretending otherwise is how bad advice spreads. You can, however, check three things.
Read the domain, right to left. The part immediately before the first single slash — or after the final @ — is the only part that identifies anyone. Everything to the left is decoration the sender controls.
Distrust the direction of travel. A message that arrives asking you to go somewhere and sign in is the pattern, regardless of how it looks. Reach the site the way you already know: a saved bookmark, or typing the name yourself.
Notice what authentication cannot tell you. A message can pass SPF and DMARC perfectly and still be a fraud. These checks confirm that a domain authorised the sender, not that the domain is honest or even the one you think it is. A lookalike domain passes its own checks with full marks, which we measured in our guide on what the padlock actually proves.
The sender name is free text and the address can be forged; the real check happens in DNS before the message reaches you, and you cannot see it. Five of the eight domains we looked up publish a policy asking receiving servers to reject forgeries outright, two ask for quarantine, and one publishes none, which collects reports but blocks nothing — that one is ours, and it published nothing at all until this guide measured it. As the recipient, read the domain right to left, treat any message that sends you somewhere to sign in as the pattern it is, and remember that passing authentication proves a domain authorised the sender rather than that the sender is honest. If you own a domain, the check is one lookup and the fix is one DNS record.
Checking a domain yourself
Our DMARC and SPF checker reads these records for any domain and tells you what is published — it is built for domain owners auditing their own, but it works just as well for satisfying yourself about someone else's. The DNS lookup shows the raw records if you would rather read them directly, and the IP lookup resolves where a domain's servers actually are.
- All eight domains were queried with
digon 11 August 2026 and the records are quoted as published. The script is committed alongside this guide and can be pointed at any domain. - ⚠️ This inspects what a DOMAIN OWNER publishes. It does not inspect any message, and nothing here can tell you whether a specific email in your inbox passed or failed those checks — that result lives in the message headers your provider received, which this guide did not examine.
- ⚠️ DNS records change, and ours did. This guide first measured recatools.com as publishing no DMARC policy; the record was added on 11 August 2026 and the page was re-measured and updated. Every other policy above is what that domain published on the date we looked, and any could differ tomorrow.
- ⚠️ THE RE-MEASUREMENT EXPOSED A FLAW IN OUR OWN SCRIPT. It queried whatever resolver the machine happened to use, and a resolver that cached a negative answer before the record existed kept serving "no such record" for the full 30-minute negative TTL — reporting no policy for a domain that had one. It now queries a public resolver explicitly.
- ⚠️ A published policy is not a guarantee of delivery behaviour. Receiving servers decide what to honour, and a policy of reject is a request rather than an enforcement mechanism. We did not test whether any receiver actually complies.
This describes published email-authentication records and what they ask receiving servers to do. It is not a judgement about the security of any organisation named, several of which publish stricter policies than we do.
View author profile → · Editorial policy
