Hi there, first time poster here. Hoping someone can help.
I use my domain for email mostly, I don’t have a website (yet), and I’ve been using an iCloud custom email domain to host my emails.
Slightly paranoid I’m not receiving emails, or that mine are being flagged as spam, but aside from that I’ve not had any problems.
Today though I received an email, addressed to me from me saying I’d been hacked and demanding a not insignificant amount of bitcoins or else I’d be publicly shamed etc etc.
I don’t think for a second I’ve been hacked, but looking over the headers etc it really looks like the email came from my account.
DMARC, DKIM, SPF are all set up (and passed according to scammers headers), but obviously I’m missing something.
Is there some kind of validating DNS record I could publish publicly to verify I am the genuine domain owner so I can distance myself from the blackmailing lowlife that’s using my name and email, and ideally prevent anyone but me using my domain?
Generally you cannot prevent A from receiving/accepting an e-mail from B, even if B is claiming to be you (X). You’re just not part of the equation here
The only possibility is with DMARC, which you already use, as this will tell A to reject e-mails claiming to be from you but coming from somewhere else. But some recipients use DMARC as a “suggestion” or “score” even if you have "p=reject’ in there.
So no real solution, AFAIK. You have to live with the fact that people can fake any (your) identity, but also with the fact that most (sensible) recipients (software and/or human) will notice that something is not right with the e-mail (like SPF/DMARC, or merely based on the actual content of the message, etc.)
So your MX points at these two: mx01.mail.icloud.com and mx02.mail.icloud.com.
Your SPFTXT record looks like this: v=spf1 redirect=icloud.com
And you have a DKIM record like this: sig1._domainkeyCNAMEsig1.dkim.example.com.at.icloudmailadmin.com
You also created a DMARC record of some kind, perhaps: v=DMARC1; p=reject; adkim=s; aspf=s;
The only control you really have here is ensuring that the DMARC policy is as agressive as possible. The example above is pretty agressive, and should only be deployed along with some reporting service
In order for your DMARC policy to be effective at stopping these types of forgeries, your receiving MTA needs to evaluate your DMARC policy and handle the message accordingly. Assuming all of your published records are correct, the issue lies with how your email provider handles (or likely in this case, fails to handle) DMARC results.
My edge MTA is a hosted spam filtering service that treats all REJECT DMARC policies as QUARANTINE, so I see type of forgeries in my hosted spam quarantine on a regular basis. The spam filtering service does a good job at labeling them as Fraud, and does have controls in place to prevent their inadvertent release from quarantine by end users, so despite the failure to properly adhere to the published DMARC policy, it is still an effective spam filtering solution.