Important reminder, if you own a domain name and don't use it for sending email.
There is nothing to stop scammers from sending email claiming to be coming from your domain. And the older it gets, the more valuable it is for spoofing. It could eventually damage your domain's reputation and maybe get it blacklisted, unless you take the steps to notify email servers that any email received claiming to come from your domain should be trashed.
Just add these two TXT records to the DNS for your domain:
TXT v=spf1 -all
TXT v=DMARC1; p=reject;
The first says there is not a single SMTP server on earth authorized to send email on behalf of your domain. The second says that any email that says otherwise should be trashed.
If you do use your domain for sending email, be sure to add 3 records:
SPF record to indicate which SMTP server(s) are allowed to send your email.
DKIM records to add a digital signature to emails, allowing the receiving server to verify the sender and ensure message integrity.
DMARC record that tells the receiving email server how to handle email that fails either check.
You cannot stop scammers from sending email claiming to be from your domain, any more than you can prevent people from using your home address as a return address on a mailed letter. But, you can protect both your domain and intended scam victims by adding appropriate DNS records.
UPDATE: The spf and the dmarc records need to be appropriately named. The spf record should be named "@", and the dmarc record name should be "_dmarc".
Here's what I have for one domain.
One difference that I have is that I'm requesting that email providers email me a weekly aggregated report when they encounter a spoof. gmail and Microsoft send them, but most providers won't, but since most email goes to Gmail, it's enlightening when they come.
#cybersecurity #email #DomainSpoofing #EmailSecurity #phishing
![Message posted on the GitHub issue titled "Manual key verification":
"This issue has been opened for more than 6 years now, with no clear roadmap or even real consideration from the Tuta team. I have to say, I am disappointed.
You keep saying that "[...] Tuta [is] the most secure email service on the market.", but without key verification, a malicious Tuta server can read the end-to-end encrypted emails and shared calendars exchanged on the platform as there is no way to verify the recipients' public key. As explained by @llebout, "all users of Tutanota must trust Tutanota to not provide forged keys and perform an MITM attack". This is a significant flaw in the technical design of the platform, and it does not seem to bother you.
In #198, it can be read that:
> We are aware of the issues with verification, new protocol will support verification, the work is underway
However, your post-quantum implementation has now landed but still no word on the key verification issue.
Could you please stand by what you have said from day 1, that you prioritise security and privacy, and establish a clear roadmap of the work already undertaken or to be done to fix the situation?
Thank you"](https://fedi.ml/photo/preview/640/595249 "Message posted on the GitHub issue titled \"Manual key verification\":
\"This issue has been opened for more than 6 years now, with no clear roadmap or even real consideration from the Tuta team. I have to say, I am disappointed.
You keep saying that \"[...] Tuta [is] the most secure email service on the market.\", but without key verification, a malicious Tuta server can read the end-to-end encrypted emails and shared calendars exchanged on the platform as there is no way to verify the recipients' public key. As explained by @llebout, \"all users of Tutanota must trust Tutanota to not provide forged keys and perform an MITM attack\". This is a significant flaw in the technical design of the platform, and it does not seem to bother you.
In #198, it can be read that:
> We are aware of the issues with verification, new protocol will support verification, the work is underway
However, your post-quantum implementation has now landed but still no word on the key verification issue.
Could you please stand by what you have said from day 1, that you prioritise security and privacy, and establish a clear roadmap of the work already undertaken or to be done to fix the situation?
Thank you\"")
