Trust
Your DMARC policy acts on forged email
trust.dmarc-policy-none
Why this matters
A DMARC policy of 'none' asks mailbox providers to report forgeries and then deliver them anyway. That is the right place to begin — the reports are how you find out which services legitimately send mail as you — but on its own it stops nothing. Most domains that publish DMARC never move past it, and monitoring is easily mistaken for protection.
Who fixes it
You can, usually
Roughly how long
A few weeks of reading reports, then a one-line DNS change. The waiting is the work.
Care needed
Test before and after
How to fix it
Read your DMARC reports until every legitimate sender is accounted for by SPF or DKIM — there is nearly always one you had forgotten, an old newsletter tool or a CRM. Then move the policy to `p=quarantine`, and to `p=reject` once quarantine is quiet. Do not go straight to `reject`: that is how a business stops its own invoices being delivered.
How we score it
Failing this check takes up to 8 points off your trust score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 106. Free, no account, and you see the evidence for each result.
Check my siteOther trust checks
- Browsers are allowed to fill in your formsSetting autocomplete to off tells the browser not to offer a visitor their own saved details. On a phone that turns a form somebody could have completed with one tap into a dozen fields typed with a thumb, and every extra field measurably costs completions. It is almost always inherited from a template or added years ago to stop a browser suggesting the wrong thing, and on a password field it is worse than useless: password managers ignore it, so the only people it stops are the ones typing by hand, who then choose something they can remember.
- Email cannot be forged from your domain (SPF)There is no record saying which servers are allowed to send email as you. That means someone can email your customers from your address, and it also means your own legitimate email is more likely to land in spam.
- Every form field has a labelA field whose only description is grey text inside the box loses that description the moment somebody starts typing. Anybody who is interrupted half way down a form comes back to a column of filled-in boxes with nothing saying what each one held, and a screen reader announces most of them as "edit text" and nothing else. A visible label also gives the field a bigger target, because tapping a label focuses the box it belongs to.
- Fields tell the browser what they are forAn autocomplete token tells the browser that a box wants an email address or a postcode, so it can offer the visitor the one they have saved. Without it the browser has to guess from the field's name, and it frequently guesses wrong or gives up. It is also a WCAG requirement at AA, because the same information lets assistive software present a field in terms somebody recognises.
- Forms submit over a secure connectionA form that posts to a plain HTTP address sends everything typed into it unencrypted, readable by anything between the visitor and your server. Browsers warn about it directly on the field when the form collects a password or payment details. A page can be served over HTTPS and still have a form that submits insecurely, which is why this is checked separately from the connection itself.
- Phone and email fields bring up the right keyboardA box expecting an email address should be marked as one. When it is not, a phone shows the ordinary letter keyboard rather than the one with the @ sign on it, and the browser does not check the address looks plausible before the form is sent. The same goes for a phone number, which should bring up the number pad. It is a single word in the markup and it is the most common reason a mobile enquiry form feels awkward to use.