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
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.

@Aganim @Jerry Correct. DMARC alignment only requires a single thing to pass. A forwarded email or newsletter might fail SPF but pass DKIM, and that’s acceptable.

#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 arghh forgot to up date the IP address …. 🤬
Good tip

@Jerry No-email [inbound] domains should also set a "null MX", per RFC7505:

https://www.rfc-editor.org/rfc/rfc7505.html

MX 0 "."

RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail

@tychotithonus @Jerry
Important: the preference number should be 0.

RFC 7505 indicates "no-email" inbound; it's a way for your domain to tell the rest of the world that it does not accept any email from outside.

Don't use it on a domain that's supposed to be hosting the email address in a DMARC 'rua' value.

@dec23k

Oof, finger-memory typo - will fix, good catch

@Jerry

@tychotithonus @Jerry
It will probably work OK with 10 - that's supposed to be a relative number, for when there's more than one MX record and a "main MX / backup MX" disposition is desired.

As with line numbers in BASIC, the default is 10 to allow for numbers to be added above and below.

The important part is the null host (single dot).
But I wouldn't want to rely on every other mail server interpreting that correctly.

@dec23k @tychotithonus
My DNS provider doesn't allow just a dot. Many don't. But saying nobody is allowed to send emails for me (SPF record) should cover it.
@Jerry @tychotithonus
The last time I tried it on Cloudflare (more than a year ago) they didn't support it.
But I moved away from them so _/shrug\_
@dec23k @Jerry
For others, could be worth opening a ticket with providers for it, mentioning the RFC. And probably other platforms don't support it. Gotta blaze the trail. 😁
Very good tip! Thank you.
@Jerry thanks for sharing this. It was boosted into my neck of the woods and I don’t actually know who you are - is there a semi-authoritative place this advice is documented that I can 1) double check, because that seems like a good idea at least in principle with security related stuff like this and 2) pass on to others?

@simrob @Jerry If it helps, I can say it's correct, too, but you don't know who I am either. The second TXT record needs to be on the "_dmarc" record though, not the top level.

Without reading the RFCs, you can verify with generator sites, e.g. search for "spf generator" (top for me comes up as the one on mxtoolbox.com, any should do). Put in your domain and then say "No" to all the answers, and leave the mail servers blank and say it sould be "strict". It'll come up with the same records.

@mcnewton @simrob
Thanks for this. I should have posted the record names. Thanks for adding this!

Yep, "@" as the name of the spf record, and "_dmarc" for the name of the dmarc record.

@Jerry Last I knew, my roommate who ran a homebrew server was frustrated that they *can't* run an email server because outgoing email was assumed to be spam anyway. It would be nice if there were an actual way out of this!

@pteryx I set up my own email server on DigitalOcean and instantly got blacklisted by Spamhaus because it was a new domain, and then by another company because the IP address belonged to DigitalOcean.

Most mail servers also flagged it as spam because the domain was less than 60 days old and because it was a .online TLD. For a long time, some of my emails were immediately bounced back or went to spam folders because of all these reasons.

I also believe that every home IP address is automatically blacklisted, which makes it worse for your roommate.

You can eventually overcome it by letting the domain reputation slowly develop and then doing a direct appeal to the blacklist companies. But, it takes a long time.

It's amazing any spam gets delivered.

Some of that isn’t quite the case. I run an email server quite successfully on a residential IP, with no valid PTR. And I’ve added recent domains without getting them blocked.

I’m not sure if the age of my primary domain (20ish?) might translate to google etc trusting any other domains from the same IP and DKIM key perhaps. But I’ve literally never had to dispute a block, ever. From all the horror stories I read, apparently I’m a unicorn.

@ikidd @Jerry Until IP address has reverse record (PTR) matching to hostname in e-mail server's HELO, most major e-mail services will reject them.
@Jerry @pteryx Facebook bans my Selfhosted Server, frustrating. So I’m banned on all of Meta.
@Dero_10 @pteryx
I had that issue a lot when I was running a Linux server in the cloud. It's why I stopped using my own Wireguard VPN server I hosted on Digital Ocean. So many sites would block it.
@Jerry @pteryx
Some IP from DigitalOcean, or OVH make sometimes that the whole AS is considered suspicious.
I remember when I had a dedicated server at OVH, I needed many time to gain reputation. Also, may be the previous user for the IP trashed the reputation.
I also remember later, with a server at other place that I needed to ban the AS for several weeks to prevent flooding in log by trivial attacks.
Create good reputation need time. And, sometimes you need fill form (for Microsoft) with IP.
There is nothing admin-wise I hate more than dealing with email security. Fucking google is horrible. At least when Microsoft randomly decides the half dozen family members on my personal domain are bulk email spammers, there’s a form to reach out. Google is a piece of shit in this way just like in so many other ways.
@Jerry thanks for the advice!
Shouldn't the dmarc record be added, differently to SPF, to the subdomain of "_dmarc"?
@Jerry I've never been able to get SPF or DKIM to work properly, honestly. The DKIM information just never sends (using Postfix) and SPF checks don't pass anymore, no clue why. I just gave up at some point.
@amyipdev @Jerry I found it easiest to set up DKIM through amavisd-new – it was already set up for other stuff, so enabling DKIM just meant generating the keys and adding $enable_dkim_signing = 1; and dkim_key('simoncic.si', 'k1', '/etc/ssl/dkim/simoncic.si.pem');.
@jernej__s @Jerry hmm, might have to try that out - planning on restructuring my homelab soon so that could be a good opportunity

