How it works
No black box. Here’s exactly what happens when you check.
Every email you send goes through three trust checks before anyone reads it. SenderCheck looks at the settings those checks depend on, tells you what’s wrong in plain English, and helps you fix it, without sending anything, changing anything, or guessing.
What happens when you check
Step 1
We look up your public settings
Your domain publishes a handful of settings that anyone can read, the same ones Gmail and Outlook read before trusting your email. We read them. That's all.
Step 2
We compare them with the rules
Each setting is checked against the published standards receivers follow. It's exact, like checking a sum: a setting is either right or it isn't.
Step 3
We explain it in plain English
Each problem comes with what it means for your business, how urgent it is, and how long the fix takes, not just a technical code.
Step 4
We walk you through the fix
Step-by-step instructions for wherever your domain is managed, with the exact values to copy. Then you check again to confirm it worked.
What we never do
We never send email from your domain
Nothing is sent to your mail server and no test message is delivered.
We never change your settings
We only read what's public. Every change is made by you, in your own account.
We never guess what's wrong
No AI decides your results. Every finding comes from code that reads a setting and applies the rule, and that code is tested.
We never promise the inbox
Correct settings are the part you control. What you send and each receiver's filters matter too.
How we decide what’s urgent
Urgency depends on what a problem breaks, not how unusual it is. The score at the top of your results sums up the problems beneath it: it isn’t a prediction, and we never present it as one.
- Fix first
It's breaking email today: for example, two lists of approved senders, which makes every email fail the check.
- Worth fixing
Nothing is broken yet, but you're exposed: for example, fake emails in your name are still delivered.
- Small improvement
It works today and is a maintenance item: for example, an older, shorter digital seal.
When we’re sure, and when we’re not
Most findings are facts we read directly: your list of approved senders has two entries, your digital seal is a certain strength. We say those plainly.
A few are educated guesses, and we label them that way. Spotting that you use Google Workspace from your mailbox settings is one: it’s usually right, but not always, so we show what we matched on. Digital seals are another: they live under names only your provider knows, so when we can’t find one we say “not found where we looked”, not “missing”.
What monitoring adds
The same check, repeated on a schedule, with each result compared to the last. You’re emailed when a problem appears, gets worse or is fixed, never when nothing has changed. Most breakage comes from someone else’s change, so the value is noticing without having to remember to look.
+ For the technically curious: exactly what we look up− Exactly what we look up
Every check reads public DNS. For a full report we resolve:
- MX records, and an A/AAAA lookup for each mail exchanger to confirm it resolves
- TXT at the domain for SPF, and every record reached through an include or redirect
- TXT at
_dmarc, plus the organisational domain for subdomains - TXT at
selector._domainkeyfor DKIM - TXT at
_mta-sts, and the MTA-STS policy file over HTTPS - TXT at
_smtp._tlsanddefault._bimi - NS records, to recognise where the domain’s settings are managed
The MTA-STS policy file is the only request that leaves DNS, because the standard puts it at a fixed HTTPS address. We don’t follow redirects when fetching it: the standard forbids that too. No language model takes part in producing findings; one may only ever rephrase a finished result, and can never add a finding, change its urgency, or invent a setting.