Why this is on a website monitoring tool at all
Because the client whose invoices get forged does not care that it was not technically a website problem. An agency that looks after a client's domain is the agency that gets the call, and "the mail records are outside our scope" is a sentence nobody wants to say that week.
It is also one of the cheapest things on the whole list to check and one of the cheapest to fix — a DNS record, not a code change — which makes it an unusually good item to find in a report.
SPF: the last two characters are the record
An SPF record lists the servers permitted to send mail for a domain. The part that decides anything is how it ends, because that is the instruction about everyone not on the list.
-all- Strict. Unlisted senders are refused. This is the setting that actually stops the forgery.
~all- Soft fail. The receiver is asked to accept the message and mark it as suspicious. In practice it usually lands, sometimes in the inbox.
?all- Neutral. The record states no opinion, which for a domain that sends invoices is close to publishing nothing at all.
- No ending at all
- A record that lists senders and never says what to do about the others. Published, and inert.
Glarion reports which of these a domain is on, in those words, rather than telling you "SPF: present".
DMARC: the policy is the whole point
SPF tells a receiving server how to judge a message. DMARC is what tells it to act on that judgement, and the p= value is the instruction.
p=reject- Forgeries are refused at the door.
p=quarantine- Forgeries are delivered to spam rather than the inbox.
p=none- Monitoring only. Reports are generated and the forged message is still delivered to the customer exactly as it would have been with no DMARC record at all.
- Published without a policy
- A DMARC record with no readable
p=. It looks like protection in an audit checklist and behaves like nothing.
p=none is the setting almost every domain is left on after somebody "set up DMARC". It is the correct first step — you want the reports before you start rejecting real mail — but it is a step, and a great many domains have been standing on it for years.
How to check a client's domain
Both records are public DNS entries. Every mail server on the internet reads them before accepting a message, so looking them up is not contacting the client's site, is not a scan, and needs no authorisation from anybody. Glarion's public check reads both alongside the certificate and the security headers, with no account.
What it will not do is tell you what to change them to. Tightening SPF on a domain that sends through a CRM, a helpdesk, an invoicing tool and a newsletter platform will bounce real mail if any of those is missing from the record, and that is a piece of work with a rollout rather than a setting to flip. The check tells you where the domain stands. Moving it is a job you scope.
Read next
- The free public checkCertificate, headers, cookies and public policy files too.
- Certificate expiry monitoringThe other finding that arrives with a deadline attached.
- Turning findings into a client reportHow to write this up so the client acts on it.