Important reminder, if you own a domain name and don't use it for sending email.

Jerry Lerman

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.

#cybersecurity #email #DomainSpoofing #EmailSecurity #phishing

[email protected]

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.

Royce Williams

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

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

(www.rfc-editor.org)

MX 0 "."

Rob Simmons

@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?

Pteryx the Puzzle Secretary

@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!

Amy (she/her/hers)

@[email protected] 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.

Jernej Simončič �

@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');.

Matthew Newton

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

Jerry Lerman

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

Jerry Lerman

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

Dec.tar.gz

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

Jerry Lerman

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

Freddie Leeman

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

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

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

Royce Williams

@dec23k

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

@Jerry

mkj

@Jerry A null MX is also a good idea for any domain name which is not used for email, though you (obviously) can't set a null MX on a domain used to receive email.

Indicating that a domain never legitimately originates email – Michael Kjörling

(michael.kjorling.se)

Leon Cowle

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

Sharon of the Strange Times

@Jerry I have this problem! But I also use my domain for sending post notifications via MailPoet. What are my options?

DJM (freelance for hire)

@Jerry If needed, here's a DMARC domain checker https://dmarcian.com/domain-checker/

esplovago :tux:

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

M.O.M.O.

@[email protected] There’s also a null MX record for the sake of completeness https://serverfault.com/questions/714052/why-is-rfc-7505-null-mx-necessary