atm my main problem is that my homelab, being on residential internet, is on SBL because of my ISP (screw you charter!!) and I've yet to find a reasonable SMTP relay. should I ever find a relay, I'd need to re-set-up DMARC around that
@amyipdev @jernej__s
What I learned is that every single home IP address from every single ISP provider is pre-blacklisted by spamhaus and several others I came across. It's not your ISP's fault.
@Jerry @jernej__s it is my ISP's fault in this case because they provided spamhaus with the list themselves. I contacted Spamhaus about it and they were like "oh yeah normally we'd except you on request, but because your ISP listed it we can't"
@amyipdev @Jerry this is also inspiring me to try and fix my DKIM/SPF setup - I want to let some mailing lists that resend my mail as if it's from me to be allowed to do so, and then I can harden my DKIM settings to reject
@Jerry I needed to hear this
@Jerry sometimes I'm getting tons of mail.ru DMARC reports saying that someone has tried to send shittones of mail from my domain but SPF+DKIM stopped them
@Jerry OFC one should always configure domains properly...

@kkarhan @Jerry have domains that predate SPF, requirements unclear.

:p

@fennix @Jerry you can just add the TXT records with the DNS provider...

@kkarhan @Jerry

I'm aware, was mostly sarcasm about how no security was baked in in the first place.

These solutions are all hacked onto systems that themselves are unreliable and require additional security features to begin to trust.

Turtles all the way down, if you will.

There's an article at gov.uk also covering DKIM and null-records:
https://www.gov.uk/guidance/protect-domains-that-dont-send-email
@Jerry
Protect domains that do not send email

Make sure that domains that do not send email cannot be used for spoofing.

GOV.UK

@Xitnelat @Jerry Note that *._domainkey record is only meaningful when domain is not supposed to send e-mail.

When you have one or more servers, first part (before the dot) must contain name of server set in e-mail server config. Default usually is mail, thus mail._domainkey. But if you have more than one server authorized to send on behalf of domain, there must be separate records with unique names that also must be set on corresponding mail daemons, since these servers will have their own set of DKIM keys 

@Jerry
#email
If it helps anyone as an example of a domain w/o email, I have a domain 'hack-char.dev' that has those records configured. Never knew about the null mx, and will put one in today.

As a side note, I've seen someone try to spoof a different domain of mine and for some reason gmail sends a bounce to my domain, without rua set. I was wondering if it was an attempt to get a phish through in a bounce, but I don't see how that would be successful.

@Jerry Saving this for later. I do run email from my personal domain, but adding spf for a little extra insurance is a good idea.

@Jerry The M3AAWG provides best practices for parked domains, including the recommendation to implement a wildcard DKIM record.

*._domainkey.example.com TXT “v=DKIM1; p=”

https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf

@Jerry Thanks for posting this. I never think about this, but I do have several domains and I need to make sure I have the proper DNS records for the new email security stuff. (I date from the days when all you had to worry about were MX records, but I realize we've moved on from that.)

@Jerry Great post, as a reminder! I work on this at work, but haven't paid the same attention to my own personal domains.

And just a slight FYI, the SPF TXT record does indeed need to be on the apex/root domain, which, yes, some DNS providers use “@“ as a placeholder for, but that's not what “it is called”. Others, like AWS Route53, don't use that nomenclature. R53 writes out the apex/base domain, e.g. “example.com”, to indicate the apex/root domain.

@Jerry great advice. One question: does this config protect also subdomains?

@esplovago
Yep.

If you want to have different rules for subdomains, then the records get much more complicated. but "v=spf1 -all" pertains to the domain and subdomains.

@Jerry

My domain is older than Google and has had SPF, DKIM and DMARC since each was just exiting proposal stages, yet Google and O365 each see fit to block mail from my MTA (yet I regularly receive spam from each): the 900lb gorillas don't actually care about spam; more that they want everyone to stop self-hosting.
@Jerry wow thanks, this is useful
@Jerry There’s also a null MX record for the sake of completeness https://serverfault.com/questions/714052/why-is-rfc-7505-null-mx-necessary
Why is RFC 7505 (Null MX) necessary?

IETF RFC 7505 describes MX records for a domain/host that explicitly should not receive email. This is accomplished by pointing the MX at the Domain Name System root. For example, nomail.example.c...

Server Fault
@momo
Yep, people have mentioned it. I went back to try it and discovered my ISP does not allow a null MX record to be added. If it can be done, it's great, but an SPF that says nobody can send email should do the trick. If you could do, that's better.

@Jerry would adding those txt records cause any issue to a wildcard redirect I use for myself?

I have xxxxx.com and an auto redirect by my dns provider so that anything sent to [email protected] is forwarded to [email protected] so when I give out the address I can see if it's been shared.

I like the idea of protecting against unauthorized use but wouldn't want to lose my throwaway capability.

I find email servers to be akin to dark arts so am at a loss here tbh.

@b3lt3r I'm far from an expert, but if your redirect is at the server, and your server adds a ".forward" to the email, and does not alter anything, you should be fine because your SPF and DKIM should pass.

If your redirect is via an email client, or the server doesn't add a .forward, it may alter the email slightly, but in a way sufficient for DKIM to fail because the hash won't match any longer. But, I think in this case, if SPF passes, your email client would still accept it since the original DKIM passed before the forwarding.

It gets really complicated. Suggest you try it.

And this is based on my understanding, which, who knows?

@Jerry ok - I'll try it on a less critical domain first, thank you.

I run most of my own services from here to avoid any cloud usage but the one thing I do not dare to host is email - I can't see any refinement in configuration/management has happened since the '70s :-)

@Jerry is @ even legal in DNS? (It is not in hostnames, but so is _, so…)
@mirabilos In some records it is, and even required. It means the "root" or no sub domain name.