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
DMARC record that tells the receiving email server how to handle email that fails either check.
Could be that I misunderstood you, but: It tells what to do if no mechanism (DKIM or SPF) results in a pass. DMARC actually only requires one mechanism to pass. So an email with a DKIM fail, but an SPF pass is considered OK. And vice-versa.
Edit: good advice by the way regarding protecting your domain reputation, I’ll check our non-email domains at work first thing tomorrow.
@Aganim@lemmy.world
I’m not an expert on this (it’s a career), but I know it’s not that simple.
If I get an unforwarded email, I definitely want both DKIM and SPF to pass. I want only email from an authorized server, and I want an email that is not modified and is properly signed. No exceptions. Both must pass.
If I get email from a mailing list that is sending email to me on behalf of a different domain, I want SPF to pass in that I want to know that the mailing list provider’s server is authorized to send email on behalf of the original domain. But, in this case, the original DKIM will fail because the mailing list provider will have changed the email. But, I expect the new DKIM to be correct, or I won’t accept it. So, here, a failure on the original DKIM can be acceptable.
If someone forwards an email to me, the original DKIM will fail. I will accept it. But, I want the SPF of the forwarding server to pass, and the new DKIM for the changed email to pass.
There’s also email redirection and forwards that happen at the server vs. the client and there can be separate rules for this.
The records can get complicated if you truly want to control different scenarios.
But, you don’t always want to accept an email if only 1 check passes.
At least, this is my understading of it all.
You are of course free to do with email what you want if you run your own email server. It’s simply that the DMARC RFC states that only one mechanism has to pass, so if you rely on your server’s DMARC implementation you won’t get what you want.
Edit: reworded a bit, I made it sound as if only one pass is allowed by DMARC.
This is overall best practices and overall correct (as in: you should probably do this, and it will never hurt), but realistically any domain that doesn’t at least have an SPF record will be already treated as unable to send mail at all by any properly configured receiving server, especially ones that would report you to a blocklist.
This isn’t bad advice regardless, just a bit redundant.
@Jerry@hear-me.social arghh forgot to up date the IP address …. 🤬
Good tip
@Jerry@hear-me.social No-email domains can also set a null MX:
https://www.rfc-editor.org/rfc/rfc7505.html
MX 10 “.”
Very good tip! Thank you.
