Home
When it comes to spoofing email domains, there are several aspects to understand.
First, there is a massive difference between SPF, DKIM and ARC protections for Envelope/Return-Path addresses. Second, you need a well-configured DMARC record to prevent email contents address spoofing. And finally, preventing spoofing can be incredibly difficult to fix and may not be possible in some edge cases.
Domains missing DMARC records are the easiest to spoof. Receiving email servers do not check the From address in the email message contents if a DMARC is not present.
You can interrogate the record using dig.
$ dig _dmarc.*****.com TXT +short
If you do not receive a reply, then the domain is vulnerable. Note that SPF, DKIM and ARC do NOT prevent spoofing the From address in the email contents.
Missing DMARC records are also observable from the DMARC Checker output.
A small number of the domains scanned in this repository contain false positives. It's challenging and time-consuming to perform lookups exhaustively for subdomains — make sure to check the primary domain DMARC.
Even if a domain has a DMARC record, it does not mean that it's protected. There are many types of misconfigurations we've observed — and actively abuse.
DMARC records have policies that apply to primary domains and their associated subdomains. If policies aren't universally applied, one can be vulnerable, even if the other is not.
Policies are applied at a domain level with the p= attribute and subdomain with the sp= attribute. As previously mentioned, they can be different — although sp= defaults to the p= value if it is not present.
If there's a policy of p=none or sp=none, then spoof emails are explicitly permitted. The DMARC check will fail, but the receiving email server will follow the record and deliver the email to the target inbox.
$ dig _dmarc.*****.gov.uk TXT +short
"v=DMARC1;p=none"
The RFCs the government DMARC are strict with the naming and spelling of keywords and identifiers. However, we have observed records with incorrect spelling rendering the policies redundant.
$ dig _dmarc.*****.cat TXT +short
"v = DMARC1; p = cuarentena; rua = mailto: *****.cat; ruf = mailto: *****.cat; sp = cuarentena"
The percentage indicator is the final piece of the puzzle. It tells the receiving email server the percentage number of emails to apply against your DMARC policy.
By default — if pct= is not present — the number will be 100 or 100%. In other words, check all emails against your DMARC policy, which is a sensible default.
However, we've observed many DMARC records with an explicit pct=0 value, or less than 25%. You can read this value by deducting is from 100% to estimate your success rate.
If a record returns pct=1, 1% of emails get checked against DMARC policy specified via the p= field. The other 99% will get checked against the next most restrictive policy.
For example, if p=reject then 1% of emails will have the reject policy applied to them and the other 99% will have the quarantine policy applied. If p=quarantine then 1% of the emails will have the quarantine policy applied and the other 99% will have the none policy applied.
We typically only target percentage values of 25% or below. But anything below 100% with a policy of quarantine is vulnerable.
$ dig _dmarc.*****.gov TXT +short
"v=DMARC1; p=reject; pct=10; fo=1; ri=86400; rua=mailto:*****.gov,mailto:*****.gov,mailto:*****.gov,mailto:*****.email; ruf=mailto:*****.gov"
